Add support for SRL16/SRL32

[mkurc-ant]

SRL16/SRL32 are another modes of operation of the SLICEM LUT part. Yosys now supports inferring them. FASM features required to activate SRL mode are already in the DB.

[mkurc-ant]

My findings so far:

• Each LUT can be put into SRL mode independently.
• A LUT can either function as 2xSRL16 (common delay select, independent in and out) or as 1xSRL32
• Each LUT (in SRL32 mode) has the MC31 output which always reflects 31st bit of the SR
• The MC31 of DLUT can goto DI1 of CLUT. The same is for CLUT,BLUT and BLUT,ALUT. This allow chaining SRL32s
• The MC31 of ALUT can be routed to the fabirc. Others can't be.
• There are ADI1MUX, BDI1MUX and CDI1MUX muxes used to route to corresponding SRL inputs.

I suggest to redefine the arch so we can have separate LUT models for SLICEM and SLICEL. This requires getting rid of the 'common slice' stuff. Each LUT of the SLICEM would then have 'LUT', 'SRL16' and 'SRL32' modes. There is also need to model muxes to the DI1 input.

[litghost]

I suggest to redefine the arch so we can have separate LUT models for SLICEM and SLICEL. This requires getting rid of the 'common slice' stuff. Each LUT of the SLICEM would then have 'LUT', 'SRL16' and 'SRL32' modes. There is also need to model muxes to the DI1 input.

Take a closer look at how SLICEL and SLICEM is defined. The common portion does not include the LUT's at all for the reasons you have identified.

[mkurc-ant]

Maybe I am missing something but I found common_slice/common_lut_and_f78mux.pb_type.xml explicitly included in both ntemplate.slicelN.pb_type.xml and slicem.pb_type.xml.

The difference is that the SLICEM have modes, where only one of them uses the "lut_and_f78mux" while others use DRAM stuff.

My suggestion is not to use the "lut_and_f78mux" for the mode "LUTs" in SLICEM but define individual instances of something like "lut_or_srl" for each LUT. With that we would be able to individually choose for each LUT whether it is a LUT or SRL.

Something like that for the beginning:

<pb_type name="nLUT6_OR_SRL32">
 ...
 <mode LUT6>
 ...
 </mode>
 <mode SRL32>
 ...
 </mode>
</pb_type>

But maybe I am not aware right now that it is not possible due to the way in which MUX6, MUX7 and MUX8 are modeled.

[litghost]

My suggestion is not to use the "lut_and_f78mux" for the mode "LUTs" in SLICEM but define individual instances of something like "lut_or_srl" for each LUT. With that we would be able to individually choose for each LUT whether it is a LUT or SRL.

In the case of the DRAM's, special care was required in the packing to ensure that the DLUT LUTRAM was used first. There may be a similiar requirement for SRL's. I'd start with a new top level SRL model, like the LUTRAM mode, rather than touching the LUTs mode.

[litghost]

https://github.com/SymbiFlow/symbiflow-arch-defs/pull/961