Stats

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

  • Pre-route, trialRoute is used to estimate route topologies and then FE-Default accuracy RC extraction is performed to build up parasitics.  These parasitics are then summed with the input pin cap of driven cells and delay calculation is performed with the FE delay calculator (or the SignalStorm delay calculator depending on how "setDelayCalMode" is set).  Encounter does not have a notion of wire-load models.

    Post-route, FE-Detail accuracy RC extraction is performed (or signoff accuracy if you'd like) and similarly delay calculation is performed.

    It is conceptually quite similar whether pre-route or post-route.  I imagine you're asking for clarity here because you're having a hard time understanding why the design is being timed the way it is?  If you have more specifics on the nature of the timing that's troubling you please do follow-up to see if we can help.

    Thanks for your question!

  • When you refer to "FE-Default accuracy RC" and "FE-Detail accuracy RC" are you refering to the FE native extraction (extractRC)? We use QRC for signoff extraction. Is the native extraction accurate enough for sign-off?

  • 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

     

  • Hi BobD ;
    Thanks for your reply.I'm a beginner in ASIC design.So i may be wrong sometimes.Anyway i shall tell you my exact problem in a detailed way.
    from your reply i understood that Encounter does not take wireload models for delay calculation.ok thats fine. Then it may be taking the extracted prasitics of trial route during pre route and nanoroute during post route.
     
    I'm having the idea that ;
     
    For calculating the delay for a cell two things are considered
    1) input slew
    2) output load.
     
    In the sdf file , i have seen both interconnect delay as well as cell delay. You told that the extracted net parasitic will be added to the input pin cap of driven cell to calculate cell delay. So it means that you have already considered the delay of the interconnect to calculate cell delay , is'nt it?If thats the case what is the need of calculating the interconnect delay once more?

  • @gops:

    The load presented by the interconnect influences the cell delay, and then additionally the net delay includes point to point delay times from each driver through the interconnect to each receiver on a net.  There's no double-counting in that respect, just 2 components that determine overall path delay. 

    Hope this makes sense,
    Bob

     

  • Hello Bob ;
    You meant to say that
     
    Path delay = Net delay + Cell delay
     
    Net delay -----> Point  to Point Delay due to RC component of the metal used for routing.
    Cell delay -> Delay of the Driving cell considering input slew and Capacitive load( Net parasitic + driven cell pin parasitics).
     
    Am i correct?

  • Yes, that is a nice summary of how it should work.  Thanks!

  •  how can i  get the cell delay ?? is there any command to report that ??

     

    i know by timing report we can get that but i need command ??

     

     

  • does report_cell_instance_timing give you what you're looking for?

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.