Analog Simulation Insights

 

More comments on AMS Verification at ICCAD: modeling parasitic effects

In his comments on AMS Verification at ICCAD, responding to my remarks on the challenge of post-layout transistor-level verification, Martin asked:

  1. Is it really required to combine the top-level architecture modeling with a full-blown extracted netlist with parasitics of the entire chip?
  2. … The system-level guy is probably interested whether his “Quality of Service” is ok (Bit-error-rate is already to “low-level”), and if not, is the analog guy able to dig-down to the parasitic-level to find out whether it’s an parasitic-related problem?
  3. Should we not propagate a cascaded approach: validate & replace physical implementation with schematic with the dominant parasitics only validate & replace schematics with a behavioral model validate & replace combination of behavioral models with system-level model, etc (note in top-down or bottom-up direction or both). But this requires a rather strict design methodology and modeling philosophy, which is again not always fully supported by today’s flow/tools.

Martin, it looks to me like you are describing a hierarchical verification methodology; i.e. one where different levels of abstraction (and the associated tools) are applied throughout the flow from circuit to block to full-chip . That is exactly what is required, which is why no single language or tool can ever completely cover the range of abstraction levels required to complete design and verification of an AMS SoC. Only an integrated and seamless (as possible) flow will suffice.

To answer your first question, no – it is not required to use the “full-blown” post-layout netlist with extracted parasitics of the entire chip at the architectural level. The first question to answer is “what are you trying to verify”? It’s critical to apply judgment in choosing the right model and abstraction level for each problem, rather than throwing all the data at it with the hope that this will provide the best insurance. My 1st post on this thread addressed this problem of “extraction overload”, as John Croix of Nascentric described it at ICCAD.

As a starting point for post-layout analysis, there are automated methods of applying only the dominant parasitics to a schematic-level simulation. For more details on how to optimize post-layout transistor-level analysis; you should review a webinar that I put together in 2006 (it is archived on the Synopsys website) – see Verifying Performance and Reliability in Nanometer Designs.

At the top-level, nobody would use a “full-blown” netlist. First of all, most AMS SoCs are “big-D/little-a” so analog-digital co-simulation is the way to go here. The parasitics in the digital blocks are back annotated into Verilog or VHDL models, and Fast-SPICE is used to accelerate the post-layout transistor-level blocks.

If you are verifying the power/ground buses for IR drop in the presence of parasitics, a similar hierarchical approach is the answer. There is no need, and it is totally impractical, to verify the entire chip at the transistor-level. As in the case of full-chip functional verification, different levels of abstraction are used for analog and digital blocks. A tool like Synopsys’ PrimeRail integrates the flow from transistor to gate-level, so that a unified view of the dynamic power grid IR drop can be performed.

What issues have you seen where the flow you want to employ is not supported by today’s tools?

-Mike
visit my blog -




  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • RSS
  • Twitter