search

verilog-to-routing / vtr-verilog-to-routing

Verilog to Routing -- Open Source CAD Flow for FPGA Research
https://verilogtorouting.org
Other
1k stars 386 forks source link

Clock routing enhancements #971

Open vaughnbetz opened 4 years ago

vaughnbetz commented 4 years ago

Things to do to finish off the clock code:

  1. Support import of the clock network in an rr_graph.xml. I think this just needs a

    tag to be supported, and to identify the virtual clock sink.

  2. Add documentation to the vtr web site.

    • In the tutorial section, add the example from your thesis with the pictures of the network, showing how to build a rib and spine.
    • In the architecture reference section, add the available tags and their meanings. Pictures giving small examples would be helpful here too, or at least refer to the tutorial and its pictures.

  3. The placer should model the delay of global clock networks as a constant, ideally derived by walking the rr-graph. But even modeling the delay as 0 ns or a defined constant would be preferable to the current behaviour (that we think is happening, but I have not examined the code) of assuming regular routing (and hence high skew).

  4. The timing analyzer currently sends back slack ratios to guide optimization as sr = slack/max_arrival_time_for_this_constraint I believe that is causing a 1.6% critical path degradation from your results, due to the max_arrival_times_increasing with the clock network vs. ideal clocks. We should try changing this to sr = slack / max_datapath_delay_for_this_constraint (i.e. remove the clock delay)

For #4, probably need discussion with Kevin about how to do that. Since #4 is also an unproven theory about why we lose QoR and may be wrong, this should also be hacked to test the theory before doing any elegant coding. We can (and should) just subtract the clock delay (even as a constant) from the arrival time before dividing to check this theory.

kmurray commented 4 years ago

For (3) the relevant code is here: https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/vpr/src/place/place.cpp#L2238-L2287 which currently assumes the delay of 'ignored' nets is zero. But presumably when we are routing clocks the nets are no longer ignored and hence would get delays from the standard placement delay model (which at the moment won't account for the global clock network).

mustafabbas commented 4 years ago

(2) is complete here: PR https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/1104