-
Notifications
You must be signed in to change notification settings - Fork 439
Description
Context
When the location is fixed, in a fabricated FPGA, the timing is deterministic and easy to debug.
This can avoid unexpected timing changes when CAD tools are upgrading for a fabricated FPGA device.
The following is an example where a LUT and a FF are mapped to two fixed location in a CLB, as they drive external FF with a fixed timing path.

Proposed Behaviour
For timing convergence between FPGAs and external chips, users may need to fix the location of atom blocks that directly drive the external chips. The atom blocks could be LUTs, FFs, heterogeneous blocks.
The VPR constraints is the most proper file to add such constraints.
-
Take the example of the VPR architecture k4_N4_tileable_90nm.xml
-
Consider a simple benchmark as and2_latch
.model and2_latch
.inputs a b clk
.outputs c d
.latch n1 d re clk 0
.names a b c
11 1
.names c n1
1 1
Assume a 2x2 (core size) layout, the following constraints to the fix the location when mapping two atom blocks .latch and .names.
<vpr_constraints tool_name="vpr">
<partition_list>
<partition name="fix_pb_mapping_loc">
<add_atom name_pattern="d" logical_block_location="clb[0].fle[2]{n1_lut4}.ble4[0].ff[0]"/>
<add_region x_low="2" y_low="1" x_high="2" y_high="1"/>
</partition>
<partition name="fix_pb_mapping_loc">
<add_atom name_pattern="n1" logical_block_location="clb[0].fle[3]{n1_lut4}.ble4[0].lut4[0]"/>
<add_region x_low="2" y_low="2" x_high="2" y_high="2"/>
</partition>
</partition_list>
</vpr_constraints>
Note that the new syntax logical_block_location is proposed to constrain the exact location in the logical block clb, where
- the mappable location is defined as
<pb_type_name>[<placement_index>]{<mode_name>} - the fully hierarchy is a cascading of the mapping location
<pb_type_name>[<placement_index>]{<mode_name>}. ... .<pb_type_name>[<placement_index>]{<mode_name>}
Note that the default mode can be omitted when the pb_type has only 1 mode.
But the placement index must be provided.
The packer may error out if the constraints are too tight and unable to create a clustered block (for instance, not routable inside a clustered block)
Current Behaviour
Currently, users can only
- fix the location for a clustered block
- constrain what atom blocks to be included in a cluster block
- constrain atom blocks to be mapped to a specific type of clustered block
But it miss the feature that
- constrain the exact location of atom block to be in a cluster block.