Stats

  • Locked Locked
  • Replies 10
  • Subscribers 92
  • Views 16195
  • 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

Cell delay estimation for pre route and post route

gops
How does the encounter estimates cell delay for post route and pre routes. Actually my doubt is about the load capacitance it will take for both the analysis.I think that for pre route it takes the load capacitance as the sum of both net capacitance(in the WLM) and pin capacitance of the driven cell.But for post route which load cpacitance its going to take.Is it the same as pre route OR is it the effective capacitance as seen from the driving pin?
Parents

  • Yes, I'm referring to the native FE extractor.  As you know, setExtractRCMode influences what happens when you call extractRC.  In 7.1, setExtractRC supports the following engines:  [-engine {default|detail|signoff}].

    Is native extraction accurate enough for signoff?  Since signoff implies a certain level of qualification has been performed with semiconductor manufacturers, no, the native FE extractor is not signoff in the same way that QRC is.  However, FE-Detail extraction typically correlates closely enough to QRC and other signoff extractors that it can successfully be used as the extraction engine that drives optimization.

    If you're finding that correlation between the FE-Detail extractor and QRC is poor, there are a number of things to consider.  In my recent experience working on 40nm processes, I've found the FE-Detail extractor to correlate quite well to QRC (90+% of the nets are within +/- 20%).  If your correlation isn't as good, you might want to consider leveraging enhancements to the FE-Detail extractor available in 7.1.USR2.  SPEF-based optimization (or even SDF-based optimization) based on your standalone QRC extraction might also be something to consider.  Lastly, CCE (the "Common Capacitance Engine"- a native form of QRC within Encounter) can increasingly be part of your optimization flow depending on the version you're on (beta in 7.1 and becoming more fully supported in 8.1).  The decision here depends on how well you're correlating currently and the run-time/accuracy tradeoff appropriate for your designs.

    Hope this helps,
    Bob

     

Reply

  • Yes, I'm referring to the native FE extractor.  As you know, setExtractRCMode influences what happens when you call extractRC.  In 7.1, setExtractRC supports the following engines:  [-engine {default|detail|signoff}].

    Is native extraction accurate enough for signoff?  Since signoff implies a certain level of qualification has been performed with semiconductor manufacturers, no, the native FE extractor is not signoff in the same way that QRC is.  However, FE-Detail extraction typically correlates closely enough to QRC and other signoff extractors that it can successfully be used as the extraction engine that drives optimization.

    If you're finding that correlation between the FE-Detail extractor and QRC is poor, there are a number of things to consider.  In my recent experience working on 40nm processes, I've found the FE-Detail extractor to correlate quite well to QRC (90+% of the nets are within +/- 20%).  If your correlation isn't as good, you might want to consider leveraging enhancements to the FE-Detail extractor available in 7.1.USR2.  SPEF-based optimization (or even SDF-based optimization) based on your standalone QRC extraction might also be something to consider.  Lastly, CCE (the "Common Capacitance Engine"- a native form of QRC within Encounter) can increasingly be part of your optimization flow depending on the version you're on (beta in 7.1 and becoming more fully supported in 8.1).  The decision here depends on how well you're correlating currently and the run-time/accuracy tradeoff appropriate for your designs.

    Hope this helps,
    Bob

     

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.