You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, there is no specific constraints on the placement of cells within macros. As nextpnr currently only requires a legal site routing and nothing more, this currently results in a rather 'quirky' placement of something like a RAM128X1D, where route-through LUTs are used to legalise the MUXF7 inputs.
The more usual placement of a RAM128X1D, as done by Vivado (and the existing open source Xilinx flows), is to have all the cells in one site and using dedicated paths:
It should definitely be possible to infer the placement constraints based on site routing patterns, however there are always edge cases and I think there are some philosophical questions here:
how much should the device resources schema be describing the device; versus telling the PnR tool what to do
what about patterns like separate LUT6s and MUXF7s which are similar but without the extra 'guide' of a macro
what about carry chains?
finally, what about the dedicated LUT-FF path that is very much optional, and indeed better not to use in some rare cases, this is almost certainly something that the PnR tool should prefer based on routing
In general, I think there are three approaches possible here:
device resources just describes routing and constraints; and leaves pattern discovery implicitly up to the place and route tool
device resources is more explicit and includes explicit patterns, like whether a macro should be constrained to a site and which bels should be used
device resources is implicit as in (1) but there is a documented set of patterns that a functionally complete place and route tool consuming the format should be able to recognise
In general, I think the pros and cons of (1), and to some extent (3) are:
simpler schema
more flexibility to the place and route tool, at the expense of more complexity to recognise these patterns
potentially more generic to unusual patterns
less work to create device resources data, at the expense of being harder to debug if the place and route tool isn't producing the expected results
whereas the pros and cons of (2) are:
more complex schema
place and route tool development is simplified
format starts to become less 'data-driven' and more imperative
more work for the device resources data developer to identify these explicit patterns
I think these questions potentially affect a lot of other design decisions down the line, like clocking and advanced IO support, so I think it's worth having some discussions here and hearing what people think about this.
The text was updated successfully, but these errors were encountered:
If a macro placement is not quite correct, it will cause errors for Vivado. Perhaps in other flows/architectures, things can be more forgiving. However, in the context of Vivado, there probably has to be some sort of hint or direction provided in order to have a successful implementation with macros. However, I resonate with a simpler schema and less rigidity in specification. Ultimately, for the Interchange to succeed it has to find a careful balance here. Of the 3 approaches you suggested, I would more closely align with #3.
Macro placement constraints Macros are an expansion of one logical cell into a small, finite number of physical cells. In many cases a specific placement of those cells is intended, or even required. Examples of typical macros are: Distributed RAM (e.g. RAM128X1D) Complex IO (e.g. IOBUFDS) Dual o...
At the moment, there is no specific constraints on the placement of cells within macros. As nextpnr currently only requires a legal site routing and nothing more, this currently results in a rather 'quirky' placement of something like a RAM128X1D, where route-through LUTs are used to legalise the MUXF7 inputs.
The more usual placement of a RAM128X1D, as done by Vivado (and the existing open source Xilinx flows), is to have all the cells in one site and using dedicated paths:
It should definitely be possible to infer the placement constraints based on site routing patterns, however there are always edge cases and I think there are some philosophical questions here:
In general, I think there are three approaches possible here:
In general, I think the pros and cons of (1), and to some extent (3) are:
whereas the pros and cons of (2) are:
I think these questions potentially affect a lot of other design decisions down the line, like clocking and advanced IO support, so I think it's worth having some discussions here and hearing what people think about this.
The text was updated successfully, but these errors were encountered: