Allow for heterogenous placements #1063
Comments
|
Thanks for filing the issue @litghost. I do not quite grasping what 'heterogeneous placement types' and 'Non-uniform physical to logical pin mappings' mean. Can you perhaps provide some examples and diagrams of what you want to model, and how these ideas would enable that? One thing we want to avoid is putting all of the complexity of the packer into the placement engine (see discussion of case 3 here where we note that we want to avoid making the architecture description too general since it would allow specifications of unroutable architectures, and note that with the newest equivalent tile code from #988 we currently support case 2). |
To address this specific concern, the modelling I'm talking about has no impact on packing, as the relevant logical tiles have zero within cluster connections. They are simply bels that are collocated at a routing graph location. |
Let's talk about this first. Consider the cmt tile in the 7 series graph. It contains several BELs, but they don't represent co clustered instances. The BELs at this tile are a couple ADC BELs, some fabric BELs (bitstream reset and reconfigure logic). Each of these BELs are really independently placeable instances, but they share a routing graph location. |
The current modelling language requires that a port have an location e.g. side and height and width offset. When capacity is added, all instances of the port share these values. In some cases, each instance of the port might need different height or width offsets, or even sides in stranger configurations. The example i gave was:
|
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
|
Basic change: [x][y].type to [x][y][z].type (where z in 0..capacity -1, i.e. a subblock). |
|
Discussion on case 3 of 36k vs. 18k RAMs: I suggest modeling 18k RAMs in the placement grid and using placement macros to tie two 18k together when necessary. Keith thinking about the SW engineering. |
I realized a downside to this approach, which is that the resource utilization will get filled with spam. If there are 32 global buffers, each with their own physical tile type, it will make the resource utilization harder to read. This isn't a huge problem, but it is less than ideal. |
|
You can re-use the same physical type when it is re-used in multiple places. So unless the physical implementation (pin-out) of all 32 buffers is truly different for all 32, you wouldn't need 32 different physical types. You'd have some number of different physical types, and then the 32 global buffers would each refer to the appropriate one. This is a bit like the horizontal and vertical IOs in many FPGAs: two physical types that most I/Os belong to. So while every I/O at an (x,y) could have a different physical type (and would have its own pointer/index into the physical type structure) in the end they'd wind up with only two different ids that were actually used. |
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
This implements part one of verilog-to-routing#1063 Signed-off-by: Keith Rothman <[email protected]>
|
This issue has been inactive for a year and has been marked as stale. It will be closed in 15 days if it continues to be stale. If you believe this is still an issue, please add a comment. |
|
This issue has been marked stale for 15 days and has been automatically closed. |
|
This upgrade was made; closing as completed. |
Uh oh!
There was an error while loading. Please reload this page.
Proposed Behaviour
Enable a tile definition that has the following properties:
Current Behaviour
Tile capacity causes a full duplication of the tile ports and each instance in the capacity stack must be identical.
Possible Solution
I believe this feature requires two steps:
Because in step #1 the relationship between physical tile ports and logical tiles was already made flexible, there should not be a problem once step #2 is implemented at the placer.
Context
The 7-series fabric has several instance of heterogeneous tiles, where multiple logical tiles that should be placed independently are co-located at the same routing location. While it is possible to split the tiles, it will further throw off the wirelength and lookahead calculations, and in the long term heterogeneous placement is likely desired.
In addition, there is some need to flexibility when it comes to homogeneous tiles. The current "duplicate the port" strategy is simple, but unrealistic. For example, in the 7-series fabric, the global clock tile has 16 instances. To take a single port example, the clock enable (CE) port on instance 1-4 should have a height offset of 0, 5-8 should have a height offset of 1, etc. The current strategy of duplicating ports does not accommodate this level of flexibility.
Note on simplicity and backwards compatibility
The plan is to add new flexible into the arch parser, rather than break backwards campatiplity. My current thinking is to add a capacity_type attribute that defaults to the current duplicate strategy. If the atttibute is missing, the capacity_type will be "duplicate" (e.g. duplicate the ports for each instance of capacity). The new capacity_type of "explicit" will not duplicate the ports. Instead, a custom pin mapping will be required to map the explicit ports to the logical instances.
The text was updated successfully, but these errors were encountered: