Very nice to see this kind of conversation popping up from Dave Rich at Mentor. He’s got a post on their verification horizons blog called A Decade of SystemVerilog: Unifying Design and Verification? to announce an upcoming conference talk. Glossing over just the title, you’d hardly expect this post to stand out from any other post on a big three website… probably just more backslapping and high-fives about how SystemVerilog has become the granite foundation for successful ASIC teams, how it’s been the catalyst for bringing design and verification engineers together in peace and harmony, how it’s feeding starving children, slowing global warming, etc, etc, etc.

But then there’s the matter of that pesky little question mark…

Reading it, turns out Dave’s raising the possibility that most of the potential that was packaged with SystemVerilog, after 10 long years, is still just potential. Wow. He – and presumably others at Mentor – are interested in getting to the bottom of why that is so they’re engaging with academia and user communities to figure it out. Great idea and good for the folks at Mentor for openly considering it.

Lots of people complain about SystemVerilog. I suspect any discussion opened up by Dave and Mentor around SystemVerilog will lead to more complaining so I’m not going to pile on. Instead, I’ll play devil’s advocate and suggest SystemVerilog isn’t really the problem. What SystemVerilog was designed to overcome weren’t language issues at all so to blame SystemVerilog isn’t right. Here’s why…

---

SystemVerilog Doesn’t Address Code Ownership

We have this idea of individual code ownership in hardware development. Code is written in relative secrecy. I write my code therefore I own it. You write your code, which you own. When we’re done writing our code, we’ll put them together and see what happens. If there’s bugs in mine, you file a defect report which I get to a few days later. After a few cryptic back-and-forth emails, the defect is resolved neither productively nor effectively.

First, SystemVerilog can’t help people understand that their customer is the one that owns the code. Second, SystemVerilog can’t force people to understand that shared understanding and maintenance is more productive than individual ownership. It’s not SystemVerilog’s fault that defects pile up in a high-priced defect tracking tool while capable people sit around and wait for its ‘owner’ to fix it.

SystemVerilog Cannot Enforce Responsibility

It’s not SystemVerilog’s fault that engineers are taught from birth that they shouldn’t even consider testing their own code. Effectively, we’re saying don’t be responsible… it’s not your job to decide whether or not what you’re doing is decent quality… that’s someone else’s responsibility.

SystemVerilog Doesn’t Let You Test in Quality

Go ask a carpenter why they don’t build a house without a tape-measure or a level (i.e test fixture), then go back and adjust the walls when they’re done. Sounds pretty stupid, right? Even if you had some sort of flying laser level drone that could read in an outdated blueprint then magically float around the house through the night, choosing and measuring walls at random to verify they’re properly built and plumb, then listing the crooked/misshapen walls on a company intranet so they could be fixed the next morning. Completely awesome; also completely useless.

Measure twice, cut once; nail walls up straight as they go; that’s what carpenters do. Straightening everything out after the fact doesn’t make sense to anyone… except us. It’s not SystemVerilog’s fault that our code is crooked, it’s ours. We think the efficient thing to do is write bad code, then rely on debug tools to fix it. Completely flawed. Time to kill the drone programs out there and start using techniques that produce high quality code… something you can do with SystemVerilog.

Oil and Water Won’t Mix, Even if You Stir Them Together Really Fast

We’ve brought the design and verification constructs together! Wonderful! That’s a half-point for SystemVerilog. The reason we don’t get the other half-point is because what we’ve effectively done is merged Ruby with Assembly, expecting it to be the catalyst behind bringing web and embedded developers together. That would work very poorly, just as it’s worked in the case of SystemVerilog. The only thing that might help is to educate designers in the verification space and verification engineers in the design space. Again, not SystemVerilog’s fault that’s not happening. The only thing stopping us from doing that is…

Verification Engineers Don’t Design and Designers Don’t Verify

If there is one reason why the merging of design and verification constructs has failed to live up to it’s potential, it’s this: the people that do design and verification are more isolated than ever. Design and verification engineers continue to be pushed apart by the idea that near isolation is the most productive way to collaborate. What are effectively two languages crammed into one doesn’t help but that’s not the only obstacle between design and verification.

Not only is there very little incentive to build a collaborative environment, there’s actual disincentive within organizations that still feel isolation is the only true way to ensure valid double checks and oversight (i.e. verification engineers have their hands slapped for meddling in RTL as do designers for meddling in testbench code). Until we believe that responsible people will act responsibly, that they won’t somehow be corrupted by collaboration with their fellow designer/verifier, no language will help us. Not SystemVerilog; not anything.

---

I’ll finish by saying I do respect the candor Dave Rich and Mentor have in A Decade of SystemVerilog: Unifying Design and Verification? I’m hoping the presentation and follow-up is just as candid.

If I could lend a small suggestion to Dave, his buddies at Mentor and anyone else listening it’d be to consider beginning their quest beyond the language. It’s not SystemVerilog’s fault it hasn’t lived up to expectations. No language could. There are other deeper issues to overcome first. Once we do that, then we can get to a proper critique of SystemVerilog.

-neil