The-OpenROAD-Project
Add feature to automate handling of clock insertion latency of Element in mock-array and mock-array itself
Description
The Element in the mock-array and mock-array itself has a clock insertion latency.
The idea is that this clock insertion latency will keep increasing as one goes up in the design levels until at the top level everything is connected to an asynchronous FIFO, probably connected to a bus, at which point the entire clock insertion latency is "absorbed" by this asynchronous FIFO.
This is what is happening in e.g. Chipyard MegaBoom.
Suggested Solution
Add support for automatically handle the clock insertion latency in mock-array and mock-array/Element.
Additional Context
No response
@rovinski A rough prototype... https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/1801
@oharboe is this a good example of the path that we want to push the clock latency into the Element for?
openroad> report_checks -through [get_cells ces_6*]
Startpoint: ces_6_1 (rising edge-triggered flip-flop clocked by clock)
Endpoint: ces_6_5 (rising edge-triggered flip-flop clocked by clock)
Path Group: clock
Path Type: max
Delay Time Description
---------------------------------------------------------
0.00 0.00 clock clock (rise edge)
263.75 263.75 clock network delay (propagated)
0.00 263.75 ^ ces_6_1/clock (Element)
219.48 483.24 v ces_6_1/io_lsbOuts_7 (Element)
36.82 520.06 v ces_6_2/io_lsbOuts_6 (Element)
39.84 559.89 v ces_6_3/io_lsbOuts_5 (Element)
40.28 600.17 v ces_6_4/io_lsbOuts_4 (Element)
0.00 600.17 v ces_6_5/io_lsbIns_4 (Element)
600.17 data arrival time
320.00 320.00 clock clock (rise edge)
252.48 572.48 clock network delay (propagated)
-10.00 562.48 clock uncertainty
2.25 564.73 clock reconvergence pessimism
564.73 ^ ces_6_5/clock (Element)
84.91 649.64 library setup time
649.64 data required time
---------------------------------------------------------
649.64 data required time
-600.17 data arrival time
---------------------------------------------------------
49.46 slack (MET)
@tspyrou Unsure what you mean by "push the clock latency into the Element". This is a good example of where it is critical that the CTS at the mock-array level takes the clock latency within the Element into account.
It is also an example of where it is useful to know the clock latencies within the Element: when does the clock reach the flip flop and how much logic/buffers are there before/after the flip flop. I usually dive into the Element reports for details, but it would be nice to be able to surmise an overview from the mock-array level reports.
https://github.com/parallaxsw/OpenSTA/blob/b6cdea9566032fa3d5d2dbc09f5857a028458812/tcl/StaTcl.i#L4930 set paths [find_timing_paths -through [get_cells ces_6*]] set path [lindex $paths 0] $path slack # This is the latency of the destination clock $path target_clk_delay # This is the target clock arrival time including the waveform $path target_clk_arrival
@oharboe with the above code snippet, we can calculate the latency for a representative path and use it when optimizing the blocks so the i/o paths won't be over fixed for hold.
Right now the flow is that the top checks for the blocks, runs the blocks if they are not there, and then runs the top. We could iterate again or we could store the latency in a file and update that file when the top runs saving a new value for next time. What did you have in mind?
@tspyrou Ref. https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/1911#pullrequestreview-1978697804, I need an example of how mock-array/Element uses this information to piece together what is going on at the EDA domain level.