By Ed Sperling
System-Level Design sat down to discuss hardware-software co-design with Frank Schirrmeister, group marketing director for Cadence’s System and Software Realization Group; Shabtay Matalon, ESL market development manager at Mentor Graphics; Kurt Shuler, vice president of marketing at Arteris; Narendra Konda, director of hardware engineering at Nvdia; and Jack Greenbaum, director of engineering for advanced products at Green Hills Software. What follows are excerpts of that conversation.

SLD: How often is co-design really warranted?
Greenbaum: The case for power and performance may be more common than you think. Looking at the products from Nvidia, is a Tegra processor a standard product or an SoC? You put a Tegra in an automobile running an IVI (in-vehicle infotainment system and maybe an instrument cluster. That instrument cluster gets prototyped on a desktop. Then someone gets the idea of taking that high-polygon-count design and putting it in a car. Now you have a cost you have to optimize. If I can’t do it with today’s Tegra, can I do it with the next one? You’re not going to know. That’s one advantage of co-design. You can know before the sand gets melted. Even if your application can be implemented in software, co-design to let you know what price point you can do it at is very valuable.
Konda: We are delivering a solution today that is not just silicon. It used to be the case 10 years ago. But today it’s a complex piece of software and highly complex software. These two things have to come together. First and foremost, we have to make sure the design is in a semi-working condition before bringing in the software team to develop their code. To do that, we cannot wait for emulation or an FPGA. These bits and pieces of a design where we have multiple cores, multiple processors in that SoC—20 to 25 processors and components and interfaces—creates a very complex device. RTL is not available all the time. Some parts of the design are in RTL, some parts are in C models. As soon as we have a little bit of confidence we want to encourage the software team to come in. That’s very early in the design cycle.
Shuler: Why do you wait so long? Why don’t you do it as soon as you get the initial requirements?
Konda: We have been doing that for a number of years, but it’s still not a full-fledged solution. In our case, we have 30% to 40% of the design modeled at the very beginning and software teams are already working on that model. But it is not the entire SoC. They are working on the GPU or CPU portion of the SoC. How do we model all of these peripherals? That’s not there yet.

SLD: There are two trends unfolding in IC design. One involves a general-purpose processor, where you may leverage one or more cores and only a specific amount of memory. The second is a very specialized processor where you may run a specific application. How does co-design deal with these different approaches?
Matalon: One issue is really validating the spec. The earlier you can capture your specification using an executable specification where you don’t just generate UML diagrams but simulate it dynamically to represent the conditions upon which the specification is working is an ideal solution. This is a level above implementation. That’s very important. If you go one level down and start doing partitioning in LT mode, you can’t really evaluate the tradeoffs. It’s good to refine the specification, but you can’t validate the performance, bandwidth and power are there. In my view, the key is to first focus on architectural exploration to make sure you have the right performance and power. For that you need an approximately timed model that allows you to do an evaluation of performance and power for your standard processor, for your specialized processor, for multiple cores, for all the combinations and topologies. It cannot be too low-level so it can be used in a way where you can do power/performance evaluations, do a power budget, and if you need to, you can shut it off and run other parts very fast. That’s where I see the ideal solution. Some customers are using it and many customers are not. You can’t wait for the RTL. It’s too late. You can do co-design, co-validation through all the stages of implementation, but from a design perspective for these types of designs you have to start above RTL.
Shuler: When we’re talking co-design, it’s a people problem, not a technology problem. You don’t see kick-offs where there are hardware and software people in the same room—or even where the architects and verification people are in the same room. The semiconductor vendor is responsible now. When you think about it, the real customer of the semiconductor companies are the software vendors.
Greenbaum: Absolutely. And very few semiconductor companies recognize this.
Matalon: It’s not as bad as that, but it’s not yet the prevalent methodology. Co-validation is already quite entrenched, because emulation, acceleration and virtual prototypes are really co-validation. The co-design—evaluating the performance and power—is still at the early stages.
Greenbaum: The big difference is between code software drivers written for verification or validation vs. those written for real applications. The semiconductor vendors that are doing the worst job of delivering a full platform of silicon and software don’t understand the difference. They’re delivering verification code, but when you try to use it in a software environment it rolls over and dies very quickly. There is a spectrum of companies that get it, and if you look at the acquisitions in the embedded software arena—Cavium acquiring Montavista, Intel acquiring Wind River, the in-house Linux teams that are pervasive and Mentor with the Nucleus product—we’re seeing the recognition there. But only the top vendors are there today.
Schirrmeister: There is always the Yin and Yang in here. We have polar opposite trends. There is the generalization of the processor, which is meant to not shoot yourself in the foot. In the embedded space you have Java-based applications. Those development environments are built in a way that is very abstract. On the other hand there are highly specialized processors enabling highly specialized applications—highly specialized hardware with an abstraction layer and then the application development environment built on top of it. Now, going back to the models, if you had the model generator where you just talk to it and it creates the AT model, that would be the perfect environment. As a practical matter, what chipmakers are looking for is the ability to mix and match. The AT model is great to represent some of those effects, such as area, power and performance. But in the next version, the question might be slightly different. That makes it very hard to build those AT models.
Shuler: We have to do all three in addition to RTL. We have cycle-accurate, loosely timed and approximately timed. You never know what people will need.
Schirrmeister: As a practical matter, there are a lot of people using AT models. But in parallel people are taking the appropriate model for the system and hooking them together. So you have emulation or rapid prototyping for the pieces that are already stable, which is where IP re-use comes in. You may not have to rebuild them as an AT model. Having a processor model of the next big.LITTLE chip and execute the software, and for the subsystem that does more computing to be able to analyze the performance, allows you to create the right mix. Would the perfect environment be to have AT models for everything? Absolutely. Can you practically build AT models for everything? It may not be possible all the time.
Matalon: AT models are ideal because the other models are too slow or don’t have sufficient information. I disagree it is difficult to build them. We automate that from simple definitions. The challenge we see sometimes is that the functional model doesn’t exist. You have a design that is very complex and now you want to build a functional description that is equivalent to RTL. To wrap it with timing and power can be fully automated. Even the entire platform can be fully automated. But when you have a complex design and you want a functional abstract model, you have to write it yourself. If you put the RTL on an emulator and connect it to the rest of the models you are missing some of the capabilities of how you evaluate power or performance and you’re using RTL again, so what’s the point?
Konda: On the models front, it’s true you will not be in a position to provide models for the entire SoC. And to expect a functional model from an EDA vendor is not realistic. In an SoC environment, we have a number of interfaces and devices that get attached to the SoCs that are standard specs. At Nvidia we design our own CPUs. We also use ARM CPUs. We have a GPU. If you look at where these teams are, the CPU guys are in Santa Clara, the video guys are in Shanghai, and the simple interfaces like an SD card are in India. To realize the SoC model there is no common platform that pulls all these things together. The CPU and GPU guys are forced to develop a high-level C model. They start doing their work earlier in the cycle because they are forced to. Each team is doing whatever they have to do. But bringing all of these things together to create an SoC is the biggest missing piece. If you run a Facebook or a Twitter application, power and performance are key. So how do we estimate the power consumption? We cannot do this in one platform. With emulation it is too slow. With an FPGA, by the time the FPGA starts working the chip has already come back from the fab. It is a mix of parts of the design on an emulator or an FPGA, which is a real model, and then you hook up the rest of the design that gives a good approximation of the real system. It may not be highly accurate, but if you can estimate power and performance plus or minus 10% that’s still great.

All of the major EDA vendors and standards groups are pitching modeling as the next level of abstraction for advanced process nodes, but is it working as planned for the chipmakers? System-Level Design caught up with Frans Theeuwen, Department Manager for System Design at NXP Semiconductors Corp. to discuss system-level design and power modeling.

By Ann Steffora Mutschler

SLD: How long has NXP designed at the system-level for production chips?

Frans Theeuwen: It depends on what you call ‘system-level design.’ We have been doing hardware/software co-verification activities for quite some time, which goes back about eight years. Many things we are doing in system-level design are creating virtual prototypes and software development for virtual prototypes. We first did that for production designs about three or four years ago. There was one chip for identification, used in banking applications, and now we are using it more heavily in the area of television chips (consumer electronics). What we are doing now for consumer applications is transaction-level modeling and using that mostly for software development.

SLD: What works and what doesn’t in this area?

Theeuwen: The largest problem for introduction is you need to create all the models. That requires quite an investment if you want to reuse that within the company. In 2007 and 2008, we did quite an investment in creating lots of models for our standard SoCs, so for all the IPs that are there. That’s one thing that is important. The other thing is that most people want to use these virtual prototypes for accurate simulations – for really cycle accurate things. That is what you should not do because then the models are much too complicated and you are too late. If you do transaction-level modeling, you can still do software development, so convincing people they should use one use case for software development and create the models for that, and then do software development for that.

SLD: How long have you been doing power modeling on the transaction level, and are you using tools that you created or outside tools?

Theeuwen: For power modeling on the transaction level, I think we started four years ago. Before we started on the transaction level we did it for power estimation on the gate level. Then, later on, we extended this capability of power modeling at the gate level to go up in abstraction to the transaction level, and there we created our own tools.

SLD: How is the learning curve for the engineers in terms of power modeling?

Theeuwen: Our power models are part of the SystemC TLM models. First, you have to create TLM SystemC models, and then you can put the power models to that. First, you must have all the TLM models available and then you can think about power modeling. We’ve only been working on full-fledged TLM models for a few years, so now we can add the power models to that and the extra work is not that much. Once you have the TLM model, then adding the power view is really not so much work and we rely there on the gate level simulation. As most of the designs are reused – about 90% to 95% of large SoCs is reused – you can have quite accurate power models because you have the RTL so you can simulate. If you have that on the TLM level, you can have quite accurate power modeling on your whole SoC. There are only a few parts for which you do not have implementations and there you need high-level power estimates.

SLD: What are some other issues that need to be addressed at the system level?

Theeuwen: The largest problem with TLM modeling is that interoperability between models is still very difficult. TLM 2.0 is a step in a good direction, so it gives a bit of framework, but if you are modeling in TLM 2.0 there is no guarantee that everything works together.

SLD: What is missing from TLM 2.0?

Theeuwen: One part of being interoperable is being able to connect models to each other with the same buses and pins, and things like that. But also, in a complete system, how scheduling works or how different parts run on a multiprocessor design and how does that change, and how it interfaces to memory. All of those things are still not standardized.

By Ed Sperling

System-Level Design sat down with Simon Bloch, vice president and general manager of ESL/HDL Design and Synthesis at Mentor Graphics; Mike Gianfagna, vice president of marketing at Atrenta; and Jim Hogan, a private investor. What follows are excerpts of a lively, often contentious two-hour conversation.

SLD: What’s the starting point for designs in this world?

Hogan: In the virtual world, where you start is models. Those models have to accurately represent your concept at the level of abstraction you’re working at. The problem with models is they have to be accurate enough but not too heavy. I used to get SPICE models with 98 terms. I could only use 5, so I would fill in coefficients on 10 of the terms and zero everything else out and see what happens. We need more standardized concepts to make this work. Then we have to figure out what is the right level of abstraction, and then we can go off and build simulators and optimizers and analysis systems to take advantage of that.

Bloch: The SystemC TLM 2.0 enables us to go from light to heavy on an as-needed basis. You start with less accurate but fast, which is good enough for virtual prototyping. You don’t need a lot of information for prototyping. But at the next step, if you want to do exploration for performance of power you need more accuracy. You’re okay to sacrifice some speed, and you can load in more data. The key is a scalable model, and it exists in TLM 2.0. Function, performance and power are separate. You start with function, you incrementally add timing.

Hogan: We used to live in a 2D world—performance and area. Now it’s a 3D model. And there’s a shape within that model that’s your design space. You have to optimize that 3D model for your design space. You can’t do this on an Excel spreadsheet. That’s only two dimensions. You can’t do this without a simulator.

SLD: How about software dependencies?

Bloch: Software dependencies are taken care of in the TLM model, which is comprised of TLM functions, interconnections—which are called transactions these days—and if you add software it affects the transactors, it propagates functions, and you can measure things like power, performance and how the architecture affects that. Software is part of the TLM platform.

SLD: As we head into even more complexity with more power islands all the way down to 22nm, you need to layer your model, right?

Bloch: Yes, and that’s the beauty of dealing with different levels of abstraction. When you talk about power islands, this is reflected at the RTL level and down. At the virtual platform level you care about how long it takes you to go from wake to sleep. That’s what you care about at that level. But if you made the wrong decisions for the user experience, it’s very hard to recover at the power island level.

Hogan: What will you tolerate in terms of sleep? Maybe half a second?

SLD: It depends on whether you can receive your phone call or not, right?

Hogan: Yes, and there are hardware requirements for that. The memory for that has to be powered up all the time. This is all hierarchical. We used to talk about timing models, and that’s where EDA stayed. When we got to RTL we talked about cycle-based models. Transactors are the next thing. Then there are threshold models from the applications. The abstraction has gone up to the level of the software.

SLD: Basically like a software stack, right?

Bloch: Yes, that’s a good analogy.

Hogan: The challenge is traversing the hierarchy from the abstraction down, and then back up. Power is an artifact of how your function wants to be.

Gianfagna: We have a customer now with 20 power domains. Of those 20, there are hundreds of ways you can slice them. Which one is right? There is a lot of ‘What If’ going on. Maybe you do a trial through a high-level synthesis through a synthesis down through RTL, and then go back and try it again. The good news is I can do that in days. If I go down to the gate level, it’s weeks. You’ve got to do these ‘What ifs’ at the higher level. New tools—some exist, some are still to be invented and released—are the only way to get there.

Hogan: Since the late 1970s, digital design has been sequential. That implies there’s a clock. That consumes a lot of power. Asynchronous doesn’t. I’ve seen chips with 90 power domains. They’re basically doing an asynchronous design, but they haven’t figured that out. You have to decide how you want your chip built at the architectural level. It’s been tough for investors to go there. Mentor has done that and so has Atrenta, but there isn’t a lot more. We have to invest in that.

Gianfagna: How much of EDA’s lifetime has been directly aligned with our customers delivering and accessing an end market? Very little. It goes into a product and when we ask a question about where our stuff is getting used, the answer is, ‘It doesn’t matter. That’s not your business.’ With this platform movement, the semiconductor companies are trying to figure out how to collaborate, how to build derivatives in a cost-effective manner, how to build hardware and software together and how to build a hierarchical model. It’s not cost-effective for them to do this on their own. If the EDA industry gets involved at that level, then they become a partner. We can work with TI, ST or Qualcomm to deliver a platform to their end customer that they can customize for their application. We’re starting to get involved in the business of producing semiconductors.

SLD: It sounds like you’re vertically integrating the entire process.

Gianfagna: Yes, which I think is new for EDA.

Bloch: Is that called Spectrum Design Solutions? (Spectrum was bought by Digi International last year.)

Hogan: Or (Cadence’s) Tality?

Gianfagna: No, it’s not a service at all. It’s not a design flow. It’s enabling technology to allow the semiconductor companies to deliver a complete applications environment. That requires EDA’s help.

Bloch: It goes in stages. There are standards first. There is methodology second. With methodology, then you know what to build. In this platform-based design space, we’re early.  We tried things in the past for virtual platforms at the RTL level and they were too slow. Now we’re going up a level of abstraction. TLM is a new standard and we’re figuring out the methodology. It’s a good model to work with customers, but it may not be an ongoing business model. We need to understand the methodology to build the tools.

Gianfagna: I would argue that with some of the larger accounts and early adopters, that’s happening today. Is it hundreds of companies? No. Is it a dozen? Yes.

Hogan: If you’re a general contractor you have to build a scalable practice. Wherever you can on a methodology, you automate it. Automation takes people out and builds in scalability. But for a long time it’s going to have a significant people component. It’s not like analog. Analog isn’t chip design. It’s always block design. And something most people don’t think about, analog doesn’t differentiate a product. You can have good analog and bad analog, but functionally it doesn’t change things. Analog has been very resistant to automation. It takes awhile. The first SPICE engine was in 1962. Everyone agrees on the need. System-level customers are giving us their permission. And those leading-edge customers that Mike talked about are system-level customers. They’ve moved up a notch. Our opportunity is not clear to everybody. We’re all comfortable doing place and route. It’s our comfort zone. We have to evolve.

SLD: It’s evolving, but isn’t it also a compromise on all sides based on an explosion in complexity?

Bloch: I think complexity is driving outsourcing and separation of functions. Semiconductor companies used to do it all. Automobile companies used to do it all. I am a big believer that system-based companies are going to use platform-based design as an executable spec.

Gianfagna: Yes, and that’s the opportunity for this stagnant EDA market. It’s a whole new customer base. Traditional EDA needs this methodology. There also are a lot of new users well above our traditional semiconductor guys.

Hogan: What we know as semiconductor implementation isn’t going away. The customers are going to squeeze as much money out of that as possible so there will be less money to share among the suppliers of that. There will be consolidation, and usually in a market only the top three survive. Semiconductor companies have short product cycles, they can’t amortize these tools across the life of the product anymore and they push the risk onto the subcontractors.