Why IC Design Safety Nets Have Limits

Experts at the Table: Semiconductor Engineering sat down to discuss different responsibilities in design teams and future changes in tools with Ashish Darbari, CEO at Axiomise; Ziyad Hanna, corporate vice president R&D at Cadence; Jim Henson, ASIC verification software product manager at Siemens EDA; Dirk Seynhaeve, vice president of business development at Sigasi; Simon Davidmann, formerly CEO of Imperas Software (since acquired by Synopsys) and Manish Pandey, fellow and vice president R&D at Synopsys. What follows are excerpts of that discussion. To view part one of this discussion, click here. Part two is here.

L-R: Axiomise’s Darbari, Cadence’s Hanna, Siemens’ Henson, Sigasi’s Seynhaeve, Imperas’ Davidmann, Synopsys’ Pandey.

SE: Many aspects of design now require relevant vector sets, like power and thermal. Is the creation of those vector sets the role of the verification architect, or is that a task distributed between the design specialists or verification specialists associated with those tasks?

Darbari: Power estimation and thermal analysis are related, but power verification, as I mentioned above, requires a systematic analysis both at the architectural level with software as well as micro-architectural. This requires architects, designers and verification engineers to work together, I’d not say that it is the role of a verification architect alone. But one thing is clear to me that power (and PPA) should be part of verification plans – we should think of what would need to be verified not necessarily rush into deciding that we will use simulation or emulation for that; in many cases formal would be a great way of assessing this.

Seynhaeve: We do have the unified verification methodology (UVM), which includes different verification methodologies, such as assertion-based and others. But in UVM, you have the concept of constrained vector sets, and you can guide these constraints. Currently, that is the job of the verification engineer, taking some domain knowledge and steering it to constraints, the UVM methodology, and having sufficient coverage. I believe that working with AI as your partner will improve the task, but the responsibility is always going to lay with the verification engineer. However, there probably are automations through AI that can help the verification engineer in doing so.

Davidmann: There’s more than one verification discipline, whether it’s functionality, performance, or architecture. We deal with so many different groups in different companies. Each set has verification engineers, and they’re doing different things, whether it’s at the lowest level for processors, the ISA, and then maybe the compatibility layer. They want to make sure that an OS is going to run on these three or four different cores that are meant to be the same, whether they’re systems-ready, or there are performance teams that are checking that. So to answer the question, there are many groups all doing verification, and they’re all different.

Henson: It takes a specialist, too. I wouldn’t consult on leakage power or glitch power at the back end. I need a specialist to help me with that. But that could ripple back up to some design decisions at the top, too.

Pandey: The question is really alluding to whether we can shift left some on these issues by detecting them at the RTL level, and is it the role of the verification engineer? Well, it’s a pretty big responsibility, and we cannot give it to the verification engineer until we enable him or her with the right tools. Some of these things, like power estimation and glitch analysis, can be done at the RTL if the tools enable it. Certainly, along many of these vectors, the verification engineer or even the designer can make some of the early calls as to whatever they are authoring, or whether whatever he or she is looking at has implications at the physical electrical level. So, absolutely, with the right tooling, it can happen, and I do see the industry and CAD tools moving in the direction of getting these vectors visible, along with their implications on the design.

Hanna: In very abstract thinking, we build safety nets with holes, and these safety nets are in hierarchy. The functional bugs — the big ones — we find as early as possible. We cannot leave them to be found at the end of the design flow. That safety net depends on how big the holes are. If the holes are big, that means during verification these bugs can fall down into the next safety net. We catch them later on. The majority of them have to be caught. I believe it’s about the methodology — how tight, how robust the safety net is at each level of the design flow. If it’s more robust, if it’s going to be very complex and very tight, it would be very hard for the engineers to achieve their jobs. So we need to find a way to mitigate the complexity of the task, partitioning it in the flow such that every team can contribute to the safety net and find the relevant bugs that are supposed to be at their level of the design flow — and find functional bugs as early as possible. Implementation bugs like data glitches, poor synthesis, are sometimes hard to find them in the early stage at the RTL. So why make the methodology so hard and so complicated? We need to be wise in the way we set the expectations on what to find, where, and what tool? This is the aim of the flow development experts, and the CAD experts on the customer side. They want to build a methodology to be able to fit things with the right expectations at every phase. The tools have to be smarter, such that if a methodology somewhere decided to put more emphasis on glitches on the RTL, such as the formal verification tool for example, they should be able to do it. If they decide not to do it or do it later on, maybe the synthesis should be finding it. The expectation is for our tools to be smarter for multi-dimensional, multiple vectors of design aspects. And the choice now, for the methodologists on the customer side, is to find what best fits their team’s skill set and where the pain points are. Based on that they build their methodologies, of course, with the assistance of experts.

Davidmann: I agree with that, but I’d focus more on making the design tooling more verification-aware. Whether it’s with a little bit of abstraction or otherwise, the goal is to make sure we left shift the verification technology so it’s easier to use right up front in the early stage of the design, so they put less bugs into it. Some 20 years ago, I came across a team in AMD that had built their own Verilog simulator, and they threw out a lot of the Verilog language because they said it added too many bugs into the design. All the designers hated it because it was actually lower abstraction, but what it meant was the project finished seven months early because they put fewer bugs into the design because they were only allowed to use the essential bits. For this reason we need to move left the essential bits and provide the abstractions so we get better quality upfront, and fewer bugs put into.

Hanna: Every design doesn’t start from scratch. In every design cycle, there is 70% existing design, and 30% internal IP and incremental. You cannot interrupt this practice. I’ve been in this abstraction domain, and when I was at Intel we developed a tool methodology called IDV — in-design verification. Every step of the design can be verified, and it’s great for fresh, new IPs. But in reality, people are in incremental mode. We need to cope and make sure that the tools are smart to be able to mix and match all different methodologies.

Seynhaeve: There’s probably disagreement. We all agree that safety nets are important and that smarter tools are very nice. But the problem is that as soon as you start relying on that safety net, you will be resolving your bugs later, and the later you solve them the more costly they get.

Hanna: I disagree. There are different bugs. There are bugs in the function that can found in the RTL and architecture level. You cannot afford leaving functional bugs in RTL.

Seynhaeve: And yes, indeed we do agree on that. But that is not a tool issue. That is a mindset issue. And the problem that we have is that a lot of the design engineers do not have that mindset. They think that if my Verilog meets the LRM (language reference model), I don’t have any bugs. No, no, no.

Hanna: There are two things. One is the specification, which is the proofs or the validation. People miss the specification. They spend time, less than expected, to understand the spec, a different level of abstraction. They’re going to go after the architectural level or the RTL, or even in the timing and algorithm, etc. The spec is the spec. It doesn’t matter what’s the content. You need to understand it, you need to make it precise, review it, and determine where were the pitfalls. People don’t spend much time on capturing the intent. The tool is not for capturing intent.

Seynhaeve: I don’t think those are exclusive statements. You’re correct. But the mindset also needs to be that you need to design for verification. They might have the mindset that they want to have a correct functional spec, but I do not think people have the mindset to design for verification.

Hanna: I don’t agree with you. I’ve been in this industry for 30 years. The majority of the RTL designers are coping with something completely complex, and their main issues are functional and PPA. They spend days and nights, and they’re extremely conservative. They don’t push new methodologies, because their task is very complex and they’re aware of it. Every bit they put in the design, they make sure it doesn’t impact the performance and the power, correctness, etc. Despite that, there are lots of bugs, not because they are paying less attention to design for verification or for implementability, but because the nature of things becomes so complex.

Read parts one and two of the discussion:
Engineers Or Their Tools: Which Is Responsible For Finding Bugs?
As chips become more complex, the tools used to test them need to get smarter.
Communication Is Key To Finding And Fixing Bugs In ICs
AI will be increasingly needed to make sense of huge amounts of data, allowing teams to work more effectively.