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 ``<pb_type name="io">`` under the ``<complexblocklist>`` should be adapted to the following:
..code-block:: xml
<!-- Define I/O pads begin -->
<pb_type name="io">
<input name="outpad" num_pins="1"/>
<output name="inpad" num_pins="1"/>
<!-- A mode denotes the physical implementation of an I/O
This mode will not be used by packer but is mainly used for fabric verilog generation
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 ``<models>`` XML node by adding a new I/O model.
..code-block:: xml
<models>
<!-- A virtual model for I/O to be used in the physical mode of io block -->
<model name="io">
<input_ports>
<port name="outpad"/>
</input_ports>
<output_ports>
<port name="inpad"/>
</output_ports>
</model>
</models>
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 ``<layout>`` node.
..code-block:: xml
<layout tileable="true">
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.
..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 ``<circuit_model>``, each of which describes how a circuit is implemented for a FPGA component.
Typically, we will defined a few atom ``<circuit_model>`` which are used to build primitive ``<circuit_model>``.
..code-block:: xml
<circuit_library>
<!-- Atom circuit models begin-->
<circuit_model>
...
</circuit_model>
<!-- Atom circuit models end-->
<!-- Primitive circuit models begin -->
<circuit_model>
...
</circuit_model>
<!-- Primitive circuit models end -->
</circuit_library>
..note:: Primitive ``<circuit_model>`` are the circuits which are directly used to build a FPGA component, such as Look-Up Table (LUT). Atom ``<circuit_model>`` are the circuits which are only used inside primitive ``<circuit_model>``.
In this tutorial, we need the following atom ``<circuit_model>``, which are inverters, buffers and pass-gate logics.
<wire_param model_type="pi" R="0" C="0" num_level="1"/> <!-- model_type could be T, res_val cap_val should be defined -->
</circuit_model>
<!-- Atom circuit models end-->
In this tutorial, we require the following primitive ``<circuit_model>``, 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.
See details in :ref:`circuit_library` and :ref:`circuit_model_examples`.
Annotation on VPR Architecture
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In this part, we bind the ``<circuit_model>`` 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 ``<circuit_model name=sc_dff_compact>``.
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.
..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 ``<pb_type>`` defined in the ``<complexblocklist>`` of VPR architecture, we need to specify
- The physical mode for any ``<pb_type>`` that contains multiple ``<mode>``. The name of the physical mode should match a mode name that is defined in the VPR architecture. For example:
- The circuit model used to implement any primitive ``<pb_type>`` in physical modes. It is required to provide full hierarchy of the ``pb_type``. For example:
..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 ``<circuit_model name="iopad">``. We specify that by default, the configuration memory will be set to logic ``1``.
- The physical ``<pb_type>`` for any ``<pb_type>`` 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,
..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,
..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 ``<circuit_model name="mux_1level_tapbuf">``, 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
<pb_type_annotations>
<!-- physical pb_type binding in complex block IO -->
The ``<clock_setting>`` 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 ``<simulator_option>`` 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 ``<monte_carlo num_simulation_points="2"/>`` 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 ``<measurement_setting>`` 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 ``<stimulus>``, we specify that ``20ps`` slew time will be applied to built clock waverforms in SPICE simulations.
