riscv
/
OpenFPGA
mirror of https://github.com/lnis-uofu/OpenFPGA.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #176 from lnis-uofu/dev 

Documentation Formatting
This commit is contained in:
ganeshgore 2021-01-24 21:11:49 -07:00 committed by GitHub
parent df9df7c93c 815468ac65
commit 1ba7e0663f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
14 changed files with 648 additions and 458 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

149
docs/source/manual/arch_lang/fabric_key.rst
View File

@ -27,151 +27,4 @@ A fabric key can be achieved in the following ways:
File Format
```````````
A fabric key follows an XML format. As shown in the following XML code, the key file includes the organization of configurable blocks in the top-level FPGA fabric.
Configurable Region
^^^^^^^^^^^^^^^^^^^
The top-level FPGA fabric can consist of several configurable regions, where a region may contain one or multiple configurable blocks. Each configurable region can be configured independently and in parrallel.
.. option:: <region id="<int>"/>
- ``id`` indicates the unique id of a configurable region in the fabric.
.. warning:: The id must start from zero!
.. note:: The number of regions defined in the fabric key must be consistent with the number of regions defined in the configuration protocol of architecture description. (See details in :ref:`config_protocol`).
The following example shows how to define multiple configuration regions in the fabric key.
.. code-block:: xml
<fabric_key>
<region id="0">
<key id="0" name="grid_io_bottom" value="0" alias="grid_io_bottom_1__0_"/>
<key id="1" name="grid_io_right" value="0" alias="grid_io_right_2__1_"/>
<key id="2" name="sb_1__1_" value="0" alias="sb_1__1_"/>
</region>
<region id="1">
<key id="3" name="cbx_1__1_" value="0" alias="cbx_1__1_"/>
<key id="4" name="grid_io_top" value="0" alias="grid_io_top_1__2_"/>
<key id="5" name="sb_0__1_" value="0" alias="sb_0__1_"/>
</region>
<region id="2">
<key id="6" name="sb_0__0_" value="0" alias="sb_0__0_"/>
<key id="7" name="cby_0__1_" value="0" alias="cby_0__1_"/>
<key id="8" name="grid_io_left" value="0" alias="grid_io_left_0__1_"/>
</region>
<region id="3">
<key id="9" name="sb_1__0_" value="0" alias="sb_1__0_"/>
<key id="10" name="cbx_1__0_" value="0" alias="cbx_1__0_"/>
<key id="11" name="cby_1__1_" value="0" alias="cby_1__1_"/>
<key id="12" name="grid_clb" value="0" alias="grid_clb_1__1_"/>
</region>
</fabric_key>
Configurable Block
^^^^^^^^^^^^^^^^^^^
Each configurable block is defined as a key. There are two ways to define a key, either with alias or with name and value.
.. option:: <key id="<int>" alias="<string>" name="<string>" value="<int>"/>
- ``id`` indicates the sequence of the configurable memory block in the top-level FPGA fabric.
- ``name`` indicates the module name of the configurable memory block. This property becomes optional when ``alias`` is defined.
- ``value`` indicates the instance id of the configurable memory block in the top-level FPGA fabric. This property becomes optional when ``alias`` is defined.
- ``alias`` indicates the instance name of the configurable memory block in the top-level FPGA fabric. If a valid alias is specified, the ``name`` and ``value`` are not required.
.. warning:: For fast loading of fabric key, strongly recommend to use pairs ``name`` and ``alias`` or ``name`` and ``value`` in the fabric key file. Using only ``alias`` may cause long parsing time for fabric key.
The following is an example of a fabric key generate by OpenFPGA for a 2 :math:`\times` 2 FPGA.
This key contains only ``alias`` which is easy to craft.
.. code-block:: xml
<fabric_key>
<region id="0">
<key id="0" alias="sb_2__2_"/>
<key id="1" alias="grid_clb_2_2"/>
<key id="2" alias="sb_0__1_"/>
<key id="3" alias="cby_0__1_"/>
<key id="4" alias="grid_clb_2_1"/>
<key id="5" alias="grid_io_left_0_1"/>
<key id="6" alias="sb_1__0_"/>
<key id="7" alias="sb_1__1_"/>
<key id="8" alias="cbx_2__1_"/>
<key id="9" alias="cby_1__2_"/>
<key id="10" alias="grid_io_right_3_2"/>
<key id="11" alias="cbx_2__0_"/>
<key id="12" alias="cby_1__1_"/>
<key id="13" alias="grid_io_right_3_1"/>
<key id="14" alias="grid_io_bottom_1_0"/>
<key id="15" alias="cby_2__1_"/>
<key id="16" alias="sb_2__1_"/>
<key id="17" alias="cbx_1__0_"/>
<key id="18" alias="grid_clb_1_2"/>
<key id="19" alias="cbx_1__2_"/>
<key id="20" alias="cbx_2__2_"/>
<key id="21" alias="sb_2__0_"/>
<key id="22" alias="sb_1__2_"/>
<key id="23" alias="cby_0__2_"/>
<key id="24" alias="sb_0__0_"/>
<key id="25" alias="grid_clb_1_1"/>
<key id="26" alias="cby_2__2_"/>
<key id="27" alias="grid_io_top_2_3"/>
<key id="28" alias="sb_0__2_"/>
<key id="29" alias="grid_io_bottom_2_0"/>
<key id="30" alias="cbx_1__1_"/>
<key id="31" alias="grid_io_top_1_3"/>
<key id="32" alias="grid_io_left_0_2"/>
</region>
</fabric_key>
The following shows another example of a fabric key generate by OpenFPGA for a 2 :math:`\times` 2 FPGA.
This key contains only ``name`` and ``value`` which is fast to parse.
.. code-block:: xml
<fabric_key>
<region id="0">
<key id="0" name="sb_2__2_" value="0"/>
<key id="1" name="grid_clb" value="3"/>
<key id="2" name="sb_0__1_" value="0"/>
<key id="3" name="cby_0__1_" value="0"/>
<key id="4" name="grid_clb" value="2"/>
<key id="5" name="grid_io_left" value="0"/>
<key id="6" name="sb_1__0_" value="0"/>
<key id="7" name="sb_1__1_" value="0"/>
<key id="8" name="cbx_1__1_" value="1"/>
<key id="9" name="cby_1__1_" value="1"/>
<key id="10" name="grid_io_right" value="1"/>
<key id="11" name="cbx_1__0_" value="1"/>
<key id="12" name="cby_1__1_" value="0"/>
<key id="13" name="grid_io_right" value="0"/>
<key id="14" name="grid_io_bottom" value="0"/>
<key id="15" name="cby_2__1_" value="0"/>
<key id="16" name="sb_2__1_" value="0"/>
<key id="17" name="cbx_1__0_" value="0"/>
<key id="18" name="grid_clb" value="1"/>
<key id="19" name="cbx_1__2_" value="0"/>
<key id="20" name="cbx_1__2_" value="1"/>
<key id="21" name="sb_2__0_" value="0"/>
<key id="22" name="sb_1__2_" value="0"/>
<key id="23" name="cby_0__1_" value="1"/>
<key id="24" name="sb_0__0_" value="0"/>
<key id="25" name="grid_clb" value="0"/>
<key id="26" name="cby_2__1_" value="1"/>
<key id="27" name="grid_io_top" value="1"/>
<key id="28" name="sb_0__2_" value="0"/>
<key id="29" name="grid_io_bottom" value="1"/>
<key id="30" name="cbx_1__1_" value="0"/>
<key id="31" name="grid_io_top" value="0"/>
<key id="32" name="grid_io_left" value="1"/>
</region>
</fabric_key>
See details in :ref:`file_formats_fabric_key`

100
docs/source/manual/file_formats/architecture_bitstream.rst Normal file
View File

@ -0,0 +1,100 @@
.. _file_formats_architecture_bitstream:
Architecture Bitstream (.xml)
-----------------------------
OpenFPGA can output the generic bitstream to an XML format, which is easy to debug. As shown in the following XML code, configuration bits are organized block by block, where each block could be a LUT, a routing multiplexer `etc`. Each ``bitstream_block`` includes the following information:
- ``name`` represents the instance name which you can find in the fabric netlists
- ``hierarchy_level`` represents the depth of this block in the hierarchy of the FPGA fabric. It always starts from 0 as the root.
- ``hierarchy`` represents the location of this block in FPGA fabric.
The hierachy includes the full hierarchy of this block
- ``instance`` denotes the instance name which you can find in the fabric netlists
- ``level`` denotes the depth of the block in the hierarchy
- ``input_nets`` represents the path ids and net names that are mapped to the inputs of block. Unused inputs will be tagged as ``unmapped`` which is a reserved word of OpenFPGA. Path id corresponds the selected ``path_id`` in the ``<bitstream>`` node.
- ``output_nets`` represents the path ids and net names that are mapped to the outputs of block. Unused outputs will be tagged as ``unmapped`` which is a reserved word OpenFPGA.
- ``bitstream`` represents the configuration bits affiliated to this block.
- ``path_id`` denotes the index of inputs which is propagated to the output. Note that smallest valid index starts from zero. Only routing multiplexers have the path index. Unused routing multiplexer will not have a ``path_id`` of ``-1``, which allows bitstream assembler to freely find the best path in terms of Quality of Results (QoR). A used routing multiplexer should have a zero or positive ``path_id``.
- ``bit`` denotes a single configuration bit under this block. It contains \
- ``memory_port`` the memory port name which you can find in the fabric netlists by following the hierarchy.
- ``value`` a binary value which is the configuration bit assigned to the memory port.
.. code-block:: xml
<bitstream_block name="fpga_top" hierarchy_level="0">
<!-- Bitstream block of a 4-input Look-Up Table in a Configurable Logic Block (CLB) -->
<bitstream_block name="grid_clb_1_1" hierarchy_level="1">
<bitstream_block name="logical_tile_clb_mode_clb__0" hierarchy_level="2">
<bitstream_block name="logical_tile_clb_mode_default__fle_0" hierarchy_level="3">
<bitstream_block name="logical_tile_clb_mode_default__fle_mode_n1_lut4__ble4_0" hierarchy_level="4">
<bitstream_block name="logical_tile_clb_mode_default__fle_mode_n1_lut4__ble4_mode_default__lut4_0" hierarchy_level="5">
<bitstream_block name="lut4_config_latch_mem" hierarchy_level="6">
<hierarchy>
<instance level="0" name="fpga_top"/>
<instance level="1" name="grid_clb_1_1"/>
<instance level="2" name="logical_tile_clb_mode_clb__0"/>
<instance level="3" name="logical_tile_clb_mode_default__fle_0"/>
<instance level="4" name="logical_tile_clb_mode_default__fle_mode_n1_lut4__ble4_0"/>
<instance level="5" name="logical_tile_clb_mode_default__fle_mode_n1_lut4__ble4_mode_default__lut4_0"/>
<instance level="6" name="lut4_config_latch_mem"/>
</hierarchy>
<bitstream>
<bit memory_port="mem_out[0]" value="0"/>
<bit memory_port="mem_out[1]" value="0"/>
<bit memory_port="mem_out[2]" value="0"/>
<bit memory_port="mem_out[3]" value="0"/>
<bit memory_port="mem_out[4]" value="0"/>
<bit memory_port="mem_out[5]" value="0"/>
<bit memory_port="mem_out[6]" value="0"/>
<bit memory_port="mem_out[7]" value="0"/>
<bit memory_port="mem_out[8]" value="0"/>
<bit memory_port="mem_out[9]" value="0"/>
<bit memory_port="mem_out[10]" value="0"/>
<bit memory_port="mem_out[11]" value="0"/>
<bit memory_port="mem_out[12]" value="0"/>
<bit memory_port="mem_out[13]" value="0"/>
<bit memory_port="mem_out[14]" value="0"/>
<bit memory_port="mem_out[15]" value="0"/>
</bitstream>
</bitstream_block>
</bitstream_block>
</bitstream_block>
</bitstream_block>
</bitstream_block>
</bitstream_block>
<!-- More bitstream blocks -->
<!-- Bitstream block of a 2-input routing multiplexer in a Switch Block (SB) -->
<bitstream_block name="sb_0__2_" hierarchy_level="1">
<bitstream_block name="mem_right_track_0" hierarchy_level="2">
<hierarchy>
<instance level="0" name="fpga_top"/>
<instance level="1" name="sb_0__2_"/>
<instance level="2" name="mem_right_track_0"/>
</hierarchy>
<input_nets>
<path id="0" net_name="unmapped"/>
<path id="1" net_name="unmapped"/>
</input_nets>
<output_nets>
<path id="0" net_name="unmapped"/>
</output_nets>
<bitstream path_id="-1">
<bit memory_port="mem_out[0]" value="0"/>
<bit memory_port="mem_out[1]" value="0"/>
</bitstream>
</bitstream_block>
</bitstream_block>
</bitstream_block>

108
docs/source/manual/file_formats/fabric_bitstream.rst Normal file
View File

@ -0,0 +1,108 @@
.. _file_formats_fabric_bitstream:
Fabric-dependent Bitstream
--------------------------
.. _file_formats_fabric_bitstream_plain_text:
Plain text (.txt)
~~~~~~~~~~~~~~~~~
This file format is designed to be directly loaded to an FPGA fabric.
It does not include any comments but only bitstream.
The information depends on the type of configuration procotol.
.. option:: vanilla
A line consisting of ``0`` | ``1``
.. option:: scan_chain
A line consisting of ``0`` | ``1``
.. option:: memory_bank
Multiple lines will be included, each of which is organized as <address><space><bit>.
Note that due to the use of Bit-Line and Word-Line decoders, every two lines are paired.
The first line represents the Bit-Line address and configuration bit.
The second line represents the Word-Line address and configuration bit.
For example
.. code-block:: xml
<bitline_address> <bit_value>
<wordline_address> <bit_value>
<bitline_address> <bit_value>
<wordline_address> <bit_value>
...
<bitline_address> <bit_value>
<wordline_address> <bit_value>
.. option:: frame_based
Multiple lines will be included, each of which is organized as <address><space><bit>.
Note that the address may include don't care bit which is denoted as ``x``.
OpenFPGA automatically convert don't care bit to logic ``0`` when generating testbenches.
For example
.. code-block:: xml
<frame_address> <bit_value>
<frame_address> <bit_value>
...
<frame_address> <bit_value>
.. _file_formats_fabric_bitstream_xml:
XML (.xml)
~~~~~~~~~~
This file format is designed to generate testbenches using external tools, e.g., CocoTB.
In principle, the file consist a number of XML node ``<bit>``, each bit contains the following attributes:
- ``id``: The unique id of the configuration bit in the fabric bitstream.
- ``value``: The configuration bit value.
- ``path`` represents the location of this block in FPGA fabric, i.e., the full path in the hierarchy of FPGA fabric.
A quick example:
.. code-block:: xml
<bit id="0" value="1" path="fpga_top.grid_clb_1__2_.logical_tile_clb_mode_clb__0.mem_fle_9_in_5.mem_out[0]"/>
</bit>
Other information may depend on the type of configuration procotol.
.. option:: memory_bank
- ``bl``: Bit line address information
- ``wl``: Word line address information
A quick example:
.. code-block:: xml
<bit id="0" value="1" path="fpga_top.grid_clb_1__2_.logical_tile_clb_mode_clb__0.mem_fle_9_in_5.mem_out[0]"/>
<bl address="000000"/>
<wl address="000000"/>
</bit>
.. option:: frame_based
- ``frame``: frame address information
.. note:: Frame address may include don't care bit which is denoted as ``x``.
A quick example:
.. code-block:: xml
<bit id="0" value="1" path="fpga_top.grid_clb_1__2_.logical_tile_clb_mode_clb__0.mem_fle_9_in_5.mem_out[0]"/>
<frame address="0001000x00000x01"/>
</bit>

151
docs/source/manual/file_formats/fabric_key.rst Normal file
View File

@ -0,0 +1,151 @@
.. _file_formats_fabric_key:
Fabric Key (.xml)
~~~~~~~~~~~~~~~~~
A fabric key follows an XML format. As shown in the following XML code, the key file includes the organization of configurable blocks in the top-level FPGA fabric.
Configurable Region
^^^^^^^^^^^^^^^^^^^
The top-level FPGA fabric can consist of several configurable regions, where a region may contain one or multiple configurable blocks. Each configurable region can be configured independently and in parrallel.
.. option:: <region id="<int>"/>
- ``id`` indicates the unique id of a configurable region in the fabric.
.. warning:: The id must start from zero!
.. note:: The number of regions defined in the fabric key must be consistent with the number of regions defined in the configuration protocol of architecture description. (See details in :ref:`config_protocol`).
The following example shows how to define multiple configuration regions in the fabric key.
.. code-block:: xml
<fabric_key>
<region id="0">
<key id="0" name="grid_io_bottom" value="0" alias="grid_io_bottom_1__0_"/>
<key id="1" name="grid_io_right" value="0" alias="grid_io_right_2__1_"/>
<key id="2" name="sb_1__1_" value="0" alias="sb_1__1_"/>
</region>
<region id="1">
<key id="3" name="cbx_1__1_" value="0" alias="cbx_1__1_"/>
<key id="4" name="grid_io_top" value="0" alias="grid_io_top_1__2_"/>
<key id="5" name="sb_0__1_" value="0" alias="sb_0__1_"/>
</region>
<region id="2">
<key id="6" name="sb_0__0_" value="0" alias="sb_0__0_"/>
<key id="7" name="cby_0__1_" value="0" alias="cby_0__1_"/>
<key id="8" name="grid_io_left" value="0" alias="grid_io_left_0__1_"/>
</region>
<region id="3">
<key id="9" name="sb_1__0_" value="0" alias="sb_1__0_"/>
<key id="10" name="cbx_1__0_" value="0" alias="cbx_1__0_"/>
<key id="11" name="cby_1__1_" value="0" alias="cby_1__1_"/>
<key id="12" name="grid_clb" value="0" alias="grid_clb_1__1_"/>
</region>
</fabric_key>
Configurable Block
^^^^^^^^^^^^^^^^^^^
Each configurable block is defined as a key. There are two ways to define a key, either with alias or with name and value.
.. option:: <key id="<int>" alias="<string>" name="<string>" value="<int>"/>
- ``id`` indicates the sequence of the configurable memory block in the top-level FPGA fabric.
- ``name`` indicates the module name of the configurable memory block. This property becomes optional when ``alias`` is defined.
- ``value`` indicates the instance id of the configurable memory block in the top-level FPGA fabric. This property becomes optional when ``alias`` is defined.
- ``alias`` indicates the instance name of the configurable memory block in the top-level FPGA fabric. If a valid alias is specified, the ``name`` and ``value`` are not required.
.. warning:: For fast loading of fabric key, strongly recommend to use pairs ``name`` and ``alias`` or ``name`` and ``value`` in the fabric key file. Using only ``alias`` may cause long parsing time for fabric key.
The following is an example of a fabric key generate by OpenFPGA for a 2 :math:`\times` 2 FPGA.
This key contains only ``alias`` which is easy to craft.
.. code-block:: xml
<fabric_key>
<region id="0">
<key id="0" alias="sb_2__2_"/>
<key id="1" alias="grid_clb_2_2"/>
<key id="2" alias="sb_0__1_"/>
<key id="3" alias="cby_0__1_"/>
<key id="4" alias="grid_clb_2_1"/>
<key id="5" alias="grid_io_left_0_1"/>
<key id="6" alias="sb_1__0_"/>
<key id="7" alias="sb_1__1_"/>
<key id="8" alias="cbx_2__1_"/>
<key id="9" alias="cby_1__2_"/>
<key id="10" alias="grid_io_right_3_2"/>
<key id="11" alias="cbx_2__0_"/>
<key id="12" alias="cby_1__1_"/>
<key id="13" alias="grid_io_right_3_1"/>
<key id="14" alias="grid_io_bottom_1_0"/>
<key id="15" alias="cby_2__1_"/>
<key id="16" alias="sb_2__1_"/>
<key id="17" alias="cbx_1__0_"/>
<key id="18" alias="grid_clb_1_2"/>
<key id="19" alias="cbx_1__2_"/>
<key id="20" alias="cbx_2__2_"/>
<key id="21" alias="sb_2__0_"/>
<key id="22" alias="sb_1__2_"/>
<key id="23" alias="cby_0__2_"/>
<key id="24" alias="sb_0__0_"/>
<key id="25" alias="grid_clb_1_1"/>
<key id="26" alias="cby_2__2_"/>
<key id="27" alias="grid_io_top_2_3"/>
<key id="28" alias="sb_0__2_"/>
<key id="29" alias="grid_io_bottom_2_0"/>
<key id="30" alias="cbx_1__1_"/>
<key id="31" alias="grid_io_top_1_3"/>
<key id="32" alias="grid_io_left_0_2"/>
</region>
</fabric_key>
The following shows another example of a fabric key generate by OpenFPGA for a 2 :math:`\times` 2 FPGA.
This key contains only ``name`` and ``value`` which is fast to parse.
.. code-block:: xml
<fabric_key>
<region id="0">
<key id="0" name="sb_2__2_" value="0"/>
<key id="1" name="grid_clb" value="3"/>
<key id="2" name="sb_0__1_" value="0"/>
<key id="3" name="cby_0__1_" value="0"/>
<key id="4" name="grid_clb" value="2"/>
<key id="5" name="grid_io_left" value="0"/>
<key id="6" name="sb_1__0_" value="0"/>
<key id="7" name="sb_1__1_" value="0"/>
<key id="8" name="cbx_1__1_" value="1"/>
<key id="9" name="cby_1__1_" value="1"/>
<key id="10" name="grid_io_right" value="1"/>
<key id="11" name="cbx_1__0_" value="1"/>
<key id="12" name="cby_1__1_" value="0"/>
<key id="13" name="grid_io_right" value="0"/>
<key id="14" name="grid_io_bottom" value="0"/>
<key id="15" name="cby_2__1_" value="0"/>
<key id="16" name="sb_2__1_" value="0"/>
<key id="17" name="cbx_1__0_" value="0"/>
<key id="18" name="grid_clb" value="1"/>
<key id="19" name="cbx_1__2_" value="0"/>
<key id="20" name="cbx_1__2_" value="1"/>
<key id="21" name="sb_2__0_" value="0"/>
<key id="22" name="sb_1__2_" value="0"/>
<key id="23" name="cby_0__1_" value="1"/>
<key id="24" name="sb_0__0_" value="0"/>
<key id="25" name="grid_clb" value="0"/>
<key id="26" name="cby_2__1_" value="1"/>
<key id="27" name="grid_io_top" value="1"/>
<key id="28" name="sb_0__2_" value="0"/>
<key id="29" name="grid_io_bottom" value="1"/>
<key id="30" name="cbx_1__1_" value="0"/>
<key id="31" name="grid_io_top" value="0"/>
<key id="32" name="grid_io_left" value="1"/>
</region>
</fabric_key>

7
docs/source/manual/file_formats/index.rst
View File

@ -12,3 +12,10 @@ OpenFPGA widely uses XML format for interchangable files
pin_constraints_file
repack_design_constraints
architecture_bitstream
fabric_bitstream
fabric_key

4
docs/source/manual/file_formats/pin_constraints_file.rst
View File

@ -1,7 +1,7 @@
.. _file_format_pin_constraints_file:
Pin Constraints File
--------------------
Pin Constraints File (.xml)
---------------------------
The *Pin Constraints File* (PCF) aims to create pin binding between an implementation and an FPGA fabric

6
docs/source/manual/fpga_bitstream/repack_design_constraints.rst → docs/source/manual/file_formats/repack_design_constraints.rst
View File

@ -1,7 +1,7 @@
.. _fpga_bitstream_repack_design_constraints:
.. _file_formats_repack_design_constraints:
Repack Design Constraints
-------------------------
Repack Design Constraints (.xml)
--------------------------------
An example of design constraints is shown as follows.

93
docs/source/manual/fpga_bitstream/fabric_dependent_bitstream.rst
View File

@ -13,98 +13,9 @@ The fabric bitsteam can be outputted in different file format in terms of usage.
Plain Text File Format
```````````````````````
This file format is designed to be directly loaded to an FPGA fabric.
It does not include any comments but only bitstream.
The information depends on the type of configuration procotol.
.. option:: vanilla
A line consisting of ``0`` | ``1``
.. option:: scan_chain
A line consisting of ``0`` | ``1``
.. option:: memory_bank
Multiple lines will be included, each of which is organized as <address><space><bit>.
Note that due to the use of Bit-Line and Word-Line decoders, every two lines are paired.
The first line represents the Bit-Line address and configuration bit.
The second line represents the Word-Line address and configuration bit.
For example
.. code-block:: xml
<bitline_address> <bit_value>
<wordline_address> <bit_value>
<bitline_address> <bit_value>
<wordline_address> <bit_value>
...
<bitline_address> <bit_value>
<wordline_address> <bit_value>
.. option:: frame_based
Multiple lines will be included, each of which is organized as <address><space><bit>.
Note that the address may include don't care bit which is denoted as ``x``.
OpenFPGA automatically convert don't care bit to logic ``0`` when generating testbenches.
For example
.. code-block:: xml
<frame_address> <bit_value>
<frame_address> <bit_value>
...
<frame_address> <bit_value>
See details in :ref:`file_formats_fabric_bitstream_plain_text`
XML File Format
```````````````
This file format is designed to generate testbenches using external tools, e.g., CocoTB.
In principle, the file consist a number of XML node ``<bit>``, each bit contains the following attributes:
- ``id``: The unique id of the configuration bit in the fabric bitstream.
- ``value``: The configuration bit value.
- ``path`` represents the location of this block in FPGA fabric, i.e., the full path in the hierarchy of FPGA fabric.
A quick example:
.. code-block:: xml
<bit id="0" value="1" path="fpga_top.grid_clb_1__2_.logical_tile_clb_mode_clb__0.mem_fle_9_in_5.mem_out[0]"/>
</bit>
Other information may depend on the type of configuration procotol.
.. option:: memory_bank
- ``bl``: Bit line address information
- ``wl``: Word line address information
A quick example:
.. code-block:: xml
<bit id="0" value="1" path="fpga_top.grid_clb_1__2_.logical_tile_clb_mode_clb__0.mem_fle_9_in_5.mem_out[0]"/>
<bl address="000000"/>
<wl address="000000"/>
</bit>
.. option:: frame_based
- ``frame``: frame address information
.. note:: Frame address may include don't care bit which is denoted as ``x``.
A quick example:
.. code-block:: xml
<bit id="0" value="1" path="fpga_top.grid_clb_1__2_.logical_tile_clb_mode_clb__0.mem_fle_9_in_5.mem_out[0]"/>
<frame address="0001000x00000x01"/>
</bit>
See details in :ref:`file_formats_fabric_bitstream_xml`

95
docs/source/manual/fpga_bitstream/generic_bitstream.rst
View File

@ -18,97 +18,4 @@ This can be regarded as a raw bitstream used for
File Format
```````````
OpenFPGA can output the generic bitstream to an XML format, which is easy to debug. As shown in the following XML code, configuration bits are organized block by block, where each block could be a LUT, a routing multiplexer `etc`. Each ``bitstream_block`` includes the following information:
- ``name`` represents the instance name which you can find in the fabric netlists
- ``hierarchy_level`` represents the depth of this block in the hierarchy of the FPGA fabric. It always starts from 0 as the root.
- ``hierarchy`` represents the location of this block in FPGA fabric.
The hierachy includes the full hierarchy of this block
- ``instance`` denotes the instance name which you can find in the fabric netlists
- ``level`` denotes the depth of the block in the hierarchy
- ``input_nets`` represents the path ids and net names that are mapped to the inputs of block. Unused inputs will be tagged as ``unmapped`` which is a reserved word of OpenFPGA. Path id corresponds the selected ``path_id`` in the ``<bitstream>`` node.
- ``output_nets`` represents the path ids and net names that are mapped to the outputs of block. Unused outputs will be tagged as ``unmapped`` which is a reserved word OpenFPGA.
- ``bitstream`` represents the configuration bits affiliated to this block.
- ``path_id`` denotes the index of inputs which is propagated to the output. Note that smallest valid index starts from zero. Only routing multiplexers have the path index. Unused routing multiplexer will not have a ``path_id`` of ``-1``, which allows bitstream assembler to freely find the best path in terms of Quality of Results (QoR). A used routing multiplexer should have a zero or positive ``path_id``.
- ``bit`` denotes a single configuration bit under this block. It contains \
- ``memory_port`` the memory port name which you can find in the fabric netlists by following the hierarchy.
- ``value`` a binary value which is the configuration bit assigned to the memory port.
.. code-block:: xml
<bitstream_block name="fpga_top" hierarchy_level="0">
<!-- Bitstream block of a 4-input Look-Up Table in a Configurable Logic Block (CLB) -->
<bitstream_block name="grid_clb_1_1" hierarchy_level="1">
<bitstream_block name="logical_tile_clb_mode_clb__0" hierarchy_level="2">
<bitstream_block name="logical_tile_clb_mode_default__fle_0" hierarchy_level="3">
<bitstream_block name="logical_tile_clb_mode_default__fle_mode_n1_lut4__ble4_0" hierarchy_level="4">
<bitstream_block name="logical_tile_clb_mode_default__fle_mode_n1_lut4__ble4_mode_default__lut4_0" hierarchy_level="5">
<bitstream_block name="lut4_config_latch_mem" hierarchy_level="6">
<hierarchy>
<instance level="0" name="fpga_top"/>
<instance level="1" name="grid_clb_1_1"/>
<instance level="2" name="logical_tile_clb_mode_clb__0"/>
<instance level="3" name="logical_tile_clb_mode_default__fle_0"/>
<instance level="4" name="logical_tile_clb_mode_default__fle_mode_n1_lut4__ble4_0"/>
<instance level="5" name="logical_tile_clb_mode_default__fle_mode_n1_lut4__ble4_mode_default__lut4_0"/>
<instance level="6" name="lut4_config_latch_mem"/>
</hierarchy>
<bitstream>
<bit memory_port="mem_out[0]" value="0"/>
<bit memory_port="mem_out[1]" value="0"/>
<bit memory_port="mem_out[2]" value="0"/>
<bit memory_port="mem_out[3]" value="0"/>
<bit memory_port="mem_out[4]" value="0"/>
<bit memory_port="mem_out[5]" value="0"/>
<bit memory_port="mem_out[6]" value="0"/>
<bit memory_port="mem_out[7]" value="0"/>
<bit memory_port="mem_out[8]" value="0"/>
<bit memory_port="mem_out[9]" value="0"/>
<bit memory_port="mem_out[10]" value="0"/>
<bit memory_port="mem_out[11]" value="0"/>
<bit memory_port="mem_out[12]" value="0"/>
<bit memory_port="mem_out[13]" value="0"/>
<bit memory_port="mem_out[14]" value="0"/>
<bit memory_port="mem_out[15]" value="0"/>
</bitstream>
</bitstream_block>
</bitstream_block>
</bitstream_block>
</bitstream_block>
</bitstream_block>
</bitstream_block>
<!-- More bitstream blocks -->
<!-- Bitstream block of a 2-input routing multiplexer in a Switch Block (SB) -->
<bitstream_block name="sb_0__2_" hierarchy_level="1">
<bitstream_block name="mem_right_track_0" hierarchy_level="2">
<hierarchy>
<instance level="0" name="fpga_top"/>
<instance level="1" name="sb_0__2_"/>
<instance level="2" name="mem_right_track_0"/>
</hierarchy>
<input_nets>
<path id="0" net_name="unmapped"/>
<path id="1" net_name="unmapped"/>
</input_nets>
<output_nets>
<path id="0" net_name="unmapped"/>
</output_nets>
<bitstream path_id="-1">
<bit memory_port="mem_out[0]" value="0"/>
<bit memory_port="mem_out[1]" value="0"/>
</bitstream>
</bitstream_block>
</bitstream_block>
</bitstream_block>
See details in :ref:`file_formats_architecture_bitstream`

2
docs/source/manual/fpga_bitstream/index.rst
View File

@ -12,5 +12,3 @@ FPGA-Bitstream can generate two types of bitstreams:
generic_bitstream
fabric_dependent_bitstream
repack_design_constraints

55
docs/source/manual/openfpga_shell/openfpga_commands/fpga_bitstream_commands.rst
View File

@ -14,46 +14,61 @@ Repack's functionality are in the following aspects:
- It re-routes all the nets by considering the programmable interconnects in physical modes **only**.
.. note:: This must be done before bitstream generator and testbench generation. Strongly recommend it is done after all the fix-up have been applied
.. note:: This must be done before bitstream generator and testbench generation. Strongly recommend it is done after all the fix-up have been applied
.. option:: --design_constraints
Apply design constraints from an external file.
Normally, repack takes the net mapping from VPR packing and routing results.
Alternatively, repack can accept the design constraints, in particular, net remapping, from an XML-based design constraint description.
See details in :ref:`fpga_bitstream_repack_design_constraints`.
.. warning:: Design constraints are designed to help repacker to identify which clock net to be mapped to which pin, so that multi-clock benchmarks can be correctly implemented, in the case that VPR may not have sufficient vision on clock net mapping. **Try not to use design constraints to remap any other types of nets!!!**
.. option:: --verbose
Show verbose log
.. option:: --design_constraints
Apply design constraints from an external file.
Normally, repack takes the net mapping from VPR packing and routing results.
Alternatively, repack can accept the design constraints, in particular, net remapping, from an XML-based design constraint description.
See details in :ref:`file_formats_repack_design_constraints`.
.. warning:: Design constraints are designed to help repacker to identify which clock net to be mapped to which pin, so that multi-clock benchmarks can be correctly implemented, in the case that VPR may not have sufficient vision on clock net mapping. **Try not to use design constraints to remap any other types of nets!!!**
.. option:: --verbose
Show verbose log
build_architecture_bitstream
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Decode VPR implementing results to an fabric-independent bitstream database
- ``--read_file`` Read the fabric-independent bitstream from an XML file. When this is enabled, bitstream generation will NOT consider VPR results.
.. option:: --read_file <string>
- ``--write_file`` Output the fabric-independent bitstream to an XML file
Read the fabric-independent bitstream from an XML file. When this is enabled, bitstream generation will NOT consider VPR results. See details at :ref:`file_formats_architecture_bitstream`.
.. option:: --write_file <string>
Output the fabric-independent bitstream to an XML file. See details at :ref:`file_formats_architecture_bitstream`.
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
build_fabric_bitstream
~~~~~~~~~~~~~~~~~~~~~~
Build a sequence for every configuration bits in the bitstream database for a specific FPGA fabric
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
write_fabric_bitstream
~~~~~~~~~~~~~~~~~~~~~~
Output the fabric bitstream database to a specific file format
- ``--file`` or ``-f`` Output the fabric bitstream to an plain text file (only 0 or 1)
.. option:: --file <string> or -f <string>
- ``--format`` Specify the file format [``plain_text`` | ``xml``]. By default is ``plain_text``.
Output the fabric bitstream to an plain text file (only ``0`` or ``1``)
- ``--verbose`` Show verbose log
.. option:: --format <string>
Specify the file format [``plain_text`` | ``xml``]. By default is ``plain_text``.
See file formats in :ref:`file_formats_fabric_bitstream_xml` and :ref:`file_formats_fabric_bitstream_plain_text`.
.. option:: --verbose
Show verbose log

158
docs/source/manual/openfpga_shell/openfpga_commands/fpga_sdc_commands.rst
View File

@ -8,77 +8,127 @@ write_pnr_sdc
Write the SDC files for PnR backend
- ``--file`` or ``-f`` Specify the output directory for SDC files
- ``--hierarchical`` Output SDC files without full path in hierarchy
- ``--flatten_names`` Use flatten names (no wildcards) in SDC files
- ``--time_unit`` Specify a time unit to be used in SDC files. Acceptable values are string: ``as`` | ``fs`` | ``ps`` | ``ns`` | ``us`` | ``ms`` | ``ks`` | ``Ms``. By default, we will consider second (``s``).
- ``--output_hierarchy`` Output hierarchy of Multiple-Instance-Blocks(MIBs) to plain text file. This is applied to constrain timing for grids, Switch Blocks and Connection Blocks.
.. note:: Valid only when ``compress_routing`` is enabled in ``build_fabric``
- ``--constrain_global_port`` Constrain all the global ports of FPGA fabric.
- ``--constrain_non_clock_global_port`` Constrain all the non-clock global ports as clocks ports of FPGA fabric
.. note:: ``constrain_global_port`` will treat these global ports in Clock Tree Synthesis (CTS), in purpose of balancing the delay to each sink. Be carefull to enable ``constrain_non_clock_global_port``, this may significanly increase the runtime of CTS as it is supposed to be routed before any other nets. This may cause routing congestion as well.
- ``--constrain_grid`` Constrain all the grids of FPGA fabric
- ``--constrain_sb`` Constrain all the switch blocks of FPGA fabric
- ``--constrain_cb`` Constrain all the connection blocks of FPGA fabric
- ``--constrain_configurable_memory_outputs`` Constrain all the outputs of configurable memories of FPGA fabric
- ``--constrain_routing_multiplexer_outputs`` Constrain all the outputs of routing multiplexer of FPGA fabric
- ``--constrain_switch_block_outputs`` Constrain all the outputs of switch blocks of FPGA fabric
- ``--constrain_zero_delay_paths`` Constrain all the zero-delay paths in FPGA fabric
.. note:: Zero-delay path may cause errors in some PnR tools as it is considered illegal
.. option:: --file <string> or -f <string>
Specify the output directory for SDC files
For example, ``--file /temp/pnr_sdc``
.. option:: --hierarchical
Output SDC files without full path in hierarchy
.. option:: --flatten_names
Use flatten names (no wildcards) in SDC files
.. option:: --time_unit <string>
Specify a time unit to be used in SDC files. Acceptable values are string: ``as`` | ``fs`` | ``ps`` | ``ns`` | ``us`` | ``ms`` | ``ks`` | ``Ms``. By default, we will consider second (``s``).
.. option:: --output_hierarchy
Output hierarchy of Multiple-Instance-Blocks(MIBs) to plain text file. This is applied to constrain timing for grids, Switch Blocks and Connection Blocks.
.. note:: Valid only when ``compress_routing`` is enabled in ``build_fabric``
.. option:: --constrain_global_port
Constrain all the global ports of FPGA fabric.
.. option:: --constrain_non_clock_global_port
Constrain all the non-clock global ports as clocks ports of FPGA fabric
.. note:: ``constrain_global_port`` will treat these global ports in Clock Tree Synthesis (CTS), in purpose of balancing the delay to each sink. Be carefull to enable ``constrain_non_clock_global_port``, this may significanly increase the runtime of CTS as it is supposed to be routed before any other nets. This may cause routing congestion as well.
.. option:: --constrain_grid
Constrain all the grids of FPGA fabric
.. option:: --constrain_sb
Constrain all the switch blocks of FPGA fabric
.. option:: --constrain_cb
Constrain all the connection blocks of FPGA fabric
.. option:: --constrain_configurable_memory_outputs
Constrain all the outputs of configurable memories of FPGA fabric
.. option:: --constrain_routing_multiplexer_outputs
Constrain all the outputs of routing multiplexer of FPGA fabric
.. option:: --constrain_switch_block_outputs
Constrain all the outputs of switch blocks of FPGA fabric
.. option:: --constrain_zero_delay_paths
Constrain all the zero-delay paths in FPGA fabric
.. note:: Zero-delay path may cause errors in some PnR tools as it is considered illegal
.. option:: --verbose
Enable verbose output
- ``--verbose`` Enable verbose output
write_configuration_chain_sdc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Write the SDC file to constrain the timing for configuration chain. The timing constraints will always start from the first output (Q) of a Configuration Chain Flip-flop (CCFF) and ends at the inputs of the next CCFF in the chain. Note that Qb of CCFF will not be constrained!
- ``--file`` or ``-f`` Specify the output SDC file
- ``--time_unit`` Specify a time unit to be used in SDC files. Acceptable values are string: ``as`` | ``fs`` | ``ps`` | ``ns`` | ``us`` | ``ms`` | ``ks`` | ``Ms``. By default, we will consider second (``s``).
.. option:: --file <string> or -f <string>
- ``--max_delay`` Specify the maximum delay to be used. The timing value should follow the time unit defined in this command.
- ``--min_delay`` Specify the minimum delay to be used. The timing value should follow the time unit defined in this command.
.. note::
Only applicable when configuration chain is used as configuration protocol
Specify the output SDC file. For example, ``--file cc_chain.sdc``
.. option:: --time_unit <string>
Specify a time unit to be used in SDC files. Acceptable values are string: ``as`` | ``fs`` | ``ps`` | ``ns`` | ``us`` | ``ms`` | ``ks`` | ``Ms``. By default, we will consider second (``s``).
.. option:: --max_delay <float>
Specify the maximum delay to be used. The timing value should follow the time unit defined in this command.
.. option:: --min_delay <float>
Specify the minimum delay to be used. The timing value should follow the time unit defined in this command.
.. note:: Only applicable when configuration chain is used as configuration protocol
write_sdc_disable_timing_configure_ports
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Write the SDC file to disable timing for configure ports of programmable modules. The SDC aims to break the combinational loops across FPGAs and avoid false path timing to be visible to timing analyzers
- ``--file`` or ``-f`` Specify the output SDC file
- ``--flatten_names`` Use flatten names (no wildcards) in SDC files
- ``--verbose`` Show verbose log
.. option:: --file <string> or -f <string>
Specify the output SDC file. For example, ``--file disable_config_timing.sdc``.
.. option:: --flatten_names
Use flatten names (no wildcards) in SDC files
.. option:: --verbose
Show verbose log
write_analysis_sdc
~~~~~~~~~~~~~~~~~~
Write the SDC to run timing analysis for a mapped FPGA fabric
- ``--file`` or ``-f`` Specify the output directory for SDC files
- ``--flatten_names`` Use flatten names (no wildcards) in SDC files
.. option:: --file <string> or -f <string>
- ``--time_unit`` Specify a time unit to be used in SDC files. Acceptable values are string: ``as`` | ``fs`` | ``ps`` | ``ns`` | ``us`` | ``ms`` | ``ks`` | ``Ms``. By default, we will consider second (``s``).
Specify the output directory for SDC files. For example, ``--file counter_sta_analysis.sdc``
.. option:: --flatten_names
Use flatten names (no wildcards) in SDC files
.. option:: --time_unit <string>
Specify a time unit to be used in SDC files. Acceptable values are string: ``as`` | ``fs`` | ``ps`` | ``ns`` | ``us`` | ``ms`` | ``ks`` | ``Ms``. By default, we will consider second (``s``).

69
docs/source/manual/openfpga_shell/openfpga_commands/fpga_verilog_commands.rst
View File

@ -8,43 +8,78 @@ write_fabric_verilog
Write the Verilog netlist for FPGA fabric based on module graph
- ``--file`` or ``-f`` Specify the output directory for the Verilog netlists
.. option:: --file <string> or -f <string>
- ``--explicit_port_mapping`` Use explicit port mapping when writing the Verilog netlists
Specify the output directory for the Verilog netlists. For example, ``--file /temp/fabric_netlist/``
- ``--include_timing`` Output timing information to Verilog netlists for primitive modules
.. option:: --explicit_port_mapping
Use explicit port mapping when writing the Verilog netlists
.. option:: --include_timing
Output timing information to Verilog netlists for primitive modules
- ``--include_signal_init`` Output signal initialization to Verilog netlists for primitive modules
.. option:: --include_signal_init
- ``--support_icarus_simulator`` Output Verilog netlists with syntax that iVerilog simulatorcan accept
Output signal initialization to Verilog netlists for primitive modules
- ``--print_user_defined_template`` Output a template Verilog netlist for all the user-defined ``circuit models`` in :ref:`circuit_library`. This aims to help engineers to check what is the port sequence required by top-level Verilog netlists
.. option:: --support_icarus_simulator
Output Verilog netlists with syntax that iVerilog simulatorcan accept
- ``--verbose`` Show verbose log
.. option:: --print_user_defined_template
Output a template Verilog netlist for all the user-defined ``circuit models`` in :ref:`circuit_library`. This aims to help engineers to check what is the port sequence required by top-level Verilog netlists
.. option:: --verbose
Show verbose log
write_verilog_testbench
~~~~~~~~~~~~~~~~~~~~~~~
Write the Verilog testbench for FPGA fabric
- ``--file`` or ``-f`` The output directory for all the testbench netlists. We suggest the use of same output directory as fabric Verilog netlists
.. option:: --file <string> or -f <string>
The output directory for all the testbench netlists. We suggest the use of same output directory as fabric Verilog netlists. For example, ``--file /temp/testbench``
- ``--fabric_netlist_file_path`` Specify the fabric Verilog file if they are not in the same directory as the testbenches to be generated. If not specified, OpenFPGA will assume that the fabric netlists are the in the same directory as testbenches and assign default names.
.. option:: --fabric_netlist_file_path <string>
- ``--reference_benchmark_file_path`` Must specify the reference benchmark Verilog file if you want to output any testbenches
Specify the fabric Verilog file if they are not in the same directory as the testbenches to be generated. If not specified, OpenFPGA will assume that the fabric netlists are the in the same directory as testbenches and assign default names. For example, ``--file /temp/fabric/fabric_netlists.v``
- ``--pin_constraints_file`` specify the *Pin Constraints File* (PCF) if you want to custom stimulus in testbenches. Strongly recommend for multi-clock simulations. See detailed file format about :ref:`file_format_pin_constraints_file`.
.. option:: --reference_benchmark_file_path <string>
- ``--fast_configuration`` Enable fast configuration phase for the top-level testbench in order to reduce runtime of simulations. It is applicable to configuration chain, memory bank and frame-based configuration protocols. For configuration chain, when enabled, the zeros at the head of the bitstream will be skipped. For memory bank and frame-based, when enabled, all the zero configuration bits will be skipped. So ensure that your memory cells can be correctly reset to zero with a reset signal.
Must specify the reference benchmark Verilog file if you want to output any testbenches. For example, ``--reference_benchmark_file_path /temp/benchmark/counter_post_synthesis.v``
.. option:: --pin_constraints_file <string> or -pcf <string>
Specify the *Pin Constraints File* (PCF) if you want to custom stimulus in testbenches. For example, ``-pin_constraints_file pin_constraints.xml``
Strongly recommend for multi-clock simulations. See detailed file format about :ref:`file_format_pin_constraints_file`.
.. option:: --fast_configuration
Enable fast configuration phase for the top-level testbench in order to reduce runtime of simulations. It is applicable to configuration chain, memory bank and frame-based configuration protocols. For configuration chain, when enabled, the zeros at the head of the bitstream will be skipped. For memory bank and frame-based, when enabled, all the zero configuration bits will be skipped. So ensure that your memory cells can be correctly reset to zero with a reset signal.
.. note:: If both reset and set ports are defined in the circuit modeling for programming, OpenFPGA will pick the one that will bring largest benefit in speeding up configuration.
- ``--print_top_testbench`` Enable top-level testbench which is a full verification including programming circuit and core logic of FPGA
.. option:: --print_top_testbench
- ``--print_formal_verification_top_netlist`` Generate a top-level module which can be used in formal verification
Enable top-level testbench which is a full verification including programming circuit and core logic of FPGA
- ``--print_preconfig_top_testbench`` Enable pre-configured top-level testbench which is a fast verification skipping programming phase
.. option:: --print_formal_verification_top_netlist
- ``--print_simulation_ini`` Output an exchangeable simulation ini file, which is needed only when you need to interface different HDL simulators using openfpga flow-run scripts
Generate a top-level module which can be used in formal verification
- ``--explicit_port_mapping`` Use explicit port mapping when writing the Verilog netlists
.. option:: --print_preconfig_top_testbench
Enable pre-configured top-level testbench which is a fast verification skipping programming phase
.. option:: --print_simulation_ini <string>
Output an exchangeable simulation ini file, which is needed only when you need to interface different HDL simulators using openfpga flow-run scripts. For example, ``--print_simulation_ini /temp/testbench/sim.ini``
.. option:: --explicit_port_mapping
Use explicit port mapping when writing the Verilog netlists

109
docs/source/manual/openfpga_shell/openfpga_commands/setup_commands.rst
View File

@ -8,56 +8,83 @@ read_openfpga_arch
Read the XML file about architecture description (see details in :ref:`arch_generality`)
- ``--file`` or ``-f`` Specify the file name
.. option:: --file <string> or -f <string>
Specify the file name. For example, ``--file openfpga_arch.xml``
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
write_openfpga_arch
~~~~~~~~~~~~~~~~~~~
Write the OpenFPGA XML architecture file to a file
- ``--file`` or ``-f`` Specify the file name
.. option:: --file <string> or -f <string>
Specify the file name. For example, ``--file arch_echo.xml``
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
read_openfpga_simulation_setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Read the XML file about simulation settings (see details in :ref:`simulation_setting`)
- ``--file`` or ``-f`` Specify the file name
.. option:: --file <string> or -f <string>
Specify the file name. For example, ``--file auto_simulation_setting.xml``
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
write_openfpga_simulation_setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Write the OpenFPGA XML simulation settings to a file
- ``--file`` or ``-f`` Specify the file name
.. option:: --file <string> or -f <string>
Specify the file name. For example, ``--file auto_simulation_setting_echo.xml``
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
link_openfpga_arch
~~~~~~~~~~~~~~~~~~
Annotate the OpenFPGA architecture to VPR data base
- ``--activity_file`` Specify the signal activity file
.. option:: --activity_file <string>
- ``--sort_gsb_chan_node_in_edges`` Sort the edges for the routing tracks in General Switch Blocks (GSBs). Strongly recommand to turn this on for uniquifying the routing modules
Specify the signal activity file. For example, ``--activity_file counter.act``
- ``--verbose`` Show verbose log
.. option:: --sort_gsb_chan_node_in_edges
Sort the edges for the routing tracks in General Switch Blocks (GSBs). Strongly recommand to turn this on for uniquifying the routing modules
.. option:: --verbose
Show verbose log
write_gsb_to_xml
~~~~~~~~~~~~~~~~
Write the internal structure of General Switch Blocks (GSBs) across a FPGA fabric, including the interconnection between the nodes and node-level details, to XML files
- ``--file`` or ``-f`` Specify the output directory of the XML files. Each GSB will be written to an indepedent XML file
.. option:: --file <string> or -f <string>
- ``--verbose`` Show verbose log
Specify the output directory of the XML files. Each GSB will be written to an indepedent XML file
For example, ``--file /temp/gsb_output``
.. option:: --verbose
Show verbose log
.. note:: This command is used to help users to study the difference between GSBs
@ -69,9 +96,13 @@ check_netlist_naming_conflict
.. warning:: This command may be deprecated in future when it is merged to VPR upstream
- ``--fix`` Apply fix-up to the names that violate the syntax
.. option:: --fix
- ``--report <.xml>`` Report the naming fix-up to a log file
Apply fix-up to the names that violate the syntax
.. option:: --report <string>
Report the naming fix-up to an XML-based log file. For example, ``--report rename.xml``
pb_pin_fixup
~~~~~~~~~~~~
@ -81,7 +112,9 @@ pb_pin_fixup
.. warning:: This command may be deprecated in future when it is merged to VPR upstream
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
lut_truth_table_fixup
~~~~~~~~~~~~~~~~~~~~~
@ -90,7 +123,9 @@ lut_truth_table_fixup
.. warning:: This command may be deprecated in future when it is merged to VPR upstream
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
.. _cmd_build_fabric:
@ -99,21 +134,35 @@ build_fabric
Build the module graph.
- ``--compress_routing`` Enable compression on routing architecture modules. Strongly recommend this as it will minimize the number of routing modules to be outputted. It can reduce the netlist size significantly.
.. option:: --compress_routing
Enable compression on routing architecture modules. Strongly recommend this as it will minimize the number of routing modules to be outputted. It can reduce the netlist size significantly.
- ``--duplicate_grid_pin`` Enable pin duplication on grid modules. This is optional unless ultra-dense layout generation is needed
.. option:: --duplicate_grid_pin
- ``--load_fabric_key <xml_file>`` Load an external fabric key from an XML file.
Enable pin duplication on grid modules. This is optional unless ultra-dense layout generation is needed
- ``--generate_fabric_key`` Generate a fabric key in a random way
.. option:: --load_fabric_key <string>
- ``--write_fabric_key <xml_file>`` Output current fabric key to an XML file
Load an external fabric key from an XML file. For example, ``--load_fabric_key fpga_2x2.xml`` See details in :ref:`file_formats_fabric_key`.
- ``--frame_view`` Create only frame views of the module graph. When enabled, top-level module will not include any nets. This option is made for save runtime and memory.
.. option:: --generate_fabric_key
Generate a fabric key in a random way
.. option:: --write_fabric_key <string>.
Output current fabric key to an XML file. For example, ``--load_fabric_key fpga_2x2.xml`` See details in :ref:`file_formats_fabric_key`.
.. option:: --frame_view
Create only frame views of the module graph. When enabled, top-level module will not include any nets. This option is made for save runtime and memory.
.. warning:: Recommend to turn the option on when bitstream generation is the only purpose of the flow. Do not use it when you need generate netlists!
- ``--verbose`` Show verbose log
.. option:: --verbose
Show verbose log
.. note:: This is a must-run command before launching FPGA-Verilog, FPGA-Bitstream, FPGA-SDC and FPGA-SPICE
@ -122,10 +171,16 @@ write_fabric_hierarchy
Write the hierarchy of FPGA fabric graph to a plain-text file
- ``--file`` or ``-f`` Specify the file name to write the hierarchy.
.. option:: --file <string> or -f <string>
Specify the file name to write the hierarchy.
- ``--depth`` Specify at which depth of the fabric module graph should the writer stop outputting. The root module start from depth 0. For example, if you want a two-level hierarchy, you should specify depth as 1.
.. option:: --depth <int>
- ``--verbose`` Show verbose log
Specify at which depth of the fabric module graph should the writer stop outputting. The root module start from depth 0. For example, if you want a two-level hierarchy, you should specify depth as 1.
.. option:: --verbose
Show verbose log
.. note:: This file is designed for hierarchical PnR flow, which requires the tree of Multiple-Instanced-Blocks (MIBs).