Macro parameter mapping

[gatecat]

Consider the following design with initialized LUTRAM, for the xc7:

module top(
    input clk, we,
    input [6:0] wa, ra,
    input wd,
    output [1:0] rd
);
    RAM128X1D #(
        .INIT(128'hFFEEDDCCBBAA99887766554433221100)
    ) ram_i (
        .WCLK(clk), .WE(we),
        .A(wa), .DPRA(ra),
        .D(wd),
        .SPO(rd[0]), .DPO(rd[1])
    );
endmodule

Opening the implemented design in Vivado and running:

get_property INIT [get_cells ram_i/DP.LOW]
64'h7766554433221100
get_property INIT [get_cells ram_i/DP.HIGH]
64'hFFEEDDCCBBAA9988

you can see that the INIT parameter of the RAM128XD 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?

[gatecat]

Parameter transforms we would probably want to support:

• just copying parameters across
• taking a slice of a parameter (as in this example)
• taking every N^th bit of a parameter (required for Nexus LUTRAM: https://github.com/YosysHQ/nextpnr/blob/3fd1ee7757356660c7f440705553d345837eaed5/nexus/pack.cc#L992-L994)
• table lookups for string parameters (don't have a concrete example but may well crop up in some IP/IO use cases)

GitHub

YosysHQ/nextpnr

nextpnr portable FPGA place and route tool. Contribute to YosysHQ/nextpnr development by creating an account on GitHub.

[mithro]

@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?

[gatecat]

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

[mithro]

@gatecat - Just confirming, #264 is converting a single block into multiple blocks, right?

[gatecat]

Yes, but importantly only from a physical netlist point of view and not from a logical netlist point of view.

[mithro]

This looks to be the relevant section?

https://github.com/SymbiFlow/fpga-interchange-schema/blob/5208d794d318e9151b93120d7e5ba75d8aef45e7/interchange/DeviceResources.capnp#L267-L286

[mithro]

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

Device Resources — SymbiFlow FPGA Interchange Format 0.0-53-g5208d79 documentation

[mithro]

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.

[gatecat]

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

[gatecat]

I think the two ways of solving this would be:

• extending https://github.com/SymbiFlow/fpga-interchange-schema/blob/5208d794d318e9151b93120d7e5ba75d8aef45e7/interchange/LogicalNetlist.capnp#L162-L166 to include a "this property is derived following a rule from a property of the parent". This is quite a neat solution, but does now mean LogicalNetlist includes functionality that is specific to macros and illegal elsewhere
• adding a parameter mapping rule section to https://github.com/SymbiFlow/fpga-interchange-schema/blob/5208d794d318e9151b93120d7e5ba75d8aef45e7/interchange/DeviceResources.capnp#L242-L245 that specifies how parameters map from the parent primitive to cells in the macro. This avoids adding any complication to LogicalNetlist.

[mithro]

@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?

[clavin-xlnx]

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.

[gatecat]

Fixed by #42