[STA] Updated SDF File Generation to Include Min Delays

[AlexandreSinger]

The SDF file generated by the post-implementation netlist writer was only using the max delays of timing connections in the timing graph. In the SDF file, it set all values of the rising and falling triples to the max delay. When using this SDF file for external timing analysis, the minimum timing (hold) paths were incorrect.

Updated the netlist writer to work with triples instead of bare delays. This allows (minimum, typical, maximum) delays to be passed through the different functions and be printed cleanly. For standard delay signals in the circuit (not setup / hold times) Tatum provides the minimum delays. These are now being printed in the SDF file and the minimum timing paths are being found correctly in the external timing analyzer.

Cleaned up some parts of the netlist printing code as well. 1) netlist_writer.cpp declared many functions in the global scope which
may cause conflicts at link time in VTR. Put all of these methods in
anonymous namespace to prevent this.
2) The code was casting the delays from seconds to picoseconds in
strange places. This was tricky to work with since these are both
stored as doubles. Changed all of the code to only work with delays
in seconds, and only cast to picoseconds when printing.
3) General cleanup of the header file and the include files.

[AlexandreSinger]

@vaughnbetz Please review this PR when you have a moment. This PR adds the minimum timing delays to the SDF file generated by the post-implementation netlist writer. I tried to also improve the code where I could by encapsulating delay into a nicer class. I was not sure what to give for the "typical" delay of a timing arc, so I just set this to be the average of the minimum and maximum delays. Is this a reasonable thing to do, or is it more common to set it to the max / min? I do not think this value affects external timing analsis, but I just want to set it to something reasonable for now.

[AlexandreSinger]

@amin1377 FYI

[gigeresk]

Some unsolicited questions/comments:

• Should "typical" be stored here at all if it's fixed to being the avg of min and max for the foreseeable future?
• Why are the delays stored in seconds? Is this done consistently throughout VPR?
• The members here should be initialized to something (presumably quiet_nan)

[AlexandreSinger]

Always appreciate comments! I believe typical should be stored here since this class is just abstracting concept of delay triples. It will make it easier to update in the future if we allow the user of the delay triple to select what they would like for minimum, typical, and maximum independently.

Delays are stored in seconds since Tatum does the same (I think). Basically we do not convert the delays before storing them in this struct, they only get converted when printing. This was confusingly done before, so this class just tries to clean that up.

That is an excellent point on initializing the members to something! That could clean up some of the code elsewhere in that file. I will implement that now!

Thank you so much for the comments!

[vaughnbetz]

Yes, VPR and Tatum use SI base units everywhere. I think that's a good convention; no wondering if something is in pF or nF or ps or ns etc. So I'd stick with that and convert only on output if needed.

[vaughnbetz]

Looks good; a few suggestions.

[vaughnbetz]

I'd explain what post-implementation means here (post routing, implementation is complete).
merged_netlist_writer and netlist_writer don't seem like the best names. What do they do that is different? If the only difference is when they are called we wouldn't need two different routines.

I suggest renaming them to post_synthesis_netlist_writer and post_implementation_netlist_writer (or post_routing_netlist_writer if it can only be called after routing), and explaining what is different between them (where they get their delays? If they adjust the inputs to primitives based on what inputs were actually used after routing?).

[AlexandreSinger]

Hi Vaughn, I updated the comment slightly to include what post-implementation means in this context. These two methods are basically the same and are called in the same spot (during the analysis stage). The only difference is that the "merged" one merges the IO pins on the top-level module. The user selects which type of netlist to generate from the command line:

I am not sure why this second one is needed, but it really does not add much code. I am hesistent to change the name since I am not sure the context for why this merged netlist is needed.