System Level Design sat down to discuss issues in system-level verification with Frank Schirrmeister, director of product development in Synopsys’ solutions group; Donald Cramb, director of professional services at Eve; Patrick Sheridan, director of marketing at CoWare, and Scott Sandler, president of SpringSoft USA. What follows are excerpts of that conversation.

By Ed Sperling

SLD: Verification has been the biggest time hog in chip design, and it has become a system-level problem at advanced process nodes. How are we going to resolve this?
Sheridan: You’re right that it isn’t just a chip-level problem anymore. It’s a system verification problem. We have to do things differently. In the context of multicore, it’s potentially multiple subsystems, multiple processors, multiple software stacks, integrating them and debugging both the hardware and software side.
Cramb: I think it’s the word ‘verification’ that gets people confused. There’s this thing called chip verification. But from a system-level, it’s validation. You bring the software and hardware together and validate the whole environment. You’re not just verifying against a spec. You’re validating how this thing is going to work for the end user
Sandler: Is it validation if it’s a whole system and verification if it’s a chip?
Schirrmeister: No, validation is against intent. Is it really what the user wanted? There are three elements to verification. One is the traditional hardware verification. The second is system validation, which is the chip in the context of the overall system. The third is software. It’s the whole aspect of software development and verification in the context of hardware. Whenever we had too much complexity in the past, we went up in levels of abstraction. The same will happen in verification. We are using transaction-based verification, and eventually we will have to figure out how to verify these higher-level models.

SLD: Is validation the same as debugging?
Sandler: There’s a general tendency to say you’re debugging when you’re verifying or validating. Ultimately what happens is when you validate or verify, things happen that you don’t understand. In my view, that’s the point at which you shift to debugging. You let the thing run, it does something you don’t understand, and then a human has to get involved. Debugging can only happen when someone is looking at some output or data.
Schirrmeister: Validation and verification can both be done if you express the design intent for validation and if you have a specification that you can verify against. Both can be done offline. You have a regression suite and it says, ‘It works.’ Debug is the last resort when this regression suite says, ‘It doesn’t work.’ Now you need to go in and debug. The hardware-software interface becomes critical there.
Cramb: The level of abstraction for verification is getting higher, but the same is true for debug.
Sandler: No matter what level you do the validation or verification, you have to be able to do the debug at that same level. The same things that affect simulators and models affect the data capture mechanisms you need to hook the person into the process and show people what is going on.

SLD: So what’s new here?
Cramb: For us the term is smart debug. You bring together not just wave forms and monitors, but you raise it to the right level of abstraction.
Sandler: Debug is the same thing we were doing years ago with the logic analyzer and the oscilloscope years ago on the bench. Then we went to wave forms and source views. When you do that at the next level up with transactions and C-level source code and you have the debugger linked in and synchronized, it’s just a progression.
Schirrmeister: It’s not the word ‘debug’ that’s in question. It’s the scope of the work. There’s IP debug, which is block-level, there’s chip debug and there’s system debug. The way we phrase things at Synopsys is system prototyping. You want to mix the different abstraction levels. You want to have virtual, including the software, connected to prototypes, which run in hardware-assisted environments. Together with system prototyping, you have system debug. You need to be able to correlate what happens in the software on one side with what happens on the hardware side. One of the things users are looking for is the ability to set an assertion in hardware, or set a break point in software, which is kind of the same thing if it’s conditional, and be able to hold the whole system. The scope really has changed since the complexity has increased.
Sheridan: When you’re validating, you’re still in the process of designing and making tradeoffs of features vs. performance vs. cost. You may not be at the point where you’re verifying whether it’s being implemented correctly. Those problems become more important to solve at the system level. Moving up in abstraction is the only way to make this work productive, whether you’re the designer of the system who is looking at architectural issues, or the people implementing hardware or software. They all have to come together.

SLD: In the past, verification occurred several steps down the line after the initial design. With increased complexity does it now need to move forward in the design flow?
Cramb: That’s validation.
Schirrmeister: It’s a thin line. Validation is against intent. On the architecture side, it’s validation.
Sandler: Since the beginning of architectural design, there’s been some intent specified. It has to run this fast, it has to be able to handle these kinds of problems, this is the input and this is the output. There’s always been a level of validation that had to be done. I don’t think there’s much change here. There’s more tools for this now and more commercialization.
Schirrmeister: Yes, it always was a requirement, but commercially it was not supported by tools. People always did it with C and C++ models. We tried to commercialize it, but it was too early. But over the past two years, the pressure has been growing to solve this issue. If you get your design out in time but you haven’t met all the architectural requirements for performance, your design will be very short-lived and your career as a project manager may be very short-lived, also. Pressure has increased over the last two or three years. We always wait when we make these transitions for projects to run into the wall over and over again. But people now realize they will have to switch to system-level design.
Sheridan: If you have a system design that’s multicore with multiple subsystems and you’re changing the camera piece from 3 megapixel to 8 megapixel, that’s more that just verification tests. It’s adjusting the challenges that impact performance of the entire product. So you have a system-level issue that’s on top of the verification of how you build the camera. The complexity is greater, and the impact of any changes is greater.

Tags: CoWare, debug, EVE, Springsoft, Synopsys, System-Level Design, validation, Verification

This entry was posted on Friday, July 17th, 2009 at 7:14 am and is filed under Round Tables. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.