Taken for Granted

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.

Many people are familiar with Salvador Dali’s painting, The Persistence of Memory:

When I look at developments in ESL, I sometimes think of the painting and its title. Some of the old ideas in ESL must be good ones because they keep coming back. ESL synthesis, for example, has now been through at least two or three generations. In fact, to many people, ESL = ESL synthesis (or behavioural synthesis, or high-level synthesis). We have seen some recent activity in this area - for example, Celoxica got out of ESL synthesis to focus on FPGA-based accelerators for high performance computing applications, and moved its technology and team to Catalytic, forming Agility Design Solutions. At the recent Electronic Design Process Workshop, I saw Rishiyur Nikhil, CTO of Bluespec, give a talk on Parallel Atomic Transactions in the Bluespec synthesis approach. I’ve heard some people comment that they don’t really consider Bluespec (using System Verilog and some particular constructs to express their atomic transactions) to be “high-level” enough to be ESL synthesis. Most ESL synthesis tools use C/C++/SystemC or other dialects of C as inputs. However, the atomic transaction semantic used by Bluespec is definitely more abstract than the normal way people write HDL for RTL synthesis, so I think we can count it as among the family of recent high level synthesis approaches.

It was therefore interesting to read on the wire this morning of a new high level synthesis company called Fastpath Logic, with what they say on their very minimalist and unfinished web site is new ESL technology based on a new input language Chip Specification Language (CSL) for “chip and verification infrastructure generation”. They describe this task as being different from, and complementary to, the creation of the algorithm implementation (which has been the focus of most ESL synthesis up till now). It will be interesting to see exactly what is entailed in CSL, and what the interface generation will provide, and how it will complement the use of RTL or other ESL synthesis approaches for algorithm implementation. No doubt more will be revealed by the time the Design Automation Conference (DAC) rolls around in Anaheim June 12-18. I don’t see Fastpath Logic on the list of exhibitors as of today (April 24, 2008) but perhaps someone from there will be wandering the DAC floor and people may run into them.

Hope springs eternal in the ESL arena….

I’m sitting here at the Electronic Design Process Symposium 2008 in Monterey after a fascinating morning session on multicore, manycore, MPSoC, SMP, AMP and the like, in which my colleague Steve Leibson and I participated. Together with impressions from attending the MultiCore Expo in Santa Clara a couple of weeks ago, the discussion, and the need to constantly define our terms (and redefine them, and discuss them when people disagree) makes me wish that the world of electronics, system and software design had some agreement on what the right terms are and what they mean. A kind of taxonomy of multicore related terms, together with a taxonomy of programming models (SMP, AMP, etc.) that everyone could be referred to when these discussions are held and that everyone could begin to build a consensus around would be of great value to all.

Taxonomies of this kind have been useful in EDA and ESL in the past - I think of the RASSP and VSIA work on model taxonomies that at one point was the most widely downloaded VSIA reference document. It would certainly be useful if everyone recognised a common definition for “multicore” when they hear it (2 cores? 4 cores? a few but less than 32? symmetric? cache-coherent?), or “manycore”….

As most people in industry may be too biased by their particular corporate inclinations (and I concur that I am too!), this would be a great thing for an academic to set up as a web site to which many could contribute - maybe a Wikipedia of the Multicore world. Perhaps a vigorous discussion by interested industry and academic people could lead to a consensus………perhaps not! But it might be worth trying.

While we were at it, it would also be a useful place for people who have successful examples of parallel or concurrent programming on multicore or mapping examples to homogeneous or heterogeneous multiprocessor systems to be able to list them there. This would be valuable for all who are new to this area who don’t have all the right history in the field that a lot of the HPC (high performance computing) people have, for example.

Is there someone in academia who could take the lead on this? I’m hoping….

About 30 years ago (!!!!) I worked for Burroughs in Scotland. (Some of you may remember it…….designed and built computers. After merging with Sperry, it became Unisys). Here I was introduced to the grand institution of the local: i.e., the pub just up the way. Our works local was the Castlecary Inn, up the road from our location in Cumbernauld. Here I was introduced to a variety of ale……….mass-produced, cask-conditioned, real (this was during the heyday of CAMRA: CAMpaign for Real Ale) and the best of pub lunches: pie beans and chips, sausage egg and chips, chips beans and chips, chips chips and chips, etc.

Working in Santa Clara, I have begun to think of the Santa Clara Convention Centre, which is about a mile or so from Tensilica, as in some ways fulfilling the functions of a local, at least when there is a relevant conference going on there. They often have receptions at such conferences, usually on an exhibit floor, and there may well be some good food and beer on offer at these receptions. These receptions also meet some of the other criteria for a good pub: a chance to meet old friends and colleagues, to make new friends and colleagues, to get new gossip and possibly information, to swap stories, etc. It may lack the more intimate surroundings of a good pub, but still offer a fun experience.

Last week (March 31-April 3) there were two interesting and overlapping conferences at the Santa Clara Convention Centre: SNUG (the Synopsys User Group) and the MultiCore Expo. Both had a lot of interesting content and quite reasonable attendance. (Both also had good receptions!) But one interesting thing I noticed relates to ESL.

For many years, ESL has been talked about a bit like the Once and Future King: always on the horizon, never quite there, always promising, never being used. Of course, as I have commented on before, this may be partly due to your definition of ESL, and they do vary widely.

What I noticed in one session in SNUG, where Filip Thoen of Synopsys talked about a virtual platform case study, and in many sessions at the Multicore Expo, including the panel I was on talking about virtual platforms, was that the Existential question about ESL seems to have gone away…..at least, if your definition includes the use of system models and what are called ‘virtual platform’ models for architects and software developers. Richard Goering, who chaired the Multicore Expo panel on virtual platforms, asked the audience how many had or were using these kinds of models. I noticed about 15 hands go up. Although Richard in his article on SCDSource (http://www.scdsource.com/article.php?id=164) called that “only a handful”, from my perspective, that is a much bigger handful than it would have been a year ago, and I expect in another year that it will be two or more handfuls in such a venue.

In other words, I think we can stop debating the Existential questions about ESL: it exists, it is being used, and the real debate should be about the particular methods, tools, models and approaches that are most useful.

Funny what you can find out down at your local……………..

Hello, and welcome to my first blog post on the Chip Design website. Thanks for John Blyler and his colleagues for setting this up. For my first post, I want to talk a bit about whether ESL has standardised on one approach. As always, I welcome your comments! I hope to follow up this first post fairly regularly.

One aspect of the standard digital design flow that has developed over the last 20 years, and been supported by competing EDA design tools that in many ways are interoperable, is that the design process has converged to a common RTL to GDS II (and beyond) methodology that can be thought of as a shared design ‘ideology’. That is, there is a common belief system in what the methodology is, how it should work and how it should be improved.

When we turn to system level design, do we see any traces of a common design ideology emerging? I think the answer has to be no - not yet, and perhaps, never. When we look at ESL, we see at least five different categories of ESL tools, models and design flows - whose use depends on the type of systems being developed, the architectural choices being made, and indeed, the wishes and experience of the architects and developers involved in the project. These categories include:

• Algorithmic design
• Architectural design space exploration
• Virtual prototypes for embedded software development/validation
• Behavioural/high-level synthesis
• Processor/Multi-processor-centric design

let alone the classical categories of hardware-software codesign, and software specification, analysis and implementation.

Many commentators on ESL pick one of these categories and conflate it with the entire segment. For example, to some, ESL will never be “real” until RTL level designers have replaced their synthesis methodologies and tools with some kind of high-level or behavioural synthesis perhaps using C, C++ or SystemC as a specification language. All other kinds of ESL, including the now venerable algorithmic tools such as SPW, the Mathworks Matlab and Simulink, and research tools such as Ptolemy, are ignored by these commentators as not being true ‘design’ - even if they are widely used. Taking a narrow parochial view of what ESL is will condemn it to always being marginal.

Depending on the kind of system, some or all of these categories may be important. Developing a multiprocessor SoC using application-specific processors will emphasis processor-centric design flows and the concomitant software development flows, along with the use of virtual prototypes for validation. Developing new digital logic using behavioural synthesis may be unimportant for this type of design.

Thus, I wonder whether a common ESL design ideology will ever emerge. On the other hand, a 500 year old quote from Michel de Montaigne is perhaps appropriate:

“There were never in the world two opinions alike, any more than two hairs or two grains. Their most universal quality is diversity.”
Long live the diversity that makes system design such a fascinating topic!