The tyranny of the, err, hem, actually, I'm not really sure

There was an interesting post on the verification guild this morning called "Testbench's Tyranny".  It's interesting to me because I have no idea what it's about.  I'm baffled, although I think I have it narrowed down to 2 possibilities:

1. It's going to be a discussion on why constrained random testbenches are evil, why OOP is evil, and why RTL based directed tests are all we need
2. It's a precursor to an announcement of yet another wonder product that's going to make verification push button, and remove the need for verification engineers and their brains

Based on the poster's name "xxx" and the fact this is his only post, I suspect the latter (unless we're encountering an interesting crossover from an entirely different industry!).  If it turns out to be possibility 1, then I'm looking forward to the follow up posts about why we should never have abandoned schematics in the first place, and a counter reply along the lines of "schematics!  It's been a disaster since we stopped using Rubylith".

Either way, I think it's worth watching.

But what prompted me to launch myself out of my writer's block and type was the following line:

"What on earth is the good of [sic] ``OOP, Layered'' TB to a DUT, which is written in plain Verilog modules/VHDL processes ready for synthesis"

OOP bad. RTL good.

ARGHHH. What is it with the IC engineers that makes most of them want to remain firmly rooted in the past? Seriously - it's like working with the Amish. Zips bad. Buttons good.

I'm trying to think what life would be like if IC engineers were in charge. I'm guessing we'd have fire, but I'm not sure if we'd have left the safety of caves, and I suspect that something as outlandish as the wheel would have been avoided as "too dangerous".

Make fire with stick. Stone too modern.

I used to think that danger was the problem. Making an ASIC is difficult and expensive, so perhaps we were all just being ultra risk adverse. I don't buy that anymore, because if we really were risk adverse, I wouldn't have to be constantly trying to justify why planning is important, and why we actually need to verify designs. People who will plan a trip to a restaurant for dinner will quite happily start a multi-million gate project with the same amount of planning, and consider verification as gold plating.

So if it's not risk that people are scared of, why (as an industry) are we so reluctant to try new things? Look at SystemVerilog. Years in the making and it's still not quite as good as e with VHDL [1][2]. Rather than embrace AOP, predicate classes, a meta language, duck typing, and a whole bunch of other "modern" software constructs, it actually moved backwards in time by replacing {} with begin-end to make it look more like Verilog (that other cutting edge language we have). Oh - and they felt the need to distinguish between functions and tasks. It's so 1978.

I've not seen any hardware engineers adopt any of the new design features (or even complain that they can't because DC doesn't support them), and many designers verifying with it just seem to be writing Verilog RTL (one testcase I saw recently started with "Warning - SystemVerilog construct used").

I'm not sure what the reason is, but I'm wondering about these three:

1. We spent so long studying at university to get qualified in the first place that most of us never want to learn anything new ever again
2. We just want to be part of the herd, so won't try anything new until more than 50% of our peers are doing it as well
3. We genuinely enjoy doing things the hard way. That's the only justification I can see for people still writing counters, registers and FSMs in an HDL

I'm baffled.  Anyone have their own thoughts?

Cheers

David

ps. - if you'd like to drag the IC world into at least 1995, like the designer I met recently who was using Ruby to generate his code, or the team we know who are using Python to write their constrained random testbench, then click here.

[1] I had a fun chat with a Synopsys marketing guy in Munich once when he was trying to work out why he was having so much trouble convincing the VHDL/e users that they needed to switch

[2] Ignoring VHDL's over addiction to type-casting of course