More comments on AMS Verification at ICCAD: modeling parasitic effects
Posted by mike demler on December 22nd, 2008
In his comments on AMS Verification at ICCAD, responding to my remarks on the challenge of post-layout transistor-level verification, Martin asked:
- Is it really required to combine the top-level architecture modeling with a full-blown extracted netlist with parasitics of the entire chip?
- … 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?
- 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
AMS verification
Fast-SPICE
Verilog
co-simulation
parasitic back annotation
RSS
Mike, when I look at the parasitic problem, it seems that the analog portion of the mixed signal world is missing the flow that digital has. The digital guy gets rough estimates (think wireload models or equiv) and he can know very quickly if his design is likely to work when it gets to layout…. where is the equivelent on the analog side?
Once the digital designer starts down the physical path, every tool he uses from a floor-planner to placer to router can all give him quick feedback about parasitics with increasing levels of accuracy and how they affect his design…. where is the equivalent flow on the analog side?
If the goal is to send up with a chip that works in a resource limited company (time is limited, $$ are limited, people are limited) then to me the best answer is to work smarter and have a flow that gives you information as you go along, rather than the “the layout passes LVS, now you can back annotate and start running sims to see what happens”
Mike, what do you think is needed to enable the mixed signal community to have a flow that manages parastics rather than reacts to them?
David
A standing issue with Verilog-AMS for over a decade has been the lack of a method to do back-annotation in the way SDF works for regular Verilog.
I personally proposed a methodology back in the mid 90s, and have seen no other offerings nor any support for mine.
This one missing feature means that it is very difficult to mix analog behavioral descriptions with parasitics, so designers usually have to resort to fully extracted netlists to get accurate simulations.
The same feature is required for handling power distribution properly with behavioral models during floor planning etc. – Verilog(-AMS) also lacks good hooks for power supply management.
But what’s really missing is people turning up at the Accellera and IEEE committees and voting for the language extensions they need. I see a lot of software-like features being added, but not much that improves the basic electrical description of circuits.
Kev.