Of course the current buzz is all about "Property Languages" (or "Assertion Languages," or whatever you wish to call them). One can only imagine how much fun we'd all have if there were four or five competing standards! This is why, in my May 15 column "Why Properties are Important," I stated:

"If like me, your reaction is "Please, not again!" then you'll have been as delighted as I was by the April 22 news announcement from the Accellera Formal Verification Technical Committee. After months of careful deliberation and debate by members of the committee, which represents a wide variety of electronics and EDA companies, they selected the Sugar formal property language from IBM."

Ah, how young I was and how innocent ... and how quickly things can change in only a few short weeks. I started to realize that things were not quite as they seemed when everyone continued to throw their own property languages into the pot at this year's DAC. I also became puzzled when a number of folks started ranting and raving that the syntax and semantics of Sugar were horribly non-compatible with SystemVerilog 3.0, which had also just been adopted as an Accellera standard. I asked one Sugar detractor (who shall remain nameless) why a group like Accellera would adopt two disparate standards, and he tapped the side of his nose in a knowing manner and muttered "two different committees" before disappearing into the sunset with his lower lip quivering and a little tear rolling down his cheek.

So, amongst all of the other incredibly time-consuming tasks I had to perform at DAC (quaffing copious amounts of beer and attending every party isn't as easy as you might think, let me tell you), I tried to make sense of where the various languages were positioned and where everyone was heading. Which, if I were a betting man, I would have to say was to the four points of the compass.

First of all, the good news
Settle down. I just used this title to cheer you up and to increase the sum total of happiness in the world. In reality there isn't any good news. Wait, I tell a lie. At last year's DAC the proponents of SystemC were fiercely battling things out with the various Verilog factions. By comparison, everyone this year was shaking hands, slapping each other on the back, calling each other jolly good fellows, and saying that they had got things wrong.

Apparently the way things are going to work from here on in is that SystemC will be used by system architects and system designers, who will then hand off to traditional HDL-based design engineers using Verilog (in one or more of its incarnations) and/or VHDL. It all sounds rather cozy, really ... let's wait and see, shall we?

In the beginning there was the original Verilog we used to know and love so well, which moved into the public domain and evolved in the hands of Open Verilog International (OVI). For the purposes of these discussions, and to match the current positioning of various companies, the earliest flavor of Verilog we'll concern ourselves with will be referred to as Verilog 95. Over time, this was augmented and enhanced until we had Verilog 2001 (or Verilog 2K1), which many would say was much like Verilog 95 but with "go faster" stripes painted on the side.

Meanwhile, in 1997, the company Co-Design Automation was formed. Co-design's chief scientist Phil Moorby created the original Verilog, and both Moorby and Co-design's chief technical officer Peter Flake were instrumental in the development of the HiLo simulation suite in the early 1970s. Working away furiously, the folks at Co-design developed the "Buck Rogers in the 25th Century" version of Verilog called SuperLog (like Verilog on steroids).

SuperLog combines the simplicity of Verilog and the power of C, and augments the mix with a wealth of verification and system features. Realizing that there's no point in having a language without being able to do something with it, Co-Design also offer a suite of simulation tools that would make even the most hardened design engineer's knees go week. (Don't panic -- we've all heard the recent rumors that Co-Design may be poised on the brink of being acquired by one of the "big boys" like Synopsys or Cadence, but this doesn't detract from the tale with which I'm about to regale you.)

So now we have Verilog 2001 at the lower end of the sophistication spectrum ("jolly nice but lacking a lot of features") and SuperLog at the other end ("incredibly powerful, but as yet falling well short of industry-wide support"). This is where Accellera reenters the picture. These busy little rapscallions have been working with Co-design and everyone else on the planet to come up with a common meeting ground, which would be SystemVerilog 3.0 (don't even ask me about 1.0 and 2.0).

The great advantages for SystemVerilog 3.0 from most people's perspective is that it includes things like assertions and extended synthesis capabilities, and it's an Accellera standard, so it will quickly gain widespread adoption. The advantage for Co-Design is that it's a step along the way to transmogrifying the Verilog everyone is using into SuperLog.

Figure 1 - Verilog 2001 to SuperLog

Actually this diagram is something of a simplification, because there could be a number of intermediate steps before SystemVerilog 3.0 evolves into SuperLog (which itself is a moving target, because engineers being what we are, we can't help ourselves from improving things ... even if they don't actually need to be improved any more!).

Of course everything depends on your point of view. The way the folks at Co-Design Automation see the world is that they already have SuperLog, which encapsulates all of the capabilities of less-sophisticated Verilog incarnations.

Figure 2 - SuperLog components

And then we have the property languages ...
By this stage I was beginning to feel that I had a reasonably good grasp on where we had come from, where we were now, and in which direction we were heading into a brave new world, Verilog-wise.

So next I decided to look at the way in which different folks were using properties/assertions with Verilog today. I also thought it would be interesting to discover why some folks thought that the Sugar formal property language was great, while others were moaning, groaning, rending their garb, and proclaiming the end of the world as we know it.

If I knew then what I know now, I would have dropped this question like a hot potato and headed for the hills while still maintaining some semblance of sanity. Similarly, with seemingly simple related queries; for example, I started off by asking anyone involved in this area to define the difference between a Property, an Assertion, and a Constraint ... and they all did ... but everyone defined them in different ways. Oh, my poor aching head. (Actually, if feel you know the way through this quagmire and you have a "pet" definition you'd care to share, please feel free to drop me a line at my email address below).

But I see that I've already overstepped my allotted word count for this column (the "Word Police" at EEDesign are not known for giggles, grins, and smiling faces). So I'll leave that portion of my ramblings for my next column. Until then ... don't do anything I wouldn't do!

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.