• 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 SDF

Stats

  • Locked Locked
  • Replies 8
  • Subscribers 62
  • Views 15903
  • 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 SDF

archive
archive over 19 years ago

Hi,

I need to simulate a gate-level netlist from RC 4.2.2
Can anybody knows how to generate an
sdf file from RC?

I've used the "write_sdf" command but the program says
that it's obsolete and doesn't accept any option.
Moreover the RC documentation doesn't tell
anything about "write_sdf"

Thank you.


Originally posted in cdnusers.org by giohdl
  • Cancel
Parents
  • archive
    archive over 19 years ago

    Hi Crispy Duck,

    Your reply is enlightening. Actually, I am going along your approach but my reply was short... the effort to get gate level simulate correctly depend on many things, so it is hard to generalise.

    What I did is to change the delay directly in the verilog model (std cell, and sometime even IP like memory), those numerbs in the "specify". This does not require additional file, and the simulation run faster and less memory. The delays are as what you suggest; sometime I use a very small delay for clock buffer, and use the actual delay for delay cell.

    To be more complete, typically we also have to tune the testbench, and sometime adjust the cycle where the data will start to appear. Also have to disable the hold/setup/etc of the synchonisers so that the control-logic does not end up with all "X". Depend on the library and the version of the software you use, you have to patch the SDF to make it "annotatable" (for example you have posedge in .lib, but not in the verilog model). In my last project, I have to use a patched version of Encounter to generate the sdf and 5.* cannot (I might remember wrongly here, but just get the idea) with setuphold / recrem (so that -ve check is supported). Lastly, remember to check the timescale has sufficient accuracy. I think this list can add on; there is always something new in every project.

    Regards,
    Eng Han


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

    Hi Crispy Duck,

    Your reply is enlightening. Actually, I am going along your approach but my reply was short... the effort to get gate level simulate correctly depend on many things, so it is hard to generalise.

    What I did is to change the delay directly in the verilog model (std cell, and sometime even IP like memory), those numerbs in the "specify". This does not require additional file, and the simulation run faster and less memory. The delays are as what you suggest; sometime I use a very small delay for clock buffer, and use the actual delay for delay cell.

    To be more complete, typically we also have to tune the testbench, and sometime adjust the cycle where the data will start to appear. Also have to disable the hold/setup/etc of the synchonisers so that the control-logic does not end up with all "X". Depend on the library and the version of the software you use, you have to patch the SDF to make it "annotatable" (for example you have posedge in .lib, but not in the verilog model). In my last project, I have to use a patched version of Encounter to generate the sdf and 5.* cannot (I might remember wrongly here, but just get the idea) with setuphold / recrem (so that -ve check is supported). Lastly, remember to check the timescale has sufficient accuracy. I think this list can add on; there is always something new in every project.

    Regards,
    Eng Han


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