Specman Verification
Verification engineer? Verifigen has the right project for you!
Specman And SystemVerilog 
Monday, December 25, 2006, 01:24 PM
Almost one and a half years back I wrote an entry entitled “Specman vs. Systemverilog”, which contained a virulent attack of SystemVerilog and found it inferior to e in most of the aspects that I thought were crucial for an HVL. At the time the SystemVerilog hype was at its height, and numerous people, some with no verification experience at all, were prophesizing Specman’s immediate end. Annoyed at this tidal wave, and considering it to be driven by fear of the relatively new coverage driven methodologies more than anything else, I “gut reacted” with my own prophecy, predicting that SystemVerilog standard will soon turn into a “dead word”.

Looking back it is now safe to say that neither prophecy was correct, and that both Specman and SystemVerilog are here to stay. In fact, I now find the whole Specman vs. Systemverilog (just like the almost parallel AOP vs. OOP) debate a bit childish and out of place. While I still think that as an overall single solution Specman retains the upper hand, I have gradually come to realize that each of the two has some important advantages and stronger domains, and that the best verification strategy, even if not the most economic ones, would probably consist of a combination that uses each HVL to compensate for the other’s weaker spots.

SystemVerilog has two big advantages. The first is that it is an industry wide accepted standard. All the three big ones – Synopsys, Cadence and Mentor – have some SystemVerilog supporting tools. While e is a standard as well, it has only Cadence at its back. Feel free to throw some vicious remarks about the fact that it’s the e standard and not the SystemVerilog one, which had turned into a dead word first.

SystemVerilog standardization also goes beyond the level of the language itself. A single sentence in the standard, which for a good reason became a mantra of SystemVerilog sales, states that “If a solution exists, the constraint solver must find it”. This sentence is an important step in making your code vendor independent. Moving code from one platform to another would not be really feasible if you had to rephrase all your generation constraints. However, even if you don’t do that kind of move twice a day, you now have your vendor’s word, that its tool will be able to solve a certain set of constraints. Such a promise is bound to touch a sensitive chord with Specman users, who are by now accustomed to see solver contradictions caused by constraints that could be solved by hand. It rids us of all those things that Specman force fed us with and that we shouldn’t have known or cared about at the first place, such as the way in which generation order is determined and how it affects generation results.

The other major advantage SystemVerilog has with regards to Specman, is that it is much better suited for integration of Assertion Based Verification (ABV) in the verification process. Integrating ABV changes the division of labor between design and verification teams by leveraging a large part of the block level verification work back to the designers themselves, and leaving the verification team to take care of system and end-to-end tests. This is achieved, for example, by letting designers write the assertions (including coverage) for the interfaces of their modules or their internal state machines, and debug those assertions in case they fail. It implies, for sure, a certain shift from the idea of a verification that is totally separated from design, but it’s a good way to go in times where good verification people are hard to find, and when you have some sort of a safety net in the form of end-to-end tests.

It is true that both e and SystemVerilog support assertions (known as temporal expressions in e) and therefore could both be used for ABV. SystemVerilog assertions, however, lend themselves much more readily for this kind of use. The reason is that SystemVerilog assertions could be implanted in the HDL code itself, or directly attached to an HDL module/entity. You could, for example, get a FIFO code along with some built in SystemVerilog assertions, that make sure it always works the right way. Each time the FIFO is instantiated its assertions will be instantiated as well. The assertions, in this case, might be seen as a part of the design, and not a part of the testbench – you could have a complete SystemVerilog testbench, with generators, checkers and everything, that is completely unrelated and unaware of any FIFO or other module assertions that you have. Achieving the same thing in e is quite difficult because assertions are always instantiated as part of the testbench, and e doesn’t allow for assertions that are part of the design itself. I’m using “quite difficult” instead of “impossible” only because there might be some acrobatic way that would allow you to do that. As for me, I haven’t found it yet (but if I would it would make it immediately to the headline of my blog).
Don’t mistake that last point for an entirely technical one. At the root of the whole thing you have a different vision of how verification should be carried out. With e, you have the verification team that is responsible for every aspect of the verification, even at block level. With SystemVerilog, on the other hand, you have grey zones with designers participating in the verification effort as well. Of course, this also helps understand why Verilog was chosen as the base for this new HVL. As said, each of these visions has its own for and against.

I hope that with this entry I have returned my debt to SystemVerilog. If you want to read about Specman’s strong points (and there are plenty of them), you can read my old Specman vs. SystemVerilog entry…I should probably integrate these two entries into one but I’m too lazy for that now :-)