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

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

 

Download the MP3

Transcript

Part 4
(John Swan): Hi, I'm (John Swan).  So I'm going to refer to something I think Mike said earlier about what I'll name "shift left" and moving the verification earlier so we're less dependent on verification with UVM and RTL.  So, my question is, how can we move – you know, grab some specific ideas on how we can move more of a shift left, and how do you see adoption of virtual platforming and things such as high level synthesis which could help with earlier software verification as well as not manually coding in errors with RTL, for example?  Do you see industry as needing to pick that up?  Is that a cultural thing?  You know, engineers happen to know RTL and object or (sounds like:  inter programming), etcetera?  So what does it take to shift left?  And I haven't heard much yes or no as to the answer on the question.  So if you could be more specific on yes or no, we did create it, but looking in particular virtual platforming and like high level synthesis.
 
Mike Stellfox: I think one of the keys is putting in development flows in place that are software driven from conception.  Right?  It doesn't mean -  I don't – I think UVM is a key approach, right, and it applies very well for bottom-up – it – kind of exhaustive verification of a block, whether that's an RTL block, whether it's a system (sounds like:  CTLM) block.  Right?
 
But what I see happening along – to answer your question, I see a lot of some leading-edge customers actually trying to set up flows so that they're actually building into their design of their hardware early validation with the software.  Right?  And virtual platforms certainly enable that.  That's one stepping stone so you can get the software developed concurrently against the model.  High level synthesis is an optimization.  If you're capturing that model, you may as well try to create the implementation from it.  And then also being able to start your verification on a model that's more abstract and earlier is also – helps reduce the overall effort of creating the verification.  So that's definitely an area under the envelope of trying to put in place flows – design flows that are recognizing the need to design concurrently with software.  Right?  You can actually find a lot of potential downstream integration issues much earlier, and you can be designing – optimizing your hardware for exactly the software APIs that, you know – or frankly how the device can be exercised by the applications above it.
 
So those two areas you pointed out are being adopted.  It's definitely not mainstream yet, but it's – I would say it's picking up at a very fast rate.
 
Male #3: Yes.  I mean, high level synthesis in the particular domains that it will apply, it works quite well.  The point is general.  So…
 
Male #2: The problem is that RTL design works well.  From a designer's perspective, it works.  It's not painful enough.  Until it becomes a verification issue, that's when you'll see the impetus for adopting those methods.  So it – only when verification is going to become so painful it's going to force a change in the design side.  Right now, the design guys are – still have a good life.
 
(John Swan): Could it be a painful issue that we're not realizing where the pain is coming from?
 
Male #2: It could be – to this day, we're – I think we're at the cusp of (inaudible)
 
{Crosstalk}
 
Male #3: I don't know.  I was talking about back in the late '80s when I was doing design and we had a verification gap.  We had a severe gap.  It couldn't learn gate-level simulations.  They were just too slow, you know.  And all of a sudden you saw all these solutions start to emerge, like a hardware acceleration to speed up the gate-level simulation, you know.  The point being there's always been some type of gap, and there always will be some type of a gap.  If – it just is the nature of the beast, you know.  Designs grow at a (sounds like:  Moore's Law's) rate and the verification grows at a double exponential rate, you know.  There always will be a gap.  But I'm an optimist, and we've always solved it.  They already solved it by moving to RTL.  You know, I'm convinced we'll solve it here.
 
Bill Grundmann: Yes, I think gaps are opportunities.
 
Jim Caravella: My perspective on that is I agree.  It really comes down to return on investment.  Right?  Once we see the gap is large enough that there is a significant return, we'll put something in place or the teams will adopt what's available.  And I think that's what it comes down to.
 
Male #3: Yes, in fact, another way, as I've always said, when is the problem more painful than the solution or the solution more painful than the problem.
 
Male: Right.  What I've seen is a lot of the larger companies are adopting some of the left shift flow, but a lot of the smaller design centers, they're stuck with their RTL designers and their software designers and they don't have anyone that can do high level synthesis or TLM modeling, for example.
 
Male #2: There's some things to keep in mind is you must not minimize the shock to the system that making such a change would create.  I mean, when I first started out of an engineering, I was in the (sounds like:  logic synthesis tool) at Nortel.  And trying to get gate level guys to write RTL, man, it was like – we had to sacrifice a generation of designers.  So it's…
 
{Laughter}
 
…we did.  So – it was painful.  And it's going to – the next one's going to be even more painful.