mirror of https://github.com/openXC7/prjxray.git
Add description of architecture-specific database files to docs
This commit adds description of the following database files: - mask_*.db - ppips_*.db - segbits_*.db - site_type_*.db - tile_type_*.db Signed-off-by: Robert Winkler <rwinkler@antmicro.com>
This commit is contained in:
Robert Winkler
parent
1b296ea876
commit
e8ff146443
|
|
@ -0,0 +1,15 @@
|
|||
=============================
|
||||
Files Common for Architecture
|
||||
=============================
|
||||
|
||||
This section contains a description of :term:`database <database>` files
|
||||
that are common for a whole chip architecture.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
mask
|
||||
ppips
|
||||
segbits
|
||||
site_type
|
||||
tile_type
|
||||
|
|
@ -0,0 +1,104 @@
|
|||
==========
|
||||
mask files
|
||||
==========
|
||||
|
||||
The *mask files* are generated for every FPGA :term:`tile <tile>` type. They store
|
||||
the information, which bits in the bitstream can configure the given
|
||||
:term:`tile <tile>` type.
|
||||
|
||||
Naming convention
|
||||
-----------------
|
||||
|
||||
The naming scheme for the mask files is the following::
|
||||
|
||||
mask_<tile>.db
|
||||
|
||||
Note that auxiliary ``mask_<tile>.origin_info.db`` files
|
||||
provide additional information about the :term:`fuzzer <fuzzer>`,
|
||||
which produced the :term:`database <database>` file. This file is optional.
|
||||
|
||||
Every :term:`tile <tile>` is configured at least by one of three configurational
|
||||
buses mentioned in the :doc:`Configuration Section <../../architecture/configuration>`.
|
||||
The default bus is called ``CLB_IO_CLK``. If the :term:`tile <tile>` can also be
|
||||
configured by another bus it has additional ``mask_<tile>.<bus_name>.db``
|
||||
related to that bus.
|
||||
|
||||
In example:
|
||||
|
||||
- ``mask_dsp_r.db``
|
||||
- ``mask_bram_l.db`` (configured with default ``CLB_IO_CLK`` bus)
|
||||
- ``mask_bram_l.block_ram.db`` (configured with ``BLOCK_RAM`` bus)
|
||||
|
||||
File format
|
||||
-----------
|
||||
|
||||
The file consist of the records that describes configuration bits for
|
||||
the particular :term:`tile <tile>` type. Each entry inside the file is of the form::
|
||||
|
||||
bit <frame_address_offset>_<bit_position>
|
||||
|
||||
This means that the :term:`tile <tile>` can be configured by bit located in the
|
||||
:term:`frame <frame>` at the address ``<base_frame_addr> + <frame_address_offset>``,
|
||||
at position ``<tile_offset> + <bit_position>``. Information about ``<base_frame_address>``
|
||||
and ``<tile_offset>`` can be taken from part specific ``tilegrid.json`` file.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Below there is a part of artix7 ``mask_clbll_l.db`` file describing FPGA *CLBLL*
|
||||
:term:`tile <tile>`::
|
||||
|
||||
<...>
|
||||
bit 00_61
|
||||
bit 00_62
|
||||
bit_00_63
|
||||
bit 01_00
|
||||
bit 01_01
|
||||
bit 01_02
|
||||
<...>
|
||||
|
||||
The line ``bit 01_02`` means that the *CLBL_LL* :term:`tile <tile>` can be
|
||||
configured by the bit located in the :term:`frame <frame>` at the address
|
||||
``<base_frame_address> + 0x01``, at position ``<tile_offset> + 0x2``.
|
||||
|
||||
The ``tilegrid.json`` is a file specific to a given chip package.
|
||||
For *xc7a35tcpg236-1* we can find exemplary *CLBLL_L* entry::
|
||||
|
||||
"CLBLL_L_X2Y0": {
|
||||
"bits": {
|
||||
"CLB_IO_CLK": {
|
||||
"baseaddr": "0x00400100",
|
||||
"frames": 36,
|
||||
"offset": 0,
|
||||
"words": 2
|
||||
}
|
||||
},
|
||||
"clock_region": "X0Y0",
|
||||
"grid_x": 10,
|
||||
"grid_y": 155,
|
||||
"pin_functions": {},
|
||||
"sites": {
|
||||
"SLICE_X0Y0": "SLICEL",
|
||||
"SLICE_X1Y0": "SLICEL"
|
||||
},
|
||||
"type": "CLBLL_L"
|
||||
},
|
||||
|
||||
The ``<base_frame_addr>`` can be found as a argument of the *"baseaddr"* key
|
||||
and for *CLBLL_L_X2Y0* :term:`tile <tile>` it is equal to ``0x00400100``. The ``<tile_offset>``
|
||||
on the other hand is an argument of the *"offset"* key. Here it is equal to 0.
|
||||
|
||||
Finally, we are able to compute the bit location associated with the
|
||||
``bit 01_02`` entry.
|
||||
|
||||
The configuration bit for this record can be found in the following
|
||||
:term:`frame <frame>` address::
|
||||
|
||||
0x00400100 + 0x01 = 0x00400101
|
||||
|
||||
Located at the bit position::
|
||||
|
||||
0x0 + 0x2 = 0x2
|
||||
|
||||
More about the configuration process and the meaning of the :term:`frame <frame>`
|
||||
can be found in the :doc:`Configuration Section <../../architecture/configuration>`.
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
===========
|
||||
ppips files
|
||||
===========
|
||||
|
||||
The *ppips files* are generated for every FPGA :term:`tile <tile>` type.
|
||||
They store the information about the pseudo-PIPs, inside the tile.
|
||||
|
||||
Programable Interconnect point (:term:`PIP <pip>`) is a connection inside the
|
||||
:term:`tile <tile>` that can be enabled or disabled. Pseudo PIPs appears as standard
|
||||
:term:`PIPs <pip>` in the Vivado tool, but they do not have actual configuration
|
||||
bit pattern (they are not configurable).
|
||||
|
||||
Naming convention
|
||||
-----------------
|
||||
|
||||
The naming scheme for the PPIPs files is the following::
|
||||
|
||||
ppips_<tile>.db
|
||||
|
||||
In example:
|
||||
|
||||
- ``ppips_dsp_l.db``
|
||||
- ``ppips_clbll_l.db``
|
||||
- ``ppips_bram_int_interface_l.db``
|
||||
|
||||
File format
|
||||
-----------
|
||||
|
||||
The file contains one entry per pseudo-PIP, each with one of the following
|
||||
three tags: ``always``, ``default`` or ``hint``. The entries are of the form:::
|
||||
|
||||
<ppip_location> <tag>
|
||||
|
||||
The tag ``always`` is used for pseudo-PIPs that are actually always-on, i.e.,
|
||||
that are permanent connections between two wires.
|
||||
|
||||
The tag ``default`` is used for pseudo-PIPs that represent the default behavior
|
||||
if no other driver has been configured for the destination net
|
||||
(all default pseudo-PIPs connect to the VCC_WIRE net).
|
||||
|
||||
The tag ``hint`` is used for PIPs that are used by Vivado to tell the router
|
||||
that two logic slice outputs drive the same value, i.e., behave like they
|
||||
are connected as far as the routing process is concerned.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Below there is a part of artix7 ``ppips_clbll_l.db`` file::
|
||||
|
||||
<...>
|
||||
CLBLL_L.CLBLL_L_A.CLBLL_L_A6 hint
|
||||
CLBLL_L.CLBLL_L_AMUX.CLBLL_L_A hint
|
||||
CLBLL_L.CLBLL_L_AX.CLBLL_BYP0 always
|
||||
CLBLL_L.CLBLL_L_B.CLBLL_L_B1 hint
|
||||
CLBLL_L.CLBLL_L_B.CLBLL_L_B2 hint
|
||||
CLBLL_L.CLBLL_L_B.CLBLL_L_B3 hint
|
||||
CLBLL_L.CLBLL_L_B.CLBLL_L_B4 hint
|
||||
<...>
|
||||
|
||||
The ``<ppip_location>`` name is arbitrary. However, we named them in the convention
|
||||
similar to the Vivado tool, which allows us to identify them quickly and provides
|
||||
suggestions about their role in the FPGA chip.
|
||||
|
|
@ -0,0 +1,117 @@
|
|||
=============
|
||||
segbits files
|
||||
=============
|
||||
|
||||
The *segbits files* are generated for every FPGA :term:`tile <tile>` type.
|
||||
They store the information about the combinations of bits in the bitstream
|
||||
that are responsible for enabling different features inside the :term:`tile <tile>`.
|
||||
The features can be related to enabling some part of the primitive, setting some
|
||||
initial state of the block, configuring pin pull-up on output pins, etc.
|
||||
|
||||
Naming convention
|
||||
-----------------
|
||||
|
||||
The naming scheme for the segbits files is the following::
|
||||
|
||||
segbits_<tile>.db
|
||||
|
||||
Note that auxiliary ``segbits_<tile>.origin_info.db`` files
|
||||
provide additional information about the :term:`fuzzer <fuzzer>`, which produced the
|
||||
:term:`database <database>` file. This file is optional.
|
||||
|
||||
Every :term:`tile <tile>` is configured at least by one of three configurational buses
|
||||
mentioned in the :doc:`Configuration Section <../../architecture/configuration>`.
|
||||
The default bus is called ``CLB_IO_CLK``. If the :term:`tile <tile>` can also be configured
|
||||
by another bus, it has additional ``segbits_<tile>.<bus_name>.db``
|
||||
related to that bus.
|
||||
|
||||
|
||||
Exemplary files:
|
||||
|
||||
- ``segbits_dsp_r.db``
|
||||
- ``segbits_bram_l.db`` (configured with default ``CLB_IO_CLK`` bus)
|
||||
- ``segbits_bram_l.block_ram.db`` (configured with ``BLOCK_RAM`` bus)
|
||||
|
||||
File format
|
||||
-----------
|
||||
|
||||
The file consists of the lines, containing the information about the feature
|
||||
and the list of bits that should be enabled/disabled to provide the feature's
|
||||
functionality::
|
||||
|
||||
<feature> <bit_list>
|
||||
|
||||
where:
|
||||
|
||||
- ``<feature>`` is of the form ``<feature_name>.<feature_addr>``
|
||||
- ``<bit_list>`` is the list of bits. Each bit is of the form
|
||||
``<frame_address_offset>_<bit_possition>``. If the bit has the ``!``
|
||||
mark in front of it, that means it should be set to **0** for feature configuration,
|
||||
otherwise it should be set to **1**.
|
||||
|
||||
The names of the features are arbitrary. However, we named them in the convention,
|
||||
which allows us to identify them quickly and provides suggestions
|
||||
about the functionality that they provide. The feature names are used in the
|
||||
fasm files generation.
|
||||
|
||||
|
||||
Feature naming conventions
|
||||
--------------------------
|
||||
|
||||
PIPs
|
||||
^^^^
|
||||
|
||||
The ``<feature>`` names for interconnect :term:`PIPs <pip>` are stored in the
|
||||
``segbits_int_l.db`` and ``segbits_int_r.db`` database files. The features that
|
||||
enable interconnect :term:`PIPs <pip>` have the following syntax::
|
||||
|
||||
<tile_type>.<destination_wire>.<source_wire>.
|
||||
|
||||
For example, consider the following entry in ``segbits_int_l.db``::
|
||||
|
||||
INT_L.NL1BEG1.NN6END2 07_32 12_33
|
||||
|
||||
CLBs
|
||||
^^^^
|
||||
The ``<feature>`` names for CLB tiles use a dot-separated hierarchy.
|
||||
|
||||
For example::
|
||||
|
||||
CLBLL_L.SLICEL_X0.ALUT.INIT[00]
|
||||
|
||||
This entry documents the initialization bits the *LSB LUT* for the *ALUT* in
|
||||
the *SLICEL_X0* within a *CLBLL_L tile.*
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Below there is a part of ``segbits_liob33_l.db`` file for the *artix7*
|
||||
architecture. The file describes *CLBLL* :term:`tile <tile>`::
|
||||
|
||||
<...>
|
||||
LIOB33.IOB_Y0.IBUFDISABLE.I 38_82
|
||||
LIOB33.IOB_Y0.IN_TERM.NONE !38_120 !38_122 !39_121 !39_123
|
||||
LIOB33.IOB_Y0.IN_TERM.UNTUNED_SPLIT_40 38_120 38_122 39_121 39_123
|
||||
LIOB33.IOB_Y0.IN_TERM.UNTUNED_SPLIT_50 38_120 38_122 !39_121 39_123
|
||||
LIOB33.IOB_Y0.IN_TERM.UNTUNED_SPLIT_60 38_120 !38_122 !39_121 39_123
|
||||
LIOB33.IOB_Y0.INTERMDISABLE.I 39_89
|
||||
LIOB33.IOB_Y0.LVTTL.DRIVE.I24 38_64 !38_112 !38_118 38_126 39_65 39_117 39_119 !39_125 !39_127
|
||||
LIOB33.IOB_Y0.PULLTYPE.KEEPER 38_92 38_94 !39_93
|
||||
LIOB33.IOB_Y0.PULLTYPE.NONE !38_92 38_94 !39_93
|
||||
LIOB33.IOB_Y0.PULLTYPE.PULLDOWN !38_92 !38_94 !39_93
|
||||
LIOB33.IOB_Y0.PULLTYPE.PULLUP !38_92 38_94 39_93
|
||||
<...>
|
||||
|
||||
In example, the line::
|
||||
|
||||
LIOB33.IOB_Y0.PULLTYPE.PULLUP !38_92 38_94 39_93
|
||||
|
||||
means that the feature ``LIOB33.IOB_Y0.PULLTYPE.PULLUP`` will be set by clearing
|
||||
bit ``!38_92`` and setting bits ``38_94`` and ``39_93``.
|
||||
|
||||
Generally, ``<feature>`` name is connected with its functionality.
|
||||
In example, ``LIOB33.IOB_Y0.PULLTYPE.PULLUP`` means that in the LIOB33
|
||||
:term:`tile <tile>`,
|
||||
in IOB_Y0 site the *pull type* will be set to *PULLUP*.
|
||||
This simply means that all pins belonging to this particular IOB
|
||||
will be configured with pull-up.
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
===============
|
||||
site_type files
|
||||
===============
|
||||
|
||||
The *site_type files* are generated for every FPGA
|
||||
:term:`site <site>` type. They store the information about the pins and
|
||||
:term:`PIPs <pip>` of the :term:`site <site>`.
|
||||
|
||||
Naming convention
|
||||
-----------------
|
||||
|
||||
The naming scheme for the :term:`site <site>` type files is the following::
|
||||
|
||||
site_type_<site>.json
|
||||
|
||||
Exemplary files:
|
||||
|
||||
- ``site_type_IDELAYE2.json``
|
||||
- ``site_type_PLLE2_ADV.json``
|
||||
- ``site_type_SLICEL.json``
|
||||
|
||||
File format
|
||||
-----------
|
||||
|
||||
The :term:`site <site>` type files are JSON files with the following scheme::
|
||||
|
||||
{
|
||||
"site_pins": {
|
||||
"<PIN_NAME>": {
|
||||
"direction": "<DIR>"
|
||||
},
|
||||
<...>
|
||||
},
|
||||
"site_pips": {
|
||||
"<PIP_NAME>": {
|
||||
"from_pin": "<PIN_NAME>",
|
||||
"to_pin": "<PIN_NAME>"
|
||||
}
|
||||
},
|
||||
"type": "<TYPE>"
|
||||
}
|
||||
|
||||
where:
|
||||
|
||||
- *<PIN_NAME>* - specifies the :term:`site <site>` pin name
|
||||
- *<PIP_NAME>* - specifies the :term:`site <site>` :term:`pip <pip>` name
|
||||
- *<DIR>* - is a direction of a pin (either **IN** or **OUT**)
|
||||
- *<TYPE>* - specifies the :term:`site <site>` type
|
||||
|
||||
|
||||
The ``"site_pins"`` section describes the input pins of a :term:`site <site>`
|
||||
and its directions. The ``"site_pips"`` describes the :term:`PIPs <pip>`
|
||||
inside the :term:`site <site>` and which wires they can connect.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Below there is a part of ``site_type_SLICEL.json`` file for the *artix7*
|
||||
architecture::
|
||||
|
||||
{
|
||||
"site_pins": {
|
||||
"A": {
|
||||
"direction": "OUT"
|
||||
},
|
||||
"A1": {
|
||||
"direction": "IN"
|
||||
},
|
||||
"A2": {
|
||||
"direction": "IN"
|
||||
},
|
||||
"A3": {
|
||||
"direction": "IN"
|
||||
},
|
||||
"A4": {
|
||||
"direction": "IN"
|
||||
},
|
||||
"A5": {
|
||||
"direction": "IN"
|
||||
},
|
||||
"A6": {
|
||||
"direction": "IN"
|
||||
},
|
||||
<...>
|
||||
},
|
||||
"site_pips": {
|
||||
"A5FFMUX:IN_A": {
|
||||
"from_pin": "IN_A",
|
||||
"to_pin": "OUT"
|
||||
},
|
||||
"A5FFMUX:IN_B": {
|
||||
"from_pin": "IN_B",
|
||||
"to_pin": "OUT"
|
||||
},
|
||||
"A5LUT:A1": {
|
||||
"from_pin": "A1",
|
||||
"to_pin": "O5"
|
||||
},
|
||||
"A5LUT:A2": {
|
||||
"from_pin": "A2",
|
||||
"to_pin": "O5"
|
||||
},
|
||||
"A5LUT:A3": {
|
||||
"from_pin": "A3",
|
||||
"to_pin": "O5"
|
||||
},
|
||||
"A5LUT:A4": {
|
||||
"from_pin": "A4",
|
||||
"to_pin": "O5"
|
||||
},
|
||||
"A5LUT:A5": {
|
||||
"from_pin": "A5",
|
||||
"to_pin": "O5"
|
||||
},
|
||||
<...>
|
||||
},
|
||||
"type": "SLICEL"
|
||||
}
|
||||
|
||||
Compare the description with the `Xilinx documentation`_ of that :term:`site <site>`.
|
||||
|
||||
.. _Xilinx documentation: https://www.xilinx.com/support/documentation/user_guides/ug474_7Series_CLB.pdf#page=20
|
||||
|
|
@ -0,0 +1,259 @@
|
|||
===============
|
||||
tile_type files
|
||||
===============
|
||||
|
||||
The *tile_type files* are generated for every FPGA :term:`tile <tile>`
|
||||
type. They store the information about the :term:`tile <tile>` configuration,
|
||||
it's :term:`PIPs <pip>`, :term:`sites <site>`, wires and their properties.
|
||||
|
||||
Naming convention
|
||||
-----------------
|
||||
|
||||
The naming scheme for the segbits files is the following::
|
||||
|
||||
tile_type_<tile>.json
|
||||
|
||||
Exemplary files:
|
||||
|
||||
- ``tile_type_INT_L.json``
|
||||
- ``tile_type_BRAM_L.json``
|
||||
- ``tile_type_HCLK_CLB.json``
|
||||
|
||||
File format
|
||||
-----------
|
||||
|
||||
The :term:`tile <tile>` type files are JSON files with the following shape::
|
||||
|
||||
{
|
||||
"pips": {
|
||||
"<PIP_NAME>": {
|
||||
"can_invert":' "<BOOL>",
|
||||
"dst_to_src": {
|
||||
"delay": [
|
||||
"<DEALY_VALUE>",
|
||||
"<DELAY_VALUE>",
|
||||
"<DELAY_VALUE>",
|
||||
"<DELAY_VALUE>"
|
||||
],
|
||||
"in_cap": "<IN_CAPACITANCE>",
|
||||
"res": "<RESISTANCE>"
|
||||
},
|
||||
"dst_wire": "<WIRE_NAME>",
|
||||
"is_directional": "<BOOL>",
|
||||
"is_pass_transistor": <BOOL>,
|
||||
"is_pseudo": "0",
|
||||
"src_to_dst": {
|
||||
"delay": [
|
||||
"<DELAY_VALUE>",
|
||||
"<DELAY_VALUE>",
|
||||
"<DELAY_VALUE>",
|
||||
"<DELAY_VALUE>"
|
||||
],
|
||||
"in_cap": "<IN_CAPACITANCE>",
|
||||
"res": "<RESISTANCE>"
|
||||
},
|
||||
"src_wire": "<WIRE_NAME>"
|
||||
},
|
||||
},
|
||||
"sites": [
|
||||
{
|
||||
"name": "<SITE_NAME>",
|
||||
"prefix": "<SITE_PREFIX>",
|
||||
"site_pins": {
|
||||
"<SITE_PIN_NAME>": {
|
||||
"cap": "<CAPACITY>",
|
||||
"delay": [
|
||||
"<DELAY_VALUE>",
|
||||
"<DELAY_VALUE>",
|
||||
"<DELAY_VALUE>",
|
||||
"<DELAY_VALUE>"
|
||||
],
|
||||
"wire": "<WIRE_NAME>"
|
||||
},
|
||||
<...>
|
||||
],
|
||||
"tile_type": "<TILE_TYPE>",
|
||||
"wires": {
|
||||
"<WIRE_NAME>": {
|
||||
"cap": "<WIRE_CAPACITY>",
|
||||
"res": "<WIRE_RESISTANCE>"
|
||||
},
|
||||
<...>
|
||||
},
|
||||
}
|
||||
|
||||
"pips" section
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
The "pips" section describes all :term:`PIPs <pip>` in the :term:`tile <tile>`.
|
||||
Every :term:`PIP <pip>` has it's name - ``"<PIN_NAME>"`` and may be
|
||||
characterized by the following attributes:
|
||||
|
||||
- ``"can_invert"`` - takes a value which can be either **1** or **0**.
|
||||
It defines whether the :term:`PIP <pip>` has an inverter on it's output or not.
|
||||
|
||||
- ``dst_to_src"`` - information about the connection in the direction
|
||||
from destination to source. It describes the following properties of the connection:
|
||||
|
||||
- ``"delay"`` - four-element list, which contain information about the delays.
|
||||
- ``"in_cap"`` - the input capacitance of the :term:`PIP <pip>`
|
||||
- ``"res"`` - the resistance of the :term:`PIP <pip>`.
|
||||
|
||||
- ``dst_wire`` - the destination wire name
|
||||
|
||||
- ``is_directional`` - contains the information whether :term:`PIP <pip>` is directional.
|
||||
|
||||
- ``is_pass_transisstor`` - contains the information whether :term:`PIP <pip>` acts
|
||||
as a pass transistor
|
||||
|
||||
- ``is_pseudo`` - contains the information whether :term:`PIP <pip>` is a pseudo-PIP
|
||||
|
||||
- ``src_to_dst`` - contains the information about the connection in the direction
|
||||
from source to destination. It is described by the same set of properties as
|
||||
``dst_to_src`` section.
|
||||
|
||||
"sites" section:
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The "sites" section describes all :term:`sites <site>` in the :term:`tile <tile>`.
|
||||
Every :term:`site <site>` may be characterized by the following attributes:
|
||||
|
||||
- ``"name"`` - location in the :term:`tile <tile>` grid
|
||||
|
||||
- ``"prefix"`` - the type of the :term:`site <site>`
|
||||
|
||||
- ``"site_pins"`` - describes the pins that belong to the :term:`site <site>`.
|
||||
Every pin has it's name - ``"<PIN_NAME>"`` and may be described
|
||||
by the following attributes:
|
||||
|
||||
- ``"cap"`` - pin capacitance
|
||||
- ``"delay"`` - pin delay
|
||||
- ``"wire"`` - wire associated with the pin
|
||||
|
||||
- ``"type"`` - indicates the type of the site
|
||||
|
||||
- ``"x_coord"`` - describes *x* coordinate of the site position inside the tile
|
||||
|
||||
- ``y_coord"`` - describes the *y* coordinate of the site position inside the tile
|
||||
|
||||
"wires" section
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
The "wires" section describes the wires located in the :term:`tile <tile>`.
|
||||
Every wire has it's name - ``"<WIRE_NAME>"`` and may be characterized
|
||||
by the following attributes:
|
||||
|
||||
- ``"cap"`` - wire capacitance
|
||||
- ``"res"`` - wire resistance
|
||||
|
||||
Other
|
||||
^^^^^
|
||||
- ``"tile_type"`` - indicates the type of the tile
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Below there is a part of ``tile_type_BRAM_L.json`` for the *artix7* architecture::
|
||||
|
||||
{
|
||||
"pips": {
|
||||
"BRAM_L.BRAM_ADDRARDADDRL0->>BRAM_FIFO18_ADDRATIEHIGH0": {
|
||||
"can_invert": "0",
|
||||
"dst_to_src": {
|
||||
"delay": [
|
||||
"0.038",
|
||||
"0.046",
|
||||
"0.111",
|
||||
"0.134"
|
||||
],
|
||||
"in_cap": "0.000",
|
||||
"res": "737.319"
|
||||
},
|
||||
"dst_wire": "BRAM_FIFO18_ADDRATIEHIGH0",
|
||||
"is_directional": "1",
|
||||
"is_pass_transistor": 0,
|
||||
"is_pseudo": "0",
|
||||
"src_to_dst": {
|
||||
"delay": [
|
||||
"0.038",
|
||||
"0.046",
|
||||
"0.111",
|
||||
"0.134"
|
||||
],
|
||||
"in_cap": "0.000",
|
||||
"res": "737.319"
|
||||
},
|
||||
"src_wire": "BRAM_ADDRARDADDRL0"
|
||||
},
|
||||
<...>
|
||||
"BRAM_L.BRAM_IMUX12_1->BRAM_IMUX_ADDRARDADDRU8": {
|
||||
"can_invert": "0",
|
||||
"dst_to_src": {
|
||||
"delay": null,
|
||||
"in_cap": null,
|
||||
"res": "0.000"
|
||||
},
|
||||
"dst_wire": "BRAM_IMUX_ADDRARDADDRU8",
|
||||
"is_directional": "1",
|
||||
"is_pass_transistor": 1,
|
||||
"is_pseudo": "0",
|
||||
"src_to_dst": {
|
||||
"delay": null,
|
||||
"in_cap": null,
|
||||
"res": "0.000"
|
||||
},
|
||||
"src_wire": "BRAM_IMUX12_1"
|
||||
},
|
||||
<...>
|
||||
},
|
||||
"sites": [
|
||||
{
|
||||
"name": "X0Y0",
|
||||
"prefix": "RAMB18",
|
||||
"site_pins": {
|
||||
"ADDRARDADDR0": {
|
||||
"cap": "0.000",
|
||||
"delay": [
|
||||
"0.000",
|
||||
"0.000",
|
||||
"0.000",
|
||||
"0.000"
|
||||
],
|
||||
"wire": "BRAM_FIFO18_ADDRARDADDR0"
|
||||
},
|
||||
<...>
|
||||
"WRERR": {
|
||||
"delay": [
|
||||
"0.000",
|
||||
"0.000",
|
||||
"0.000",
|
||||
"0.000"
|
||||
],
|
||||
"res": "860.0625",
|
||||
"wire": "BRAM_RAMB18_WRERR"
|
||||
},
|
||||
<...>
|
||||
},
|
||||
"type": "RAMB18E1",
|
||||
"x_coord": 0,
|
||||
"y_coord": 1
|
||||
}
|
||||
],
|
||||
"tile_type": "BRAM_L",
|
||||
"wires": {
|
||||
"BRAM_ADDRARDADDRL0": null,
|
||||
"BRAM_ADDRARDADDRL1": null,
|
||||
"BRAM_ADDRARDADDRL2": null,
|
||||
"BRAM_ADDRARDADDRL3": null,
|
||||
"BRAM_EE2A0_0": {
|
||||
"cap": "60.430",
|
||||
"res": "268.920"
|
||||
},
|
||||
<...>
|
||||
"BRAM_EE2A0_1": {
|
||||
"cap": "60.430",
|
||||
"res": "268.920"
|
||||
},
|
||||
<...>
|
||||
}
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
===========
|
||||
Description
|
||||
===========
|
||||
|
||||
The main goal of the X-Ray Project is to provide information
|
||||
about Xilinx 7-Series FPGA internals. All obtained chip data is stored in
|
||||
the project's database and is used by `Architecture Definitions`_ project
|
||||
to prepare bitstream for the chosen 7-Series FPGA chip.
|
||||
|
||||
The database is generated by the fuzzers and is located in the ``database``
|
||||
directory. Each supported chip architecture has its own set of files, they
|
||||
are located in ``database/<device_arch>/``. Although the database
|
||||
is huge it consists only of a few file types. Some of them are common
|
||||
for whole 7-Series architecture, but some of them are part-specific.
|
||||
|
||||
.. _Architecture Definitions: https://github.com/SymbiFlow/symbiflow-arch-defs
|
||||
|
||||
Files common for whole 7-Series family:
|
||||
|
||||
- ``mask_*``
|
||||
- ``ppips_*``
|
||||
- ``segbits_*``
|
||||
- ``site_type_*``
|
||||
- ``tile_type_*``
|
||||
- ``timings/*``
|
||||
|
||||
Some files are specific to a given part and are located in a separate directory.
|
||||
The directory is named from the FPGA part name i.e *xc7a35tcpg236-1* or *xc7a50tfgg484-1*.
|
||||
|
||||
Files specific for the particular FPGA part:
|
||||
|
||||
- ``package_pins.csv``
|
||||
- ``part.json``
|
||||
- ``part.yaml``
|
||||
- ``tileconn.json``
|
||||
- ``tilegrid.json``
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
========
|
||||
Database
|
||||
========
|
||||
|
||||
This section documents how prjxray represents the bitstream database.
|
||||
The databases are plain text files, using either simple line-based syntax or JSON.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
description
|
||||
common/index
|
||||
part_specific/index
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
===================
|
||||
Part Specific Files
|
||||
===================
|
||||
|
||||
This section contains a description of :term:`database <database>` files that
|
||||
are part (chip) specific:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
tilegrid
|
||||
tileconn
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
=============
|
||||
tileconn file
|
||||
=============
|
||||
|
||||
The file ``tileconn.json`` contains the information how the wires of neighboring
|
||||
tiles are connected to each other. It contains one entry for each pair of tile
|
||||
types, each containing a list of pairs of wires that belong to the same node.
|
||||
|
||||
.. warning:: FIXME: This is a good place to add the tile wire, pip, site pin diagram.
|
||||
|
||||
This file documents how adjacent tile pairs are connected.
|
||||
No directionality is given.
|
||||
|
||||
The file contains one large list. Each entry has the following fields:
|
||||
|
||||
- ``grid_deltas`` - (x, y) delta going from source to destination tile
|
||||
- ``tile_types`` - (source, destination) tile types
|
||||
- ``wire_pairs`` - list of (source tile, destination tile) wire names
|
||||
|
||||
Sample entry:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
{
|
||||
"grid_deltas": [
|
||||
0,
|
||||
1
|
||||
],
|
||||
"tile_types": [
|
||||
"CLBLL_L",
|
||||
"HCLK_CLB"
|
||||
],
|
||||
"wire_pairs": [
|
||||
[
|
||||
"CLBLL_LL_CIN",
|
||||
"HCLK_CLB_COUT0_L"
|
||||
],
|
||||
[
|
||||
"CLBLL_L_CIN",
|
||||
"HCLK_CLB_COUT1_L"
|
||||
]
|
||||
]
|
||||
}
|
||||
|
||||
Interpreted as:
|
||||
|
||||
- Use when a CLBLL_L is above a HCLK_CLB (ie pointing south from CLBLL_L)
|
||||
- Connect CLBLL_L.CLBLL_LL_CIN to HCLK_CLB.HCLK_CLB_COUT0_L
|
||||
- Connect CLBLL_L.CLBLL_L_CIN to HCLK_CLB.HCLK_CLB_COUT1_L
|
||||
- A global clock tile is feeding into slice carry chain inputs
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
=============
|
||||
tilegrid file
|
||||
=============
|
||||
|
||||
The file ``tilegrid.json`` contains lists of all tiles in the device and the
|
||||
configuration segments formed by those tiles. It also documents the membership
|
||||
relationship of tiles and segments.
|
||||
|
||||
For each segment this contains the configuration frame base address, and the
|
||||
word offset within the frames, as well as the number of frames for the segment
|
||||
and number of occupied words in each frame.
|
||||
|
||||
.. warning:: FIXME: We should cross link to how to use the base address and word offset.
|
||||
|
||||
For each tile this file contains the tile type, grid X/Y coordinates for the tile,
|
||||
and sites (slices) within the tile. This section assumes you are already
|
||||
familiar with the 7 series bitstream format.
|
||||
|
||||
This file contains two elements:
|
||||
|
||||
- segments: each entry lists sections of the bitstream that encode part of one or more tiles
|
||||
- tiles: cores
|
||||
|
||||
segments
|
||||
--------
|
||||
|
||||
Segments are a prjxray concept. Each entry has the following fields:
|
||||
|
||||
- ``baseaddr`` - a tuple of (base address, inter-frame offset)
|
||||
- ``frames`` - how many frames are required to make a complete segment
|
||||
- ``words`` - number of inter-frame words required for a complete segment
|
||||
- ``tiles`` - which tiles reference this segment
|
||||
- ``type`` - prjxray given segment type
|
||||
|
||||
Sample entry:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
"SEG_CLBLL_L_X16Y149": {
|
||||
"baseaddr": [
|
||||
"0x00020800",
|
||||
99
|
||||
],
|
||||
"frames": 36,
|
||||
"tiles": [
|
||||
"CLBLL_L_X16Y149",
|
||||
"INT_L_X16Y149"
|
||||
],
|
||||
"type": "clbll_l",
|
||||
"words": 2
|
||||
}
|
||||
|
||||
Interpreted as:
|
||||
|
||||
- Segment is named SEG_CLBLL_L_X16Y149
|
||||
- Frame base address is 0x00020800
|
||||
- For each frame, skip the first 99 words loaded into FDRI
|
||||
- Since its 2 FDRI words out of possible 101, its the last 2 words
|
||||
- It spans across 36 different frame loads
|
||||
- The data in this segment is used by two different tiles: CLBLL_L_X16Y149, INT_L_X16Y149
|
||||
|
||||
Historical note:
|
||||
|
||||
In the original encoding, a segment was a collection of tiles that were encoded together.
|
||||
For example, a CLB is encoded along with a nearby switch.
|
||||
However, some tiles, such as BRAM, are much more complex. For example,
|
||||
the configuration and data are stored in seperate parts of the bitstream.
|
||||
The BRAM itself also spans multiple tiles and has multiple switchboxes.
|
||||
|
||||
tiles
|
||||
-----
|
||||
|
||||
Each entry has the following fields:
|
||||
|
||||
- ``grid_x`` - tile column, increasing right
|
||||
- ``grid_y`` - tile row, increasing down
|
||||
- ``segment`` - the primary segment providing bitstream configuration
|
||||
- ``sites`` - dictionary of sites name: site type contained within tile
|
||||
- ``type`` - Vivado given tile type
|
||||
|
||||
Sample entry:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
"CLBLL_L_X16Y149": {
|
||||
"grid_x": 43,
|
||||
"grid_y": 1,
|
||||
"segment": "SEG_CLBLL_L_X16Y149",
|
||||
"sites": {
|
||||
"SLICE_X24Y149": "SLICEL",
|
||||
"SLICE_X25Y149": "SLICEL"
|
||||
},
|
||||
"type": "CLBLL_L"
|
||||
}
|
||||
|
||||
Interpreted as:
|
||||
|
||||
- Located at row 1, column 43
|
||||
- Is configured by segment SEG_CLBLL_L_X16Y149
|
||||
- Contains two sites, both of which are SLICEL
|
||||
- A CLBLL_L type tile
|
||||
|
|
@ -1,144 +0,0 @@
|
|||
.db Files
|
||||
=========
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This section documents how prjxray represents the bitstream database. The databases are plain text files, using either simple line-based syntax or JSON. The databases are located in `database/<device_class>/`. The `settings.sh` file contains some configurations used by the tools that generate the database, including the region of interest (ROI, see [[Glossary]]).
|
||||
|
||||
These ".db" files come in two common flavors:
|
||||
* `segbits_*.db`_: encodes bitstream bits
|
||||
* `mask_*.db`_: which bits are used by a segment? Probably needs to be converted to tile
|
||||
|
||||
Also note: .rdb (raw db) is a convention for a non-expanded .db file (see below)
|
||||
|
||||
Segment bit positions
|
||||
---------------------
|
||||
|
||||
Bit positions within a segment are written using the following notation: A two digit decimal number followed by an underscore followed by a two digit decimal number. For example `26_47`.
|
||||
|
||||
The first number indicates the frame address relative to the base frame address for the segment and ranges from `00` to `35` for Atrix-7 CLB segments.
|
||||
|
||||
The second number indicates the bit position width.
|
||||
|
||||
.. warning:: FIXME: Expand this section. We've had a couple questions around this, probably good to get a complete description of this that we can point people too. This is probably a good place to talk about tile grid and how it applies to segbit.
|
||||
|
||||
|
||||
segbits_*.db
|
||||
------------
|
||||
|
||||
Tag files document the meaning of individual configuration bits or bit pattern. They contain one line for each pattern. The first word (sequence of non-whitespace characters) in that line is the *configuration tag*, the remaining words in the line is the list of bits for that pattern. A bit prefixed with a `!` marks a bit that must be cleared, a bit not prefixed with a `!` marks a bit that must be set.
|
||||
|
||||
No configuration tag may include the bit pattern for another tag as subset. If it does then this is an indicator that there is an incorrect entry in the database. Usually this either means that a tag has additional bits in their pattern that should not be there, or that `!<bit>` entries are missing for one or more tags.
|
||||
|
||||
These are created by segmatch to describe bitstream IP encoding.
|
||||
|
||||
Example lines:
|
||||
* CLB.SLICE_X0.DFF.ZINI 31_58
|
||||
* For feature CLB.SLICE_X0.DFF.ZINI
|
||||
* Frame: 31
|
||||
* Word: 58 // 32 = 1
|
||||
* Mask: 1 << (58 % 32) = 0x04000000
|
||||
* To set an actual bitstream location, you will need to adjust frame and word by their tile base addresses
|
||||
* CLBLL_L.SLICEL_X0.AOUTMUX.A5Q !30_06 !30_08 !30_11 30_07
|
||||
* A multi bit entry. Bit 30_06 should be cleared to use this feature
|
||||
* INT_L.BYP_BOUNCE5.BYP_ALT5 always
|
||||
* A pseudo pip: feaure always active => no bits required
|
||||
* CLBLL_L.OH_NO.BAD.SOLVE <const0>
|
||||
* Internal only
|
||||
* Candidate bits exist, but they've only ever been set to 0
|
||||
* CLBLL_L.OH_NO.BAD.SOLVE <const1>
|
||||
* Internal only
|
||||
* Candidate bits exist, but they've only ever been set to 1
|
||||
* INT.FAN_ALT4.SS2END0 <m1 2> 18_09 25_08
|
||||
* Internal only
|
||||
* segmatch -m (min tag value occurrences) was given, but occurrences are below this threshold
|
||||
* ie INT.FAN_ALT4.SS2END0 occcured twice, but this is below the acceptable level (say 5)
|
||||
* INT.FAN_ALT4.SS2END0 <M 6 8> 18_09 25_08
|
||||
* Internal only
|
||||
* segmatch -M (min tag occurrences) was given, but total occurrences are below this threshold
|
||||
* First value (6) is present=1, second value (8) is present=0
|
||||
* Say -M 15, but there are 6 + 8 = 14 samples, below the acceptable threshold
|
||||
|
||||
Related tools:
|
||||
* segmatch: solves symbolic constraints on a bitstream to produce symbol bitmasks
|
||||
* dbfixup.py: internal tool that expands multi-bit encodings (ex: one hot) into groups. For example:
|
||||
* .rdb file with one hot: BRAM.RAMB18_Y1.WRITE_WIDTH_A_18 27_267
|
||||
* .db: file expanded: BRAM.RAMB18_Y1.WRITE_WIDTH_A_18 !27_268 !27_269 27_267
|
||||
* parsedb.py: valides that a database is fully and consistently solved
|
||||
* Optionally outputs to canonical form
|
||||
* Ex: complains if const0 entries exist
|
||||
* Ex: complains if symbols are duplicated (such as after a mergedb after rename)
|
||||
* mergedb.sh: adds new bit entries to an existing db
|
||||
* Ex: CLB is solved by first solving LUT bits, and then solving FF bits
|
||||
|
||||
|
||||
Interconnect :term:`PIP <pip>` Tags
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Tags for interconnect :term:`PIPs <pip>` are stored in the `segbits_int_l.db` and `segbits_int_r.db` database files.
|
||||
|
||||
Tags that enable interconnect :term:`PIPs <pip>` have the following syntax: `<tile_type>.<destination_wire>.<source_wire>`.
|
||||
|
||||
The `<tile_type>` may be `INT_L` or `INT_R`. The destination and source wires are wire names in that tile type. For example, consider the following entry in `segbits_int_l.db`: `INT_L.NL1BEG1.NN6END2 07_32 12_33`
|
||||
|
||||
.. warning:: FIXME: This is probably a good place to reference tileconn as the documentation that explains how wires are connected outside of switchboxes (which is what pips document).
|
||||
|
||||
This means that the bits `07_32` and `12_33` must be set in the segment to drive the value from the wire `NN6END2` to the wire `NL1BEG1`.
|
||||
|
||||
CLB Configurations Tags
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Tags for CLB tiles use a dot-separated hierarchy for their tag names. For example the tag `CLBLL_L.SLICEL_X0.ALUT.INIT[00]` documents the bit position of the LSB LUT init bit for the ALUT for the slice with even X coordinate within a `CLBLL_L` tile. (There are 4 LUTs in a slice: ALUT, BLUT, CLUT, and DLUT. And there are two slices in a CLB tile: One with an even X coordinate using the `SLICEL_X0` namespace for tags, and one with an odd X coordinate using the `SLICEL_X1` namespace for tags.)
|
||||
|
||||
|
||||
|
||||
ppips_*.db
|
||||
----------
|
||||
|
||||
Pseudo :term:`PIPs <pip>` are :term:`PIPs <pip>` in the Vivado tool, but do not have actual bit pattern. The `ppips_*.db` files contain information on pseudo-:term:`PIPs <pip>`. Those files contain one entry per pseudo-PIP, each with one of the following three tags: `always`, `default` or `hint`. The tag `always` is used for pseudo-:term:`PIPs <pip>` that are actually always-on, i.e. that are permanent connections between two wires. The tag `default` is used for pseudo-:term:`PIPs <pip>` that represent the default behavior if no other driver has been configured for the destination net (all `default` pseudo-:term:`PIPs <pip>` connect to the `VCC_WIRE` net). And the tag `hint` is used for :term:`PIPs <pip>` that are used by Vivado to tell the router that two logic slice outputs drive the same value, i.e. behave like they are connected as far as the routing process is concerned.
|
||||
|
||||
mask_*.db
|
||||
---------
|
||||
|
||||
These are just simple bit lists
|
||||
|
||||
Example line: bit 01_256
|
||||
|
||||
See previous section for number meaning
|
||||
|
||||
For each segment type there is a mask file `mask_<seg_type>.db` that contains one line for each bit that has been observed being set in any of the example designs generated during generation of the database. The lines simply contain the keyword `bit` followed by the bit position. This database is used to identify unused bits in the configuration segments.
|
||||
|
||||
|
||||
.bits example
|
||||
-------------
|
||||
|
||||
Say entry is: bit_0002050b_002_05
|
||||
|
||||
2 step process:
|
||||
* Decode which segment
|
||||
* Decode which bit within that segment
|
||||
|
||||
We have:
|
||||
* Frame address 0x0002050b (hex)
|
||||
* Word #: 2 (decimal, 0-99)
|
||||
* Bit #: 5 (decimal, 0-31)
|
||||
|
||||
The CLB tile and the associated interconnect switchbox tile are configured together as a segment. However, configuration data is grouped by segment column rather than tile column. First, note this segment consists of 36 frames. Second, note there are 100 32 bit words per frame (+ 1 for checksum => 101 actual). Each segment takes 2 of those words meaning 50 segments (ie 50 CLB tiles + 50 interconnect tiles) are effected per frame. This means that the smallest unit that can be fully configured is a group of 50 CLB tile + switchbox tile segments taking 4 * 36 * 101 = 14544 bytes. Finally, note segment columns are aligned to 0x80 addresses (which easily fits the 36 required frames).
|
||||
|
||||
tilegrid.json defines addresses more precisely. Taking 0x0002050b, the frame base address is 0x0002050b & 0xFFFFFF80 => 0x00020500. The frame offset is 0x0002050b & 0x7F => 0x0B => 11.
|
||||
|
||||
So in summary:
|
||||
* Frame base address: 0x00020500
|
||||
* Frame offset: 0x0B (11)
|
||||
* Frame word #: 2
|
||||
* Frame word bit #: 5
|
||||
|
||||
So, with this in mind, we have frame base address 0x00020500 and word # 2. This maps to tilegrid.json entry SEG_CLBLL_L_X12Y101 (has "baseaddr": ["0x00020600", 2]). This also yields "type": "clbll_l" meaning we are configuring a CLBLL_L.
|
||||
|
||||
.. warning:: FIXME: This example is out of date with the new tilegrid format, should update it.
|
||||
|
||||
|
||||
Looking at segbits_clbll_l.db, we need to look up the bit at segment column 11, offset at bit 5. However, this is not present, so we fall back to segbits_int_l.db. This yields a few entries related to EL1BEG (ex: INT_L.EL1BEG_N3.EL1END0 11_05 13_05).
|
||||
|
||||
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
============
|
||||
Output Files
|
||||
============
|
||||
|
||||
.. toctree::
|
||||
|
||||
db
|
||||
tile.rst
|
||||
|
|
@ -1,154 +0,0 @@
|
|||
.json Files
|
||||
===========
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This section documents how prjxray represents FPGA fabric. Its primarily composed of two files:
|
||||
* tilegrid.json: list of tiles and how they appear in the bitstream
|
||||
* tileconn.json: how tiles are connected together
|
||||
|
||||
General notes:
|
||||
* prjxray created names are generally lowercase, while Vivado created names are generally uppercase
|
||||
* _l and _r entries are generally identical, but probably represent different physical IP block layouts
|
||||
|
||||
|
||||
tilegrid.json
|
||||
-------------
|
||||
|
||||
The file `tilegrid.json` contains lists of all tiles in the device and the configuration segments formed by those tiles. It also documents the membership relationship of tiles and segments.
|
||||
|
||||
For each segment this contains the configuration frame base address, and the word offset within the frames, as well as the number of frames for the segment and number of occupied words in each frame.
|
||||
|
||||
.. warning:: FIXME: We should cross link to how to use the base address and word offset.
|
||||
|
||||
For each tile this file contains the tile type, grid X/Y coordinates for the tile, and sites (slices) within the tile.
|
||||
|
||||
This section assumes you are already familiar with the 7 series bitstream format.
|
||||
|
||||
This file contains two elements:
|
||||
* segments: each entry lists sections of the bitstream that encode part of one or more tiles
|
||||
* tiles: cores
|
||||
|
||||
segments
|
||||
########
|
||||
|
||||
Segments are a prjxray concept.
|
||||
|
||||
Each entry has the following fields:
|
||||
* baseaddr: a tuple of (base address, inter-frame offset)
|
||||
* frames: how many frames are required to make a complete segment
|
||||
* words: number of inter-frame words required for a complete segment
|
||||
* tiles: which tiles reference this segment
|
||||
* type: prjxray given segment type
|
||||
|
||||
Sample entry:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
"SEG_CLBLL_L_X16Y149": {
|
||||
"baseaddr": [
|
||||
"0x00020800",
|
||||
99
|
||||
],
|
||||
"frames": 36,
|
||||
"tiles": [
|
||||
"CLBLL_L_X16Y149",
|
||||
"INT_L_X16Y149"
|
||||
],
|
||||
"type": "clbll_l",
|
||||
"words": 2
|
||||
}
|
||||
|
||||
Interpreted as:
|
||||
* Segment is named SEG_CLBLL_L_X16Y149
|
||||
* Frame base address is 0x00020800
|
||||
* For each frame, skip the first 99 words loaded into FDRI
|
||||
* Since its 2 FDRI words out of possible 101, its the last 2 words
|
||||
* It spans across 36 different frame loads
|
||||
* The data in this segment is used by two different tiles: CLBLL_L_X16Y149, INT_L_X16Y149
|
||||
|
||||
Historical note:
|
||||
In the original encoding, a segment was a collection of tiles that were encoded together.
|
||||
For example, a CLB is encoded along with a nearby switch.
|
||||
However, some tiles, such as BRAM, are much more complex. For example,
|
||||
the configuration and data are stored in seperate parts of the bitstream.
|
||||
The BRAM itself also spans multiple tiles and has multiple switchboxes.
|
||||
|
||||
tiles
|
||||
#####
|
||||
|
||||
Each entry has the following fields:
|
||||
* grid_x: tile column, increasing right
|
||||
* grid_y: tile row, increasing down
|
||||
* segment: the primary segment providing bitstream configuration
|
||||
* sites: dictionary of sites name: site type contained within tile
|
||||
* type: Vivado given tile type
|
||||
|
||||
Sample entry:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
"CLBLL_L_X16Y149": {
|
||||
"grid_x": 43,
|
||||
"grid_y": 1,
|
||||
"segment": "SEG_CLBLL_L_X16Y149",
|
||||
"sites": {
|
||||
"SLICE_X24Y149": "SLICEL",
|
||||
"SLICE_X25Y149": "SLICEL"
|
||||
},
|
||||
"type": "CLBLL_L"
|
||||
}
|
||||
|
||||
Interpreted as:
|
||||
* Located at row 1, column 43
|
||||
* Is configured by segment SEG_CLBLL_L_X16Y149
|
||||
* Contains two sites, both of which are SLICEL
|
||||
* A CLBLL_L type tile
|
||||
|
||||
tileconn.json
|
||||
-------------
|
||||
|
||||
The file `tileconn.json` contains the information how the wires of neighboring tiles are connected to each other. It contains one entry for each pair of tile types, each containing a list of pairs of wires that belong to the same node.
|
||||
|
||||
.. warning:: FIXME: This is a good place to add the tile wire, pip, site pin diagram.
|
||||
|
||||
This file documents how adjacent tile pairs are connected.
|
||||
No directionality is given.
|
||||
|
||||
The file contains one large list. Each entry has the following fields:
|
||||
* grid_deltas: (x, y) delta going from source to destination tile
|
||||
* tile_types: (source, destination) tile types
|
||||
* wire_pairs: list of (source tile, destination tile) wire names
|
||||
|
||||
Sample entry:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
{
|
||||
"grid_deltas": [
|
||||
0,
|
||||
1
|
||||
],
|
||||
"tile_types": [
|
||||
"CLBLL_L",
|
||||
"HCLK_CLB"
|
||||
],
|
||||
"wire_pairs": [
|
||||
[
|
||||
"CLBLL_LL_CIN",
|
||||
"HCLK_CLB_COUT0_L"
|
||||
],
|
||||
[
|
||||
"CLBLL_L_CIN",
|
||||
"HCLK_CLB_COUT1_L"
|
||||
]
|
||||
]
|
||||
}
|
||||
|
||||
Interpreted as:
|
||||
* Use when a CLBLL_L is above a HCLK_CLB (ie pointing south from CLBLL_L)
|
||||
* Connect CLBLL_L.CLBLL_LL_CIN to HCLK_CLB.HCLK_CLB_COUT0_L
|
||||
* Connect CLBLL_L.CLBLL_L_CIN to HCLK_CLB.HCLK_CLB_COUT1_L
|
||||
* A global clock tile is feeding into slice carry chain inputs
|
||||
|
||||
|
|
@ -37,4 +37,4 @@ to develop a free and open Verilog to bitstream toolchain for these devices.
|
|||
:maxdepth: 2
|
||||
:caption: Output Formats
|
||||
|
||||
format/index
|
||||
dev_database/index
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ important data about the Xilinx chips. The needed information includes:
|
|||
|
||||
Final results are stored in the database which is further used by the
|
||||
`Architecture Definitions`_ project. The whole database is described in
|
||||
the dedicated :doc:`chapter <format/index>`.
|
||||
the dedicated :doc:`chapter <dev_database/index>`.
|
||||
|
||||
Methodology
|
||||
-----------
|
||||
|
|
|
|||
Loading…
Reference in New Issue