Stats

  • Locked Locked
  • Replies 8
  • Subscribers 90
  • Views 16584
  • 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

SOC timing problem

archive

Hi all,


I've a post-P&R timing problem using SOC Encounter.
As you can see in the attached file,
my circuit generates an inverted clock.


 
The timing analyzer reports a setup-violation between
two FFs which use the inverted and the positive clock.
 
I've read the reports and I've found that
the combinational delay  MAX_DELAY is less than the clock  period.
The problem is that the analyzer doesn't identify the correct clock edges
for setup checking.
In particular it should consider the next edge
of  CLK_END for a correct check.



In order to eliminate the false violation, I've tried to declare
CLK_NEG as a generated clock in the sdc constraint file:

create_generated_clock  -name CLK_NEG -source CLK -invert [get_pins "MODULE_PATH"/MYMOD/INV/Z]

But I get the folloving warning messages:

 >Skipped invalid point "MODULE_PATH"/MYMOD/INV/Z
 >Empty pin list in get_pins command
 >Unsupported commad  "create_generated_clock"
 
 
 I've the following questions:
 
 1. The "create_generated_command" could actually avoid the false violation?
 
 2. If So, can it be applied in a hierarchycal module?
 
 3) What is the correct syntax?
 
 
 Sorry for the long post,
 thank you.


Originally posted in cdnusers.org by giohdl
Parents

  • Hi,
    first I must admit my poor practice in constraining designs.
    I've just declared the ideal clock signal this way:

    create_clock [-get_pins {pad_clock/Z}] -name ideal_CLK -period 2 -waveform{0 1}


    As you suggested, I've used the "create_generated_clock" constraint
    and repeated the timing analysis on my layout.
    The timing analyzer now considers CLK_NEG as a clock and doesn't report
    the previous setup violations.

    Actually I think that  layout design
    must repeated and include proper constraints for the generated clock signals.
    I've read the CTS reports and I've seen that
    clocktree generation has been ignored for all FFs driven by CLK_NEG.
    As a result there is a big latency (unbalanced phase delay) for those paths.

    I've attached the real timing.
    CLK and CLK_NEG have a latency of about 1ns respect to the ideal clock.
    CLK_END has a latency of about 300ps.

    I suppose that it's necessary to include the  generated clock
    requirements in the clocktree generation tool.
    Beside the sdc file,
    could you tell me how to modify the CTS constraint file?

    Thank you again.
    Regards,
    Giohdl


    Originally posted in cdnusers.org by giohdl
Reply

  • Hi,
    first I must admit my poor practice in constraining designs.
    I've just declared the ideal clock signal this way:

    create_clock [-get_pins {pad_clock/Z}] -name ideal_CLK -period 2 -waveform{0 1}


    As you suggested, I've used the "create_generated_clock" constraint
    and repeated the timing analysis on my layout.
    The timing analyzer now considers CLK_NEG as a clock and doesn't report
    the previous setup violations.

    Actually I think that  layout design
    must repeated and include proper constraints for the generated clock signals.
    I've read the CTS reports and I've seen that
    clocktree generation has been ignored for all FFs driven by CLK_NEG.
    As a result there is a big latency (unbalanced phase delay) for those paths.

    I've attached the real timing.
    CLK and CLK_NEG have a latency of about 1ns respect to the ideal clock.
    CLK_END has a latency of about 300ps.

    I suppose that it's necessary to include the  generated clock
    requirements in the clocktree generation tool.
    Beside the sdc file,
    could you tell me how to modify the CTS constraint file?

    Thank you again.
    Regards,
    Giohdl


    Originally posted in cdnusers.org by giohdl
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.