The biggest effort of the kind was IBM's attempt to unify COBOL and FORTRAN into PL/1. The result was to be all you would ever need for business or scientific computing. But the compilers were huge for the time, and in the early stages only IBM ever wrote one. In spite of huge promotion, PL/1 just never really caught on. It was never loved.

All else being equal, having one language for a range of tasks is, of course, valuable. It allows for reuse of engineers if nothing else. Your designers can verify and your verifiers can design, without holding two languages in their heads simultaneously. Cool. Just make sure you avoid a single person designing and verifying the same module, and who wouldn't want engineer reuse?

But if design and verification are sufficiently different tasks, then sticking to one language comes at a cost. It is the cost of not having the ideal language to hand for one (or possibly both) of the two tasks. After all, we'd get engineer reuse if Perl were mandated for all software.

But while that's acceptable for the systems administrator script writers, it's not for people who want to write high performance graphics. And neither would the majority of systems admins or graphics gurus thank us for insisting everything was written in Prolog. Application domain does matter.

Also, if the single language is created from a conjunction of more than one original language, another potential cost is introduced. It is the difficulty of working with an overly large language, and one in which a portion of the syntax is simply not available in your particular problem space. Open source evangelist Eric Raymond's comments on Perl versus Python hit a nerve: " ... many of the features that were later patched into Perl to address the complexity-control needs of bigger programs ... had a fragile, jerry-rigged feel about them."

But that's the theory. In practice, are design and verification sufficiently different to render "oneness" too costly? From a technical point of view, the answer seems to be "yes". And the reason is what we could call the "Tyranny of Synthesis".

Despite continuing improvements in synthesis technology, and the advent of more abstract design entry capabilities, the bulk of today's HDL-based design is still not much more than the extensive use of "always @(posedge clock)". It has to be — synthesis is, for the most part, still too complex a task for it to be otherwise. The need to get to gates is a brake on the engineer's thought processes. And so the programming aspect of the design task is relatively simple.

But in sharp and increasing contrast, HVLs and their target domain, verification, are not held back in this way. In the context of a powerful HVL such as e, or Vera, writing a testbench is akin to writing a device driver. And writing a device driver has much greater scope for complex thinking, and abstraction as a solution, than writing a device.

So, creating HDL digital designs is a very different task from creating testbenches for those designs. Specifically, verification is — or, more accurately, is able to be — a more complex task than design. Therefore, the ideal languages for design and verification are different. Rather than merging the two into a single unit, an alternative approach would be to optimize Verilog/VHDL for design, optimize e/Vera/whatever for verification, but have an overlap for any design-for-verification constructs such as assertions.

Finally, joining together design and verification constructs, with a sprinkling of C does raise the question of what it means for something to be a single language. Je could just mix French et Anglais, and hope pour a unified whole. Mais, it's ne going to happen pas. In other words, even if design and verification were similar and so a single language was worth doing, it's not clear that SystemVerilog is it.

It could be argued that it's not really a single language at all. It will be no surprise if designers using SystemVerilog ignore one significant fraction of the language, and verification engineers ignore another. Even if a single engineer is doing both design and verification, they will find that they are effectively working with two languages wrapped under a single name.

Of course, all of this could change if HDL design were freed from the Tyranny of Synthesis. That's unlikely to happen any time very soon, but it's coming closer. And there are clearly good logistical reasons for wanting a single language. Unified training, unified licensing, and certainly the opportunity for many engineers to see some increase in skill reuse are candidates.

Furthermore, SystemVerilog is certainly an advance on Verilog for design or verification. Provided we resist the temptation to treat it as a single language silver bullet, SystemVerilog is a welcome addition to the EDA arsenal.

In the end, to the engineers at the sharp end of an emacs buffer, the key to successful use of SystemVerilog, e, Vera or any of the newer languages is to embrace software approaches to complexity management and to see them as essential additions to their portfolio of skills. Verilab's view is that all of these powerful languages, including SystemVerilog, provide significant benefits to the designer and verification engineer over the simpler HDLs. Which, if any, of the current contenders will prevail shouldn't matter to the well-equipped engineer with sufficient software exposure.

Tommy Kelly is CEO of Verilab, a provider of verification services, methodology consulting, and training.