Friday, June 20, 2008

Verification Planning

David Robinson, another Verilab dude, has started a blog over here. Coincidentally, David also just uploaded his recent DAC presentation, made in association with Springsoft. The document is simply the PowerPoint slides, so it'll be of primary use to anyone who attended one of David's sessions and wants the slides as a reminder. Verilab does however provide intensive consulting on requirements-based verification, so if you'd like to discuss that in more detail, give us a call. Our emails take the usual canonical form: firstname dot lastname at verilab dot com.

Tuesday, June 17, 2008

What does business need from "The Government"

That - specifically about EDA, but it applies more widely - was the thorny issue tackled by some brave souls at one of the numerous panels at DAC last week. It's good I wasn't on that panel. My answer to the question tends to be a more or less (usually less) polite version of "To have them get out of my face and let me get on with running a business." In particular, the visa issue they discussed is always a raw nerve for me. It's not just that I myself am an immigrant. It's the fact that my US clients, owned by US shareholders, with lots of US employees, paying US taxes, are crying out for good technical people to make more money for those shareholders, employ more of those US folks, and pay more US taxes, but can't find enough of them because the immigration policies of their own of-the-people-by-the-people-for-the-people government are:
  1. Blocking foreign talent who want to come here from doing that and, as a result
  2. Scaring the local talent away from engineering (because they think all the jobs are going to India)
The first point is particularly frustrating. Put it this way. There is very little question as to whether the amount of VLSI engineering being done by Indian, Chinese and other "foreigners" is going to increase. It is. The only question is, where are they going to be doing it: India or China, on the one hand; or, on the other hand, here. And as current policy stands, it's not going to be here.


It reminds me of a survey in which I participated earlier this year. Somewhere in "The Economist", I'm on a list of people to whom they send such surveys from time to time. As a reward for participating, they'll send me books and let me see the results. This one was on how immigration rules were affecting business in the US. And they appear to have published the results more widely than usual. I'm not sure how long these links will stay live, but here's the press release:

http://graphics.eiu.com/upload/eb/EIU_immigration_PR.pdf

and here is a graphical version:

http://tinyurl.com/3e3bum

Personally I think they're being overly hard on the Americans. I mean, the UK isn't exactly open-armed to the world either. And Europe as a whole - not exactly the land of immigration opportunity, is it? (Just say "van der Elst Visa" and stand back.) No, the real criticism I'd have to reserve for those who although clearly understanding the principles of "Life, Liberty and the Pursuit of Happiness" choose to ignore them; those for whom the terms jus soli and jus sanguinis should be mere Olde Worlde artefacts, never to be used in anger, but instead are baked right into the zeitgeist. The real criticism is reserved for any nation which, despite being:
"...conceived in Liberty, and dedicated to the proposition that all men are created equal",
despite knowing that - to misquote Lincoln:
"They that can give up essential liberty to purchase a little temporary [job security], deserve neither liberty nor [job security]."
and despite having stapled to a big bloody statue the words:
"Give me your tired, your poor, Your huddled masses yearning to breathe free."
still choose a policy that is the modern equivalent of the common ownership of the means of production.

Did I mention this was a raw nerve for me?

Cadence, bla, Mentor, bla, acquisition, yada ...

So now we, 60 and climbing EDA bloggers, have something to blogstorm about. JL's on it already, scooping me by five minutes. And John, at his Semi-Blog, is even gathering comments. Daniel Payne, over at Chip Design Mag, has a take too, and none too complimentary.
600pxmerge_signsvg

Daniel's general sense of underwhelmedness is understandable. But he misses one semi-important verification issue when he says, of a merger, "it really wouldn’t bring the EDA industry anything new". One thing it could do is reduce the number of SystemVerilog methodologies out there, from three to two. The three being the VMM, and let's call them: OVM_m (Mentor's OVM) and OVM_c (Cadence's OVM).

Sunday, June 15, 2008

Saturday, June 14, 2008

On Write-Only Code and SystemVerilog Implicit Port Connections

At the iDesign II session, Cliff Cummings gave a great overview of SystemVerilog implicit port connections. Cliff was, as always, an excellent and enjoyable presenter. And the material was spot on, and current. But at several points during his talk, I felt like someone was scratching fingernails down a blackboard. It wasn't so much Cliff and his presentation. I'd have to say his was one of the best in DAC. Rather it was those subtle wee implications you can pick up if you listen really carefully to a presenter's ad hoc sidebars. Here then are Three Important Things I learned from Cliff (other than the undoubtedly useful details of how implicit port connections work).

The First Important Thing was Cliff's observation that the connectivity-intensive HDL top level of a big SoC is almost completely uninteresting to the human reader. While we have to get those connections down "on paper", few people will ever then want to read them. In "The Budding Artisan's Big Book of Beautiful Code Examples - Learn from the Masters", nowhere will you find a chapter on top level SoC connection code. The top level is, effectively, Write-Only code. In that respect, it's the opposite of what Don Knuth advocated with Literate Programming. The question is, why? The whole point of high level languages is to wrap boring, repetitive, typo-prone structures in an abstraction that protects the humans who have to write things down. The fact that SystemVerilog hasn't really figured that out (interfaces aside) suggests that the abstraction SV provides is, at best, leaky. Look hard enough at Java and you'll see, well, Java. Look hard enough at SystemVerilog, and you'll see wires, and flip-flops, and gates. Oh my.

OK, but so we still need the top level. And interfaces don't take away all the pain. Fair enough. The nice people at the Department of SystemVerilog haven't left us to wallow in our typos. There's a solution in the form of implicit port connections. If the ports on a top level instance have the same name and width as the wires to which they are to be connected, you can avoid the usual shenanigans of connecting them all up and instead just saying the magic words "dot star". Now I'm not a language expert, so take the following with a pinch of salt. But .* smells bad. My first reaction was similar to the one I had when I heard about the use of the * wildcard in sensitivity lists; namely, well why didn't they go the whole hog and give us full regular expressions?

The Second Important Thing I learned came from Cliff's explanation of why they didn't give us full regular expressions. In fact it turns out that the idea of expanding the simple * wildcard to a more complete regexp was discussed. See, those language committee dudes are clever people. The reason the language dudes (hurray) didn't implement the regexp's was because the tool vendors (boo, hiss) pushed back on the idea. Said those same Evil Tool Vendors:
"Hang on. Let's get simple .* going first, before we mess with the gore and pain of more complete regular expressions."
And of course, who can blame them? The key point though is that languages such as the ones we use in EDA are not developed in the cathedral-like purity in which things like Lisp and Haskell arose (if indeed even they did). Our industrial-strength, real-men-have-fabs, your-methodology-sucks-three-cheers-and-a-cookie-to-me languages have a large political component to them. Surprise, surprise. Let's get over it and just remember not to simply blame the poor language committees when they make something a bit smellier than we'd like.

The Third Important Thing was Cliff's explanation for the existence of the ".name" construct. Are you sitting down? (I was, which is just as well.) The ".name" construct is a compromise, made because your typical user of SystemVerilog is scared of the .* construct. Having that 2000-line piece of incomprehensible top level connectivity reduced to a 1000-line list of .*'s, is giving designers the world over the heebie jeebies. And the depressing thing is - Cliff is right! Partly because your typical chip head is a EEE graduate who didn't get the chance to write much code at university, and partly because his typical manager is an EE graduate who may not have had the chance to write any code at university, today's typical VLSI engineer is less comfortable with software engineering than is good for our craft.

So there you have it. Three Important Things I Learned Today:
  1. The SV abstraction is leaky, especially at the top level
  2. Tool vendors have more to say about language design than your average Joe Designer may realize
  3. Average Joe is, however, taken into consideration. Specifically, the fact that he is not too smart on the software engineering front is a bigger factor than you might think
I can just hear the collective, "Well, duh!" resound across EDA-land.

Friday, June 13, 2008

Panning for Gold in California

I'm not sure I actually attended DAC. That root canal flared up and I needed a visit to an emergency dentist the day before flying out in order to pick up some antibiotics to kill off the nascent abscess. That, and heavy doses of Vicodin and ibuprofen left me a bit dazed as I wandered around the exhibits.

Or maybe that was just the exhibits.

Because as the pain, abscess, and Vicodin wore off (and yes, it was just those things - I didn't even make it to the Denali party), I realized just what DAC is (apart from being a Cortical Homunculus). It's another California Gold Rush. True, we're a bit further south than Coloma, but it feels the same. Excited people, from all corners of the globe, descending on an unsuspecting town in the hope of finding a particularly large nugget of value. And, as with the actual Gold Rush, much of the hope is forlorn. It's not that there's no value to be found. Far from it. But the really big nuggets? Like the one found by Spider Conway in "Pale Rider"? Those are rare events.

Finding a major nugget can be industry-changing and create one of those inverted knees in growth curves. Unfortunately, but not unexpectedly, there were none at DAC this year. In fact, in the area of front-end digital VLSI design, I reckon there have really only been two such nuggets found in the last 25 years. The biggest was synthesis of RTL in the early 80's. This was to VLSI design what the then Taniyama-Shimura Conjecture was to Fermat's Last Theorem. Taniyama-Shimura said, very (very) roughly, of two areas of mathematics,
"See elliptic curves? See modular forms? Well, they're kinda the same thing."
As a result, theorems from one area were then able to be applied to the other area, solving problems that had remained pains in the neck for years. And so it was with synthesis in VLSI design. Acting as chip design's very own T-S Conjecture (now a proven Theorem):
"See hardware design? See software design? Well, they're kinda the same thing"
And then all of a sudden, freed from the restrictions of schematic capture, chip designers were able to look to their software cousins and pinch years of well-established methods and norms and apply them to their problems.

The other major nugget was "found" a decade later, in the form of high level hardware verification languages, such as e and Vera. It was more of a corollary to the bigger discovery of synthesis, rather than a significant theorem in its own right. But it was still highly significant. While RTL, expressed in Verilog or VHDL, was a huge advance on schematic capture, it was still little more than assembly code. HVLs raised the abstraction significantly, and were to HDLs, what C, C++ and beyond are to X86 assembler.

But anyway, as I say, no such nuggets this year. There were, however, a fair number of smaller prizes. None will create a revolution, but if each can knock 2% or so off product cycle times, that can soon add up to significant value.

The most obvious has to be the perennial (and my word is it perennial!) Formal Verification. Jasper, One-Spin, Averant, to name but three. FV's biggest problem is probably its associated over-hyped expectations. But keep it in perspective and it's absolutely a Good Thing. Only yesterday, there was a rapid-fire internal mailing list discussion between some of the Verilab teams in the UK, Germany and US about the applicability of FV to a particularly complex arbiter structure. If the time to verify that structure can be reduced from four weeks to one week, with the added benefit of the confidence provided by FV, what's not to like. Just don't get carried away. FV has been touted as The Answer for at least the past ten years, and it will be so touted for years to come. It's not, and it won't be. But not being The Answer doesn't mean it can't be an answer.

Another example is Certess's Certitude. This is trying to deal with the worrying problem that testbenches are becoming at least as complex and, as a result, bug-prone, as the designs they are meant to verify. Given that growth in complexity, how can we be sure that the testbench is able to spot a bug in the design if one exists. In some ways, Certitude is more like a nugget of platinum than one of gold, in the sense that it has been staring us in the face for ages but we haven't noticed its value. I spoke to one of Certess's founders, Mark Hampton, several years ago when they first conceived the idea. It was one of those "Dang, that's so obvious. Why didn't I think of that?" moments. Five years or more on, and clearly putting that "obvious" idea into practice has taken a lot of work. But it looks promising. Again, it's not like inventing the wheel, or discovering penicillin, or realizing that if you stick your finger in a glass of newly-poured diet coke the froth will dissipate more quickly. But worth keeping an eye on nonetheless.

Finally, an at-first-sight uninteresting nugget from Starnet. Their X-Win32 X server is barely noticeable amid the shouts of "OVM!", "VMM!", "My simulator can beat your simulator!" heard all around the DAC exhibition floor. But think about it. VNC-ish-ness, persistence an' all, but faster (if their claims are true). With the increase in use of distributed teams, that could be similar to the sort of performance improvement you get when moving from a 12" monitor to two 22" monitors. A lot. And, at a couple of hundred bucks or less to get those wave displays refreshing faster - not so uninteresting after all.

Tuesday, June 3, 2008

How lawyers govern their own corporate blogs

Sitting for two hours in the dentist's chair this morning for part 3 of 4 of a root canal treatment, I took the opportunity of various pauses (wait five minutes for the local anaesthetic to take effect; wait for six minutes for the post to set; wait for six minutes for the crown impression mould to set; and so on) to catch up on some blog and email reading using my new iPhone. (Aside: I've used iPaqs, Blackberries, and Treos. The iPhone simply buries them all.)

Some interesting blogging stuff over at Real Lawyers Have Blogs. In particular, this sample blog policy could be useful. And, the "Related Posts" at the bottom of that article are good starting points for further browsing.

Ow. Have to go. Local is now wearing off. Where did I put those painkillers...