Life on the Hardware-Software Frontier

In last week’s post, we spent quite a bit of time talking about the concept of a (realistic) use case that reflected how actual users will eventually manipulate the design being verified. Our focus was on Breker’s graph-based scenario models and how they can easily and concisely capture such use cases. We did some research on the term “use case” and found that it seems to be more common in software design and verification than in hardware verification. That caused us to think about how we at Breker seem to be living on the hardware-software frontier.

It’s not uncommon for hardware designers and software engineers to borrow ideas from each other. Code coverage, for example, was well established in software before it was adopted for hardware design and verification languages. With the move from gates to RTL, hardware became just another form of code and therefore more amenable to software techniques. This is just one example showing that the boundary between hardware and software is fuzzy and changing over time.

We’ve discussed at some length the current trend in which several types of chips are evolving into multi-processor SoCs. This means, of course, that some functions formerly implemented in dedicated hardware blocks will instead be performed using code running on the SoC’s embedded processors. This is another case of a constantly shifting boundary between software and hardware. It is also an example of Makimoto’s Wave, in which product development ebbs and flows between generalization and specialization.

Anything that can be performed in software while meeting performance goals will be; when new requirements exceed the capability of the code, specialized hardware will be developed. This seems entirely reasonable, although if you dig a bit deeper you may find that the hardware implementation uses microcode, which is really just another form of software. Just to confuse matters even more, some people use “microcode” to refer to the hardware-dependent software (HdS) running on the embedded processors in multi-core SoCs.

So what does this have to do with Breker? For a start, we automatically generate software test cases to verify hardware, so we’re naturally somewhere along the frontier. Beyond that, our users often include existing HdS such as bare-metal drivers in their scenario model descriptions to reduce the size of their graph. To the extend that portions of this code is reused in the production drivers, we are effectively helping to verify some of our customer’s SoC software as well as their hardware (RTL code).

Our generated test cases run very efficiently on high-level processor models such as those from Carbon, and in fact some of our customers have used us at the ESL stage as well as in RTL simulation. Usually there are two goals: get an early read on such critical system metrics as performance and power consumption; and to try architectural tradeoffs before starting to write RTL. All of ESL is very much on the hardware-software boundary.

Finally, we come to the topic of software generation. Today we generate test cases for verification of hardware. But one can imagine a scenario model at a high enough level of abstraction that we could generate test cases for software verification as well, and perhaps the software itself. The company Vayavya Labs promotes the generation of production-quality device drivers in this way. We wonder whether it might be feasible to extend the scope of the Accellera Portable Stimulus Working Group (PSWG) into the HdS domain, especially since Vayavya is a fellow member

This post has been a bit of a grab-bag of topics along the hardware-software frontier. The key message is that there is no clear line, with technology migrating back and forth as needed. We’re not sure how the industry will evolve going forward, but we’re excited at the possibilities. Stick with Breker, and you’ll have a front row seat.

The truth is out there … sometimes it’s in a blog.

Tom A.

Tags: Accellera, Breker, device driver, EDA, functional verification, graph, graph-based, hardware, hardware-dependent software, HdS, portable stimulus, PSWG, realistic use case, scenario model, simulation, SoC verification, software, test generator, use case

This entry was posted on Wednesday, August 5th, 2015 at 4:56 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.