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: There are now six or seven levels of abstraction in a leading-edge design. How many levels will we have in the future?
Schirrmeister: There is no definitive answer. When you went from gate level to RTL, which is the last major shift we did, at least you stayed within the constraint of hardware. You were either designing a block or the whole chip. IP re-use came to the rescue with making sure the automatic synthesis can stay focused on the block level, and then you do the rest with synthesis or re-use of the components. Now that we’re trying to go up another level, it’s completely impractical for a user to keep eight different models in sync. You need models for software that are fast but which don’t need all the architectural requirements. For the verification team, you may not need all the functionality but you need all the performance and architectural aspects. Bringing software into the mix has made things much more complex.
Sandler: There have always been a lot of different levels of abstraction, and if you look at what one person calls TLM (transaction-level modeling) it’s probably different than what another person calls TLM. Modeling is an art. There are certainly some standards, but there are also differences. As we automate more, these levels will get standardized. The notion of RTL used to be pretty loose 20 years ago. Synopsys absolutely codified what RTL meant. It was a very specific subset of the Verilog and VHDL languages with very specific semantics about how that subset was translated into hardware. That became the definition of RTL. But until we have automation and translation tools that work above the level of abstraction above the RTL, that will continue to float and be more artistic than scientific.
Cramb: For us, this is the key—how you move through the levels of abstraction for the entire methodology, whether it’s architectural, RTL, integral or functional. It’s how you mix and match these levels of abstraction, and how you move through them to get to the end point, which is a piece of silicon with software running on that silicon.

SLD: Can it be automated?
Schirrmeister: The automation may only work for subsets of this technology. We have reached a level of complexity where it’s probably not practical for high-level synthesis to cover a whole chip, which may be 50 blocks. Block development, which is IP synthesis, is either re-using IP or starting with a higher-level model to build your hardware accelerator. Then you have the integration between the blocks, where you have companies like Sonics and Arteris trying to automate that level. It never will be a high-level model of the complete thing where you push a button and out comes the whole thing.
Sandler: In 10 years or 20 years, we may be having a different discussion. But we can’t see that at the moment.

SLD: How are the chip makers dealing with this?
Schirrmeister: From what we hear from customers, there are a number of different requirements for bringing together hardware and software. They want to know when it is available. Speed is important. So is accuracy. Even within TLM there are loosely timed views, approximately timed views and then cycle-accurate models. Modeling needs ROI. If you have hardware and software involved, there is overhead. Then you need to debug it, control it and then ideally you want this model to point to the system environment. No model will fit all those requirements. This is where transaction-based verification comes in.
Sandler: The real renaissance is that you’re starting to see real system-level commercial design automation. That’s the leading edge. To be able to get IP that implements transaction-level models that interface with the ones you write yourself and to have some standards for the transaction-level modeling rather than writing it yourself is a big step. We’re just on the cusp of seeing these things get standardized and flushed out with version 2.0 and 3.0—that’s a big change.
Schirrmeister: We have some standards. SystemC helps with the assembly of systems. It also has a synthesizable subset. Obviously, the market determines what this synthesizable subset looks like and the acceptance of it. Standardization helps. But we’re at a stage where traditional hardware verification is undergoing very significant changes. When you go up to the next level you have the software in the system. Our customers tell us that more and more software running on the embedded processor in their designs becomes part of the verification regression suite. That’s tough because the guy who used to be the System Verilog expert for verification now needs to be able to bring up a Lauterbach debugger to be able to have the embedded software in the system. That is a fundamental change.

SLD: Are there enough people trained to do this?
Cramb: That’s a key problem—finding someone in a company who can move from wave forms to bringing up a Lauterbach debugger for software. People are beginning to verify software. Verification guys are in a strong comfort zone. There aren’t many people who can write complex test benches in Vera or e. It’s a very valuable skill, and it’s hard for them to move into a more general skill.
Sandler: There’s been a huge distraction in schools. They’ve been using the commercial tools. I’m not sure there are a lot of kids learning proper system-level verification techniques. That’s fairly esoteric stuff. So when you look at that shortage of people who know how to do these things, they have to be getting on-the-job training.
Sheridan: The people are there, but they’re software developers. They have to cultivate some interest to cross over. In our experience, the people who are quickest to pick up the system-level verification come from a software background. They can help their hardware colleagues, but teaming up together is a good combination.
Schirrmeister: When I first started using logic synthesis in the 1990s, there was a guy next to me who had never seen a schematic. I started with full custom layout and moved up through the abstractions. The guy next to me programmed, ‘If a variable is larger than 398 multiplied by another variable,’ he was surprised the logic synthesis tool wouldn’t work because it would run at 100KHz and he had a 20MHz target. If you don’t have the understanding of the underlying hardware, know how the schematic looks in the hardware world, know how the chip works, then you have big issues. It’s an education issue.

Tags: CoWare, EVE, springsoft, Synopsys, System-Level Design, TLM, Verification

This entry was posted on Friday, July 24th, 2009 at 6:02 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.