Make the FPGA architecture definition file format more composable (and possible templating?)

[mithro]

Currently the FPGA architecture definition file format makes it hard to define smaller bits of the definition which are then combined to create the full architecture definition.

An example is were you have many very similar FPGA types that are built out of very similar primitives or tile types. It would be good to be able to define the primitives and then include them together to build tiles which you can then include together to create an architecture.

I'm currently doing this by creating XML files with the xinclude directives and the using xmllint to expand the files before giving them to vpr. Eventually, I hope vpr will support the xinclude directives directly but that is a low priority and the xmllint preprocessing is a good work around.

This mostly works pretty well, however there are a few places it goes wrong. I'm creating this issue to record the places that I find that this doesn't work well.

I am also having to use Python to do template creation of parts that could also probably be done by some small extension of file format.

[mithro]

The first big thing I have run into is num_pb=X property on pb_type definition.

Frequently you have something like a generic flip flop which you want to include in multiple things. Sometimes you want 2 of them, sometimes you want 8, etc. By having the number in the pb_type you can't easily reuse the definition.

If instead multiple devices were done by an other object like pb_array or pb_repeat type thing which had a pb_type inside it, it would be easy.

Will post a little code example shortly.

[mithro]

There is a seperate language for the properties such as input / output on interconnects and the loc of the pin patterns. IE,

OBJ.Port
OBJ.Port[pin]
OBJ.Port[pin_from:pin_to]
{OBJ1.Port[pin] OBJ2.Port[pin]}
Maybe more?

I assume this is just like Verilog? It seems inconsistently supported and various parts cause segfaults...

It would be better if these were proper XML description?

[mithro]

For the num_pb issue see this somewhat contrived example below;

<!-- Tiles of type TILE_N3 have 3 frobbits -->
<pb_type name="TILE_N3">
  <xi:include href="frobbits.pb_type.xml" />
</pb_type>
<!-- Tiles of type TILE_N2 have 2 frobbits -->
<pb_type name="TILE_N2">
  <xi:include href="frobbits.pb_type.xml" />
</pb_type>

frobbits.pb_type.xml

<pb_type name="TILE_N2" num_pb="XXXXX">
  <snip>
</pb_type>

This would work if you had the following (because frobbits.pb_type.xml) doesn't have a repeat number in it any more.

<!-- Tiles of type TILE_N3 have 3 frobbits -->
<pb_type name="TILE_N3">
 <pb_array num_pb="3">
  <xi:include href="frobbits.pb_type.xml" />
 </pb_array>
</pb_type>
<!-- Tiles of type TILE_N2 have 2 frobbits -->
<pb_type name="TILE_N2">
 <pb_array num_pb="2">
  <xi:include href="frobbits.pb_type.xml" />
 </pb_array>
</pb_type>

[kmurray]

The idea of making the architecture description more compose-able is a good one. There is lots of duplication among the architectures in vtr_flow/arch which could be reduced by this.

The idea of moving num_pb into a separate tag (e.g. <pb_array>) seems reasonable. The num_pb has always been a bit subtle and a common source of mistakes, so <pb_array> may make the structure more explicit.

However, a change like this likely warrants further discussion. @vaughnbetz @KennethKent Any thoughts?