March 2-5, 2020

DoubleTree Hotel, San Jose, CA

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

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


Download the MP3


Part 1
Male #1: So one of the things that's happening is the hardware and software world's hardware designers using software and software designers in general, it's coming closer and closer together.  At some point, you know, you're going to be doing more and more software emulation or simulation as you're also doing this verification.  Is there something the software world can help us with as we're moving forward, you know, us hardware guys?
Male #2: If they had the earlier specs and detailed requirements, that would help.  But the nature of software is they know they can change, they can adapt (inaudible)
Male #1: Well, what – I guess what I meant is process-wise.
So in the software world, you have pairwise development – and you do in the hardware world, too – but what I mean is, you know, you build it – design a little bit and you're going to test it right away, so there's more of this partnership perhaps between the designer and the verifier.  And this then would speak to the global issues, too, of what do you do when you have design teams spread out all over.
Male #3: Well, these concepts are being explored in extreme programming.  The concept as well as agile development techniques are being explored.  They have shown much more success in the area of verification, which is a big software project, than they have in actual design itself.  But, again, it's kind of a new frontier.
Mike Stellfox: Yes.  I would say before looking at what we could adopt from software, I think the bigger challenge I see is that there's such a divide between the software teams and the hardware teams and the knowledge of the use cases of the systems.  It's a lot of times fundamentally a cultural issue in the companies and, you know, we've been geared up separately to build up hardware separately from software teams.  And the biggest issue there is really getting the teams together and actually designing hardware from the beginning with software in mind and doing early and often software integration; so not waiting until the end after you designed your hardware to actually start integrating and verifying it.  So that concept of putting things together quickly I think could be applied much better in the hardware space to kind of verify the hardware from the perspective of the software APIs.  And then as you refine your use cases over time, to build that up more gradually versus sort of throwing it all together at the end and then trying to put together a monolithic-type environment to put those things together.
Male #3: Yes, if anything, I think the software world could learn a lot from the hardware world.  Part of the problem today is lack of good concurrent engineering practices.  And like Mike's talking about, the software is often delivered late, they have to go back and redo the hardware because things weren't worked out correctly in the beginning.  So I wouldn't say that the software world's in much better shape than the hardware world.
Male #2: And the sad thing is the technology is here.  I mean, the virtual prototyping world, I mean, all major vendors, we have solution net space.  They can be linked to hardware emulation for the parts that you do need to try in hardware eventually.  The technology is there.  It's the discipline to use it and plan for it and invest early enough in developing those models.
Male #3: Yes, my other comment would be I think going along with what's been said is I think what would be more important is to bring the hardware/software guys together to look at, okay, here's our risks in the system, and now how can we mitigate them with a combination of hardware and software.
Male #1: Is that…
Male #3: Is it happening?  Not really.
Male #1: So almost an organizational change, a structural change within the organization perhaps.  That seems a little harder to get going.
Bill Grundmann: Possibly.  So the dilemma we're reaching here is that there's no chip that's – no product's really done by one person anymore.  It used to be in the old ages, one person could do the whole design, do the verification, everything.  Now you have large teams, hundreds maybe, on a product.  And so you have some kind of hierarchy and so you're got a handoff of information between these teams.  And I think the handoff is what's flawed in a lot of cases.  Somebody developing an IP that's going to be using an SoC, okay, they're going to deliver this 150-page, 300-page document to the software guys and say, "Go for it."  And they – the software guys start thumbing through it and they say, "Well, I've got 300 registers I've got to program.  What do I do with these registers?"  And, of course, everybody knows that document's not proven to be correct because it has nothing to do with our verification processes.  So the realization here is that it's not going to get easier as the premise was.  It's going to be hierarchical.  We have to figure out how to solve these other things that aren't part of the chip itself.  There's collaterals that need to be connected.
Jim Caravella: Yes, we talk about hardware and software, but I would also throw out the analog and digital world is also still a problem, even if we just talk hardware.  It's at least as bad as the hardware/software world is the digital/analog divide.
Male #1: Would you see that as – I mean, so one – we could say, well, you know, you have the analog on a separate (sounds like: dye) and you're going to stack them, so it's still a problem, but it's – you know, it's a…
Jim Caravella: I think it to be a problem there just as much as if it's integrated.
Bill Grundmann: It's part of the system.  If you think you're doing a chip, that's one thing.  But if you're doing a board, that's another level.  There's a box, there's an environment.  There's – what are you delivering to?
Jim Caravella: Yes.  And I think if we go back to our question here, you know, the verification gap, are we driving it, if I look at the mixed signal problem today, there is more than enough tools available today.  What we're really lacking is experience and expertise to execute much more so than a specific new tool.
Male #3: What I see is not necessarily a tool problem in the mixed signal.  It's lack of process problem.  We depend a lot on (sounds like: super stars) and they're great.  They're amazing what they can accomplish.  But it's not always repeatable.  And that's something we have been able to achieve somewhat in the digital domain.
Male #2: Yes, it's a little tougher in the analog.
Male #1: Everyone's in agreement?  No questions?  That's great.  Glad this wasn't just (inaudible)…
Male #3: We're trying to generate questions here.