Welcome to FPGA Interchange documentation!¶
Device Resources¶
The device resources schema is intended to be a complete description of an island-based FPGA design. It is made of many components, but the core description of the device is shown below.
┌─────────────────┐
│ Device │
│ ┌─────────────┐ │
│ │ Tile │ │
│ │ ┌─────────┐ │ │
│ │ │ Site │ │ │
│ │ │ ┌─────┐ │ │ │
│ │ │ │ BEL │ │ │ │
│ │ │ └─────┘ │ │ │
│ │ │ │ │ │
│ │ └─────────┘ │ │
│ │ │ │
│ └─────────────┘ │
│ │
└─────────────────┘
That is:
A device contains tiles
Tiles contains sites
Sites contains BELs
The schema contains the required information to answer questions such as:
Where are tiles located?
How are sites connected to the routing graph?
How are BELs connected to the boundary of the site?
How can cells be placed at BELs?
Terminology¶
Device - A set of tiles and package pins.
Tiles - An instance of a tile type which contains wires and sites
Package pin - A boundry between the “interior” of the device and what is “outside” the package. Generally corresponds to a pin on a package, e.g. pin 1 on SOP-8 or A1 on CSG324.
Wire - Also known as a “tile wire” . A wire is a piece of conductive material totally contained within a tile. Wires can be part of nodes. Wires can connect to PIPs or site pins.
Node - A node is a set of 1 or more wires that are connected. Nodes can span multiple tiles. Nodes connect to PIPs or site pins via the wires that are part of the node.
PIP - PIP is an abbreviation for programable interconnect point. A PIP provides a connection between two wires. PIPs can be unidirectional or bidirectional. Unidirectional PIPs always connect wire0 to wire1. Bidirectional PIPs can connect wire0 to wire1 or wire1 to wire0.
Site - A collection of site pins, site wires and BELs.
Site pin - The connection between a site and a wire. Site pins may connect to 0 or more site port BELs.
Site wire - A piece of conductive material that connects to at most 1 output BEL pin and 0 or more input or inout BEL pins.
BEL - BEL is an abbreviation of basic logic element. A BEL can be one of 3 types, site port, logic, routing. A BEL contains 1 or more BEL pins.
BEL pin - A connection between a BEL and a site wire.
Logic BEL - A placable logic element. May be subject to 0 or more placement constraints.
Site port BEL - A site port BEL represents a connection to a site pin contained within the parent tile of the site. See Site port BEL.
Routing BEL - A routing BEL connects at most 1 input BEL pin to the output BEL pin. See Routing BEL.
Site PIP - A pair of input and output BEL pins belonging to a BEL that represents a logically connection.
Cell - A logical element of a design that contains some number of cell ports and some number of cell instances, and some number of nets.
Cell port - The boundary between the interior of a cell and the containing cell (if any).
Cell instance - A instance of a cell. The cell ports of may be connected to nets within the parent cell.
Net - A set of logically connected cell ports.
The place and route problem¶
The device resources schema is intended to provide a description for a tool solving the place and route problem. The definition of the problem used by this schema is described below:
There exists exactly 1 cell instance (the top instance) that contains 1 or more leaf cell instances that must be placed at BELs, such that no constraints are violated and the nets between the cell instances are routable. Routable means that site wires, site PIPs, nodes, PIPs can be assigned to at most 1 net such that each net driver BEL pin can reach each every net sink BEL pin on the net.
The device resource format describes how cell instances can be legally placed at BELs and how cell pins relate to BEL pins. When a cell instance is placed at a BEL, it may be subject to 0 or more constraints.
Nets are divided into 3 categories. A signal net represents a signal that is not either the constant logical 0 or constant logical 1 net. The constant logical 0 and constant logical 1 nets are special because they can have multiple drivers in the device description. Routing resources that are always part of the constant logical 0 or constant logical 1 net are explicitly defined in the device resources schema. The constant logical 0 net is listed in the schema as the “gnd” type. The constant logical 1 net is listed in the schema as the “vcc” type.
Rules for routing¶
Fully routed signal nets always begin at a output/inout BEL pin, and always end at an input/inout BEL pin. If a net enters a site, that net must end at an input/inout BEL pin. It is not legal for a net to enter and leave a site. If such a path is required, a pseudo PIP should be added to the schema.
Site example¶
The following is an example site for a SLICE for a non-existent device.
▲
CO│ │
┌──────────────────────────┼─────────────────────────────────────┼──────┐
│ │ │ │
B0│ I0┌───────┐ │ BLUT ┌───────┐ ▼ CLK │
─────┼────►│ │ ┌────────o─────────────────┬────►│ │ ┌────┐ │
B1│ I1│ │O │ │ │XOR │ │D D│ │Q │ FFOUT
─────┼────►│ BLUT3 ├───┤ │ ┌────────┬──o────►│ FFMUX ├──►│ FF ├───┼───►
B2│ I2│ │ │ │ │ │ |ALUT │ │ │ │ │
─────┼────►│ │ │ │ │ ┌──┬──o──o────►│ │ └────┘ │
│ └───────┘ │ ┌───┴───┐ │ │ │ │ │ └───────┘ │
│ │ SI│ │ │ │ │ │ │ │
│ └───►│ ├─┘ │ │ │ │ │
│ DX│ CARRY │ O │ │ │ │ │
│ ┌───►│ │ │ │ │ │ │
A0│ I0┌───────┐ │ └───┬───┘ │ │ │ │ ┌────────┐ │
─────┼────►│ │ │ │ │ │ │ │ BLUT │ │ │
A1│ I1│ │O │ │ │ │ │ └─────►│ │OUT │ OUT
─────┼────►│ ALUT3 ├───┴────────o────────┘ │ │ XOR │ OUTMUX ├──────────┼────►
B2│ I2│ │ │ │ └────────►│ │ │
─────┼────►│ │ │ │ ALUT │ │ │
│ └───────┘ │ └───────────►└────────┘ │
│ │ │
│ │ │
└──────────────────────────┼────────────────────────────────────────────┘
CI│
│
In the above example, there are 17 BELs:
| BEL Name | Category | # Input | # Output |
|---|---|---|---|
| ALUT3 | Logic | 3 | 1 |
| BLUT3 | Logic | 3 | 1 |
| CARRY | Logic | 3 | 2 |
| FF | Logic | 2 | 1 |
| FFMUX | Routing | 3 | 1 |
| OUTMUX | Routing | 3 | 1 |
| A0 | Site port | 0 | 1 |
| A1 | Site port | 0 | 1 |
| A2 | Site port | 0 | 1 |
| B0 | Site port | 0 | 1 |
| B1 | Site port | 0 | 1 |
| B2 | Site port | 0 | 1 |
| CI | Site port | 0 | 1 |
| CLK | Site port | 0 | 1 |
| CO | Site port | 1 | 0 |
| FFOUT | Site port | 1 | 0 |
| OUT | Site port | 1 | 0 |
Each site port BEL has a site pin, so the site pins are:
| Site Pin Name | Direction |
|---|---|
| A0 | In |
| A1 | In |
| A2 | In |
| B0 | In |
| B1 | In |
| B2 | In |
| CI | In |
| CLK | In |
| CO | Out |
| FFOUT | Out |
| OUT | Out |
The BEL BLUT3 has 4 BEL pins:
| BEL pin name | Direction |
|---|---|
| I0 | In |
| I1 | In |
| I2 | In |
| O | Out |
The BEL A0 has 1 BEL pin:
| BEL pin name | Direction |
|---|---|
| A0 | Out |
The BEL OUTMUX has 4 BEL pins:
| BEL pin name | Direction |
|---|---|
| BLUT | In |
| XOR | In |
| ALUT | In |
| OUT | Out |
There are 12 site PIPs:
| BEL name | In pin | Out pin |
|---|---|---|
| BLUT3 | I0 | O |
| BLUT3 | I1 | O |
| BLUT3 | I2 | O |
| ALUT3 | I0 | O |
| ALUT3 | I1 | O |
| ALUT3 | I2 | O |
| FFMUX | ALUT | D |
| FFMUX | XOR | D |
| FFMUX | BLUT | D |
| OUTMUX | ALUT | OUT |
| OUTMUX | XOR | OUT |
| OUTMUX | BLUT | OUT |
The site wire BLUT3_O has 4 BEL pins:
| BEL Name | Pin |
|---|---|
| BLUT3 | O |
| CARRY | SI |
| FFMUX | BLUT |
| OUTMUX | BLUT |
The site wire B0 has 2 BEL pins:
| BEL Name | Pin |
|---|---|
| B0 | B0 |
| BLUT3 | I0 |
Details¶
Net routing summary¶
Each net start at the driver output/inout BEL pin. The BEL pin will be connected to exactly 1 site wire. If the net sink can be reached within the site, then the net can use site PIPs to reach a site wire connected to the input/inout BEL pin.
If the net sink is in another site, then the net must first reach a site port input BEL pin using site PIPs to reach the site wire connected to the site port. From there the net leaves the site via the site port and is now on the first node via the site pin matching the site port.
From there the net must use PIPs to expand to new nodes until arriving at a node attached to valid site pin for the sink. This would be a site pin that is part of the same site that the sink BEL is part of, and that the site port wire can reach the sink BEL pin (via 0 or more site PIPs). The site can be entered via the site port corresponding to the site pin. The first site wire in the site will be the site wire attached to the output BEL pin of the site port. From there site routing continues per above.
Use of site PIPs¶
It is important to note that site PIPs can only be used to access placed cells inside that site. Site PIPs cannot be used as general route-thrus, to route from site input to output. General route-thrus across entire sites should use tile pseudo PIPs as described below - even if a site pin is being validly used for one sink pin of a net that is located inside the site; site PIPs cannot also be used to leave the site again to reach other sinks.
LUT route-thrus, for example, might require both site PIPs and tile pseudo PIPs. The site PIP would be used to route through the LUT in order to access an associated flipflop input inside the site. The tile PIP would be used to route across the entire site as part of the general, inter-tile, routing problem.
A diagram illustrating the legal and illegal uses is shown below.
Tile Types and site types¶
To reduce data duplication in the device schema, both tiles and sites have a type. Most of the definition of the tile and site is in the type rather than repeated at each instance. This does cause some more complicated indirection, so the following section provides some additional explanation here.
Sites, site types and alternative site types¶
The most complicated relationship in the schema is likely the relationship between sites, site types and alternative site types.
Most of the site type description is independent of the tile / tile type that the site type is within. See the “SiteType” struct definition for the independent portion of the schema. The important exception is the relationship between wires and site pins.
Each site within a tile has a “primary site type”, which is found in the “SiteTypeInTileType” struct definition, contained in the “TileType” struct. The site within the tile will specify which “SiteTypeInTileType” to use for that particular site.
The primary site type contains a list of “alternative” site types that may be used (”altSiteTypes” in “SiteType”). The primary site type must always contains the complete list of site pins used in any of the alternative site types.
The site pins to wire relationship is always done via the primary site type. When an alternative site type is used, the site pins of that alternative site type must be first be mapped to a site pin of the primary site type.
The “SiteTypeInTileType” defines the relationship between the primary site type and the wires. It also defines the relationship from the alternative site type to the primary site type.
It first defines the primary site type (”primaryType”). It defines a map between the site pins in the primary site type and wires in the tile type that contains the site (”primaryPinsToTileWires”). Last it defines the map between the alternative site pin and the primary site pin (”altPinsToPrimaryPins”).
Important: When solving the place and route problem, only the primary or one of the alternative site types can be used at a time for a particular site.
Routing BEL¶
A routing BEL represents statically configurable site routing by connecting a site wire connected to one of the input BEL pins to the output BEL pin of the BEL. Routing BELs must have 1 output BEL pin.
Inverting routing BELs¶
Some routing BELs can invert signals that pass through them. Defined the “inverting” field in the “BEL” struct with the BEL pins that invert and do not invert.
Site port BEL¶
A site port BEL represents a connection to a site pin contained within the parent tile of the site. Site port BELs have exactly 1 BEL pin. The BEL name and pin name should be the same. The name of the BEL should match the name of the site pin that the site port connects too. The direction of the BEL pin should be the opposite of the site pin direction.
Examples:
An input site pin “I0” would have a site port BEL named “I0” with 1 BEL output pin named “I0”.
Partially routed nets¶
The schema can represent partially routed nets in a design in at least
two ways. First, if contigous routing segments are separated by a
discontinuity (sometimes referred to as an antenna), these
disconnected segments can be stored in the stubs field of a
PhysNet. However, some architectures have ways of pre-marking a net
using individual nodes such as for clock planning and have isolated
nodes to mark decision paths for later routing. In this case, these
isolated nodes should be stored in the stubNodes field. A fully
routed net, however, would generally not use stubNodes.
Additional topics¶
The device resources schema also covers some important data required for handling common cases found in island based FPGAs.
Signal inversions¶
It is fairly common for fabrics to contain site local signal inverters. Depending on the architecture, the place and route tool may be expected to leverage inverters or may even require it. The device resources schemas provides a description for how cells express inversion and how to use site local inverters to implement the requested inversion.
LUT definitions¶
LUTs are common to every island-based FPGA, and many place and route tasks depend on having knowledge of how the LUTs are arranged. The LUT definition section of the device resources defines where LUTs exist as BELs and what cells can be placed at those BELs. This is important is at least two place and route tasks. The first is that LUTs can be trivially turned into site pips from the input of the LUT to the output of the LUT, subject to constraints and LUT equation sharing. The second is that LUTs can be trivially turned into constant sources from the output pin.
Parameters¶
Some parameters attached to cell instances may be relevant for the place and route problem. A common example is LUT equation sharing, which can happen on fracturable LUTs. See the schema for details.
Pseudo PIPs¶
It may be important within a device to represent PIPs that “route-thru” one or more BELs. This can be modelled as placing a cell in a particular configuration at a BEL, subject to the normal cell placement rules. The “PseudoCell” struct defines what resources are used by using PIPs.
All pseudo PIPs must define at least 1 pseudo cell. Pseudo cells should include the site port BEL that the pseudo PIP used to enter the site.
Cell, BEL and Site Design¶
One of the key concepts within the FPGA interchange device resources is the relationship between the cell library and the device BEL and site definitions. A well designed cell library and a flexible but concise BEL and site definition is important for exposing the hardware in an efficient way that enables a place and route tool to succeed.
Good design is hard to capture, but this document will talk about some of the considerations.
Assumptions about cell placement and driver BEL pins¶
One important note is that BELs represent a placable location for a cell, and only one cell should be placable at a given BEL. This means that the cell library design and BEL design strongly affects what is expressable by the place and route tool. There will be some examples highlighted below that expand on how this is important and relevant when discussing concrete examples.
Granularity of the cell library¶
It is important to divide the place and route problem and the synthesis problem, at least as defined for the purpose of the FPGA interchange. The synthesis tool operates on the cell library, which should be designed to expose logic elements at a useful level of granularity.
As a concrete example, a LUT4 element is technically just two LUT3 elements, connected by a mux (e.g. MUXF4), a LUT3 element is just two LUT2 elements, connected by a mux (e.g. MUXF3), etc. If the outputs of those interior muxes are not accessible to the place and route tool, then exposing those interior function muxes as cells in the cell library is not as useful.
Cell definitions should be granular enough that the synthesis can map to them, but not so granular that the place and route tool will be making few if any choices. If there is only one legal placement of the cell, it’s value is relatively low.
Drawing site boundaries¶
When designing an FPGA interchange device resource for a new fabric, one important consideration is where to draw the site boundary. The primary goal of lumping BELs within a site is to capture some local congestion due to fanout limitations. Interior static routing muxes and output muxes may accommodate significantly fewer signals than the possible number of BELs that drive them. In this case, it is important to draw the site boundary large enough to capture these cases so as to enable the local congestion to be resolved during either packing for clustered approaches, or during placement during unclustered approaches. In either case, local congestion that is strongly placement dependant must be resolved prior to general routing, unless a fused placement and routing algorithm is used.
FF control sets routing¶
A common case worth exploring is FF control sets, e.g. SR type signals and CE type signals. In most fabric SLICE types, the SR and CE control signals are shared among multiple rows of the SLICE. This is a common example of local site congestion, and the site boundary should typically encompass all BELs that share this kind of local routing for all the reasons discussed above.
Another consideration with control signals is the presence of control signal constraints that cannot be expressed as local routing congestion. For example, if a set of BELs share whether the SR control line is a set or reset (or async set or async reset), it is common to expand the site boundary to cover the BELs that share these implicit configurations. The constraint system in the device resources is designed to handle this kind of non-routing driven configuration.
Drawing BEL boundaries¶
BEL definitions require creating a boundary around primitive elements of the fabric. The choice of where to place that boundary has a strong influence on the design of the cell library in the FPGA interchange.
In general, the smaller the BEL boundary, the more complexity is exposed to the place and route tool. In some cases exposing this complexity is important, because it enables some goal. For example, leaving static routing muxes outside of BELs enables a place and route tool to have greater flexibility when resolving site congestion. But as a counter point, if only a handful of static mux configurations are useful and those choices can be made at synthesis time, then lumping those muxes into synthesis reduces the complexity required in the place and route tool.
The most common case where the static routing muxes are typically lumped into the BEL is BRAM’s and FIFO’s address and routing configuration. At synthesis time, a choice is made about the address and data widths, which are encoded as parameters on the cell. The place and route tool does not typically make meaningful choices on the configuration of those static routing muxes, but they do exist in the hardware.
The most common case where the static routing muxes are almost never lumped into the BEL is SLICE-type situations. The remainder of this document will show examples of why the BEL boundary should typically exclude the static routing muxes, and leave the choice to the place and route tooling.
Static routing muxes and bitstream formats¶
Something to keep in mind when drawing BEL boundaries to include or exclude static routing muxes is the degree of configurability present in the underlying bitstream. Some static routing muxes share configuration bits in the bitstream, and so expressing them as two seperate static routing muxes potentially gives the place and route tool flexibility than the underlying fabric cannot express. This will result in physical netlists that cannot be converted to bitstream.
In some cases this can be handled through tight coupling of the cell and BEL library. The idea is to limit cell port to BEL pin mappings that avoid illegal static routing mux configurations. This approach has its limits. In general, considering how the bitstream expresses static routing muxes must be accounted for when drawing BEL boundaries.
Stratix II and Stratix 10 ALM¶
Consider both Stratix II and Stratix 10 logic sites. The first thing to note is that the architectures at this level are actually mostly the same. Though it isn’t immediately apparent, both designs are structured around 4 4-LUT elements.
Take note that of the following structure:
This is actually just two LUT4 elements, where the top select line is independent.
See the following two figures:
In Stratix 10, the LUT4 element is still present, but the top select line fracturing was removed.
So now consider the output paths from the the 4 LUT4 elements in the Stratix II site. Some of the LUT4 outputs route directly to the carry element, so it will be important for the place and route tool be able to place a LUT4 or smaller to access that direct connection. But if the output is not used in the carry element, then it can only be accessed in Stratix II via the MUXF5 (blue below) and MUXF6 (red below) elements.
So given the Stratix II site layout, the following BELs will be required:
4 LUT4 BELs that connect to the carry
2 LUT6 BELs that connect to the output FF or output MUX.
The two LUT6 BELs are shown below:
Drawing a smaller BEL boundary has little value, because a LUT5 element would still always require routing through the MUXF6 element.
Now consider the Stratix 10 output arrangement. The LUT4 elements direct to the carry element is the same, so those BELs would be identical. The Stratix 10 site now has an output tap directly on the top LUT5, similiar to the Xilinx Versal LUT6 / LUT5 fracture setup. See diagram below. LUT5 element is shown in blue, and LUT6 element is shown in red.
So given the Stratix 10 site layout, the following BELs will be required:
4 LUT4 BELs that connect to the carry
2 LUT5 BELs that connect to the output FF or output MUX
1 LUT6 BELs that connect to the output FF or output MUX
Versal ACAP¶
The Versal ACAP LUT structure is fairly similiar to the Stratix 10 combitorial elements.
Unlike the Stratix 10 ALM, it appears only 1 of the LUT4’s connects to the carry element (the prop signal). The O6 output also has a dedicate connection to the carry. See image below:
The Versal LUT structure likely should be decomposed into 4 BELs, shown in the next figures:
So given the Versal site layout, the following BELs will be required (per SLICE row):
1 LUT4 BELs that connect to the carry
2 LUT5 BELs that connect to the output FF or output MUX
1 LUT6 BELs that connect to the output FF or output MUX
Implication of a wider BEL definition¶
Consider the Versal structure, but instead of drawing four BELs per row, only have two
BELs per row. One BEL has the O5_1 and prop output BEL pins and the
other BEL has the O6 and O5_2 BEL pin. In this configuration, if the cell
library does not expose a cell that maps to both the O5_1 and prop output
BEL pins, then it will not be possible to map LUTs that leverage both output
BEL pins.
In theory, the cell port to BEL pin map could map the output pin of a LUT4
element to both the prop and O5_1 output BEL pins, but then there will be
two output BEL pins driving the net connected to the cell port. Having
multiple BEL pins driving one net is not legal, except for the global logic 0
and 1.
Quicklogic EOS S3 logic cell¶
The Quicklogic EOS S3 logic cell has an interesting LUT design because there is not LUT element specifically. Instead, the fabric exposes a 8x3 mux, with inverters at each of the mux inputs, see figure below:
The way to approach this fabric is to first draw BEL boundaries around the 4x2 mux and 8x3 mux present in the fabric:
The cell library should have 3 MUX cell types:
4-input 1-output 2-select MUX4x2 (maps to MUX4x2 BEL and MUX8x3 BEL)
8-input 1-output 3-select MUX8x3 (maps to MUX8x3 BEL)
A macro cell that is 2x (4-input 1-output 2-select MUX4x2) 2xMUX4x2 (maps to MUX4x2 and MUX8x3 BEL)
A fourth most general cell type is possible, which is to add a cell that also
has a cell port that maps to TBS, instead of tying TBS high as the
2xMUX4x2 cell would do. It is unclear how useful such a cell would be.
However given the BEL boundaries, adding such a cell would be easy after the
fact.
In all of the cells above, all inputs to the muxes have statically configured inverters.
So the question becomes, how to model LUT cells in this fabric? The LUT cells should be the regular LUT1, LUT2 and LUT3 cells. The LUT1 and LUT2 can map to either the MUX4x2 or MUX8x3 BEL. The LUT3 can map to only the MUX8x3 BEL. The question is only what is the cell port to BEL pin map?
The solution is when mapping a LUT cell, to tie all of the MUX BEL pins to VCC (or GND, whatever the default is) before the inverter. The place and route tool can treat the BEL as a regular LUT, and only the bitstream generation step will need to be aware that the inversion control is being used to encode the LUT equation.
This configuration allows most (if not all) of the logic to be available to the place and route tool, without exposing unneeded complexity.
Pseudo Cells¶
Pseudo PIPs and site pseudo PIPs are edges in the device graph that route through other sites and/or BELs. Pseudo cells are the expression of what routing resources are “blocked” by the use of a pseudo PIP.
The device database currently expresses pseudo PIPs as using BEL pins within the site that the pseudo PIP is attached too. Both input and output BEL pins are included in the pseudo cell definition, but only output BEL pins “block” the site wire.
Example¶
In the case of a Xilinx 7-series CLBLL’s CLBLL_LL_A1 to CLBLL_LL_A
pseudo PIP, this PIP connects a signal from an input site port to an output
site port. Each site wire that is consumed has both a output BEL pin
(from the site wire source) and a input BEL pin (connected to either a logic
BEL, e.g. A6LUT or routing BEL, e.g. AUSED or output site port BEL, e.g.
A).
In the case of a CLBLL’s CLBLL_LL_A to CLBLL_LL_AMUX pseudo PIP, this
PIP connects a signal from an output site port to an output site port. In
this case, it is assumed and required that some of the site wires are already
bound to the relevant net (by virtue of the wire CLBLL_LL_A already being
part of the net). In this case, the first BEL pin will be an input BEL pin
(specifically AOUTMUX/O6) that indicates that a site PIP is used as part of
the pseudo PIP. However in this case, this edge does not block the site
wire, instead it only requires it. The following output BEL pin (specifically
AOUTMUX/OUT) blocks the site wire AMUX.
Future enhancements¶
Pseudo cells right now only have BEL pins used by the pseudo PIP. This ignores the fact that some BEL’s when route through may have constraint implications. For example, routing through a LUT BEL requires that it be in LUT mode. If that BEL is in either a SRL or LUT-RAM mode, the LUT route through may not operate properly.