In case you hadn’t noticed, I like to write from time to time about EDA product ideas. I assume these are somewhat original, but given the maxim “there’s nothing new under the sun…”, I may well be wrong. In any event, I like to share these ideas if only to demonstrate that innovation in EDA is not stalled because we’ve run out big, exciting things to do. I’ll grant there are plenty of challenges on the business side but I’m hopeful that sooner or later someone will prove that profitable innovation outside the box is still possible.

We start with a proven problem: verification, the monster eating SoC design resources and schedule. High coverage, the benchmark of verification completeness as it used to be understood, has become a distant memory replaced by concepts such as “test all reasonable software use-cases” and “test until you run out of time”. Part of the problem is that the directed-random approach so effective at the IP level does not scale to SoC, leaving you with inevitably bounded case-based testing and an abiding suspicion that gremlins may still lurk in use-modes you haven’t tested.

And that motivates interest in static verification of integration-level logic as a way to get to at least one component of coverage completeness. Conventional wisdom builds a giant spreadsheet of expected connections between IPs, qualified by configuration settings and simple temporal conditions. A checker verifies that the SoC-level RTL is consistent with this spreadsheet, using graph-tracing and closely-bounded formal analysis, without needing to drill down inside IP-level logic. Because these are static checks, a complete check of all connections offers a coverage-like sense of confidence for this verification objective.

Nobody believes this is a great solution. It’s a huge amount of work and it’s massively tedious to develop the spreadsheet. And it is just as likely to be as error-prone as the RTL and probably will repeat systematic interpretation errors in the RTL, since it will be developed by the RTL design team or or a closely-related team.

So here’s the product idea. Spreadsheet approaches fall short because they are too atomic. They are a kind of machine-code representation of the integration when what we want is a higher-level, human-readable view: under such-and-such configuration settings, this IP gets a clock of this frequency or this reset pin gets a warm reset from this reset generator pin with a stall of 10 cycles before being released or … So I propose a tool that could first reverse-engineer this architectural intent from the implemented RTL. I call it a “What I Really Built Logic Extractor” or Wirble (the name is at least memorable and I’m no longer responsible for real product names).

A Wirble abstracts architecture one plane at a time: clock, reset, interrupt, bus, test, IO, .., just at the integration level, not down into IP. It may need a few hints here and there (for example this is a PLL clock output pin) but whatever may be required will be orders of magnitude simpler than what is a required for a spreadsheet. It then builds, per plane, a table or graph, a timing diagram or a very abstracted logic description showing what resources are delivered from what sources, under what conditions, to what consumers. This might be a static representation or a dynamic view where you can click through configuration options. For clocks you have to understand multipliers and dividers and muxes and gating, for resets you want to understand reset domains and what activates them (at a high level) and with what stalls. And so on.

All of this should (if well implemented) be much easier for a designer or architect to scan and immediately spot implementation problems – wherever what you really built doesn’t match what you should have built. Perhaps you may even conclude there was a bug in the spec, leading you to a corrected or perhaps even improved implementation.

I’m not claiming this will be easy. This is a tough (but I think tractable) problem with high potential value. It will require graph-tracing and formal (with cleverness in black-boxing, so formal doesn’t get lost). It will require a lot of special-case handling to cover different architectures (this is nothing new – synthesis has mass amounts of special-casing to handle different RTL structures). And it will require a clever and very intuitive representation of abstracted functionality which a designer can scan quickly for potential errors. On the plus side, it isn’t necessary to handle every plane from the outset. A Wirble that could do a good job on the clock and reset planes would provide immediate value in verification; support for more planes could be added over time.

Once the SoC team has a signed off Wirble output, they now have a human-readable regression standard against which subsequent Wirble runs could compare as the design progresses, and report not simply that connection XYZ is different from the latest RTL drop, but also that the USB external clock is disabled in configuration ABC where before it was enabled.

One last thought. Perhaps instead of abstracting Wirble output from an SoC RTL, you could do a reverse-Wirble and generate that plane of integration logic from a hand-created Wirble spec. That means you now have an integration which is correct by construction. And you can still Wirble-verify that what was generated was what you expected. Lest you think I am now completely in fantasy-land, I know of at least one design company that is already doing something very similar.

That’s it – build a Wirble if you want to build something out of the ordinary. But please don’t ask me detailed market or implementation questions. I gave you the concept, the rest is up to you.

More articles by Bernard…