By Ed Sperling
System-Level Design sat down to discuss ESL modeling with Anmol Mathur, CTO of Calypto; Steve Frank, CEO of Paneve; Fabian Clermidy, senior architect at Leti, and Sylvian Kaiser, CTO of Docea Power. What follows are excerpts of that conversation.
SLD: How important is speed in ESL?
Mathur: To get verification productivity out of an increased level of abstraction you really need to be able to quickly validate your implementation models and push the correctness of that through, whether you’re using high-level synthesis or whatever else to get to RTL and down. If you have to re-validate another model at the RTL level you’ve lost that.
SLD: What happens now that we have software in the mix? Does this complicate everything?
Frank: Absolutely. Our mantra is all about software, and we care about how efficiently the software runs on the hardware. It’s not about whether the hardware matches the architectural model. That forces us to do things early on. We develop a prototype compiler so we can take strategic samples of code and we take a real compiler and run it on the architectural model to validate that we’re actually getting the performance we’re looking for. A big part of what we’ve done is validate and automate that tool chain. In our case, that’s a big part of our design.
Mathur: One of the key motivators of people to have these high-level models is to have platforms for early development. That’s definitely one of the key drivers. People cannot wait until they have RTL or silicon to do software development.
Frank: Architectures you pick don’t just have implications for power, area and timing. They also have implications for how easy it is to write the software and to integrate it. You need to take that into account early in the design, just like power, area and performance. You have to understand when you can write the software, whether you can write it at all, and what the use cases will be. There’s more emphasis many times on just looking at the hardware metrics and not looking at the software metrics. The use cases when you design a chip aren’t necessarily the same ones when you get in front of customers. As designers, just like we wouldn’t pick a methodology that leaves us blind to timing and power, we need to pick strategies that don’t leave us blind to the software piece. Some strategies are better than others, and that’s just starting to be understood. No one really formalizes it yet, but it is an issue.
Clermidy: We have an issue with software development. On one hand, what the software people are asking for is something that is very fast. On the other side we have power management. We have software running and it has an impact on the hardware. So we need something that is very fast in terms of simulation. But we also need information on power and the circuit, so it has to be very accurate. We need something very high level but very accurate. That is very difficult.
Frank: They’re almost mutually exclusive.
Clermidy: We use different types of models that can be accurate enough, but which are not functional. They need to be running with high-level simulation and in parallel.
Frank: But the power of SystemC is you can have one model doing that with the power on an FPGA. Running SystemC at the instruction level is 100 instructions per second. An ISS is thousands, and you get 50 million to 100 million in an FPGA. We built our software platform first on an FPGA and then we retargeted to the SoC. But while we retargeted it, we had a software platform. And we could run real applications. That was more information that we could get from all of our simulation models.
SLD: And power models, right?
Frank: One of the big benefits of SystemC is the ability to re-target and get the best of both worlds. Clearly there is additional effort to do that. But most of that effort is additive. Most of the refinement you would have to do anyway.
Kaiser: There is no doubt that the possibility to write to hardware early in the design is one of the biggest benefits of system-level design. This is a real achievement of SystemC. Our customers say they need both. They can develop the software before the hardware and have a virtual product that they can show to their customers, and then take that feedback to the engineering team.
SLD: One of the whole ideas behind ESL was that it was supposed to make things simpler. The reality is that only the most advanced companies can work with this stuff. Will it ever go mainstream?
Frank: Another way of looking at the benefit of ESL is you now can have a small team of the best of the best doing what a big team could do. You could never have a big team with the best of the best.
SLD: But where are those small teams? Are they only in the most advanced companies?
Frank: It takes enough vision to go in this kind of direction. Many large companies aren’t comfortable taking what is perceived of as a technical and a business risk.
Mathur: It’s the standard adoption curve. These companies might be small. They might be big. I see many companies that are fairly small in size that need that productivity just to survive. But once the methodology is in place and once the food chain can use plug and play and swap things out, that’s when the risk-averse companies will start adopting it. We’re starting to see that. There are standards in place.
Clermidy: It’s about productivity. It’s a reality for small companies and it will be a reality for large companies. ESL will push even into large companies. It will take longer because they have established flows.
Mathur: The biggest companies are now looking at system-level modeling.
Kaiser: There is legacy in every company, but ESL will promote a seamless adoption of SystemC.
Frank: The skill level isn’t less. It’s more. It’s like a fighter jet versus a small plane. But the leverage and the power are extraordinary.