feature article
Subscribe Now

When Things Look Suspicious

ASIC Analytic Looks for Anomalies in the EDIF File

“Somethin’ just ain’t right about that boy.”

She snuck a sideways glance at him sitting alone at the counter, nursing a cup of coffee, rumpled like he just woke up in those clothes, oblivious to the furtive comments of those sizing him up at the nearby table.

“Yep, I cain’t quite put my finger on it,” she continued, “but he ain’t from this county, that’s for sure. He don’t look folk in the eye, he pert near run me down on the sidewalk th’other day not watchin’ where he was a’goin’. He don’t seem to have a job or nuthin. Just ain’t right in the head, I’m thinkin’.”

“Oh, come on Mae, you’re always getting’ all suspicious and such about new folk. What’s he done to hurt you?”

“Well, I done had my eye on him ever since that car come into town and dropped him off at Ricky’s ol’ place where he’s stayin’. Don’t know who was drivin’ the car; ain’t seen it since. Like they just dumped him off and that was that. He don’t seem to bother nobody, and I been watchin’; mostly he just sticks to hisself and don’t pay nobody no never-mind. So it ain’t like he’s doin’ somethin’ wrong, it’s just that, well, I don’t know… He just ain’t right.”

In a structured environment, things stick out when they look different. And if being different is a bad thing, it must be fixed. The nails that stick up must be hammered down.

Of course, sometimes we only think being different is bad. Sometimes it’s just… different. So the challenge is to tell the difference.

Now that synthesis tools have stabilized for many years, patterns have presumably developed that indicate the kinds of circuits that are typically created by synthesis. A scan of the EDIF circuits will generally provide a selection of familiar circuits and structures that suggest that all is well.

Or at least that is what EDA startup ASIC Analytic is betting on. Another company likening itself to Google, it finds and ranks things it sees in the EDIF file that look odd as a way to bolster verification.

Whereas once upon a time the EDIF file was something that people used to describe circuits (or, at the very most, was the direct output of a schematic program or some other such input aid), nowadays it’s pretty much just an internal interchange format that links the output of synthesis to the input of the next backend steps.

Back in the early days of synthesis, equivalence checking provided a way to ensure that the content of the EDIF file correctly matched the intent of the RTL description. This wasn’t some high-level verification step; it was just a confidence-builder to convince the engineer that the synthesis tool wasn’t making a mistake.

Those days are long gone. We pretty much trust synthesis tools now, and they make so many optimizations and transformations that there would be no way to use simple equivalence checking anymore anyway. This is generally considered progress.

So, for the most part, there’s no longer any real reason to go poking around in the EDIF file. Just take it as output and feed it to the next tool.

But ASIC Analytic doesn’t see it this way. They see in the EDIF file an indication of the health of the circuit. They comb through the file looking for anomalous structures, listing and ranking what they find in order of what they believe to be the priority of the anomaly. It sounds more or less like a process of linting the EDIF file, except that not everything found will necessarily be a mistake.

What they search for and how they do the rankings are not public information (although I don’t know if they are as top-secret as Google’s algorithms). But, for example, if both floating inputs and floating outputs are found, the floating inputs will be ranked above the floating outputs since they appear more sinister. At that level of decision, you can imagine a complex set of ranking rules.

The things they find won’t all necessarily point to problems – and in fact right now they don’t filter; they just list everything. They are working on some post-filtering so that the amount of output that needs to be analyzed by the engineer is reduced. But the operating theory here is that significant issues may well lurk within that list, and they need to be addressed.

In general, there are three possible sources for any problem found: a mistake in the engineering, a mistake in the RTL, or a mistake in synthesis. The analysis tool explicitly operates on the basis of “assume nothing,” but, in fact, most of the problems originate with the first two. Mistakes caused by synthesis will typically arise from incorrect options, false paths, constraint problems, clock settings, and other such input problems. You’re typically not discovering new mistakes that the synthesis engines are making.

When design problems are found, some can be fixed at the EDIF level, some at the RTL level. It’s not clear to me how many designers actually go mucking about in the EDIF file, and making a change there breaks continuity between the original design file and the backend, so it would seem like that might be a less preferred option. But it would be naïve to assert that no one ever breaks the continuity chain when it comes to last-minute ECOs, so I guess this would fit in that same category.

The challenge for an approach like this is that it operates at a low level of abstraction. The better job verification tools do earlier on in the process, the less likely it will be that errors show up in the EDIF file. In fact, it would seem that one of the proofs of the effectiveness of higher-level verification tools is a gradual diminution in the number of errors that propagate all the way through synthesis without being detected.

So, as a fundamental technology, this has to move forward with the confidence that, no matter how much engineers and other verification companies do to improve the quality of the input to synthesis, something’s inevitably going to get screwed up.  That the strange things found in the EDIF file will actually be wrong, not just different. And that, without an approach like this, there will always be a few bugs that, left undetected, would escape to create a faulty mask set.

And that just wouldn’t be right.

 

More info:

ASIC Analytic

Leave a Reply

featured blogs
Sep 21, 2023
Wireless communication in workplace wearables protects and boosts the occupational safety and productivity of industrial workers and front-line teams....
Sep 21, 2023
Labforge is a Waterloo, Ontario-based company that designs, builds, and manufactures smart cameras used in industrial automation and defense applications. By bringing artificial intelligence (AI) into their vision systems with Cadence , they can automate tasks that are diffic...
Sep 21, 2023
At Qualcomm AI Research, we are working on applications of generative modelling to embodied AI and robotics, in order to enable more capabilities in robotics....
Sep 21, 2023
Not knowing all the stuff I don't know didn't come easy. I've had to read a lot of books to get where I am....
Sep 21, 2023
See how we're accelerating the multi-die system chip design flow with partner Samsung Foundry, making it easier to meet PPA and time-to-market goals.The post Samsung Foundry and Synopsys Accelerate Multi-Die System Design appeared first on Chip Design....

Featured Video

Chiplet Architecture Accelerates Delivery of Industry-Leading Intel® FPGA Features and Capabilities

Sponsored by Intel

With each generation, packing millions of transistors onto shrinking dies gets more challenging. But we are continuing to change the game with advanced, targeted FPGAs for your needs. In this video, you’ll discover how Intel®’s chiplet-based approach to FPGAs delivers the latest capabilities faster than ever. Find out how we deliver on the promise of Moore’s law and push the boundaries with future innovations such as pathfinding options for chip-to-chip optical communication, exploring new ways to deliver better AI, and adopting UCIe standards in our next-generation FPGAs.

To learn more about chiplet architecture in Intel FPGA devices visit https://intel.ly/45B65Ij

featured paper

An Automated Method for Adding Resiliency to Mission-Critical SoC Designs

Sponsored by Synopsys

Adding safety measures to SoC designs in the form of radiation-hardened elements or redundancy is essential in making mission-critical applications in the A&D, cloud, automotive, robotics, medical, and IoT industries more resilient against random hardware failures that occur. This paper discusses the automated process of implementing the safety mechanisms/measures (SM) in the design to make them more resilient and analyze their effectiveness from design inception to the final product.

Click here to read more

featured chalk talk

Johnson RF Connectivity Solutions
The growing need for remote patient monitoring and wireless connectivity has made RF in medicine applications more important than ever before. In this episode of Chalk Talk, Amelia Dalton chats with Ketan Thakkar from Cinch Connectivity Solutions about the growing trends in medicine today that are encouraging the use of RF, why higher frequency, smaller form factor, cable assembly expansion and adapter expansion are vital components in today’s medical applications and why Johnson medical solutions could be a great fit for your next medical design.
Nov 28, 2022
34,937 views