Stats

  • Locked Locked
  • Replies 2
  • Subscribers 92
  • Views 1437
  • 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 Encounter - Timing Report Confusion

shayansh

 

I'm sorry if this is a basic question, I am new to using encounter.

During synthesis, i set constraints on the clock like clock_latency and uncertainty to synthesize assuming a pessimistic clock distribution. Based on my understanding these parameters make sure to create a pessimistic setting in synthesis to make sure the design meets timing. I understand these so far and mostly how they affect the synthesis and the design.

My main question is, once I move on to place and route in encounter. I feed the synthesized netlist and a *.sdc file which includes all these constraints to encounter for place and route. I am able to place and route everything and see my timing reports. BUT it seems that the timing reports, STILL use these constraints from synthesis. I feel like they shouldn't anymore, since the clock tree has already been synthesized in encounter, the tool should just use that for timing, and not rely on settings I had in synthesis. I was wondering if I need to set anything special in encounter to make sure that the timing reports reflect the synthesized clock tree and not the constraints I set in synthesis of the RTL.

Any feedback anyone can give me would be appreciated.

 

Parents

  • Generally we use two values for set_clock_uncertainty -setup,
    - slightly pessimistic values for synthesis , tuned by layout feedback.
    - the actual hard target for the layout & signoff tools. 
    You are correct the intent of the pessimism is to leave  "A get out of jail free card" for layout.

    Also you can pull a  similar trick within encounter by dynamically modifing the signoff uncertainty with the setOptMode -setupTargetSlack option. 
    ie. preSCTS +100ps , postCTS +50ps and  postRoute +10ps

    set_clock_latency is an estimate for synthesis but once CTS is run this value is automatically updated  with clockDesign -updateIoLatency option.

    Shawn

Reply

  • Generally we use two values for set_clock_uncertainty -setup,
    - slightly pessimistic values for synthesis , tuned by layout feedback.
    - the actual hard target for the layout & signoff tools. 
    You are correct the intent of the pessimism is to leave  "A get out of jail free card" for layout.

    Also you can pull a  similar trick within encounter by dynamically modifing the signoff uncertainty with the setOptMode -setupTargetSlack option. 
    ie. preSCTS +100ps , postCTS +50ps and  postRoute +10ps

    set_clock_latency is an estimate for synthesis but once CTS is run this value is automatically updated  with clockDesign -updateIoLatency option.

    Shawn

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.