• 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. SDC file-HOLD and Setup Time

Stats

  • Locked Locked
  • Replies 14
  • Subscribers 90
  • Views 23743
  • 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

SDC file-HOLD and Setup Time

archive
archive over 18 years ago

Hi,
I am just starting using the nano encounter tool. I just wonder if the sdc file we give to the encounter tool should be the same as SDC file we give to the RTL compiler?
I want to connect my synthesized block to a memory with specific setup hold time. Does anyone has an idea how to give the encounter tool the specific setup time and hold time? how to put a constrain on its output and input port for setup and hold time?

Thanks,

Houman
 


Originally posted in cdnusers.org by houmanh
  • Cancel
  • archive
    archive over 18 years ago

    Hi,

    Thanks for your reply. Here is some more information of the results I got when using different polarity for hold time:
    first SDC:  (the clock period is 4ns)
    set_output_delay -clock [get_clocks {clk}]  -min 1  [get_ports {mem_d}]
    set_output_delay -clock [get_clocks {clk}]  -max .3 [get_ports {mem_d}]
    so here I try to satisfy the memory setup and hold time which is going to be attached to the output port of the synthesized block.
    and here is the results I get:
    +--------------------+---------+
    |     Hold mode      |   all   |
    +--------------------+---------+
    |           WNS (ns):|  0.137  |
    |           TNS (ns):|  0.000  |
    |    Violating Paths:|    0    |
    |          All Paths:|   128   |
    +--------------------+---------+

    +--------------------+---------+---------+---------+---------+---------+---------+
    |     Hold mode      |   all   | reg2reg | in2reg  | reg2out | in2out  | clkgate |
    +--------------------+---------+---------+---------+---------+---------+---------+
    |           WNS (ns):|  0.139  |  0.139  |  3.006  |  0.365  |  3.955  |   N/A   |
    |           TNS (ns):|  0.000  |  0.000  |  0.000  |  0.000  |  0.000  |   N/A   |
    |    Violating Paths:|    0    |    0    |    0    |    0    |    0    |   N/A   |
    |          All Paths:|   128   |   106   |   104   |   21    |   18    |   N/A   |
    +--------------------+---------+---------+---------+---------+---------+---------+

    secodn SDC: (only difference hold time with negative value)
    set_output_delay -clock [get_clocks {clk}]  -min -1  [get_ports {mem_d}]
    set_output_delay -clock [get_clocks {clk}]  -max .3 [get_ports {mem_d}]
    results;

    +--------------------+---------+
    |     Hold mode      |   all   |
    +--------------------+---------+
    |           WNS (ns):| -0.833  |
    |           TNS (ns):| -12.468 |
    |    Violating Paths:|   18    |
    |          All Paths:|   128   |
    +--------------------+---------+
    *** Started fixing hold violations (CPU=0:00:00.2, totcpu=0:00:14.1, mem=220.5M)
    *info: PostCts hold fixing, Slew prop level: 0
    Density before buffering = 0.498 (fixHold)
    *info:
    *Info: The following delay and buffer cells will be used for hold fixing
    *Info:    cell  igArea   setupDelay f/r(inTran f/r, load)    holdDelay (inTran f/r, load)
    *Info:                     nanoSecond  ( nanoSecond  PF )    nanoSecond (nanoSecond  PF )
    *Info:   BUFFD0    4.0   0.055/0.057 (0.071/0.071, 0.009)   0.122/0.135 (0.131/0.131, 0.009)
    *Info:   CKBXD0    4.0   0.059/0.056 (0.071/0.071, 0.009)   0.13................and etc
    and here is the hold time after doing fix hold
    +--------------------+---------+---------+---------+---------+---------+---------+
    |     Hold mode      |   all   | reg2reg | in2reg  | reg2out | in2out  | clkgate |
    +--------------------+---------+---------+---------+---------+---------+---------+
    |           WNS (ns):|  0.007  |  0.138  |  3.003  |  0.007  |  1.957  |   N/A   |
    |           TNS (ns):|  0.000  |  0.000  |  0.000  |  0.000  |  0.000  |   N/A   |
    |    Violating Paths:|    0    |    0    |    0    |    0    |    0    |   N/A   |
    |          All Paths:|   128   |   106   |   104   |   21    |   18    |   N/A   |
    +--------------------+---------+---------+---------+---------+---------+---------+


    so I guess as I want my output changes after some delay from the positive edge of the clock , i have to introduce the hold time with negative value. I appreciate your comment on this.

    Thanks,

    Houman




    Originally posted in cdnusers.org by houmanh
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    here is the figure explaining what I try to achieve as a memory hold time,

    sorry if it is too obvious and trivial!



    Originally posted in cdnusers.org by houmanh
    • cdns.jpg
    • View
    • Hide
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    Hi Houmanh,

    I believe the use of -1ns for set_output_delay is okay. Actually you should look at the timing report (and not the timing summary) to check the details of the timing calculation. set_output_delay is the amount of delay on the data path that is outside the chip. By setting a -1ns, the signal inside the chip that pass through mem_d will seem to be faster by 1ns, and this is bad.

    But you should still study the detail timing report (the one that show both launching clock, receiving clock and data path). As you associate mem_d to an internal clock, it will has a clock latency due to clock tree too. This is true if you somehow output the clock and also balance it. Also, consider the option "-add_delay" for set_output_delay. Lastly, you might want to consider using virtual clock for I/O;I feel that it is more flexible.

    Regards,
    Eng Han


    Originally posted in cdnusers.org by EngHan
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • archive
    archive over 18 years ago

    Thanks Eng Han.


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