• 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. Logic Design
  3. RTL compiler inner clock definition

Stats

  • Locked Locked
  • Replies 6
  • Subscribers 63
  • Views 9552
  • 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

RTL compiler inner clock definition

EvgeniySUAI
EvgeniySUAI over 14 years ago

 Hi developers! :)

I've faced with problem with defining of timing constraint in RTL Compiler. In my design inner clock is generated based on signals from two input pins (xor on two signals actually).  How can i tell to RTL Compiler, that this inner signal is a clock? I tried create_generated_clock, but it allows to define generated clock only based on some input pin. This is unacceptable for my design. It also seems to me, that create_generated_clock can be used only for creating clock on outputs of deviders or pll.

Thanks in advance, Evgeniy

 

 

  • Cancel
  • prakashpmc
    prakashpmc over 14 years ago

    I would try creating a module whose output is the needed clock. From there on, it would be a input pin for rest of the design.You can also possibly create  constraint as it is an output for the module. This change would fit the RTL compiler requirements.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • EvgeniySUAI
    EvgeniySUAI over 14 years ago

     Thank you very much for the answer. For me it's very important to learn how to define clocks on design inner signals. It was the requirement for my project.  So i did this in the following manner:

    set C_D [define_clock -name CLOCK_D -domain d_5 -period 10000 [find /designs/upper_prj/inner_comp -pin q]]

    RTL compiler did not tell me anything bad about this construction. Is it ok, how do you think?

     

    Thanks in advance, Evgeniy

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • prakashpmc
    prakashpmc over 14 years ago
    Give it a try and see what happens!

     

    -Prakash
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • EvgeniySUAI
    EvgeniySUAI over 14 years ago

     I'll try, thank you =)

    Evgeniy

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • grasshopper
    grasshopper over 14 years ago
    HI Evgeniy,

    Can you please describe the constraint and circuit in full. You can define a clock on an internal node if you wanted to and this is also the case for generated_clock. The question is not so much what constraint you were trying to apply but what behavior you were trying to model since whatever constraints you apply can have different impact on how tools handle it down the flow. You can start by simply defining a clock on the pin in question. A generated clock needs to have a master source whether an I/O or internal node. Sounds like you have an oscillator or some sort of clock inversion circuit. If it is the latter, I do not think you need to redefine the clock if the source propagates there.

    Gh-
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • EvgeniySUAI
    EvgeniySUAI over 14 years ago

     Hi!

    Thank you for the answer.

    In details, i have incoming DS-encoded data (two signals -SIN and DIN). According to the standard of DS-encoding, clock signal for this data can be produced by XORing  SIN and DIN. So, my project contains XOR component for this operation. On the output of XOR i define clock in the manner, i described above.

    As i understand,  generated_clock must have some source clock, but in my project frequency of data transmission in DS-encoded channel is absolutely independant on any inner clock signals. So, as i understand, i cant use generated_clock here.

     Evgeniy

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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