AgO Synthesis Inc. www.ago-inc.com 100X Faster Spice Simulation
Mixed-Signal SoC By Cadence
Steve Carlson
Key Findings: There are a host of issues that arise in mixed-signal verification. As discussed in earlierblogs, the industry trends indicate that teams need to prepare themselves for a more mixed world. The good news is that these top five pitfalls are all avoidable. It’s always interesting to study the human condition. Watching the world through the lens of mixed-signal verification brings an interesting microcosm into focus. The top 5 items that I regularly see vexing teams are: 1. 2. 3. 4. 5.
When there’s a bug, whose problem is it? Verification team is the lightning rod Three (conflicting) points of view Wait, there’s more… software There’s a whole new language Reason 1: When there’s a bug, whose problem is it? It actually turns out to be a good thing when a bug is found during the design process. Much, much better than when the silicon arrives back from the foundry of course. Whether by sheer luck, or a structured approach to verification, sometimes a bug gets discovered. The trouble in mixed-signal design occurs when that bug is near the boundary of an analog and a digital domain.
Figure 1. Whose bug is it?
Typically designers are a diligent sort and make sure that their block works as desired. However, when things go wrong during integration, it is usually also project crunch time. So, it has to be the other guy’s bug, right? A step in the right direction is to have a third party, a mixed-signal verification expert, apply rigorous methods to the mixed-signal verification task. But, that leads to number 2 on my list.
Reason 2: Verification team is the lightning rod Having a dedicated verification team with mixed-signal expertise is a great start, but what can typically happen is that team is hampered by the lack of availability of a fast executing model of the analog behavior (best practice today being a SystemVerilog real number model – SV_RNM). That model is critical because it enables orders of magnitude more tests to be run against the design in the same timeframe. Without that model, there will be a testing deficit. So, when the bugs come in, it is easy for everyone to point their finger at the verification team.
Figure 2. It’s the verification team’s fault Yes, the model creates a new validation task – it’s validation – but the speed-up enabled by the model more than compensates in terms of functional coverage and schedule. The postscript on this finger-pointing is the institutionalization of SV-RNM. And, of course, the verification team gets its turn.
Figure 3. Verification team’s revenge
Reason 3: Three (conflicting) points of view The third common issue arises when the finger-pointing settles down. There is still a delineation of responsibility that is often not easy to achieve when designs of a truly mixed-signal nature are being undertaken.
Figure 4. Points of view and roles Figure 4 outlines some of the delegated responsibility, but notice that everyone is still potentially on the hook to create a model. It is questions of purpose, expertise, bandwidth, and convention that go into the decision about who will “own” each model. It is not uncommon for the modeling task to be a collaborative effort where the expertise on analog behavior comes from the analog team, while the verification team ensures that the model is constructed in such a manner that it will fit seamlessly into the overall chip verification. Less commonly, the digital design team does the modeling simply to enable the verification of their own work. Reason 4: Wait, there’s more… software As if verifying the function of a chip was not hard enough, there is a clear trend towards product offerings that include software along with the chip. In the mixed-signal design realm, many times this software has among its functions things like calibration and compensation that provide a flexible way of delivering guards against parameter drift. When the combination of the chip and the software are the product, they need to be verified together. This puts an enormous premium on fast executing SV-RNM.
Figure 5. There’s software analog and digital While the added dimension of software to the verification task creates new heights of complexity, it also serves as a very strong driver to get everyone aligned and motivated to adopt best known practices for mixed-signal verification. This is an opportunity to show superior ability!
Figure 6. Change in perspective, with the right methodology
Reason 5: There’s a whole new language Communication is of vital importance in a multi-faceted, multi-team program. Time zones, cultures, and personalities aside, mixed-signal verification needs to be a collaborative effort. Terminology can be a big stumbling block in getting to a common understanding. If we take a look at the key areas where significant improvement can usually be made, we can start to see the breadth of knowledge that is required to “get” the entirety of the picture:
Structure – Verification planning and management Methodology – UVM (Unified Verification Methodology – Accellera Standard) Measure – MDV (Metrics-driven verification) Multi-engine – Software, emulation, FPGA proto, formal, static, VIP Modeling – SystemVerilog (discrete time) down to SPICE (continuous time) Languages – SystemVerilog, Verilog, Verilog-AMS, VHDL, SPICE, PSL, CPF, UPF Each of these areas has its own jumble of terminology and acronyms. It never hurts to create a team glossary to start with. Heck, I often get my LDO, IFV, and UDT all mixed up myself.
Summary
Yes, there are a lot of things that make it hard for the humans involved in the process of mixed-signal design and verification, but there is a lot that can be improved once the pain is felt (no pain, no gain is akin to no bugs, no verification methodology change). If we take a look at the key areas from the previous section, we can put a different lens on them and describe the value that they bring:
Structure – Uniformly organized, auditable, predictable, transparency Methodology – Reusable, productive, portable, industry standard Measure – Quantified progress, risk/quality management, precise goals Multi-engine – Faster execution, improved schedule, enables new quality level Modeling – Enabler, flexible, adaptable for diverse applications/design styles Languages – Flexible, complete, robust, standard, scalability to best practices With all of this value firmly in hand, we can turn our thoughts to happier words:
Hillol.sarkar@ago-inc.com