Macro (and similar) placement constraints

[gatecat]

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:

1. device resources just describes routing and constraints; and leaves pattern discovery implicitly up to the place and route tool
2. 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
3. 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.

[clavin-xlnx]

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.

[gatecat]

I've created a Google doc with some discussion on this issue here: https://docs.google.com/document/d/1-0RF7cuNoZl2t0McTYgoXyxXa_8Tqu3JFw9ZL7bLF-I/edit?usp=sharing

Google Docs

FPGA Interchange macros & chains

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...