.. _arch_quick_start: A Quick Start ------------- In this tutorial, we will consider a simple but representative FPGA architecture to show you how to - Adapt a VPR architecture XML file to OpenFPGA acceptable format - Create an OpenFPGA architecture XML file to customize the primitive circuits - Create a simulation setting XML file to specify the simulation settings Through this quick example, we will introduce the key steps to build your own FPGA based on a VPR architecture template. .. note:: These tips are generic and fundamental to build any architecture file for OpenFPGA. Adapt VPR Architecture ~~~~~~~~~~~~~~~~~~~~~~ We start with the VPR architecture `template `_. This file models a homogeneous FPGA, as illustrated in :numref:`fig_k4n4_arch`. .. _fig_k4n4_arch: .. figure:: ./figures/k4n4_arch.png :scale: 100% K4N4 FPGA architecture A summary of the architectural features is as follows: - An array of tiles surrounded by a ring of I/O blocks - K4N4 Configurable Logic Block (CLB), which consists of four Basic Logic Elements (BLEs) and a fully-connected crossbar. Each BLE contains a 4-input Look-Up Table (LUT), a Flip-Flop (FF) and a 2:1 routing multiplexer - Length-1 routing wires interconnected by Wilton-Style Switch Block (SB) The VPR architecture description is designed for EDA needs mainly, which lacks the details physical modelingrequired by OpenFPGA. Here, we show a step-by-step adaption on the architecture template. Physical I/O Modeling ^^^^^^^^^^^^^^^^^^^^^ OpenFPGA requires a physical I/O block rather the abstract I/O modeling of VPR. The ```` under the ```` should be adapted to the following: .. code-block:: xml Note that, there are several major changes in the above codes, when compared to the original code. - We added a physical ``mode`` of I/O in addition to the original VPR I/O modeling, which is close to the physical implementation of an I/O cell. OpenFPGA will output fabric netlists base on the physical implementation rather than the operating modes. - We remove the ``clock`` port of I/O is actually a dangling port. - We specify that the phyical ``mode`` to be disabled for VPR packer by using ``packable=false``. This can help reduce packer's runtime. Since, we have added a new BLIF model ``subckt io`` to the architecture modeling, we should update the ```` XML node by adding a new I/O model. .. code-block:: xml Tileable Architecture ^^^^^^^^^^^^^^^^^^^^^ OpenFPGA does support fine-grained tile-based architecture as shown in :numref:`fig_k4n4_arch`. The tileable architecture leads to fast netlist generation as well as enables highly optimized physical designs through backend flow. To turn on the tileable architecture, the ``tileable`` property should be added to ```` node. .. code-block:: xml By enabling this, all the Switch Blocks and Connection Blocks will be generated as identical as possible. As a result, for any FPGA array size, there are only 9 unique tiles to be generated in netlists. See details in :cite:`XTang_FPT_2019`. Detailed guidelines can be found at :ref:`addon_vpr_syntax`. Craft OpenFPGA Architecture ~~~~~~~~~~~~~~~~~~~~~~~~~~~ OpenFPGA needs another XML file which contains detailed modeling on the physical design of FPGA architecture. This is designed to minimize the modification on the original VPR architecture file, so that it can be reused. You may create an XML file `k4_n4_openfpga_arch.xml` and then add contents shown as follows. Overview on the Structure ^^^^^^^^^^^^^^^^^^^^^^^^^ An OpenFPGA architecture including the following parts. - Architecture modeling with a focus on circuit-level description - Configuration protocol definition - Annotation on the VPR architecture modules These parts are organized as follows in the XML file. .. code-block:: xml ... ... ... ... ... ... Technology Library Definition ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Technology information are all stored under the ```` node, which contains transistor-level information to build the FPGA. Here, we bind to the open-source ASU Predictive Technology Modeling (PTM) 45nm process library. See details in :ref:`technology_library`. .. code-block:: xml .. note:: These information are important for FPGA-SPICE to correctly generate netlists. If you are not using FPGA-SPICE, you may provide a dummy technology library. Circuit Library Definition ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Circuit library is the crucial component of the architecture description, which contains a list of ````, each of which describes how a circuit is implemented for a FPGA component. Typically, we will defined a few atom ```` which are used to build primitive ````. .. code-block:: xml ... ... .. note:: Primitive ```` are the circuits which are directly used to build a FPGA component, such as Look-Up Table (LUT). Atom ```` are the circuits which are only used inside primitive ````. In this tutorial, we need the following atom ````, which are inverters, buffers and pass-gate logics. .. code-block:: xml 10e-12 10e-12 10e-12 10e-12 10e-12 10e-12 10e-12 5e-12 5e-12 10e-12 5e-12 5e-12 In this tutorial, we require the following primitive ````, which are routing multiplexers, Look-Up Tables, I/O cells in FPGA architecture (see :numref:`fig_k4n4_arch`). .. note:: We use different routing multiplexer circuits to maximum the performance by considering it fan-in and fan-out in the architecture context. .. note:: We specify that external Verilog netlists will be used for the circuits of Flip-Flops (FFs) ``static_dff`` and ``sc_dff_compact``, as well as the circuit of I/O cell ``iopad``. Other circuit models will be auto-generated by OpenFPGA. .. code-block:: xml See details in :ref:`circuit_library` and :ref:`circuit_model_examples`. Annotation on VPR Architecture ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In this part, we bind the ```` defined in the circuit library to each FPGA component. We specify that the FPGA fabric will be configured through a chain of Flip-Flops (FFs), which is built with the ````. .. code-block:: xml For the routing architecture, we specify the ``circuit_model`` to be used as routing multiplexers inside Connection Blocks (CBs), Switch Blocks (SBs), and also the routing wires. .. code-block:: xml .. note:: For a correct binding, the name of connection block, switch block and routing segment should match the name definition in your VPR architecture description! For each ```` defined in the ```` of VPR architecture, we need to specify - The physical mode for any ```` that contains multiple ````. The name of the physical mode should match a mode name that is defined in the VPR architecture. For example: .. code-block:: xml - The circuit model used to implement any primitive ```` in physical modes. It is required to provide full hierarchy of the ``pb_type``. For example: .. code-block:: xml .. note:: Mode-selection bits should be provided as the default configuration for a configurable resource. In this example, an I/O cell has a configuration bit, as defined in the ````. We specify that by default, the configuration memory will be set to logic ``1``. - The physical ```` for any ```` in the operating modes (mode other than the physical mode). This is required to translate mapping results from operating modes to their physical modes, in order to generate bitstreams. It is required to provide full hierarchy of the ``pb_type``. For example, .. code-block:: xml .. note:: Mode-selection bits should be provided so as to configure the circuits to be functional as required by the operating mode. In this example, an I/O cell will be configured with a logic ``1`` when operating as an input pad. - The circuit model used to implement interconnecting modules. The interconnect name should match the definition in the VPR architecture file. For example, .. code-block:: xml .. note:: If not specified, each interconnect will be binded to its default ``circuit_model``. For example, the crossbar will be binded to the default multiplexer ````, if not specified here. .. note:: OpenFPGA automatically infers the type of circuit model required by each interconnect. The complete annotation is shown as follows: .. code-block:: xml See details in :ref:`annotate_vpr_arch`. Simulation Settings ~~~~~~~~~~~~~~~~~~~ OpenFPGA needs an XML file where detailed simulation settings are defined. The simulation settings contain critical parameters to build testbenches for verify the FPGA fabric. You may create an XML file `k4_n4_openfpga_simulation.xml` and then add contents shown as follows. The complete annotation is shown as follows: .. code-block:: xml The ```` is crucial to create clock signals in testbenches. .. note:: FPGA has two types of clocks, one is the operating clock which controls applications that mapped to FPGA fabric, while the other is the programming clock which controls the configuration protocol. In this example, we specify - the operating clock will follow the maximum frequency achieved by VPR routing results - the number of operating clock cycles to be used will follow the average signal activities of the RTL design that is mapped to the FPGA fabric. - the actual operating clock frequency will be relaxed (reduced) by 20% by considering the errors between VPR results and physical designs. - the programming clock frequency is fixed at 200MHz The ```` are the options for SPICE simulator. Here we specify - SPICE simulations will consider a 25 :math:`^\circ C` temperature. - SPICE simulation will output results in a compact way without details on node capacitances. - SPICE simulation will use ``0.1ps`` as the minimum time step. - SPICE simulation will consider fast algorithms to speed up runtime. The ```` are the options for SPICE simulator. Here we specify that for each testbench, we will consider two Monte-Carlo simulations to evaluate the impact of process variations. The ```` specify how the output signals will be measured for delay and power evaluation. Here we specify that - for slew calculation (used in power estimation), we consider from the 5% of the ``VDD`` to the 95% of the ``VDD`` for both rising and falling edges. - for delay calculation, we consider from the 50% of the ``VDD`` of input signal to the 50% of the ``VDD`` of output signals for both rising and falling edges. In the ````, we specify that ``20ps`` slew time will be applied to built clock waverforms in SPICE simulations. See details in :ref:`simulation_setting`.