Rewriting Revolutionary History

The semiconductor design industry has always preferred evolution over revolution. There have been a few successful revolutions but most of the time revolution happens over time through evolutionary steps.

Many people today would probably point to the migration to RTL from schematics as being revolutionary and they are probably right in hindsight. But revolution is not what really happened and it is not how Synopsys became the company that dominated the field of RTL synthesis.

Synopsys started off by making it an evolutionary step, which was to optimize gate-level netlists. Once users became comfortable with the notion of having a tool modify their design automatically, then additional steps and the usage of language-based input to describe parts of the system became more acceptable. Users noticed the increase in productivity and in the higher quality of the design they were able to achieve, drawing them in. The rest is history and looks like a revolution happened.

A lot of people, including me, have said that the industry is ramping up for a revolution in verification. This is being driven by graph-based verification methodologies pioneered by Breker and now coming into public awareness through the standardization of this under the name of Portable Stimulus. Many aspects are revolutionary, but companies need not fear it because there are evolutionary ways in which they can learn about this new technology and gain trust in it.  There are ways in which they can slowly adopt and ways in which they can leverage the productivity gains it will ultimately provide.

Let’s go back to the Synopsys analogy for a moment. The gap between RTL and gate was a huge methodological step (schematics to language-based) but was actually a fairly small abstraction step forward. The mapping between RTL and gate is fairly clear and understandable. In comparison, the gap between what goes into high-level synthesis and the RTL code it generates is a much larger transformation and explains why HLS has not taken off in the same manner. This abstraction gap is important and I will come back to that.

Portable Stimulus can be used in a number of ways, but they all start with a model of verification intent. From this, a tool can generate specific testcases that target execution environments such as simulation, emulation or actual silicon.

In many cases, what is generated is C code that will execute on the multiple embedded processors of the design, thus testing the hardware from the inside out. This is not only faster than writing the code for the processors by hand, but also enables you to develop concurrent bare metal tests that are far more complex than you otherwise could. This abstraction shift is similar to the one from schematics to language.

In addition, most tests will require some interaction with the world outside of what is being tested. This can be handled by a connection to Verification IP models written in UVM and coordinated by some software that is also generated by the Portable Stimulus tool suite.

There is also an easy transition for the design verification team using UVM today. Instead of having to deal with UVM sequences that cannot understand the context of their usage, these can be replaced by graphs, which provide a more powerful and higher level of abstraction. They also provide a lot more portability, which help with the migration of tests between platforms, and enable a lot more communication about verification between teams and across projects.

But that is just the tip of the iceberg when it comes to gains. Portable Stimulus works by targeting coverage goals, not just creating random stimulus on the inputs. This means that the test suite is a lot more efficient and provides automatic coverage closure. It also enables effective verification prioritization.

While UVM users may not be C coders today, they are familiar with object-oriented programming practices and the migration to C++ will not only be easy for them, but look much better on their resumes than another domain-specific language.

Portable Stimulus incorporates the C++ language, a small step from the language and method that many teams are already using for doing system-level test and for doing first silicon bring-up. It is also the language most likely being used by the embedded software team who will get a huge productivity boost and an easy methodology migration from their current methods to using Portable Stimulus.

If the system-level verification team starts to create these verification intent models, they will be directly reusable by the other stages of verification. The models for each block can be used for both system-level verification and for unit level test. This works both ways around. If IP is included in the design and has a corresponding Portable Stimulus model, it can be directly incorporated at the system level with no changes. Thus teams get the benefit of leverage as soon as anyone starts to use it.

Portable Stimulus has easy migration paths for the entire verification team, ranging from system-level test, to software, to design verification and to silicon bring-up. This is because of the underlying C++ programming and semantics. The abstraction gap is small and understandable, and that means that the tools will gain trust quickly. It will be seen as a productivity enhancer. The power of leverage will then increase the potential gains for other members of the verification team. At the end of the day, it will totally look like a revolution happened, but that can only happen by making that gap and transition evolutionary.

Breker has been working with users on graph-based methodologies for almost 10 years and has helped them make the transition. In return, Breker has learned how to help minimize the gap that they have to cross and to make that first evolutionary step as simple as possible. Together we can do this.

Tags: Breker, C++ programming, graph-based verification, portable stimulus, RTL, verification

Category: Knowledge Depot

This entry was posted on Friday, June 9th, 2017 at 1:47 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.