Closed gatecat closed 3 years ago
Parameter transforms we would probably want to support:
GitHub
nextpnr portable FPGA place and route tool. Contribute to YosysHQ/nextpnr development by creating an account on GitHub.
@gatecat - I don't /think/ we want to support these types of transforms in the interchange format. Instead I think we want to make the synthesis tool do the work?
Macro transforms are currently part of the interchange format, and discussions with litghost concluded that they were in scope, because of the potential complex interactions between macro expansions and placement (and for example, how macro expansions only affect the physical and not logical netlist) mean they will be something that nextpnr-interchange supports.
See SymbiFlow/nextpnr#264 for some more discussion (I might be able to dig out some IRC logs about this too).
@gatecat - Just confirming, #264 is converting a single block into multiple blocks, right?
Yes, but importantly only from a physical netlist point of view and not from a logical netlist point of view.
This looks to be the relevant section?
Looks like @litghost didn't write down all that much about what he planned to do here - https://fpga-interchange-schema.readthedocs.io/device_resources.html#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.
This looks to be the relevant section?
Nope, that's totally different. That's describing how physical cells map onto bels.
Macro expansions are about creating a hierarchy of multiple physical cells out of a single logical cell (which then follow those rules to map onto bels, for example a RAMD64E onto a LUT6 bel); as used for LUTRAM, complex IO, etc.
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.
This affects more than just the place and route problem, it also affects FASM generation for example.
There isn't, imo, a great philosophical debate to be had here, just a relatively simple omission from the macro expansion rules (which are otherwise well documented in #264).
I think the two ways of solving this would be:
LogicalNetlist
includes functionality that is specific to macros and illegal elsewhereLogicalNetlist
.@gatecat - I think either approach could work, do you want to try both and see which works better? @clavin-xlnx - Do you have an opinion?
Yes, deriving parameter values on the primitives as a function of the parent's value makes sense to me. Given the two options, I would probably prefer the latter (augmenting PrimToMacroExpansion) just to keep the scope of the solution tight.
Fixed by #42
Consider the following design with initialized LUTRAM, for the xc7:
Opening the implemented design in Vivado and running:
you can see that the
INIT
parameter of theRAM128XD
macro has been split into two for the constituent cells.Currently the schema appears to have no way to describe a parameter mapping like this, which will need to be fixed to support initialised LUTRAM and some other macros like
LUT6_2
.cc @clavin-xlnx as I don't think RapidWright currently provides this kind of data either?