Get email delivery of the Cadence blog featured here
This month, we celebrate the 20th anniversary of Specman’s introduction to the public—at DAC 1996 in Las Vegas. This introduction was not simply of a new tool—it was the introduction of a new concept. Specman included e, and thus, with that introduction, the first Hardware Verification Language was born.
Many of you, I suspect, were still in high school in the 1990s. You would be amazed if you saw some of the verification environments written in those old days. Verification environments were implemented in almost every programming language you can think of—C, Pascal, Verilog, scripts…. What could you do with these languages? You could, for example, write a long file with input (i.e. a list of CPU instructions) and inject them one by one into the device under test. The designs then were much smaller than they are today, so most engineers were happy with these testbenches.
Luckily for us, Yoav Hollander was not that happy. Hollander decided to create a new functional verification tool that was based on a new language, a language that was tailored specifically for creating verification environments.
So, what should an HVL language contain?
For interaction with RTL designs, it should have a notion of time and some means to connect to the device under test. (In the early days of e, “tick access” was used; ports were added a few years later.)
For creating interesting scenarios while minimizing manual work, the HVL should have randomization capabilities, so that the long, directed input files can be replaced with short tests containing a small number of constraints. Hollander knew that simple randomization was not enough for advanced verification. Engineers need more than a simple “randomize a value between 0 and 100.” Verification environments need to be able to define complex relations between fields, including fields of different structs. So, Specman included an advanced constraints solver, Pgen (Pgen was replaced about 10 years later by a far more advanced solver, IntelliGen).
Generating the environment with a constraint solver saves lots of time when you are creating the tests. It also reduces the maintenance burden (adding one constraint, rather than changing hundreds of tests) and results in a more robust verification environment. Have you seen directed tests that are 10 years old, and nobody dares to modify them because nobody remembers what their purpose was at first place?
But more than that, generating the environment was a part of a new (it was new in the 1990s) verification methodology – Coverage Driven Verification. According to CDV, you let the tools work for you. You define the protocol rules and the verification goals and run random tests. Every once in a while, you analyze the coverage reports and decide which constraints need be added to extend the generation to uncovered areas.
In additions to all these engines—scheduler, constraints solver and coverage—the e language is perhaps best known for being an Aspect Oriented Programming (AOP) language. The shortest answer to what Aspect Oriented is and why it is important to us is contained in one word—“extend.” With e, engineers can extend a struct and add members to it, change a method behavior, replace a constraint, replace a temporal check, and on and on.
When Specman and e were introduced by Verisity 20 years ago, the competition, as expected, did not welcome the new player. One of the statements we and our customers heard often was “why do you need a special language for doing verification? We manage quite well writing our verification environments with other languages.”
Years went by, designs got bigger and more complex, and the EDA industry realized that the old methodology of directed tests did not scale and that, for creating more sophisticated verification environments, a special language was needed. In 2005, a new standard was created, SystemVerilog. Then, instead of hearing “why do you need a special language for verification?”, we heard “Sure, we all know that we need a Hardware Verification Language. But why e? It’s better to use a language that resembles your Hardware Design Language, Verilog.”
As all of you surely know, it didn’t take much to understand that a language that is “very much like HDL” is not enough for verification. Methodology libraries were built on top of SystemVerilog, the best known of which is UVM-SV. And what do these libraries contain? Configuration, sequences, reports (messages) …. Well, perhaps you do need a language that is specially tailored for verification.
Verification is a challenging task; it’s no surprise that it attracts enthusiastic engineers who seek perfection. If you search the net, you will find some of these enthusiastic engineers involved in interesting discussions about verification languages.
Some discussions about AOP:
Brian Bailey’s blog Aspect Oriented for Design,
You can also find some interesting posts in the Specman Users Group on LinkedIn. For example, a comparison of languages productivity written by Blake French started a lively discussion.
All this started with one innovative person, Yoav Hollander. If you ask yourself what he is up to these days -- and/or if you ask yourself what the future of verification is – visit The Foretellix Blog.
Enjoy verification,(if you use e - we know you do :) )
Efrat Shneydor, Team Specman