feature article
Subscribe Now

We Need to Talk!

Communication Needed Between Verification and Safety

What we have here is a failure to communicate. – Cool Hand Luke

The farmer and the cowman should be friends. – Oklahoma 

There are apparently a couple of silos in the EDA world that could use some breaking down. 

  • On one side, we have verification. This is a well-established discipline involving numerous EDA tools and a brief that compels verification engineers to make sure that a design does what it is intended to do.
  • On the other side, we have safety engineering. This is a newer discipline to EDA, charged with making sure that a design won’t put someone or something in danger if things go awry.

Historically, safety has been limited to the rather rarified realms of aviation and military. Folks operating in those markets have been a different breed, sacrificing flexibility and agility for what many might see as a cumbersome, inefficient process of checks and cross-checks and adherence to what can be mind-numbing regulations, all designed to keep soldiers and aircraft passengers and, frankly, innocent bystanders, safe.

Of course, today, safety is all the rage, what with everyone and their cousins storming the automotive world in order to get a piece of the high-volume action there that they would never see in the mil/aero space. So new tools are emerging, and old tools are being adapted to the needs of safety.

“Verification” and “safety” aren’t usually seen as related topics. Yes, you might say that “safety” is all about verifying that a design is safe, so to understand the split, we need to realize that “verification” really means “functional verification.” Although “functional” sometimes means logic and not timing, so perhaps we could call it “operational verification” if that gets us out of a semantic bind.

The bottom line is that “verification” has never traditionally included verification of safety, which is why we now have two silos.

Having two silos is ok if they never need to interact. And you might think that to be the case. There are verification tools and there are safety tools. Yeah, they may share some common roots, but, in everyday usage, those tools are used by very different people for very different things. 

Now… the farmer/cowman analogy above may be stretching things too far; after all, ranchers and farmers were at each other’s throats, as farmers needed fences and ranchers wanted none. There’s none of that kind of beef in the verification and safety worlds (that I’m aware of). So it’s not so much that verification and safety engineers are mutual enemies now; it’s just that they could be friends instead of strangers.

And, as OneSpin told it during DAC, smooth interaction between the groups is often missing, despite areas of overlap – and despite the fact that safety engineers need data from verification engineers in order to complete their verification.

The Overlap

We’ve seen before that there are two kinds of possible failures: systematic and random. Systematic failures are a result of a problem with the design itself. Whenever the conditions needed to trigger a fault are met, then the failure occurs. Random failures, on the other hand, have unpredictable causes and timing – like alpha particles mashing the memory.

We have spent more of our attention on the random faults because that’s where new tools are needed. But, to be clear, systematic failures are specifically the area where verification and safety have the most overlap. While verification engineers are making sure that everything works, safety engineers want to make sure that no element of the design will lead to a failure that could compromise safety.

In fact, in a way, the safety side of this is more stringent than the verification side. You may be familiar with the notion of “necessary and sufficient.” When proving, for instance, that a particular animal is a dog, it is necessary to determine that its genetics (chromosomes, genes, etc.) are that of a canine. That’s also sufficient. That the animal has fur (ignoring dogs that have hair) or that it barks (ignoring dogs that bay) may be true, descriptive, and useful, but those facts aren’t necessary to establish that the animal is a dog. The genetics are both necessary and sufficient.

Verification has traditionally been very much of a “necessary”-focused discipline. All the product requirements are necessary, and so each of the circuits that implements a requirement is therefore necessary. Verification helps to assure that all the necessary circuits are in place.

But safety adds the “sufficient” piece to the verification. Is there a block of logic that’s not doing anything? Are there some clever “easter eggs” in the design? Those have both often been ignored in the interest of getting to market quickly. If the extra circuit doesn’t do anything (at least as far as one can tell), then who cares? We can take it out in a future cost reduction to gain the area back. And if there are easter eggs, well, we just give a little “boys will be boys” chuckle.

But that won’t pass muster in a safety-oriented design. If it doesn’t do anything, get rid of it. (That goes from a security standpoint as well.) Or, if it does something that’s unrelated to any product requirement, then it goes.

In this way, verification and safety should very much be aligned in what they do when it comes to systematic failures.

The Dependency

For random errors, however, the relationship between verification and safety isn’t so much one of overlap; it’s more one of dependency. That is, the safety guys need some information from the verification folks in order to complete their determination as to whether the design meets safety criteria.

And this is where we’re seeing some issues, according to OneSpin. The communication isn’t happening as often and as openly as it could – or should.

Why would the safety folks need data from the verification folks? Well, let’s take one example. Since we’re talking about random failures here, we’re talking probabilities. And each transistor on a given process has some probability of unanticipated failure. A small probability perhaps, but, add up all of the transistors in a circuit, and it may no longer be negligible.

And that takes us specifically to the issue: in order for the safety guys to calculate the overall probability of failure for a block or circuit, they have to know how many transistors it contains. And that’s an example of data that they may have a hard time getting. Again, there’s nothing nefarious or contentious going on; it’s just that the verification guys are busy doing what they’ve always done, and that process hasn’t included good communications with safety folks.

Yes, technically, given access and permissions, safety engineers could use the same EDA tools that the verification guys use – except that safety engineers often aren’t familiar with those tools at a detailed level. So they rely on regular tool users (i.e., verification engineers) to extract the bits that they need.

Better tools can help here. For instance, OneSpin says that the safety-related tools built on their formal technology can work with other tools or design databases to get some of this information (like the number of transistors), meaning that you don’t need to wait for individuals to deliver the data. And, in fact, they say that usage of their safety tool is roughly split 50/50 between verification and safety engineers.

So that can help. But it’s evidently not enough; communication is still needed. So they’re sending a message to the community: “Let’s talk.”

 

More info:

OneSpin

Sourcing credit:

Jörg Grosse, Product Manager for Functional Safety, OneSpin

One thought on “We Need to Talk!”

Leave a Reply

featured blogs
Nov 27, 2023
Qualcomm Technologies' SVP, Durga Malladi, talks about the current benefits, challenges, use cases and regulations surrounding artificial intelligence and how AI will evolve in the near future....
Nov 27, 2023
Employees of our Cadence Cork team recently volunteered to be part of an exciting journey with our learners from Age Action. Age Action is Ireland's leading advocacy organization for older people and aging. The organization provides practical programs to support older pe...
Nov 27, 2023
See how we're harnessing generative AI throughout our suite of EDA tools with Synopsys.AI Copilot, the world's first GenAI capability for chip design.The post Meet Synopsys.ai Copilot, Industry's First GenAI Capability for Chip Design appeared first on Chip Design....
Nov 6, 2023
Suffice it to say that everyone and everything in these images was shot in-camera underwater, and that the results truly are haunting....

featured video

Dramatically Improve PPA and Productivity with Generative AI

Sponsored by Cadence Design Systems

Discover how you can quickly optimize flows for many blocks concurrently and use that knowledge for your next design. The Cadence Cerebrus Intelligent Chip Explorer is a revolutionary, AI-driven, automated approach to chip design flow optimization. Block engineers specify the design goals, and generative AI features within Cadence Cerebrus Explorer will intelligently optimize the design to meet the power, performance, and area (PPA) goals in a completely automated way.

Click here for more information

featured paper

3D-IC Design Challenges and Requirements

Sponsored by Cadence Design Systems

While there is great interest in 3D-IC technology, it is still in its early phases. Standard definitions are lacking, the supply chain ecosystem is in flux, and design, analysis, verification, and test challenges need to be resolved. Read this paper to learn about design challenges, ecosystem requirements, and needed solutions. While various types of multi-die packages have been available for many years, this paper focuses on 3D integration and packaging of multiple stacked dies.

Click to read more

featured chalk talk

Neutrik powerCON®: Twist and Latch Locking AC Power Connectors
Sponsored by Mouser Electronics and Neutrik
If your next design demands frequent connector mating and unmating and use in countries throughout the world, a twist and latch locking AC power connector would be a great addition to your system design. In this episode of Chalk Talk, Amelia Dalton and Fred Morgenstern from Neutrik explore the benefits of Neutrik's powerCON® AC power connectors, the electrical and environmental specifications included in this connector family, and why these connectors are a great fit for a variety of AV and industrial applications. 
Nov 27, 2023
119 views