image.png

I kind of follow the top part, although I don't know why 'v' is used. I looked that up in the source and it means falling edge

is it showing when the clock is falling? why 3?

in the top half the time is increasing

then in the bottom part, the time is decreasing

what does 'clock reconvergence pessimism' mean - all these things I have failed to google

and the opensta manual is just a reference for the commands

Here v shows data falling, 0.037 is the setup time of the DFF_X1, which is also the violating slack, as your input external delay matches the clock period.

@User Here v shows data falling, 0.037 is the setup time of the DFF_X1, which is also the violating slack, as your input external delay matches the clock period. Time is not decreasing, there are just 2 final calculations: clock riding edge - setup time = data required time 10.000 - 0.037 = 9.963 data required time - data arrival time = slack 9.963 - 10.000 = -0.037 OpenSTA reports are not special and very similar to others (Xilinx, Synopsys, etc.), so you'll find some docu\video on the internets.

Thanks @Tobias Strauch

yes they do look a bit similar, but I've not seen another with the ^ V before

the first set of 3 v are to do with data falling edge, and the ^ isrising edge of clock?

the top part is split into 2

image.png

I don't follow why at 0 and 10 we have the clock rise edge

is it 2 subsequent clock cycles?

@Matt Venn I would say an STA report has 4 sections 1) Insertion delay to startpoint 2) (Adding) delay btw startpoint and endpoint => data arrival time 3) Insertion delay to endpoint (adding clock period for max) => data required time 4) Calculations of slack using data arrival time, data required time, setup|hold time => slack If you want to skip insertion delay report (-no_splash option possibly???), or if you are in an idealistic world on RTL, then section 1) and 3) are not shown or are 0. The starting point is an input as your second last pic indicates, so the insertion delay to the startpoint is 0. Look at it as if the external input is "clocked" by the same clock to fit into this reporting scheme. I assume that you have an input delay set somewhere, which is 10 ns. But that is only a guess based on the report. For this input to register line the data arrival time = input delay. The clock period is 10 ns (I guess), it shows up because it is a max report, and the DFF insertion delay is 0, so the data required time is 10. The calculations I mentioned above. So I would play with the clock period (e.g. 9 ns) or the input delay (e.g. 12 ns) to see how that affects the report. PS: Always nice to have these discussions within one thread for reference.

Hi! My name is Andras Tantos and I'm new to these forums, so please let me know if I ask the wrong question in the wrong place. I have a project that I try to get synthesized on the OpenLane flow. The flow (more or less) succeeds, but fails timing closure. When I look at the 11-cts_rsz_sta.rpt file, I get path reports like this: =========================================================================== report_checks -unconstrained ============================================================================ Startpoint: 16382 (rising edge-triggered flip-flop clocked by clk') Endpoint: dram_addr[1] (output port clocked by clk) Path Group: clk Path Type: max Fanout Cap Slew Delay Time Description ----------------------------------------------------------------------------- 5.00 5.00 clock clk' (rise edge) 0.00 5.00 clock source latency 0.08 0.06 5.06 v clk (in) 1 0.04 clk (net) 0.08 0.00 5.06 v clkbuf_0_clk/A (sky130_fd_sc_hd__clkbuf_16) 0.04 0.17 5.23 v clkbuf_0_clk/X (sky130_fd_sc_hd__clkbuf_16) 2 0.02 clknet_0_clk (net) 0.04 0.00 5.24 v clkbuf_1_1_0_clk/A (sky130_fd_sc_hd__clkbuf_8) 0.03 0.14 5.37 v clkbuf_1_1_0_clk/X (sky130_fd_sc_hd__clkbuf_8) 1 0.01 clknet_1_1_0_clk (net) 0.03 0.00 5.37 v clkbuf_1_1_1_clk/A (sky130_fd_sc_hd__clkbuf_8) 0.04 0.15 5.52 v clkbuf_1_1_1_clk/X (sky130_fd_sc_hd__clkbuf_8) 2 0.02 clknet_1_1_1_clk (net) 0.04 0.00 5.52 v clkbuf_2_2_0_clk/A (sky130_fd_sc_hd__clkbuf_8) 0.04 0.15 5.67 v clkbuf_2_2_0_clk/X (sky130_fd_sc_hd__clkbuf_8) 2 0.02 clknet_2_2_0_clk (net) 0.04 0.00 5.67 v clkbuf_3_4_0_clk/A (sky130_fd_sc_hd__clkbuf_8) 0.19 0.28 5.96 v clkbuf_3_4_0_clk/X (sky130_fd_sc_hd__clkbuf_8) 17 0.18 clknet_3_4_0_clk (net) 0.19 0.00 5.96 v clkbuf_leaf_91_clk/A (sky130_fd_sc_hd__clkbuf_16) 0.05 0.24 6.20 v clkbuf_leaf_91_clk/X (sky130_fd_sc_hd__clkbuf_16) 18 0.05 clknet_leaf_91_clk (net) 0.05 0.00 6.20 v _08138_/A (sky130_fd_sc_hd__buf_1) 0.05 0.12 6.32 v _08138_/X (sky130_fd_sc_hd__buf_1) 1 0.01 03255 (net) 0.05 0.00 6.32 v clkbuf_0__03255_/A (sky130_fd_sc_hd__clkbuf_16) 0.03 0.16 6.48 v clkbuf_0__03255_/X (sky130_fd_sc_hd__clkbuf_16) 2 0.02 clknet_0__03255_ (net) 0.03 0.00 6.48 v clkbuf_1_1__f__03255_/A (sky130_fd_sc_hd__clkbuf_16) 0.04 0.15 6.63 v clkbuf_1_1__f__03255_/X (sky130_fd_sc_hd__clkbuf_16) 5 0.02 clknet_1_1__leaf__03255_ (net) 0.04 0.00 6.63 v _08991_/A (sky130_fd_sc_hd__buf_1) 0.09 0.14 6.77 v _08991_/X (sky130_fd_sc_hd__buf_1) 1 0.01 04038 (net) 0.09 0.00 6.77 v clkbuf_0__04038_/A (sky130_fd_sc_hd__clkbuf_16) 0.03 0.17 6.94 v clkbuf_0__04038_/X (sky130_fd_sc_hd__clkbuf_16) 2 0.02 clknet_0__04038_ (net) 0.03 0.00 6.94 v clkbuf_1_0__f__04038_/A (sky130_fd_sc_hd__clkbuf_16) 0.05 0.16 7.10 v clkbuf_1_0__f__04038_/X (sky130_fd_sc_hd__clkbuf_16) 6 0.04 clknet_1_0__leaf__04038_ (net) 0.05 0.00 7.10 v _13735_/A (sky130_fd_sc_hd__buf_1) 0.06 0.12 7.22 v _13735_/X (sky130_fd_sc_hd__buf_1) 1 0.01 07471 (net) 0.06 0.00 7.22 v clkbuf_0__07471_/A (sky130_fd_sc_hd__clkbuf_16) 0.03 0.16 7.38 v clkbuf_0__07471_/X (sky130_fd_sc_hd__clkbuf_16) 2 0.02 clknet_0__07471_ (net) 0.03 0.00 7.38 v clkbuf_1_1__f__07471_/A (sky130_fd_sc_hd__clkbuf_16) 0.04 0.16 7.53 v clkbuf_1_1__f__07471_/X (sky130_fd_sc_hd__clkbuf_16) 5 0.03 clknet_1_1__leaf__07471_ (net) 0.04 0.00 7.53 v _13737__23/A (sky130_fd_sc_hd__inv_2) 0.02 0.04 7.57 ^ _13737__23/Y (sky130_fd_sc_hd__inv_2) 1 0.00 net59 (net) 0.02 0.00 7.57 ^ _16382_/CLK (sky130_fd_sc_hd__dfxtp_1) 0.03 0.30 7.87 v _16382_/Q (sky130_fd_sc_hd__dfxtp_1) 1 0.00 bus_if.u170_output_port[1] (net) 0.03 0.00 7.87 v _08163_/A1 (sky130_fd_sc_hd__mux2_4) 0.11 0.34 8.21 v _08163_/X (sky130_fd_sc_hd__mux2_4) 1 0.05 03270 (net) 0.12 0.01 8.23 v _08164_/A (sky130_fd_sc_hd__buf_6) 0.03 0.16 8.38 v _08164_/X (sky130_fd_sc_hd__buf_6) 1 0.01 net14 (net) 0.03 0.00 8.38 v output14/A (sky130_fd_sc_hd__buf_6) 0.04 0.14 8.52 v output14/X (sky130_fd_sc_hd__buf_6) 1 0.03 dram_addr[1] (net) 0.04 0.00 8.52 v dram_addr[1] (out) 8.52 data arrival time 10.00 10.00 clock clk (rise edge) 0.00 10.00 clock network delay (propagated) -0.25 9.75 clock uncertainty 0.00 9.75 clock reconvergence pessimism -2.00 7.75 output external delay 7.75 data required time ----------------------------------------------------------------------------- 7.75 data required time -8.52 data arrival time ----------------------------------------------------------------------------- -0.77 slack (VIOLATED)

Can you help me in relating the entities in the list to the source code? As is, it is int terribly actionable on my side.

Thanks a bunch!

Hi everyone, when writing an SDC file for OpenLane, is there a way to get a pin or instance by it's hierarchical path name? This is how I am used to accessing pins when I have set up constraints for a Cadence design flow. For example, in my design, I have a top level

mp_serializer_top

, which contains the instance

serializer_inst

, which has a pin

dest_clk_i

. I have tried the following commands:

get_pins "serializer_inst/dest_clk_i"
get_pins "serializer_inst.dest_clk_i"
get_pins -hsc "/" "serializer_inst/dest_clk_i"
get_pins "\\serializer_inst/dest_clk_i"
get_pins "mp_serializer_top/serializer_inst/dest_clk_i"
get_pins "\\mp_serializer_top/serializer_inst/dest_clk_i"

However, they all fail (saying pin cannot be found) Also, when I try to see a list of all pins with

get_pins *

, it returns:

_9031d90700000000_p_Pin _2033d90700000000_p_Pin _7033d90700000000_p_Pin ...

as if the design has been flatted and all original names removed. So I don't even have an example of what a correct pin name is. When looking at SDC scripts posted by others on this channel, it seems like accessing pins in this way is commonly done... What am I missing? Any help appreciated, thank you!

Greetings, Q1: Is it possible to report the shortest setup path in OpenSTA ? (not to be confused with hold-time check) I’m thinking of moving from my own (hobby-level) STA engine to the way more professional OpenSTA tool, but I need at least the shortest setup path. Do I miss something in the OpenSTA docs ? Q2: Is it possible to display a timing histogram in OpenSTA ? Thanks a lot in advance.

In a project build by openlane, what’s the best way to have OpenSTA report the delay from X1.Y to X1.A for the structure below, but on the extracted netlist for a given corner? I think I know how to do a -from -to delay calc but I am mostly sure it’s not using the extracted netlist and I am not sure what corner is being used.

image.png

Maybe it’s best to do it outside of openlane and make a mini TCL script for OpenSTA? Something like:

read_liberty example1_slow.lib
read_verilog example1.v
link_design top
read_sdf example1.sdf
read_spef example1.spef
set_data_check -fall_from X1.Y -to X1.A -hold $H
report_checks

And it will measure the delay and compare against the hold requirement. This way I can be sure is at least $H long, and also get the prediction from the log.

Anyway, suggestions on the best way to go about this would be appreciated.

Oh ya, I’m also guessing the gate netlist, SDF and SPEF in runs/<RUN>/results/final are the ones to use. But I must be doing something wrong in the script template above as I get many warnings of the form “Warning: example1.sdf line $L, instance $I not found”, report_annotated_delay is showing me only like half of the cell and internal arcs are annotated, and report_dcalc doesn’t print anything, which I believe is consistent with missing timing arcs.

@Tobias Strauch Thanks! I think it worked. I even got a number that is plausible for the delay. 🙂. My script was:

read_liberty example1_slow.lib
read_verilog example1.v
link_design top
read_sdf example1.sdf
read_spef example1.spef
report_checks -unconstrained -format end -through {X1/Y} -to {X1/A}

Does that seems like a reasonable way to do it? @Vijayan Krishnan I’ll try to make a small test case that demonstrates the report_annotated_delay issue.

@Xiaochen Ni has left the channel

I have some ring oscillator designs submitted to MPW6. I now have a sample as this was one of the designs used for validating the caravel fixes. I'm looking at how close the STA predicts the ring frequency compared to what I measure. The SDF file seems to be incorrect though, with delays of 0ps. I think this is because back at MPW6, the timing wasn't so good. Can I use openRCX to re-extract the SDF from the GDS? @Matt Liberty do you have any ideas?