July 21, 2008 -- I suspect my comments may offend a few hardware engineers and probably a bunch of software engineers, so I’ll apologize in advance for that. OK, with that out of the way, I can’t help but notice two interesting phenomena that happen on a regular basis between hardware and software development communities. While most hardware engineers probably won’t admit it, many are of the opinion that hardware design is much more difficult and far more sophisticated than software design. It is “engineering” after all! Frankly, I tend toward the hardware side of the equation, and having done both hardware and software development, I tend to agree with this view. Yet, at the same time, I can’t help but notice that hardware design practices tend to lag software design practices by about five to ten years. Hmmm. . .

Case in point: SystemVerilog. If you haven’t heard about SystemVerilog, you might fit the profile of Darwin’s Galapagos Island species (i.e., very isolated). SystemVerilog introduces a spectrum of new capability for both design and verification, although most of the power is currently targeted in the verification world. But in case you haven’t had an opportunity to indulge, let me tell you that at the "root, branches and leaves" of the language, you will find object-oriented (OO) programming.

At this point, the software developer who might be reading this is most certainly yawning. After all, object-oriented programming has only been around since 1962 (SIMULA), and later reincarnated in the 80’s with ADA and PROLOG before eventually becoming absolutely mainstream in the 90s with C++ and related languages. So here we are, ten years (or more) after mainstream software adoption of OO and OO has hit the big time in hardware design. Wohoo! Incidentally, this five to ten year lag phenomena isn’t a one-time event. There are lots of other occurrences, such as the introduction of programming language for hardware design description (VHDL and Verilog), or using version management systems. Both occurred many, many years after their equivalents in the software world.

As for OO programming, it’s better late than never. The fact is, SystemVerilog and System C are extraordinarily powerful languages that solve some really important problems, due in large part to the OO nature of the language. Add to that, the sophistication of advanced verification methodologies, such as the Open Verification Methodology (OVM), and you have just traded in your bicycle for a Lamborghini or perhaps a Tesla would be more environmentally correct (they both do 0 to 60 in about 4 seconds; the Tesla does it at 135 MPG equivalent vs. the Lamborghini at 11 MPG).

Consider SystemVerilog for test bench design: Code reuse is inherent. Intellectual property (IP) creation is de facto. Coding productivity is phenomenal. So, despite my bias toward the hardware design community, my hat’s off to the software community which has brought us OO programming.

But, as the old saying goes, there’s no such thing as a free lunch. Advanced languages and methodologies, like SystemVerilog and OVM bring some new “learning” opportunities. As it turns out, most members of the hardware community that I know who are over 35 weren’t trained in OO programming techniques in college. So most hardware designers aren't familiar with the notion of Classes, Inheritance, Polymorphism, Factories (which by the way, are not a derivative of control system plants), virtual methods, constructors/destructors, assertions … the list goes on. Add to that, the new methodology involving Transaction Level Modeling (TLM), Constrained Random Stimulus, Transactors, Functional, Structural and Prototype Coverage, Checkers and Scoreboards, and you might begin to feel overwhelmed.

But, here comes the good news. In addition to the new OO languages, advanced verification methodologies and the platforms that can run them, a new breed of EDA tools have emerged to tame OO programming and advanced verification methodology coding. These tools intrinsically understand OO programming, OO languages, and verification methodologies to aid the “newbie,” as well as the most seasoned verification engineers in leveraging these languages.

One of the real challenges in OO programming is actually understanding what you’ve created. It sounds funny, but if you think about traditional hardware languages, when you create a design, you typically instantiate coded objects into a netlist. Netlists are readable and the designer can easily identify the structure of the design by simply reading the code. Not so in the world of OO. In this world, objects get created (and destroyed) during simulation run time, which makes it pretty tough to even know what you are making while you are making it.

These new tools work in real-time, not unlike spelling and grammar checkers, to reflect the state of the design through analysis. This ultimately prevents mistakes, improves code quality and reusability, reduces debug time, and accelerates creation and assembly of very powerful test benches.

Most engineers I know love to leverage the power of the latest in software process and technology, as long as they can avoid having to become a computer science major in the process. It seems that the combination of new languages and new tools will deliver just that. Which makes me wonder, what will we inherit in the next decade from our software design brethren?

By Glenn Perry
Perry is General Manager, ESL & Design Creation Division, Mentor Graphics Corp.