Propagated clock for reg2out

Aram

We always referenced ip / op delays relative to a "virtual" clock.
This virtual clock must track the real clock before and after CTS.
You can automatically update the virtual clock after CTS with the command update_io_latency.
I know this whole flow / syntax sucks, but primeTime has been doing it this way since the beginning of time.

Cadence  set_output_delay supports -reference_pin pin_name syntax which would be perfect IF pt_shell also supported it.

Shawn

preCTS ideal .............................................
create_clock -name LINE_CLK -period 3.236 -waveform { 0 1.618 } [get_ports {i_LINE_CLK}]
set_clock_transition         0.150 [get_clocks {LINE_CLK}]
set_clock_uncertainty -setup 0.110 [get_clocks {LINE_CLK}]
set_clock_latency            2.200 [get_clocks {LINE_CLK}]

create_clock -name LINE_VIRT_CLK -period 3.236 -waveform { 0 1.618 }
set_clock_transition         0.150 [get_clocks {LINE_VIRT_CLK}]
set_clock_uncertainty -setup 0.110 [get_clocks {LINE_VIRT_CLK}]
set_clock_latency            2.200 [get_clocks {LINE_VIRT_CLK}]

set_output_delay  1.6 -clock [get_clocks {LINE_VIRT_CLK}]  [get_ports {ov_fltr_y_din[1537]}]


postCTS propagated & virtual clock updated .............................................
create_clock -name LINE_CLK -period 3.236 -waveform { 0 1.618 } [get_ports {i_LINE_CLK}]
set_clock_transition         0.150 [get_clocks {LINE_CLK}]
set_clock_uncertainty -setup 0.110 [get_clocks {LINE_CLK}]
set_propagated_clock               [get_clocks {LINE_CLK}]


create_clock -name LINE_VIRT_CLK -period 3.236 -waveform { 0 1.618 }
set_clock_transition         0.150 [get_clocks {LINE_VIRT_CLK}]
set_clock_uncertainty -setup 0.110 [get_clocks {LINE_VIRT_CLK}]
set_clock_latency -fall 1.99566  [get_clocks {LINE_VIRT_CLK}]
set_clock_latency -rise 1.97041  [get_clocks {LINE_VIRT_CLK}]

set_output_delay  1.6 -clock [get_clocks {LINE_VIRT_CLK}]  [get_ports {ov_fltr_y_din[1537]}]
 

 Hello Shawn,

Thanks for your responce. This gives an idea how it works, but my question really is how the numbers are calculated. 

Have you looked into Solution ID:11327942 ?

create_clock -name clk2 -period 2.0 -waveform {0 1.0} [get_ports {CK}]

set_propagated_clock [get_ports {CK}]

 set_clock_latency 2.5 -rise clk2 <==== To insert clock delay

So the question really is how 2.5ns is calculated?

Thanks,

Aram

Sorry. I did not read Solution ID:11327942 before responding.
The clock network latency is not calculated, initially it is a  educated guess-timate until CTS is run multiple times and it's results stabilize.
On subsequent runs the new value becomes an accurate preCTS estimate until the final CTS at which point it becomes the actual measured / reported value.
set_clock_latency evolves ......  guess > estimate > measured

 Shawn

 Thanks You Shawn,

In other words I can look into timing report to see the time from clock pin (going through buffers) to the flop and put it as

clock latency, right?

Best Regards,

Aram

 Hello Shawn,

I have tried to set set vars(update_io_latency) {true} in my foundation flow, but clock latency is still not propagatedin reg2out

Am I missing anything?

Thanks,

Aram

See my first response....................

We always referenced ip / op delays relative to a "virtual" clock.
This virtual clock must track the real clock before and after CTS.
You can automatically update the virtual clock after CTS with the command update_io_latency.

We have been doing it this way for so long I forgot  the reason why, but there must be a valid reason to put me through decades of pain .
If you are doing anything different, like setting the output delay relative to the "actual" clock, sorry you are on your own.


Shawn

Hi Shawn,

 Thanks a lot for your help! It worked for me!

Best Regards,

Aram

Hello

I am facing a problem while using the command update_io_latency

after i run the command. I used timeDesign to save the reports. But io_latency is not saved in the report folder. Is there anything that I could check to make sure io_latency is updated.