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: Why is ESL growing so slowly?
Mathur: Part of the problem is the definition of ESL. For some people it means a change in the level of abstraction. My opinion is it involves a lot more than that. It requires a whole ecosystem of tools and methodologies to evolve along with the level of abstraction you’re doing for design and verification. But as you shift the level of abstraction up from C to C++ and SystemC, what portion of the design can be effectively represented and verified along with RTL is a challenge. That means you have two different kinds of models and two different kinds of expertise in your design team. Then there’s the other issue of keeping the models in sync. If you’re generating RTL anyway, you need to make sure the system-level model is consistent with the RTL model.
Kaiser: There is no doubt ESL is widely used for real problems. ESL can be used to explore the architecture. It can be used to create hardware models. These various usage models prove that ESL has value for the user. At the very beginning of SystemC development, I don’t know whether people had this full picture. The use of SystemC is widespread now and it addresses real needs on the market.
Frank: I don’t really think of it as ESL. I think of it as a problem where we’re designing a general-purpose processor with a small number of people as opposed to teams of hundreds that build them for big companies. You have to think differently. We started doing prototypes of designs in 2005 using SystemC as an implementation model. If you take the language and layer a methodology on top of that, what we have at the end is 20,000 lines of SystemC that’s equivalent to designs that are 1 million to 2 million lines of Verilog. As a user it did require us to layer a methodology on top and to create pieces that fill in what those tools don’t provide. From a system-user perspective, I don’t think any of the tools out there deal with the whole picture yet. We needed to do some things on our own to make it work.
Clermidy: We are quite similar. We have small teams and were an early user of SystemC. We’ve been using SystemC since 2003. What we intend to do with ESL is use it from the very high-level model to the RTL and down to the gate. So we’re developing something at a high level, something at a low level, and we have a gap between the two levels. We think SystemC is very important for architectural exploration.
SLD: Are you using TLM 2.0 and IP-XACT?
Clermidy: Yes, we are using both. We are doing exploration of the full architecture. What’s missing are some of the tools. At this time, we can’t get everything we want. We need to be able to use the tools more efficiently.
SLD: Is it a problem to keep all the models in sync?
Mathur: That’s a major challenge, from RTL on up. If you look at the RTL design and verification and implementation flow, you have a very clearly defined entry point. Over the years people have standardized on the Verilog and SystemVerilog subset. It’s a very clearly defined flow. But when people move to a different starting point in terms of abstraction, the interface libraries are different. First, there needs to be a convergence in the subset of SystemC. That’s starting to happen, but there has been a lot of confusion about what tools to use. There have been many levels of abstractions and interfaces over the past 10 years. Eventually people will converge on a high-enough level of abstraction that also gives them a path down into silicon.
Clermidy: It’s very difficult to have the same models for different levels because we have very different needs. For example, we are working on power enhancement. We now have dynamic voltage scaling. It’s hard to get a good estimation of power on a chip using low-level or mid-level estimation. You need to do this at a high level.
SLD: But don’t you also need some accuracy for those numbers so they actually mean something?
Clermidy: Yes. You need something that is at a high enough level to be able to try things very quickly, so you need to be able to mix this high-level modeling of power with some low-level power. Ten hours of simulation just for one core measurement is too slow. You need to do it quickly and go on to something more accurate after that.
Frank: We’re building a processor, so it’s a special case. But we have an architectural model based on a markup language that’s defining the behavior of an instruction set. That drives automated software that implements our instruction set simulator and our compiler for other tools. Then there’s the actual SystemC, which is the implementation path. So we have two very different implementations for a design. We also have a tool that explores the state space at instruction level because we’re interested in verification of instructions and sequences of instructions.
SLD: Can you keep those two models in sync?
Frank: Yes, and we depend on the fact that we can run the verification suite across both—and they’d better agree. We have an automated process with hundreds of thousands of instruction sequences that are 10 to 15 instructions long. We run those against the instruction set simulator and against the SystemC design, and we look at the before and after state and match them. We run those every night. There are challenges in keeping those in sync, but our model is based on doing that.
Mathur. The two-model style works well. People have RTL and a higher-level executable model. Two models has been the norm. But right now people have algorithmic models, fixed-point models, models that potentially can go into high-level synthesis. That’s the challenge.
Frank: The golden reference model drives our instruction simulator and all of our other tools. We’ve automated a bunch of that. In some sense, the SystemC is much higher than RTL. On the implementation side we resist all temptation to have more than one. We have the model police who say, no matter how tempting it is to bifurcate that model and make something for simulation and something for synthesis, that bites you every time. But within the SystemC we have evolved the methodology where in parts we use a TLM and in other parts we specify how things run on a cycle-by-cycle basis.
SLD: But does that work for an SoC, as well?
Frank: There is something like that for an SoC. Having this discipline sometimes makes you do a little more work, but in the end you have something that’s correct by construction. And every time we deviate from that, we pay.