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

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

 

Download the MP3

Transcript

Part 7
Male #9: This is (sounds like:  Eugene) from (inaudible).  I want to go back to this question.  Did we create the verification gap?  If we means the EDA companies, my answer is yes.
 
{Laughter}
 
(Inaudible) from Mentor gave a very interesting presentation this morning talking about standard (sounds like:  committee).  So what we need in verification community is a horse but, you know, we got a camel instead.  But we kind of get stuck here because all the, you know, accessories, you know, whip and saddle, everything, kind of (inaudible) the camel.  So we don't have many choices anymore.  So I want Mike and Janick to comment on that one.
 
Mike Stellfox: About the camel or the horse?
 
{Laughter}
 
Male #8: What we need is a horse and how come we get a camel, and what we can do to prevent this from happening again.  Basically, if you look at what (inaudible) can do today, this can be done ten years ago with either (inaudible) or (inaudible) but we're still here with UVM.  So there's not much, you know, progress since ten years ago.
 
Mike Stellfox: Right.  I mean, I think you're referring to – and I tend to agree – there was this sort of marketing view that SystemVerilog was going to solve all the verification problems of the world today.  And, you know, it's targeted for a specific thing and it does a good job at that.  Probably as an industry we definitely spent way too much time focusing on the standards aspect.  But frankly, that was driven mostly by customers actually.  I know – you know, Janick and I spent a lot of time in UVM and (sounds like:  Accelera) driving the standard along with folks from Mentor.  But that was primarily driven by customers.  So – and there was a huge amount of work there.
 
I think the key going forward is there's a balance between innovation and standardization.  Right?  And as an industry, one of the top things we have to keep in mind – and especially the customers, right, because customers drive for standardization for good reason, so they can have interoperability tools and so on.  But if you just focus on standardization, you don't get innovation.  Right?  You have to innovate stuff, get it out there, get it working, you know, with lots of customers, lots of projects, and then you should focus on standardization.  Because when you go into standardization mode, things move about a hundred "X" slower, right, because you've got to get everybody to agree.  And believe it or not, Janick and I don't always agree on everything.
 
{Laughter}
 
But, you know, it's not that easy, right, to get competitors – in fact, I don't know too many industries where you'll get the top three competitors to actually agree on something.  It's not that common.  Okay?  You know, I don't know many – how many hours we spend in that, but there is a lot of time spent in that versus on focusing on the SoC verification problem the other guy brought up earlier.  So, personally, I would like to see much more focus on innovation for the next four or five years to help solve that problem, especially in the SoC space versus a big focus on yet another marketing hyped standard-type play, to be (inaudible)
 
{Crosstalk}
 
Male #3: Yes.  But at the same time, I think – when I look at that and I see "verification gap," I think UVM is just a minute – tiny portion of that gap.  It's addressing something specific in there.  That's a huge gap, particularly when you've got software nowadays and all this other.  So, again, I think this discussion's kind of funny how it always turns back to UVM, you know.
 
Male #2: UVM is the internet of the wireless world.  Right?  It's a necessary, important component, but it's not an end in and of itself.  That's the plumbing that allows us to get IP from somebody, get some tools that talk together in the same level of abstraction, but it's just a mean; it's not the end.
 
Bill Grundmann: So I have a different take on it, obviously.  We're each in the (inaudible) like software world, it's so easy just to recompile it when it doesn't work, recompile it when it doesn't work, recompile it.  So that's – you know, you're stuck in a verification loop as part of the design process.  And I think we have hit that now because it's so easy to generate crap with the various processes.  We have wizards and stuff that can build you a chip overnight, but it may not be what you want.  And that's where verification comes in.  And so some of it comes back to a cultural change.  Somehow in the past we switched away from people thinking about what they were designing and going to an energy verification loop, which does waste effort.  Now, how to get out of that problem, I don’t know.  But we are in this loop like software developers.  They try something, they just – you know, recompiling it so quick.  Why not rebuild it every time you find a bug instead of finding all the bugs?
 
Male #9: My last comment to the user community is, we need to be smarter next time, so we shouldn't be too obsessed with the standard.  We should let the best product win.  You know, if you look at the analogy (inaudible) like you know people always use (inaudible) or (sounds like:  VHS), they didn't sit together and create another standard.  They basically let one product win.  Right?  So…
 
Male #3: Yes.  Let me just close with a comment, too, on this.  So I think the question was also around the EDA.  I think specifically it would be really good if the EDA guys would focus more with their customers on getting chips out rather than listening per se to a lot of times their marketing teams.
 
Male #9: Yes.
 
Male #3: There's a lot of things we do to get chips out that are real fundamental, and we're missing it by focusing maybe – the EDA guys are focusing maybe a little on the wrong thing, like creating another three-letter acronym.
 
{Laughter}