Support LUTRAM mode in FPGA fabric

[chungshien]

We would like to support LUTRAM mode, where CLB can be configured to dual-port RAM.

This feaure uniquely exposes the structure of config bits to the customer, we need to enhance OpenFPGA so that customer's view align with OpenFPGA's.

Few changes are needed.

Change 1 For QL Memory Bank Flatten BL/WL configuration mode: fix the WL size for CLB tile to be 32bits. Existing OpenFPGA will try to keep BL and WL in a square shape if possible (with BL might be one bit bigger than WL in some cases)

Change 2 (I am middle to understand other changes, will update more)

Describe the solution you'd like

Change 1

1. In architecture XML, introduce "num_wl" attirbute when we declare "pb_type" element
2. This attribute is optional, only special case like this need to specify "num_wl" attirbute, in this case set to 32
3. Eventually this attribute value will be stored/trasnferred as new variable "num_wl" introduced in t_physcial_tile_type class. By default the num_wl is 0 (hence the XML attribute is optional):

   If it is 0, OpenFPGA will maintain square shape BL vs WL if possible (original code) If it is non-0 (positive number), OpenFPGA will use it as hardcoded size as WL size

4. During build_physical_tile_module(), OpenFPGA will determine BL and WL size based on what had been desscribe in (3)
5. Only physical tile will be affected, other module building code (routing, grid etc) will not be impacted

[chungshien]

@tangxifan

FYI, this is something we planned to do.

I created the issue so that you can have early review.

Please comment if you have any concern.

[chungshien]

@alaindargelas

[tangxifan]

@chungshien @alaindargelas

I believe this is a good starting point to support LUTRAM. It is very reasonable to allow users to customize the size of BL/WL per block. However, I do not suggest to add them to the VPR architecture XML, which is designed for a logical/abstract -level representation. Instead, it should appear in OpenFPGA's architecture description language. A proper location to add the support is the fabric key file. For example,

<fabric_key>
  <module name="grid_clb" num_wls="32">

[tangxifan]

@chungshien @alaindargelas My vision is that the fabric key will offer these detailed customization in future. We will keep add more syntax to allow designers to customize any corner of their FPGA. The OpenFPGA's architecture file provides a high-level but rather general description.

[chungshien]

Hi @tangxifan

Thanks for reviewing. Any other place to put this info?

For us, we no longer use fabric_key.xml

So if possible, I would like to avoid fabric_key.xml, but if you really think this is the ONLY BEST way to do so, then I will look into it.

How about openfpga.xml

We can define it within "configuration_protocol", since this affect configuration bits arrangement.

[chungshien]

(@tangxifan @alaindargelas)

I had moved the original XML code from VPR architecture XML (originally suggested by Dana) to Openfpga architecture XML (suggested by Xi Fan)

I could see one extra benefit by doing so (even though the coding is more complex):

• I only need to PR to OpenFPGA repo
• Instead of PR into both OpenFPGA and vtr-verilog-to-routing repo

Latest code is committed into a branch via https://github.com/chungshien/OpenFPGA/commit/df5ce258e41df25a0b9c735c2353edf53efe09b1

Once PR https://github.com/lnis-uofu/OpenFPGA/pull/1566 is approved and merged, I could immediately PR to support this LUTRAM feature.

One thing to note: Xi Fan is suggesting define the support in fabric_key.xml, which our company is no longer using it. So in my latest code, I am doing it in openfpga.xml (see my previous comment). Example of XML would be

[alaindargelas]

@ganeshgore for review too.