• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Digital Implementation
  3. Propagated clock for reg2out

Stats

  • Locked Locked
  • Replies 9
  • Subscribers 92
  • Views 18115
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Propagated clock for reg2out

Aram Shahinyan
Aram Shahinyan over 12 years ago

Dear Friends,

I'm looking into Solution with ID 11327942. Can't figure out how clock latency 2.5ns is decided for reg2out paths

set_clock_latency 2.5 -rise clk2

 Can you please give me a hint?

 Thanks,

Aram

  • Cancel
Parents
  • fitz
    fitz over 12 years ago

    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]}]
     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • fitz
    fitz over 12 years ago

    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]}]
     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information