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:
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.
..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.
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.
- 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.
