Archive for December, 2008

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

AMS verification
Fast-SPICE
Verilog
co-simulation
parasitic back annotation

Hello Everyone,

My recent post on AMS Verification at ICCAD has generated some detailed comments, which provide great opportunities for continuing the discussion. My response is somewhat overdue, so let’s begin with this 1st comment from Martin, who is associated with the System-C AMS initiative.

In response to my statement that “A hierarchical verification methodology is the only way to go for complex, high-performance mixed-signal SoCs” Martin said:

Gluing tools together (hierarchically or not) is probably not the solution for this problem, as this will introduce fuzzy inter-tool communication (example: co-simulation between tool ‘A’ and ‘B’). What we need is a transparent design flow to support a (top-down) design refinement methodology, complemented with bottom-up verification elements. As soon as the methodology becomes clear, we should _not_ start a discussion on tools, but first look at the modeling language: which language is most suitable to do the job? Is there any? Today’s complex AMS systems are not just a bit of analog transistors and some RTL; it’s about having digital HW/SW and AMS subsystems that interact. This is one of the main reasons why the SystemC AMS extensions are being standardized.

Martin, I hope you did not think I was suggesting “gluing” together tools. In fact, I said quite the opposite in my 2nd statement that “EDA vendors need to focus more attention on flows, not just point tools“. I’m not exactly sure what you mean by a “transparent” design flow, but I absolutely agree that the challenges of AMS design and verification (the two activities being more inseparable than in digital) must be addressed from a complete top-to-bottom flow perspective and not just as a pursuit for better point tools.

The first problem though, is in the definition of any “one-size-fits all” methodology. Are you suggesting that one methodology could be developed across the EDA and semiconductor industries, that would cover all types of AMS/RF SoCs? I think that it would be unrealistic to expect that such a methodology could be created, and/or that customers would ever give up on their internal processes and proprietary methods. However, I believe that a set of best practices for a comprehensive set of relevant prototype circuits is sorely needed. What a waste it is for each company that designs ΣΔ ADCs, for example, to develop a verification methodology from scratch.

But this begs a lot of questions. EDA vendors generally do not possess the design domain expertise to develop such methodologies, and those EDA vendors that have invested in AMS methodology services and packaging of AMS verification IP have struggled to get customers to pay for them. I think that the only practical answer is to elevate the practice of AMS verification through collaborative industry efforts, so that we can develop and publish more best practices. Digital verification has been elevated to this level, but AMS is lagging.

You then propose that we should not “start a discussion on tools, but first look at the modeling language“. I have been active in the current Accellera discussions on defining a language for assertion-based AMS verification, and going further back I was involved in the early development of Verilog-AMS. There is a very significant difference in how these two efforts originated. In the case of Verilog-AMS, it started with efforts to standardize Verilog-A, which was based on commercial development of a tool and language for analog behavioral modeling by Cadence. In the case of AMS assertions there is no commercial implementation of even a first prototype, just a general consensus on the need to merge some functionality of System Verilog with Verilog-AMS.

Even if the EDA industry was not under such severe economic stress as it is today, the notion of developing a standardized language before there are tools upon which to run it is naive. It is unavoidable – a language is just the user interface for driving the tools. Academic exercises belong in academia. EDA and semiconductor companies are in business to make money. What is the point of developing a language without considering implementation requirements at the same time?

However, I am personally not very familiar with the System-C/AMS effort, as it is mostly a European initiative. How are users and vendors collaborating on that project?

-Mike

System-C
AMS verification
Verilog-AMS
assertions

I wasn’t able to attend myself, but there was an interesting session on AMS verification at the most recent ICCAD in San Jose: DESIGNERS’ PANEL: Mixed-signal Simulation Challenges and Solutions. Richard Goering has a report on the panel discussion at SCD Source – Designers cite mixed-signal challenges and solutions.

There are some important lessons to be drawn from the panelist’s presentations in Richard’s report:

1. A hierarchical verification methodology is the only way to go for complex, high-performance mixed-signal SoCs.

The challenges of verifying a 40 Gbit/second CMOS deserializer IC, presented by William Walker of Fujitsu Labs, makes this abundantly clear. While this problem was described as “outside the envelope of what CAD tools are capable of verifying today“, I think it would be more accurate to say there is no SINGLE CAD tool – it takes a hierarchical methodology built from several tools that are best-suited for various aspects of the problem.

Think about this… when you go for your next annual physical checkup, would you want your doctor to use just one instrument to verify your health? That could be painful, not to mention totally ineffective!

The hierarchical methodology described in this example includes:

• SPICE for highest accuracy at the block level
• FastSPICE to accelerate verification of difficult multi-rate circuits, such as PLLs
• Verilog-AMS for chip-level functional verification
• Matlab Simulink for top level architectural modeling

2. EDA vendors need to focus more attention on flows, not just point tools.

So, even if you agree that a hierarchical methodology is required, you may ask “how do I put one together”? While there are certainly some gaps that still call for better point-tool solutions; such as time-domain noise and jitter analysis, I believe that the bigger issue is that EDA vendors don’t give enough attention to the integration of their tools into seamless verification flows.

Now, to defend EDA vendors somewhat, while this is a big problem for users it is an even bigger problem for tool developers. They just don’t have the knowledge and expertise to take a design through a complete flow. Developing a flow requires a closer working partnership between vendors and customers, and all too often the customer can’t share their most difficult designs outside their company. The result is a lot of reactive bug reports and enhancement requests, rather than proactive joint development.

Another problem is that the best tool for each task may come from a different vendor. This is why it is worrisome to hear that some vendors are pulling back on their interoperability programs. I would like to call for an initiative to create a verification equivalent to the OpenAccess Interoperable PDK Library industry alliance. This is a critical industry need.

3. You can’t just just throw as much data as you can create at a tool and expect it to spit out an answer.

I’m not referring to garbage-in/garbage-out here. This is in some ways even worse, the case of too much data in… and nothing out! I have also seen many examples of “extraction overload”, as was described in the ICCAD discussion by John Croix of Nascentric. This is the challenge of post-layout transistor-level verification. Designers and verification engineers sometimes fear missing some minute detail in the extracted parasitics from their layouts, so you see netlists bogged down by milli-ohm resistors and atto-farad capacitors that have no meaningful effect on circuit performance. Post-layout analysis is a critical part of a hierarchical verification methodology, which requires close integration between extraction tools and simulators. These tools tend to live in separate worlds, both at EDA vendors and with users; the physical/geometric view of the design database and the electrical/schematic view of the circuit that the layout implements. Accurate parasitic reduction is required, along with intelligent back-annotation heuristics. From experience, I suggest looking into tools such as HSIM^plus if you are choking simulations with flat, multi-gigabyte parasitic files.

-Mike

p.s. I have been informed that this blog, and the other Synopsys Open Community blogs, will be moving by Dec-6 to a new location on the new Synopsys.com website. The RSS feeds should still work, and the URLs will get forwarded, so you should not lose contact with your subscriptions. A new look & feel should make the entire site easier to use and navigate.

p.p.s. If you have been using Yahoo readers for your blog subscription… well you might not be seeing this at all. Nevertheless, for some reason Yahoo is not refreshing the feeds for Synopsys blogs, so that it appears nothing new has been posted in a long time. I don’t know if the new web site will fix that, but for now I can no longer recommend using Yahoo for blog subscriptions. Please see the new link to subscribe by email through Feed Burner. I know that one still works.

mixed-signal verification
OpenAccess
analog simulation
verification methodology