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: Will the drivers in design change as we move to more levels of abstraction?
Schirrmeister: The driver still will be re-use. If I’m the manager of a chip project and I want to focus my efforts on the different levels of abstraction, system-level design always head the issue that the ROI was badly or not at all quantifiable. Where software is part of the game, it is very clearly quantifiable. It may be my hardware abstraction layer, my drivers, my middleware. If I start very early on the software development, I have a model there. Now I re-use that verification when I run my RTL. I bring my transaction model. I even re-use it when I go into hardware-assisted verification. And in post-silicon verification, I still can use that software. So verification re-use across the abstraction levels is an important driver.
Sandler: You have to have a way to go from validation on one level to verification.

SLD: What effect do restrictive design rules have on verification?
Sheridan: At the system level, it’s hard to make that connection. But what it boils down to is avoiding getting too excited about achieving performance and overdesigning and not taking into account effects on area and power. When you do have the right design in the end, you have the right performance without the overdesign that would cause power problems. This is an area where system-level or virtualization tools can help, but it does require the user to understand the impact of clock rates, for example, against the target fabrication.
Schirrmeister: It’s a very long feedback loop, but what it boils down to is models and the ability to hold the right data in the models. What people do today with virtualization is to simulate at the system level, use virtual platforms to identify multiple voltage regions and develop the drivers that will control a power management IC to induce a core voltage. So now it comes down to which of those back-end model parameters you can capture and use upwards and automate. You need to be able to characterize a model at the gate level and below to know in this state and this voltage scenario it will consume the following energy. Your system-level model can help you make the right decisions. It’s definitely a challenge from the model perspective to keep all those levels in sync and to characterize upwards.
Sheridan: But it’s going up in abstraction that does enable the user to tell how the system is performing when you make these kinds of tradeoffs. And given that, it’s software in the context of the hardware.
Cramb: You also have the ability to turn all of that stuff off.
Schirrmeister: Yes, the software guy wants one model and the verification guy wants another model, and the architect wants a model in between. That’s one of the issues around modeling. We haven’t found the silver bullet there to enable one model that does it all. That’s why this mix of things in an FPGA prototype with full RTL carried out, and it does what it’s supposed to do, together with virtual models for things you don’t have in RTL becomes more and more important.
Sheridan: You do have to get specific about the design area to make all the different levels of abstraction work.
Schirrmeister: The big issue is to make this universal and be able to bridge between these abstractions.
Sheridan: To deliver something complete you have to decide what you’re going to support, even though the building blocks are general-purpose.

SLD: Chips are no longer just digital. What does that do to the verification process?
Schirrmeister: In all practicality, there are a lot of people putting in mixed signal as a daughtercard to a hardware prototype. You have a PHY interface, which talks to the prototype, which talks back to the model. You bring these in these interfaces. From a simulation perspective, that’s a tough cookie. You have sub-cycle accuracy if you want to go into the analog world, and then you have something that tries to run for 500 cycles before it comes back. That doesn’t typically work all that well unless you put behavioral models in for the analog.
Cramb: People are very prepared to make the tradeoff where they don’t do much with the analog parts and just use the interface. If you include the analog stuff and you have a high-speed serial interface, for example, that becomes the fastest clock in the system. So you’re slowing down the whole emulation or simulation just for that one piece.
Schirrmeister: You may keep the analog portion out, just as the analog may leave out the digital part. But we have users trying to do mechatronic stuff with an analog simulator to connect this to the software. There are use cases where you want to develop your software. But is that the market that will bring us a couple hundred million new users? No.
Sandler: We haven’t really automated system-level verification or validation yet. We’re doing a lot more, but there are so many ways to model. People stitch these together, and there’s another art to manage a project from intent down to chip verification. There may be as many different methods for doing that as projects. But to make money, you can’t supply a commercial solution for every method.
Sheridan: It is possible to invest in all the pieces of one solution and make it profitable. Sandler: But we don’t know today which will be the one that takes off. In the RTL synthesis days, there were multiple vendors and it eventually settled out. The same will happen with system-level design. There will be translation tools and transactions that take off. But there’s a chicken and egg in automation between methodology and representation and tool algorithms. One drives the other in upredictable way.
Schirrmeister: We all have cell phones that seem to work without at least one reboot per day. But they also are heavily constrained. You cannot do certain things. That’s why we can’t make cell phone calls in

Tags: CoWare, EVE, Springsoft, Synopsys, Verification

This entry was posted on Friday, July 31st, 2009 at 12:01 am and is filed under Round Tables, Technology Features. 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.