Abstracting Abstracter Abstractions In Functional Verification

I heard a clear three-part message during DVCon at the end of February:

1. verification engineers must abstractly embrace the abstract idea of abstracting abstract abstraction through higher levels of abstraction;
2. we overuse the word abstract to emphasize the value of whatever verification technique we happen to be talking about; and
3. the key to new abstractions is using Portable Stimulus as abstractly as possible.

Hopefully we can agree those first two points aren’t all that new. The third is definitely new’ish… at least it is to me.

Seems Portable Stimulus is the newest next big thing and it comes with the promise of abstraction-induced productivity. I don’t know much about Portable Stimulus yet, but I’m pretty comfortable with the idea of abstraction so I thought it’d be interesting to take a look back at how successful we’ve been at creating new design abstractions and give people the chance to ponder how it may turn out with Portable Stimulus.

First, let’s agree on what it means to move to a higher level of abstraction. To me, abstraction means we’ve found a new way to represent foo that adequately captures its essence while simultaneously allowing us to avoid dealing with its details.

Foo could be anything. Foo could be the Mona Lisa. There’s a lot of detail in the Mona Lisa. People have written extensively about it; everything that came together to form a magnificent and mesmerizing work of art, Leonardo da Vinci who painted it, the effect it had on other artists and so on. That’s great; for some people those details matter. For the rest of us, an entire book about the Mona Lisa is more than we need. To us the Mona Lisa could just as easily be described as “an old painting from that famous guy of a woman with long dark hair and an odd smirk.” This is an abstract description of the Mona Lisa; an adequate generalization that captures its essence.

Within the context of hardware development, a more pertinent example of design abstraction is RTL. Through RTL – with it’s associated languages and tooling – we’ve given people a way to adequately generalize circuit behaviour while letting them largely ignore the existence of individual gates and completely ignore the existence of transistors. Design and verification IP are other good examples of abstraction. IP is a generalization of a specification that let’s us plop down an SoC sub-system or instantiate some portion of a testbench while largely ignoring its related protocols and implementation details.

Creating new design abstractions done well comes with productivity benefits (see: RTL vs. schematic capture). By definition, it also comes with trade-offs. The most obvious trade-off is that we lose control of the finer details. Successful abstractions come with productivity benefits that outweigh that loss of control.

We’re not always successful when it comes to abstraction because sometimes the loss of control is intolerable. For example, attempts at raising design abstraction above RTL – through languages and tooling for HLS – continue to fall short. (Not to dump on HLS too much, because clearly niches exist where teams have demonstrated more abstract languages as being superior to RTL because of it. But I think I’m pretty safe in saying RTL is still the overwhelming favorite as a mainstream design abstraction despite the years of research, investment and advertised potential regarding HLS.) The various design capture languages derived from C, for example, can be abstract to the point we lose connection to the hardware and opportunities for its optimization. In other words, a design abstraction is inadequate when it’s too abstract.

Another attempt at abstraction that will hit closer to home for verification engineers is transaction-level modeling. TLM aims to raise abstraction from pin level hardware interactions to loosely timed – or untimed – message based communication. TLM may be commonplace within verification teams, but I’d argue its value is less than overwhelming. Our modeling habits tend to be dictated by low-level bus protocols; bus cycles mapped directly to transactions with pins and buses mapped directly to fields. The data structures we use may give us the impression we’ve chosen a more abstract representation of pin-level transactions, though in a lot of cases all we’ve done is chosen a different representation of comparable granularity. All the same details travel through testbenches – starting from sequencers and terminating in scoreboards and checkers – in a way that makes it hard to achieve the bonus productivity we hope for. Given the consistency in detail between pin-level interfaces and modeled transactions, I think it’s more appropriate to call TLM an incremental improvement than true hardware abstraction.

To review: we nailed abstraction with RTL and IP; design capture in higher level software languages for the mainstream is too abstract; TLM isn’t abstract enough.

Which brings us to the next big thing. One of the selling points of Portable Stimulus is that it offers modeling and test at a level of abstraction more productive than where we are now. Given our history of mixed results, I think it’s only natural to question whether or not that’ll end up being the case.

If you’ve read this far hoping I have some smart insight into how things will work out, you’ll be disappointed to hear I don’t know enough to offer any. What I can say is that after listening to some of the people at DVCon who do have the insight, I made a few observations that I believe are mild cause for concern.

Specific to Portable Stimulus, I saw some detailed examples of how to model behaviour at DVCon, but I didn’t see anyone step back and present the value of Portable Stimulus with its trade-offs. Abstraction comes with trade-offs. Without admitting the trade-offs, I automatically question the value of the abstraction. It also wasn’t clear where and how Portable Stimulus applies. Aside from being presented as having a broad scope, I didn’t hear anyone at DVCon present how Portable Stimulus either (a) complements or (b) replaces our current development paradigm. Lastly, with Portable Stimulus we have a new language – a declarative language no less – that’ll present a hurdle for teams adopting it. I’m interested to see how developers take to it.

More general concerns have to do with publishing a PSS so soon. Surely I can’t be the only person who thinks standardizing an idea before it’s been readily adopted by users gives the appearance of being written to the benefit of tool providers instead of users. Further, I heard the “cooperate on standards, compete on tools” argument invoked a few times in discussions but it was stated more as fact than as part of a legitimate argument. That skips past the “compete on ideas” step where the real value is born, though admittedly, maybe the competition already happened and I got here too late to see it.

None of these observations signal guaranteed show stoppers, but in my mind they are points that’ll need to be addressed before Portable Stimulus succeeds in providing a new means of design abstraction.

One thing people did agree on is that we’re still in the early days of Portable Stimulus. If you have an opinion on what’ll happen with Portable Stimulus or a different view on how successful we’ve been with abstraction, now would be a great time to jump in.

-neil

PS: Rolling back to bullet two from the very beginning and the idea we overuse ‘abstraction’ to emphasize value… I’d like to encourage my fellow design and verification engineers to call BS when people invoke abstraction as a solution without further explanation. It happens too often. Not that abstraction isn’t a worthy goal because it is, no doubt there. But we’ve conditioned ourselves to accept ‘abstraction’ as a valid argument on its own by ignoring the fact that creating a productive design abstraction isn’t always easy, obvious, guaranteed or even useful. If people give you ‘abstraction’ without a clear value proposition or explanation, consider this a reminder to ask for more.