System-Level Design Maturing

Electronic News, Dec 18, 2000 by Gale Morrison

Convergence on one underlying model for design language seen as key

RESEARCH TRIANGLE PARK, N.C., AND WILLSONVILLE, ORE.--AS EDA and semiconductor intellectual property (IP) companies go about their business, companies have had to become aware of a huge underground river of design engineering exploration: system-level design (SLD). The design surface in recent years has shown pools, lakes and streams of this exploration-proposals for design with C++, success with instruction-set simulators for hardware/software codesign-but as yet the river cannot be mapped.

Electronic News talked with one of this area's veteran investigators: Brian Bailey, chief technologist in the system verification development office at Mentor Graphics Corp., Wilsonville, Ore., to learn more about SLD and the challenges the technology presents to both the EDA and IP markets. Bailey is also chair of the Accelera architectural language committee looking into C-based languages.

Electronic News: In looking at how the design community, EDA vendors and their customers are addressing SLD, one finds many pockets of ideas and not a lot of consensus. Each company has its own take. Are you finding any common ground out there?

Brian Bailey "It really is all over the map. SLD is still an area where everyone's trying to define what the space is and no one really knows for sure yet.

"But, I think there's something significant here. For the first time in EDA history, I think the EDA companies are actually moving a head of their customers' demands. Companies are producing tools and letting customers go out and try them, and then those customers come back and tell them what they want and they don't want in that kind of tool...

"One of the things I do see happening at the moment... is that the verification part of the system design process is having the most adoption and use. I hate to say it's simpler, but it's something that can be worked out ahead of the synthesis. That's what Seamless (Mentor's coverification software) does, and in Cadence Design Systems Inc.'s Cierto VCC line, it's the verification part of that that's seeing the most success.

"But there's always a danger in concentrating on the verification aspects in that you get languages being adopted that are mainly verification friendly. We've already seen that that creates problems down the road when you want to do synthesis and the automation of the design flow. Verilog and VHDL are, in both cases, verification languages and not design languages.

EN: You're on the architectural language committee of Accelera (the merged standards body of Open Verilog International and VHDL International), working with this subcommittee group reviewing various C/C++-based design proposals. If the goal there is using this common language, C, for hardware and software design, where are the interfaces between Accelera and its counterparts in the world of software engineering, of software standards? Are there any?

BB: "Well, the glib answer is there is no interface to the software engineers using C because there is really nothing in common between how each side uses C. Yes, Cis being used by both sides now, but one of the great fallacies out there is that now hardware and software engineers are using the same language. It doesn't work like that. The way that you would write a piece of code for some thing that is going to map to software is completely different than the way that you would write a piece of code for something that will be implemented in software.

"I personally believe that it is going to be many, many years before there is a synthesis tool intelligent enough to translate between one style of writing and another, one that is intelligent enough to know the difference between where the code will be, or should be, mapped.

"The reason for that is that when you write for software, you are assuming a sequential model of execution-unless it's written to multiple processors. One line is executed after the last. In hardware you assume everything is going to be parallel. You create that to bring down the power or the area of the cost of the solution so finding common ground for software and hardware engineering has just been tremendously difficult.

"I'm also chair of the Virtual Socket Interface Alliance interface based design committee. That's part of their system-level design group. This is a conversation we've had many, many times. We've always come to the agreement that as primarily hardware engineers, we don't have the knowledge or understanding of engineering software that would be required (to devise some common starting point). Even then, when we have tried to bring in software vendors to cooperate with us, they are very reluctant to do that...

"You might have heard of the Object Modeling Group, or OMG. There's a lot of work going on around UML, for instance. We're beginning to see some overlap. It's one of the reasons that Mentor Graphics made the Microtec (real-time operating system) acquisition.

"Software engineering for electronic systems is a very different culture, they have very different ways of doing things. We're just beginning to find ways that the two groups can communicate. It's getting to be a cliche now. When we first started going out and telling people about Seamless, we would insist on companies that we talked to having both hardware and software engineers there for our meeting. In many of those meetings, the hardware and software guys (from within the same potential customer) literally met for the first time and exchanged business cards.