Override edge attributes in RR graph

[soheilshahrouz]

Adds a new command line option to override attributes of specific edges in the RR graph.

Description

The user can pass a text file using --read_rr_edge_override, which modifies the delay of selected edges. The expected file format:

# edge    Tdel   
64812     5.9e-11 
9981      4.2e-11   
1234      7.1e-11   
4321      9.4e-11
(42, 64)  7.3e-11

The first line must start with # and is always ignored by the parser.
Each following line must include an RR edge ID and delay (Tdel). Other attributes (resistance, capacitances) are optional. Edges can also be specified using source/sink node pairs.

How Has This Been Tested?

By manual inspection of generated RR graph files to see if the edge attributes are overridden correctly.

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

[soheilshahrouz]

@petergrossmann21 I'd apprecite any feedback on this

[amin1377]

Overall, this looks good to me. I’ve added several small comments, mainly related to adding comments. :)

One more thing—I think it would be good to add a test for this PR. As we discussed, testing this requires additional functionality beyond what the current infrastructure provides. I suggest creating an issue to track it, and we can implement it in a separate PR.

[amin1377]

I also needed to do something similar when creating edges while collapsing RR Node chains in the flat router. If you could create an issue to remind me to implement a function for this, that would be helpful.

[amin1377]

Now that I think about it, I'm pretty sure I wrote a function that retrieves switch info, searches the RR Node switches for one with similar characteristics, and, if none is found, creates a new one and returns the corresponding RR switch ID (I think the name was something like get_or_create_rr_switch_id). In the issue I mentioned, if you could reference this function, I'll update this part of the code myself.

[petergrossmann21]

@soheilshahrouz Some initial thoughts:

• I think it might be beneficial to separate RC parameters from Tdel parameters. While it's nice to lay out all the parameters together, I don't think per-edge RC annotation makes sense. R and C are node properties rather than edge properties (see https://docs.verilogtorouting.org/en/latest/vpr/file_formats/#routing-resource-graph-file-format-xml) . So even if both parameter types are specified in a single file, I would recommend capturing them on separate lines of text, each with their own syntax. Separate files would also be fine, if slightly less elegant (see aside below)
• The (src_node #, sink_node #) notation is definitely useful, as it addresses scenarios where the generator of the file does not have integer IDs for edges available during delay annotation (this happens to be the case for me, but is more generically useful because the node IDs can be reliably associated with the nets in the FPGA circuit that are used in delay capture, whereas I think edge ID associations are less reliable).
• A quick sanity check on file format size: in the general case, there will be some number of bytes per edge to specify the edge ID and delay parameters. I currently develop relatively small, routing-rich architectures and am typically working with node counts at O(10K) and edge counts at O(100K). If 6 digits of precision are supplied per delay parameter, plus five characters to format in scientific notation ('.', 'e-XX'), then each delay parameter formatted in (src_node #, sink_node #) notation uses up to 27 bytes (5 for each node ID, 5 more to format them and space them apart from the delay, and then 11 for the delay constant and one for the carriage return). For a 500K-edge graph that works out to 13.5 MB -- not small, but not unworkable. This supports an architecture with O(1K) LUTs. for something with O(100K) LUTs, we would expect the file to be 100X larger, i.e. O(1GB).

I think the file size analysis above is sufficient to motivate implementing some method of shorthand in the file format so that the architect can express when multiple edges have the same delay parameter. My first instinct is that some kind of relationship between the physical tile definitions and the graph edges can help with this. Currently, the way that I do that is by relating switches in the <switchlist> section of the architecture XML to different physical tile types in my XML generator.

An aside: Note that in automatic place and route flows for ASICs, the R and C values are either not generated at all (because the wire delay is lumped with the "intrinsic" delay of the logic gates and so the VPR model will set all the RC values to 0) OR the intrinsic delay is captured independently of the RC values and thus it's convenient to annotate them separately anyway.

[petergrossmann21]

@soheilshahrouz one additional thought: if the delay annotation is to be performed as a standalone step, having a dedicated executable utility to run it will be helpful--this will avoid having to call vpr for this step and having to pass in an arbitrary blif file.

[vaughnbetz]

LGTM, thanks!
I'd like to beef up the error-handling on the file input though. Try to make sure any invalid file you can detect gives an error message.

Also, you should update the documentation.

• File format (give the format, but also the motivation / use cases)
• Command line option