Industry Leaders Panel: Did We Create the Verification Gap? - Part 9

Industry Leaders Panel: Did We Create the Verification Gap? - Part 9


Download the MP3


Part 9
Male #11: (Stefan) (inaudible) from (inaudible) Consulting.  I'm a verification engineer for 15 years, and I could see that there is a lot of rigidity in our industry, in adopting new (inaudible) and new flows and new methodologies.  It's kind of inertia.  We have so beautiful tools.  Right?  We have everything we wish and we need.  We have methodologies.  But still something in our mindset keeps us from adopting the faster pace (inaudible) industry for example.  What do you think are the elements in our mindset that somehow slows down this process?  Is it that we don't play enough or we don't experiment enough?  Is it paranoia?
Bill Grundmann: I think it's a willingness to change, as you mentioned.  Everybody has a different attitude in life.  And if you've been successful in previous projects, why would you change?  Why would you possibly risk being unsuccessful?  So you want to have a continuum, you want to do things that you're familiar with.  So if somebody suggests that there's a new way of doing it, they have to stand on their head and they really have to convince you that it's better than what they've been doing before.
Male #3: Yes, and I think from a management perspective, I want to minimize the number of variables I'm changing as I go from one project to the next.  And you can't just disrupt everything.  I think – I don't know of any manager who doesn't make changes.  There are changing some variables, but you can't just throw everything out.
Bill Grundmann: It's controlled risk.
Male #3: Is that – absolutely controlling the risk.
Jim Caravella: Yes, and I think it's incremental changes.  Right?  I think my other comment, too, to the question would be the comment was the software guys are so great, they are evolving so much faster than the hardware guys.  I think that comes back to just learning cycles.  Right?  Just fundamentally in hardware we've got, you know – it takes nine months to make a baby to get through a (sounds like:  FAB) and everything, okay, whatever that number is.  That's much longer than it is for software.  So I think inherently change in the hardware guys, that learning cycle is a lot longer.
Second thing is, of course, the aversion to risk.  It's not like, oh, we'll just go change the code, recompile, and away we go.
Male #2: It's also the inertia that we have all of the assets, the existing code that we have.  If it's an incremental change, that's relatively easy to adopt, if it demonstrates value.  But if it's something that requires a rewrite or completely recapture something you've already have, it's a huge cost.  I mean, let's look at Verilog.  I mean, SystemVerilog did not do that much on the design side.  We all know what's wrong with Verilog.  It's a crappy language, 30 years old.  I mean (sounds like:  raise) conditions, blocking versus non-blocking assignments.  Where do you think this hair went to?
There's lots of shit wrong with Verilog, but – and they ain't going to change that because of how much investment there is in there.  So…
Mike Stellfox: That's what I've seen.  And a lot of customers, you know, it's a really fast moving train.  You finish a project, the next project starts.  And you first have to overcome the risk averseness of change.  Right?  Sometimes you can actually kill yourself by not changing.  But then even where they do want to change, somehow you need to be able to – you know, you've got these flows – you know, it's not just about the tools really.  It's about the flows, you know, and how all those tools come together into a process and engineering flow.  And if you're making any kind of significant changes there, that's one of the biggest inhibitors I've seen for customers who know they need to change but they just don't have the time to change because the wheel is just cranking.  You know, I think (inaudible)
Jim Caravella: Yes.  In fact, I think one of the biggest challenges, totally orthogonal to this, is legacy and that it's a blessing and a curse.  You know, a legacy can prevent people from changes.  They can't afford it, you know, so…
Male #11: Yes, but this is like (inaudible) (sounds like:  chicken), I mean, I don't change because I'm afraid to change and at some point I would be forced to change.  And I assume that taking smaller risks constantly or experimenting from time to time would help me (inaudible) change at a faster pace.  And I couldn't see many companies that have this kind of active changing process.
Male #3: Actually, I have seen some companies have in place what they call a process for change.  They actually have formalized this so that it is part of their culture.  Those that don't do that, again, it's totally ad hoc.  So…
Male #11: Okay, thank you.
Male #1: Any final thoughts on this verification gap that exists or grows and shrinks depending on pain and fear and what not?
Male #3: I still maintain it's Janick and Mike's fault.
Male #1: Well, we know who caused it.
Male #2: I disagree with...
Male #1: Thank you very much.