Added Optional Attribute to RRGraph

[saaramahmoudi]

Description

Using tileable option with openfpga branch, we have different ptc assignment in CHANX/CHANY nodes. To generate the same format rr graph while having tileable="true" and tileable="false", We added a new tag to tag while writing the rr graph.

The picture below shows the difference in ptc assignment in CHANX/CHANY nodes. The ptc number for each part of wire increase linearly with starting point ptc number (0) and a twist number (in this case would be 1)

So, the new generated rr graph looks like this:
<node dir="" id="" type="CHANX"><loc ptc="0" twist="1" layer="" xlow="" xhigh="" ylow="" yhigh">

To be backward compatible with previously generated rrgraphs for master branch (where the ptc number doesn't change across the CHANX/CHANY nodes), the twist attribute is not required value (it is optional).

Related Issue

@ganeshgore

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[saaramahmoudi]

@vaughnbetz

[vaughnbetz]

I think you can store this more efficiently, since a tileable architecture is fundamentally a flyweight.
(x,y,layer) -> rr_tile_data
rr_tile_data stores the ptc_twist_incr for each ptc_num.

We can land this in the interim if you like, but we should explore this flyweight. It would allow efficient storage of additional openFPGA data, as well as saving storage for this entry.

[saaramahmoudi]

@vaughnbetz all suggestions applied, ready to be merged.

[vaughnbetz]

It looks like this new vector is always allocated, so we'll have a memory footprint increase.

1. Please run a big titan circuit and document what the peak memory increase is (should be small I imagine but probably not negligible).
2. I think there should be an issue to either

• Not allocate this array when it is not needed or
• (even better) store it more efficiently by "flyweighting" the data (storing the data per unique tile, instead of per rr-node).
  If 2 can be done quickly I'd do it now. If there is time pressure to get this in and it can't be done now, we should have an issue tracking the update to improve memory footprint.

[saaramahmoudi]

@vaughnbetz

The vector is defined but won't be allocated unless the graph type is UNIDIR_TILEABLE (rr_graph.cpp line 1371). I just checked for the normal flow and the memory foot print is the same. I will attach the titan benchmark shortly.

I agree that we can move to fly-weighting at some point, but it can take time (I will create an issue for it to track it)

[vaughnbetz]

OK. In that case I think it's important to check the storage is allocate before accessing a member -- see my comment above.

[vaughnbetz]

Thanks for adding the check. This is good to merge once CI passes.

[rs-dhow]

Thanks for adding twist="#". Your picture at the start of this convo says 0,1,2,3,4, but your code comment says:
//For example, an L4 wire would change tracks 4 times with metal shorts [e.g. 0, 2, 4, 6] and track 6 would drive a switch -- together this implements an L4 wire with only one layout tile.
The latter is consistent with current twisted ptc numbers (for INC_DIR) so we're OK.

Since Mahdi's original change altered e.g.
node_lookup_.add_node(node, ix, iy, node_type, node_ptc_num, SIDES[0]);
to
node_lookup_.add_node(node, ix, iy, node_type, node_ptc_num + (i*twist), SIDES[0]);
I had assumed that (i) each coordinate already had a ptc number and (ii) we didn't need to save twist in the node.

I noticed the convo about "flyweight" attributes and saving memory. Since twist = (ptc of adjacent coordinate) - (ptc of xlow,ylow), there are reduction possibilities someday.

Thanks again.

[saaramahmoudi]

@vaughnbetz updated with master branch, ready to merge

[vaughnbetz]

Merging, but I think the long term solution should be to use a flyweight ... there is significant repeated data in this solution.