Let 100 flowers bloom ….. roses or weeds?
I’ve been working in and observing the field of “virtual system prototypes” (the term coined by Graham Hellestrand several years ago - see his “The Revolution in System Engineering“, IEEE Spectrum, September, 1999) or “virtual platforms” (the current term most widely used) for a few years now. In my opinion and by observation, this has been one of the hot areas in ESL the last couple of years. What I’ve also observed the last several months is a lot of debate over the best underlying simulation models for virtual platforms. There seem to be two camps: the one-kernel SystemC camp, driven by recent work by OSCI’s TLM2 working group (in particular, Draft 2 which came out towards the end of 2007, with its Direct Memory Interface (DMI) and temporal decoupling or time quantum keepers); and the two-kernel solutions, in which a proprietary fast simulation kernel co-exists with the SystemC kernel.
Claude Monet, The Artist’s Garden at Giverny, 1900
Among the many flowers we see in this garden are the Virtutech Simics kernel (an interesting article by Michel Genard on SCD Source discusses this: see Defining an infrastructure for virtual platform design). Virtutech is working with Greensocs on a Simics-SystemC bridge, according to Michel’s article. We also have OVP: Open Virtual Platforms, coming from Imperas, with a SystemC side door. ARM’s System Generator talks about a side door to SystemC in an NASCUG presentation by Nizar Romdhane. VaST has links to SystemC described in a white paper. And of course we have the single-kernel SystemC flower, planned to be supported by some ESL vendors - for example, see a NASCUG presentation from CoWare. (I will mention here that my company, and in some cases myself, work directly with some of these companies as partners, and of course, may with others in the list in the future).
One of the big issues I see in such a rich garden, and indeed, one especially important to IP providers, is whether models will interoperate among such a rich profusion of simulator architectures. If all the side doors or portals into the two-kernel simulation architectures conform to the same version of OSCI TLM2 Draft 2 interfaces, for example, then interoperability may become a lot easier. But this carries with it a potential performance cost. It may become very important “which side of the door” you live on. If a fast processor ISS model on the SystemC side of the portal wants to access memory which lives on the proprietary other side of the door, and if the portal between worlds does not support the OSCI Direct Memory Interface, then this ISS model may have to use slower mechanisms to access memory and thus be slowed down in comparison with the fast processor models living on the other side of the door. In the end, effective system modelling may depend on which side of the door you are. In this case, the door may become a kind of servants entrance: distinctly inferior to the main part of the house. And if everyone who has such a dual-kernel solution implements a different shape, colour or size door, then interoperability with each of these solutions may require a lot of extra integration effort. If this happens, our garden may become something a lot less pretty:
Alice Webb, Through the Thorns
We’ll have to see whether there is some kind of convergence on reasonably interoperable solutions for system modelling and simulation over the next few months. Given so many players, things could diverge. Of course, given good will and a drive for interoperability, things could instead converge. Hopefully, OSCI will play a leadership role in trying to keep our garden of roses from becoming a garden of weeds.
7 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
May 2nd, 2008 @ 4:33 pm
Grant has done a great job at identifying the various strategies in use for creating simulation models and showing the diversity amongst them. I would counter by saying it is surprising that there are not more solutions and approaches to the problem and this is probably only because people do not have the imagination to come up with new things - instead trying to copy the successes of the past. But lets get back to why I think there are so many. This is simply because we have not yet decided what we want to do with them. Ask users why they use a virtual platform and you will get a plethora of answers ranging from functional verification, to validations of architectural decisions, to performance evaluation, to software verification and so on. Is it reasonably to expect a single solution to be the best at all of these. No. They have different needs, different priorities and different users in many cases. Grant I believe does hit on the biggest problem and that is the one of communications between models. At RT level we solved this with simple semantics for interfaces attached to some low level communications channels - called wires. The semantics dealt with value, transition etc. We have failed to define the equivalent for higher levels of abstraction and even things like TLM are only attempting to do it for a small class of interfaces - those of memory mapped devices. But what about all of the other interfaces in a system? As far as I know, Imperas is the only one to have attempted to take that on. Without these interfaces, we cannot expect systems models to come together, and thus I would say that until we decide on interface standards, the whole virtual platform market will not grow significantly. How many kernels should there be - does anyone care? This is an artifact of the implementation and in itself provides no functionality.
May 3rd, 2008 @ 3:34 pm
I agree with Brian that the other interfaces are just as important as the memory-mapped interface. But I do not agree that Imperas are the only ones to take it on…
Pretty much anyone who has ever created a TLM model has wound up modeling some non-memory-mapped interfaces in some way. Sometimes falling back to SystemC channels (basically wires in a different shape), but also often doing function-call-driven truly transaction-level modeling. But due to the need to abstract form the physical layer, each such model has been done in a different way. Hampering interoperability of models.
In any case, the focus needs to be on how to interconnect models in a range of languages and from different sources, rather than on SystemC per se. It is a modeling language among many, good for some things, less good for others. And not to forget that models quite often need to come in binary form in order to protect someones idea of intellectual property…
Another body looking into this is actually Power.org, with its Technical SubCommittee (TSC) on Virtual Platforms and Simulation. See http://www.power.org/resources/committeeview/
May 4th, 2008 @ 9:44 pm
Grant, it would appear to me that there’s a need for an EEMBC-like organization to benchmark and compare the efficiency of different simulation interfaces on different products. Perhaps Markus Levy could be enticed to collaborate.
May 4th, 2008 @ 9:54 pm
Steve, that’s an interesting suggestion, although another alternative, and one that might be easier to start up, would be for OSCI to take a lead here in at least encouraging some standard test cases that could be used to benchmark simulation approaches. On the other hand, that might be regarded as beyond its remit in that it concentrates on the language itself and use models. Let’s see what others think (if there are more comments).
May 5th, 2008 @ 3:48 pm
I think benchmarks here are really tricky to do well… what do you want to actually compare? Overall efficiency of a particular simulator when models are optimized for it? Or the efficiency for the case of simulating SystemC in particular? At which levels of detail (or abstraction)? What to measure? Target instructions per second, target transactions per second, target time progress per second? It is a very slippery thing, in my experience.
I have done a lot of benchmarking of our simulation solution, and even within the scope of a single kernel, single system, single level of abstraction doing anything meaningful is awfully hard. Measurements indicating that one simulation design is better than another are often invalidated by changing the nature of how the target software is using a system. As a simple example, in the same system, performance can vary by a factor of a hundred or more between a benchmark doing intense device accesses and one doing processor-intense integer math.
Maybe the best way would be meta-benchmarks, with designs to model in the best way possible for a particular simulator. With a full target software stack to drive it… But even so, finding a common base platform to work from is pretty hard. What should it be? Something old and establihsed like a PowerPC 750 with a cpc700 chipset running Linux 2.4? Or a naked plain MIPS32 processor with memory, no chipset, and just a device?
More questions than answers, sorry about that.
May 8th, 2008 @ 6:53 pm
I got a comment from my friend and colleague Frank Schirrmeister who is over at Synopsys (I first worked with Frank many years ago in the Alta group of Cadence. He is Director, Product Marketing, System-Level Solutions for Synopsys). He wanted to clarify Synopsys’s position regarding OSCI’s TLM 2 standard:
May 16th, 2008 @ 1:22 am
As mentioned in the previous comments, it’s difficult to have a scientific discussion around these issues when there are so few data to examine.
Who holds the burden of evidence here? Is it OSCI? Have they done enough to convince the modeling-public that SystemC models have sufficient horsepower to compete with other approaches? Is it possible to answer these questions in a public forum without breaching a clause in a software license?
Are we using the correct metrics to compare these different approaches? Is it all just about simulation speed or should we be looking at the product of simulation speed /and/ development effort? Are these alternative modeling styles even universally applicable or are we just talking about better ways to hack an ISS?
If I may abuse Grant’s metaphor a little: lets not forget that doors have locks. Is that the true value of “the other side of the door”? Who is locked in? Who is locked out?