Taken for Granted

Today’s posting is about a new blog written by my friend and colleague Frank Schirrmeister, who now works for Synopsys and has just started his own blog, A View from the Top - A System-Level Blog. And my image is not a classical or modern painting, but one of Frank’s variations on his “levels of abstraction” powerpoint slide:

Levels of Abstraction, by Frank Schirrmeister

As Frank points out in his blog, he drew this for Alberto Sangiovanni-Vincentelli back about a decade ago, and it has seen many incarnations since then. In fact, it has seen many many incarnations (I have now seen it in many talks and slides over the years, in a host of forms) - but usually without attribution. Although “reuse is everything” and “IP reuse” is to be encouraged, this should be done with due credit to the originators. So let’s see this slide or picture continue to propagate in many forms and variations……….but with proper attribution to its originator, Frank Schirrmeister. And someone I am proud to list among my friends and colleagues (and co-authors too). As a key thinker and do-er in the ESL domain, Frank deserves to be recognised for his contributions.

Please read Franks’ blog when you have the time, and give him comments. And please keep reading and commenting here!

A couple of interesting items from the Multicore Association front. First, they have organised a working group on Multicore Programming Practices, (MPP), to

“develop a multicore software programming guide for the industry that will aid in improving consistency and understanding of multicore programming issues.”

Even more interesting, for non-members, they are organising an informational meeting on the MPP initiative at the Design Automation Conference in Anaheim, on Tuesday June 10, from 1700 to 1830 (5-630 pm), room 201C in the convention centre. You should RSVP: see the Multicore Association website.

John Singer Sargent, Hercules and the Hydra (1922-1925)

On a related front, the end of May approaches and this should mean the appearance on the Multicore Association website of a publicly available version of MCAPI - their Multicore Communications API. Somewhat ironically, this was announced as being publicly available on April 1, but the news release just said it would “soon be publicly available” and the working group web page says it will be available by the end of May. Let’s hope so, as the public interest in MCAPI, and its possible takeup, will be a good indicator of whether the industry is beginning to converge on some standards here, as opposed to all the ad-hoc methods being used. The programming practices guide will hopefully give examples using MCAPI as well. Perhaps we’ll hear more about this in the June 10 meeting, which I also hope to attend. See you there!

One of ESL’s great chicken or egg questions is: do ESL modelling tools encourage the development of models to fit, or does model availability encourage the development of and use of ESL modelling tools?

Viktor Hartmann, Sketch of costumes for Ballet ‘Trilby’ (an inspiration for part of Mussorgsky’s “Pictures at an Exhibition”: Ballet of the unhatched chicks)

I was reminded of this conundrum while reading a press release from Synopsys (one of the pre-DAC runup in EDA-related press releases from many corners), on “Synopsys Adds 30 New Titles to DesignWare System-Level Library“, dated May 15, 2008. In this release, Synopsys discusses the addition of a number of transaction-level models to their SystemC libraries, including models of DesignWare IP blocks such as PCI Express 2.0 interconnect components, and processors such as PowerPC and MIPS.

The usage of system level models and virtual prototype or virtual platform models, in a number of tools including POSC (Plain Old SystemC), has long been felt to be gated by model availability. With this in mind, the availability of new models for components, especially interoperable SystemC models, but also including models with proprietary interfaces, is a good thing. The more models, the more likely it is that users of any of the tools out there will find models of existing IP available when they want to build system models of their complex designs.

All such developments will encourage more people to look into building system models, and the growth of use of system modelling (and the derivation of benefits thereby) will feed into a virtuous circle, where ESL modelling usage increases, encouraging demand for more models of components and IP, encouraging the growth in model availability, thus encouraging an increase in ESL modelling. Let’s hope that eventually the issue of model availability will become a secondary or tertiary issue in the growth of ESL modelling and usage.

The upcoming Design Automation Conference, June 8-13, in Anaheim, California, will be a good chance for people to catch up with what is going on in the ESL and processor-based design areas. My dance card is beginning to get full, and like all good conferences, there is so much going on in parallel that it’s impossible to get to everything of interest. Before listing things of interest, I will mention that I have been involved in helping to organise some of these events or will participate in them. And with so much going on, I can only touch on some highlights.

Edgar Degas, Rehearsal of a Ballet on Stage

In the processor-centric design area, there is the co-located Symposium on Application-Specific Processors to be held June 8-9. On Tuesday June 10 there are technical sessons on Novel techniques in embedded processor design, a pavilion panel on Multi-processor SoCs: the next generation, and a technical panel on Multi-core SoC Design is the Challenge: what is the solution? On Thursday June 12 is a session on Multi-core Design Tools and Architectures.

In the ESL domain, as one might expect at DAC, there is much more going on. Sunday full-day workshops include the 5th International UML for SoC design workshop, and one surveying High-level synthesis. A North American SystemC users group meeting runs from 4-7 pm. Monday June 9 has an OSCI event at lunchtime, an OSCI Overview of TLM 2.0 in the afternoon, and a SPIRIT general meeting in the evening. On Tuesday June 10 we have a panel on ESL Hand-off: Fact or EDA Fiction. Wednesday and Thursday have many things going on - June 11 a lunchtime Mentor ESL symposium, a pavilion panel on Behavioural Synthesis, and a session on ESL methodologies for Platform based synthesis. One of the last sessions on Thursday is one on Design Space exploration, and the Thursday keynote is by Jack Little of the Mathworks offering “a different perspective on System Design”.

On the IP front there is a Pavilion panel Tuesday on IP Selection, and an interesting breakfast IP roundtable sponsored by Sidense on Wednesday morning at 8-9:30 am.

With all this, I have barely scratched the surface of the 45th. DAC. There are many more keynotes, panels, technical sessions, workshops, tutorials, special events dealing with all aspects of EDA and ESL, that you will find of interest. I hope to see you there. If you have other suggestions of other interesting sessions and events at DAC, please leave a comment here for all to read.

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.