Und sie laufen! Nass und nässer               - And they’re running! Wet and wetter

wird’s im Saal und auf den Stufen, - get the stairs, the rooms, the hall!

Welch entsetzliches Gewässer! - What a deluge! What a flood!

Herr und Meister, hör’ mich rufen!   -   Lord and master, hear my call!

Ach, da kommt der Meister!   -   Ah, here comes the master!

Herr, die Not ist groß!   -   I have need of Thee!

Die ich rief, die Geister,   -   from the spirits that I called

werd’ ich nun nicht los.   -   Sir, deliver me!

From “Der Zauberlehrling”, Johann Wolfgang von Goethe, Translation by Brigitte Dubiel

Well, there is this moment in blogging when you review your post and your finger hesitates for a moment before clicking the submit button. When I wrote my last post there was, as always, that moment. And I actually did think of a valued colleague over at Cadence and how he would react.

I did not think that I would unleash - between us Trekkies - the “Wrath of Ran” :).

Punctually for halloween I now finally understand how the sourcerer’s apprentice in Goethe’s “Zauberlehrling” feels like (I took the picture from here). There is the famous line every German knows and cites: “Die ich rief die Geister werd’ ich nun nicht los”, “from the spirits that I called, Sir deliver me!”. In Goethe’s poem the apprentice unleashed something small and it got out of hand.

Well, that’s how I feel.

And before I move on and leave this overall topic and exchange of posts, let me state for the records that there was no intent in my last post to position any solution as the “universal” solution to early low power analysis. Also, for the record, I do respect Ran at Cadence as professional and colleague - we worked for a long time together. There was no personal attack intended here. I merely was admiring the elegant writing and mixing of two product offerings in a press release.

When discussing this matter with a friend, he pointed out rightfully so that both Ran’s and my post suffer from “Hammer and Nail-itis”. In fact, he pointed out, the combination of Cadence’s estimators (InCyte), C based synthesis, Palladium, and Synopsys virtual would be pretty powerful!It’s a good thing then that we acquired Synplicity which brought us Synplify high-level synthesis and Confirma FPGA Prototyping to Synopsys, and of course, that we have existing interfaces between our Virtual Platforms and Eve’s solutions.

So it looks like we all agree on a couple of things, especially that power analysis as early as possible is very important.

The flow Cadence suggests works pretty well and I have seen it at users being used. One remaining issue is how well the synthesized results correlate to the actual implementation later. I had analyzed this together with Eike Schmidt when we both were at ChipVision in a paper called “Towards Activity Based System Level Power Estimation” at the IP/SoC conference 2005. The energy consumption can be quite different based on the chosen micro-architecture during high level synthesis and even based on the stimulus.

This figure shows the deviation of energy consumption due to different input stimuli for a JPEG decoder created using high-level synthesis. Each column represents an RT architecture optimized to minimize the energy consumption when decoding the depicted data. The rows stand for the data used for estimating the power of that respective architecture. Results are given separately for logic and memory. The diagonal shows the relative energy consumption compared to the reference picture “White Noise”. The percentages in each column are measured relative to the column architecture as reference. An increase of up to 63% in energy consumption can be observed when operating the design (optimized for “constant grey) with different data then originally optimized for (”white noise”).

For architectural exploration of hardware blocks the suggest flow is a great flow. Too bad, that the original press release actually did not mention high-level synthesis at all

It remains the software side and the estimation of power caused by software.

It is not my place to dispel the misperceptions of virtual platforms articulated in Ran’s post. There are much better sources, like Bill Murray’s excellent article called “Virtual platforms - a reality check Part 1 and Part2“, the words of Texas Instruments and - sorry, Ran, I cannot resist - the words of Frescale, Cadence and Synopsys (Virtio) in “Parallel Software Development with Emulation and Simulation Tools for Mobile Extreme Convergence (MXC) Architectures”.Suffice it to say, virtual platforms do not take 9-12 month to develop, especially since SystemC TLM-2.0 APIs and our DesignWare System-Level Library make 100s of models available in a interoperable fashion.

On the contrary, today we are working with customers in projects for which the virtual platform is available for software development 8 month prior to RTL. And the accuracy of power data depends on the data plugged in. I outlined in detail in my presentation at ARM DevCon how this works. Developers use budget data, estimates (like the ones created from high level synthesis J) or data from previous projects. And the data can be refined once more detailed information is available during the design flow.

So in summary, I think Ran and I agree that early power estimation is important. Adding high-level synthesis makes a good flow. Our means are different but no solution is universal.

I had an epiphany while reading Eric Carle stories to my three year old daughter. And boy is she is smart! She figured out for me at her young age already the power of marketing in positioning high technology. Bottom line: What you read is not always what you will get once you buy it. But we already knew that, didn’t we?

Eric Carle’s books are great. There is his story of the Mixed-Up Chameleon and I read it to my three year old daughter the other day at bed time. It is about this chameleon who wants to be somebody else. So it asks for a bird’s wings, flamingo’s long legs, an elephant’s nose and a frog’s tongue etc. It’s a quite well done portrayal of wanting to be something or someone you are not. I have to admit that I was slightly distracted because my presentation for the ARM Developer’s Conference was (over)-due and I had planned to finish it that night. The topic I was to talk about was low power anaysis at the system-level.

During the day I had reviewed competitive announcements and was still thinking about an admirably marvelous, textually beautiful written press release claiming to now address “designers’ next critical need – faster power exploration and estimation - earlier in the product design lifecycle”. The products in question now would enable “SoC designers, architects and validation engineers to quickly estimate the power consumption of their system during the design phase, analyzing the effects of running various real software stacks and other real-world stimuli.” And there is more, the two products in question combined would “provide automated processes and capabilities early in the design process, taking in consideration the technology libraries, the embedded software and the real stimuli to ensure system power budget constraints are being met with the real environment at first silicon with first working software phase”. All of it provides the “unique ability to analyze and verify power tradeoffs at the point where hardware and software design converge – the system level”.

Well, all that is quite a mouthful. Can I counter that? I am a firm believer that going to the system-level is crucial, but why them? Sniff. That’s when my daughter’s question hit me:

“Papa, will the Chameleon’s new tongue for fly-catching work while it is flying with the bird’s wings”? It turns out, she was way ahead of me!

Let me roll back a bit … My talk at the ARM Developers Conference was titled “Software Driven Low Power Optimization for ARM Based Mobile Architectures”. It stems from discussions I had with customers and users for years now.

When users do system-level low power analysis, inevitably they will start with spreadsheets capturing high level information. Like in the design illustrated in this figure, which I analyzed in more detail using all the available datasheets a while ago, all the different components in the system have power consumptions associated with it. The same is true of course for the individual blocks in the various chips involved. The challenge with a spreadsheet is that it is static and does not execute any software stacks to actually trigger the many different power states such a design can be in.

Later in the design flow users will arrive at the RTL stage. Everything is now coded in the RTL mix of function and micro-architecture. Users can run analysis with logic synthesis and tools like Power Compiler. In an emulator or hardware prototype, RTL can be executed and software stacks can be run with it. Now the accuracy is much better and real software can run on the RTL given sufficient hardware support, but the ability to make trade-offs is very, very limited. The amount of effort it took to first write the RTL, to then verify it and even bring it up on hardware, altogether is so prohibitively expensive that in most cases fundamental architecture changes are hopeless at this point.

Bottom line, the issue articulated to me by users is that (1) spreadsheets unfortunately do not execute software and (2) when things are integrated at the RTL level all the important partitioning decisions are already made.

My talk at the ARM Developers Conference gave an overview how we at Synopsys address this issue using virtual platforms. In brief, we do allow users to enable virtual platform components for low power by exposing different power states. Different power states of CPU load as well as states for peripherals and even the actual energy consumption cost per memory write and read can be easily added in. During the execution of software the system switches through its different power states in all components and a central power accumulator combines this information into actual power and energy values. This level of power analysis and estimation positions itself well between the abstract, static spreadsheet and the RTL simulation at which actual power consumption can be measured. As outlined and in detail discussed in a whitepaper I wrote not too long ago, these virtual platforms are based on TLM-2.0 model re-use and developed from the textual specifications. As such they are available long before RTL or silicon are available, often as early as 9 to 12 month depending on the complexity of the design to be modeled.

At this point my three year old daughter – her eyes already almost closed – dozes off with the words “I think he cannot use his tongue to catch flies while he is flying with his wings”. While trying not to doze off myself … need to get that presentation done - I am happy and relieved that even beautiful writing cannot hide the three basic facts coming from all this.

• Static spreadsheets allow architecture trade-offs but only without software – which they simply don’t execute.
• RTL co-simulation with software is too late in the flow to allow meaningful architecture trade-offs. If you discover at this stage that the architecture has to be re-done to meet power envelopes, your career as project manager is at risk of coming to a potentially very abrupt and fast end.
• Power enabled virtual platforms are the way to go for early power analysis taking into account software. They are where hardware and software first meet. They can be done long enough before RTL to allow meaningful feedback into the architecture.

Well, who doesn’t believe in coincidence? First, I meet with CriticalBlue’s Skip Hovsmith and we have a interesting discussion about multi core software development practices (or lack thereof) and on the same day I run across Glenn Perry’s article “Art Imitating Life: Hardware Development Imitating Software Development“. It made me think again about which discipline is really ahead in technology and methodology - hardware design or software design? My answer once again is: It depends!

Skip Hovsmith has been a system-level expert for years. I met him actually back in 1998, when he was at National Semiconductor and he worked closely with Cadence on the Felix initiative, Cadence’s attempt at the time to crack the system-level tools market. Skip is now at CriticalBlue and heavily involved in the Multicore Assciation Best Practices working group. This working group is on a quite important mission, trying to define best practices around programming for multicore devices. This will be important going forward. My interest in that group stems from the need, to make sure our virtual platforms are modeled with enough fidelity to enable debug issues expressed at the multicore programming level. Example would be semaphores, where one best practice is to always call locks in the same order in order to avoid processes to lock up indefinitely. When discussing techniques how to enter software more efficiently, we ultimately arrived at UML and Skip’s comment struck me as perfectly correct: “UML is great to understand how things work [read: "to reason about things"] but once issues are understood programmers just get on with it and start hacking the code”. This goes back directly to my last post, in which I argued - besides other things - that a development phase only will find adoption if its output can be reused directly in the next.

Then I found Glenn Perry’s article “Art Imitating Life: Hardware Development Imitating Software Development“, in which he argues quite convincingly that software development is ahead because of technologies like object oriented programming. I am a true believer that hardware development has something to learn from software development. Hey, I even wrote articles like “Transferring software engineering methods to VLSI-design: a statistical approach” way back in 1994 as part of my never finished Ph.D. thesis (real life development projects got too interesting; bad excuse, I know).

However, I then went off and contacted people like Tom DeMarco and Fred Brooks, authors of the classic “The Mythical Man Month” and “No Silver Bullett“. I though they would be thrilled that somebody is trying to adopt function points from software engineering into the hardware world. Their response was interesting. “Why are you trying to do this? Isn’t hardware engineering perfect because you have a tape out and cannot fix issues with a new release of the software”.

That’s where these things tie together in my mind.  While I agree with Glenn that the technology in software engineering may be more advanced, for example around languages, I am certain that the required methodologies are fundamentally incompatible. The reason? In hardware engineering the project team always has the “Sword of Damocles” hanging over their head. Mess up the tape out and you will cost the company several millions in NRE (Non recurring engineering, or, “N”ever “R”eturn “E”ver). In addition you have to consider the lost product revenue because of the several months the project is now delaying production.

In contrast, in software engineering there is always service pack 2. The requirement to get everything right is not as deadly as it is in hardware engineering. And as a result of all that Skip Hovsmith is perfectly right - “Just get on with it” is unfortunately often the approach taken in software engineering. It looks to like things have to get a lot worse before this approach changes.

Looking at the design flow from the top, embedded software is a key part of the design flow. Customers I have been talking to vehemently agree. Recent IDC research even suggested a $1B market for “virtualized software development”. But why then is the market for embedded software still about 5 times smaller than the market for hardware electronic design automation? Is it the number of fundamental transformations which happen in hardware compared to seemingly simple compilation in the software world?

What caught my attention and caused this post is the recent IDC research quoted in a Virtutech press release arriving at a total available market of “just of $1B” for the playground in which Virtutech plays with Simics, Vast with Comet and Meteor, CoWare with Platform Architect, Synopsys with its Innovator Virtual Platforms and ARM with their System Generator product line. In the detailed quote Stephen D. Hendrick, group vice president for application development and deployment research, says that “Virtualized software development is an important advance in the development and maintenance of applications for electronic devices. There are a number of unique advantages specific to VSD when compared to traditional approaches that include faster time to market, cost-effective scalability, and more advanced diagnostics.” Well. I agree. And I love the total available market (TAM) predicted here.

However, it leaves me somewhat uneasy. Here is why. If I add up all the players in the so called software market I seem to arrive only at about $1B total. And this even includes UML tools like Rational Rose from Rational (now IBM), Telelogic Tau (now also IBM) and a good portion of the Mathworks with their Real Time Workshop solutions for embedded software development.

In contrast the EDA market easily can be summed up to be between $4B and $5B, just by adding up the major players Synopsys, Cadence, Mentor Graphics and Magma.

So why is that, especially in light of more and more importance being assigned to software development? What about the seemingly universal desire to advance it in the design flow to a stage as early as possible? Well, let me try an explanation.

Going back to the abstractions which I had talked about earlier, this graphic here shows a very basic design flow in the center. Starting from a system specification - which may be executable in some language like C or C++ or may use techniques like UML - there are really three different flows. First, on the left, there is the development of hardware blocks. This includes dedicated hardware blocks on the chip, processors, on chip accelerators etc. The chip integration portion is taking the different blocks and assembling them, typically adding communication structures like busses etc. The result of that flow is the actual chip, which then in exchange is integrated with other chips on the board creating the end product - our phone, PDA or media player. The third column is the software development, resulting in the software which runs on the chips used on the board.

The columns to the left and right indicate the abstraction or design entry levels starting from the transaction level (TLM), through register transfer level (RTL), gates, transistors and then finally to the layout for the chip. The final “transformation” created the board layout with integrated chips. On the software side we only find one major transformation - from a high-level description into the assembler / binary code which is then executed on the processor. Each major transformation on the hardware implementation path represents in itself quite a healthy market. On the software side only one major transformation happens from a high level language into implementation code. The software market size has a comparable order of magnitude as the hardware markets. The market numbers indicated in the graph I loosely derived from a DAC presentation I saw Daya Nadamuni give in 2006 - at that time she was with Dataquest. She very convincingly argued at the time that the RTL market was about 4x bigger than the market for gate-level tools, brightening up the outlook for the ESL and related Embedded Software markets.

So where is the money now? Well, there is the next level up, the notion of system specification which in its essence is independent from hardware and software implementations. Here is where a recent dinner in London with Allan Kennedy comes in. Allan is CEO of Kennedy Carter, a pioneer of executable UML products. Albeit slightly liquored up, we did eventually arrive at the conclusion that one key component in the hardware flow is its “seamlessness”. The output of each implementation phase is directly used as input into the next. In the software world that process is just entering mainstream in some application markets. Allan identified three major areas of UML usage - the use model of “sketches”, graphically outlining the intent of functionality, the “blueprint” use model in which the actual software architecture is described but its implementation is still unknown and then the “executable” use model in which an action semantic is added to UML and with model generators the xUML entry can be directly mapped into target implementations. It is this third use model, which directly links the output of the xUML specification phase into implementation, where I am very optimistic about significant market growths beyond the current markets. Once directly linked into the implementation flow, model investment at that level becomes safe and re-usable.

Ah yes, this of course assumes that somebody is willing to pay reasonable prices for tools in that market. Just like in the market of “virtualized software development”, tool vendors like us are facing the issue that the end user species of software developers is in numbers found about 10x as often as hardware designers but also has price expectations at least ten times smaller than the traditional hardware developers in the EDA world are used to.

Well, but that obstacle aside, it looks like there is plenty of room to grow upwards beyond the current abstraction levels and I do not need to worry to run out of them …

Some of the fruits of the Project Sydney are finally be available with the official announcement of the not so well hidden behavioral synthesis project Cadence ran for a while. The resulting C2S (C to Silicon Compiler) product has been written about by Richard Goering at SCD Source and Ron Wilson at EDN, a more thoughtful analysis on the “Return of the Prodigal Son”, in this case called ESL, has been published in Grant Martin’s Blog.

Given the various attempts on introducing behavioral synthesis in the past, I am wondering whether I could have used it as a designer when I was still actively developing chips. As pointed out in the above mentioned commentary, behavioral synthesis is today focused on the block level. The last chip development I was involved in - before moving over to the dark side of technical product management - was an integrated Video/audio/transport Decoder. My team was focused on some of the video, audio and transport IP components used in the MB87L2250 - MPEG2 Transport, Video and Audio Decoder with integrated 32-Bit RISC CPU, I include a block diagram here as well. This SoC has at its core blocks for transport, descrambling, video and audio decoding as well as some graphics capabilities. These are connected via a complex memory interface to SDRAM to shuffle data back and forth. In addition one finds less complex peripherals like an I2C interface, an IC card interface and an IR Receiver. For software control the chip has an built in ARC RISC core to run drivers and management software, alternatively the chip can also via an Host Interface to an external SPARCLite CPU.

How would I design and develop this one today? Well, several of the main blocks can be purchased as pre developer IP today. Definitely for the connectivity IP and peripherals like I2C and USB I would go to my favorite IP Provider, buy them and integrate them into the design. The RISC core I can buy from my favorite processor provider. Some of the blocks I will have to develop from scratch. Once I have all the blocks developed then I need to integrate them.

This means, that my “spec to implementation” problem can be partitioned into the two independent paths of implementing the “Chip Topology and Interconnect” and implementing the “Block Functionality”.

Let’s start with the former.

For the chip topology and interconnect this graph shows the different categories of implementation options.  At the far end of the spectrum as developer I could code all interconnect by hand. I could keep it complete flexible at the other end of the spectrum, using a completely flexible, programmable switch to which I connect all data producing units. I could use automation for the assembly using SPIRIT IP-XACT based graphical tools, often offering some level of automation in the actual bus assembly itself. Next up, remembering the challenges in designing the memory interface - balancing 15+ streams with different rates and latency requirements - I would definitely consider an automated approach available today from Sonics and Arteris. Between the synthesized interconnect and the fully porgrammable NoC router I would position mesh-networks like you can find on Intel’s 80core or Tilera’s 64 core chip. They allow flexible packet rouiting between homogeneously arranged cores.

Bottom line though I am facing at least five fundamentally different implementation choices, some of them more automated than others, some of them offering more flexibility than others.

And it gets worse.

When I look at the implementation of the block functionality itself, I am facing seven categories as indicated in this graph. Starting again with the far ends of the spectrum, one can just bite the bullet and manually implement the block using RTL. Also, for ultimate flexibility one can decide to implement the functionality manually in software. Today, in 2008, I would expect still the majority of all blocks to be implemented that way.

Working my way backwards from full flexibility in software, some of that software implementation can be automated from higher level models. The Mathworks RTW and xUML implementation tools like Rational Rose or Kennedy Carter’s xUML play in this domain. Once you have decided on a processor, there are offerings like CriticalBlue’s Cascade, allowing you to create a custom co-processor based on the performance aspects of your software. You can buy tools to create your own Application Specific Instruction Processors (ASIP) from a functional specification (Target Compiler, CoWare) and then write software for it. As another alternative you can buy ASIPs in an IP play (ARC, Tensilica), again creating the ASIP from a functional specification. Classical behavioral synthesis is the automated version of getting from a high level description to RTL. Players and products in this field today include - in no particular order or ranking - Mentor Catapult, Forte Cynthesizer, BlueSpec, NEC Cyber, Synopsys Synplify DSP, Synfora PICO, CebaTech C2R, Mathworks HDL Coder, ChipVision PowerOpt and now Cadence C2S.

Bottom line:

As a user I have to choose from five implementation choices for the topology and interconnect. I also have 7 options to implement the blocks itself. And this is where market fragmentation becomes an issue. Given these options, arranged nicely in 35 permutations, behavioral synthesis is one option in a fairly fragmented “Function to Implementation” market. That to me explains nicely while in overall numbers this market has been pretty small so far. It would be much more significant if we redefine it as the “Function to Implementation” market.

Nevertheless, its importance should not be underestimated in significance as it opens. Some users like STMicroelectronics, reported at DAC this year during a panel that in some divisions for 90% of their newly developed IP blocks behavioral synthesis is used. More importantly it gets us closer to the next abstraction level as a true design entry and has other use models as well, like an automated path of designs into rapid prototyping for instance.

This space is worth watching!

Teach your children well,
Their father’s hell did slowly go by,
And feed them on your dreams
The one they picked, the one you’ll know by.

Crosby Stills Nash & Young

Besides that I like the old Crosby, Stills, Nash & Young song a lot, the thoughts on this post had to settle a while for me. Hence this is DAC related although it seems quite a while ago already.

On my last day at DAC I took some time off from my own DAC duties and watched the key note of Jack Little, president and co-founder of The MathWorks. His keynote address was titled “Idea to Implementation: A Difference Perspective on System Design” and he discussed the use of Model-Based Design to solve the growing challenges of electronic systems and embedded software development.

He opened his address with a story of the little village called Mathville (well, it looked a bit like Natick to me J), which was disconnected from the tangential highway right next to it. No exit. No profit from traffic potentially coming to them.

Jack then talked about Engineering Math, linear algebra, static relationships, differential equations - continuous and discrete time - and asked what they have in common. Well, they all are ubiquitous and used across various industries, professions and applications. Let’s teach your children math to be prepared … and computers enable widespread use of Math. A fascinating graph he used is shown here, in which the progression of computer performance is shown since the 1984 breakthrough introduction of personal computers. The data speaks for itself.

The problems with current development flows were nicely illustrated with Flight 501 of Ariane 5, which impressively failed because the control of the nozzle control failed due to mapping the original floating point data to 16bit integer and causing an arithmetic overflow. As a solution Jack introduced model based design with automatic code generation.

At this point I realized that I have not a good enough understanding what model based design is. Is it just graphics on top of the code users write? Does there has to be a large library of models enabling re-use? Are the different levels of models? It looks like all of the above. When searching around I found in an article authored by the Mathworks the following description:

 “Model-Based Design [enables] a hierarchical design process in which the entire design is initially defined at a conceptual level and detail is added as necessary to deliver the needed functionality. The model is used to define specifications, evaluate design and system performance, automatically generate code, perform hardware-in-the-loop testing, and create a software-based test harness for testing production hardware. This approach can substantially reduce development time by rapidly leading to complete and functional proof-of-concept designs and enabling rapid design iterations and parameter optimization through a unified design, simulation, and test environment.”

This sounds very much like different levels of abstraction again, adding detail where necessary. The results presented in Jack Little’s key note are quite impressive. He showed how models are used to automatically generate 1,000,000 lines of code by Honeywell for airplane flight control systems, as well as how Toyota and Visteon automatically generate code which is more compact than hand coded software in automotive applications. Equally important, because of the coding phase going away, Toyota Denso was able to significantly shorten time to market as the graph on the left shows nicely. They expect even further improvement because of the impact of model based design on verification.

That all said - with impressive results in model based software design - Jack brought the Mathville introduction nicely home at the end by outlining that Mathville is now also connected to the hardware world via a direct exit to the “EDA highway”. This of course is an area in which Synopsys already plays for quite some time with our System Studio product for model based design of digital signal processing algorithms. For the model based implementation of algorithms of that type tools like Synplify DSP® can be used.

In closing - I had further discussions about model based design with our Synopsys Fellow Mike Keating and he had an interesting perspective on the use of graphical representations. He argues that because textual entry is one-dimensional in contrast to two dimensional graphical entry, it is easier to enter data as text and to reason about it using the graphical representation. I fully can relate to that view. When doing code reviews way back when I was designing chips, I always re-constructed graphical state charts from textual Verilog to be able to reason about the functionality of the state machine. However, model based design seems to also take into account the refinement process of adding more detail to an originally more abstract diagram.

So my conclusion for now is that in refinement from one abstraction level to the next more detailed one, graphical refinement will work fine. However, when being at a specific abstraction level, textual entry using an expressive language is more elegant than graphical design entry.

Does this make sense? I am looking forward to your thoughts and comments!

Happy post 4^th of July. Even though I am only a German observer, I did enjoy the fireworks! The last two weeks have been interesting to say the least. After the Freescale Technology Forum I immediately left for a trip San Francisco - Tokyo - Bali - Tokyo - Frankfurt - Hamburg - Berlin - Frankfurt - Tokyo - San Francisco, all in 10 days. Our mid-year sales update took place in Bali (I know, your sympathy is gone by now) and the trip to Germany was to attend my Dad’s 70^th birthday. Both events gave me enough opportunity to try to explain in Laymen’s Terms what my job and system-level design is all about. While lost between two buildings in the hotel resort in Bali I had the idea to explain it in hotel terms. Here it goes:

Assume you are the hotel business on Bali (As a disclaimer - I am not - I just enjoyed staying here for our sales training and have no connection to Hyatt). Life is good and you are planning a new hotel location. The terrain has been defined and the deal looks good. Here are two drawings of the hotel I stayed in while on Bali. One is high level structural and one is more detailed. With which one would you start your planning?

Right, in the higher level of abstraction of the structural diagram it is much easier to define the intent of the hotel plan without getting caught up in the details. At this level you have defined that you need four living complexes with a specific number of rooms. You need a spa, a pool area, a conference center, shops and restaurants and finally administrative buildings, parking and sports facilities. You define the different main hotel units and their interfaces. This is exactly what the system-level designer does for chip design, he defines the big blocks, some of which the implementation team buys as pre-defined units (Intellectual Property - IP) and some of which the team then implements from scratch. In our virtual hotel planning exercise we have constraints like “that many people will have to go to breakfast between 7am and 10am, we better have appropriate pathways to help them transfer”. Chip designers face similar issues, they have to understand the dimensions of data traffic going on between different blocks and make sure the appropriate connections or bus-systems are available.  

So it is all about the different units in the system and the interfaces between them!

What is interesting now is when a different abstraction levels are required, i.e. when a developer naturally switches to the next level of abstraction. What is defined in our Bali hotel exercise in about 12 blocks and some constraints, takes at the next level down at least 120 lines to draw. So there is roughly a factor of about 10 somewhere in here to allow entering the information in an abstracted way.

Synopsys fellow Mike Keating of the Advanced Technology Group pointed to that same factor 10 in a presentation given at the most recent Design Automation Conference 2008 titled “Simplicity and Complexity - The challenges of human-centric design in the era of billion gate SoC’s“. The EDA industry has successfully built tools to automate the transfer between abstraction levels sufficiently. This is also in sync with a basic paper from 1956 “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information“, in which George A. Miller successfully shows data that the human brains is simply not able to process more that 5 to 9 things at once, so abstracting upwards when one reaches ten makes sense.

Take away from all this is twofold. First, it is crucial to find the right level of design entry and that is what system-level design is all about. With the next abstraction level, the transaction-level, the EDA industry is in the midst of a transformation, but we are probably still in the beginning stages for mainstream automated design from the transaction level. Second, given that this is the 7^th paragraph of this post I better stop so that you have a chance to remember them. And yes, the Grand Hyatt Bali as shown here is worth the trip and I enjoyed it very much. I just made the mistake to be there only two days for work … next time I’ll stay longer.

During the technical keynote at the Freescale Technology Forum (FTF), Freescale’s CTO Lisa Su (or “Chief Geek” as she called herself) painted a vision of “Tomorrowland”. The “Jetson’s” lifestyle of connectivity and availability of pretty much everything on demand will be enabled by embedded intelligence using “behind the scenes” embedded systems. The key innovations to get us there will be hyper-integration, multiprocessing and software. Lisa Su called for a strong semiconductor and system-level ecosystem as the key enabler, stating that “we all have pieces of the puzzle” and need to collaborate.

FTF’s location Orlando seemed this June for me with my German roots to be like an uncomfortably hot assembly of amusement parks, hotels and conference centers loosely connected by swamps. Inspired by the theme parks Lisa Su opened her keynote with the music of “The Jetson’s” TV series. She cited as examples for a revolution in embedded intelligence RFID technology, OnStar and our beloved cell phones. These devices collect information, process it and connect with each other, often behind the scenes even without us knowing. With miniaturization she quite convincingly predicted 1000 embedded devices per person in 2015.

Lisa Su translated the effects of the three themes introduced by Rich Beyer the day before - “Going Green”, “Health and Safety” and “The Net Effect” - into “Sustainability”, “Wellness” and “The Invisible Network”. Required sustainability of distributed renewable energy sources will cause revolutionary changes in energy generation, its localization and distribution. Wellness will be enabled by “Telemedicine” allowing remote monitoring and even remote surgery. Explaining how the power of the network comes true especially when it is invisible, Lisa Su happily admitted how her Mom beat her to owning a Blackberry and now sometimes ignores her while checking email J She continued to paint a picture of the “Tomorrowland” amusement park in which we wirelessly can get information which rides have the shortest lines and which of our friends are also in the park without us knowing.

From my system-level perspective I was most interested in the key enablers mentioned during Lisa Su’s keynote. She called the first innovation “Hyper -integration”, which in her view needs to become an enabling technology at reasonable cost. With Hyper-integration systems are assembled from sensors, control and a combination of software and processors.

Multiprocessing was stated as the second key innovation. Starting from secure MP platforms like Freescale’s recently introduced QorIQ communications platform, Lisa Su foresees in 2015 massively parallel processing enabled by 22nm technology.

The third key enabling innovation - Software - could have been mentioned first. Lisa Su called for open APIs, OSs and interoperability enabling seamless integration of software and efficient re-compilation to different hardware platforms. Today’s run-time platforms will evolve into common software environments with code re-use. Concurrent development of hardware and software will be critical and the hiring of software expertise is today already one of the highest priorities.

In closing Lisa Su mentioned that the innovation and enablement for next generation electronics is “just at the beginning”. As successful example of incubation and innovation she pointed to Freescale’s ZigBee activities. A healthy ecosystem will be required to get us there, given that “we all have pieces of the puzzle”.

Not downplaying the importance which semiconductors play in all this, it was most impressive to me how consistently Freescale stressed the system-level aspects and collaboration issues. As an industry we cannot enable next generation electronics without substantial increases in design productivity using system-level methodologies, models and tools. And we will need to cover a broad spectrum here, from helping digital signal processing design teams to assess how their algorithms fit into systems to virtual platforms enabling collaboration between companies in the design chain ecosystem to more efficient software development and re-use.

We indeed do live in interesting times from a system-level perspective. I for one am happy to be here!

I am at the Freescale Technology Forum (FTF) here in Orlando this week, where we are demonstrating our virtual platform of Freescale’s i.MX31 application processor. Freescale’s CEO Rich Beyer kicked of the conference with a quite impressive display of demos and partnerships with the three themes “Going Green”, “Health and Safety” and “The Net Effect”. It was very clear how system-level aspects are crucial to Freescale’s success and in many instances that knowledge is shared between Freescale and key partners. Rich Beyer made it clear that software is just as important to their success as is the chip itself.

The first demo showed the adoption of wireless technologies in industrial automation. Wireless technology is mostly used for data transmission here - including video. My respect to the demonstrator, on whom the demo setup played a trick and caused him to have to re-synchronize his setup in what Rich called a diving catch in front of an audience of 100’s . Well done. In the area of health Freescale called a partner on stage, who demonstrated a belt for mobile EKG analysis using embedded processing based on the Coldfire technology.

My personal highlight was a demonstration of HDTV transmission using Long Term Evolution (LTE) next generation wireless by Tom Deitrich. He showed nicely how mobile communication evolves beyond voice services and how the 50x faster transmission rates of LTE can be used to carry video. The technology from Freescale will be ready in 2009 for field trials with deployment shortly thereafter. Tom cited power consumption and integration as the key differentiators.

Together with Sue Bostrom of Cisco, Rich Beyer then demonstrated (at 6:55am her time in California) the Cisco TelePresence system. This fit both the green and connected themes and Sue Bostrom mentioned how they have already saved $150M in travel cost and with that reduced Cisco’s carbon footprint with the equivalent of taking 8000 cars off the streets for a year.

Finally Lynelle McKay introduced with great fanfare as “path to multicore” Freescale’s QorIQ communication platform. The software aspects were crucial in this context and Lynelle especially pointed out how virtualization technology enabled their partners to do early software development.

In summary a quite impressive display of technology! The key take away for me was again that traditional chip providers like Freescale are going well beyond the chip now and need the software and system to work right for them to be successful. Collaboration with system partners is crucial and the technology to efficiently interact - for example by way of virtual platforms - is a key enabler of such collaboration.

On Wednesday Mentor hosted its 6th Annual ESL Symposium here at DAC. The panel gave a great overview of the ESL space. ESL Synthesis and Virtual Platforms for pre-silicon software development seemed to come out as the two areas of ESL with the most adoption so far.

Wally Rhines opened the panel and reminded the audience that this market has grown from $70M in 2000 to over $200M in 2007 according to EDAC data, i.e. data which the EDA vendors actually report. So, while we were not looking the market has actually grown to over $200M already.

According to survey data cited, 70% use high level synthesis and 23% use TLM based verification. The main drivers are (a) Design Complexity with 16% of designs using more than 3 processors, 11% having more than 21 clock domains and 22% more than 10MGates of logic and data path, (b) Verification with 60% of re-spins have functional causes, (c) low power and high performance and finally (d) time to market.

Wally added that originally the ESL investments were in modeling, system analysis for performance and virtual prototyping. Now ESL models can also be re-used in TLM verification and ESL synthesis. Low power was quoted by Wally as “probably the biggest driver”.

First panelist to present was Viraphol Chaiyakul, Senior Director of Engineering in the QCT SoC Platform group. He gave a snapshot of the ESL adoption at Qualcomm. They differentiate verification, analysis and design. In verification Qualcomm already uses TLM-based hardware functional verification, software driven verification and early software validation. Model sharing and reuse by way of standards is next – they will adopt SystemC TLM-2.0.

In analysis Qualcomm does a lot of non-functional, traffic based trade off analysis and estimation. Going forward they need tools to allow quantification and definition of model accuracy and fidelity. They also propose a meet-in-the middle approach for modeling combining characterization and estimation.

The design area today uses block synthesis and simulation platforms for hardware software co-development. The key challenges are to make the ESL models golden, to verify the ESL models and to measure the quality of results. Going forward they look for synthesizable and verifiable TLM-2.0 flows.

Next up on the panel they had Prakash Rashinkar, Director of Engineering at Rambus. He talked about performance analysis for memory technologies. He introduced memory as the bottleneck with the skyrocketing data rates for memory accesses combined with advanced access and protocol techniques. ESL performance models are used at Rambus to design and validate complex access protocols. Prakash also pointed to SystemC TLM-2.0 as an important step. In summary for Rambus ESL is a key step to unleash XDR performance, it supports top down design, which in turn is accelerating time to market and enables re-sue of test environment for verification. ESL is a must have technology for them.

Kaz Yoshinaga, Researcher at STARC, was up next and he pointed to interoperability issues of transactions between vendors and the resulting importance of standards. Based on OSCI and additional application standards STARC introduced a transaction-level modeling guide separating communication from computation including a refinement path from un-timed to timed models. They confirmed that the models can be imported into major system-level tools. Transaction-level design is a common ground for successful methodologies. The first edition of the STARC guide is available and will be upgraded to support TLM-2.0 in early 2009.

Nitin Chawla, Senior Member of Technical Staff at ST followed as the next panelist. He focused in ESL synthesis. In their SoCs the application engines like video codecs and wireless modems create most of the differentiation. They start with C/C++ models and use high level synthesis to automatically create the RTL which they validate using simulation technologies. Next generation sequential equivalence checking will increase confidence for them. Design productivity improvements can be 5x compared to RTL. Combined with high-level model reuse they can reach about 10x productivity improvements. He called for better memory analysis and trade-offs to be able to explore a bigger design space. ESL synthesis is reality for ST, have done a large number of production designs. Key benefits are productivity flexibility and improved QoR.

Final speaker was Bernard Candaele, department head of SoC, IC & EDA at Thales. He introduced their project focus on high complexity system developments like the Galileo satellite navigation systems. They have several candidate platforms and use early software execution on virtualized platforms. In addition they are using ESL synthesis in some of their designs. The next challenge will be the maturation of tools and links to verification. Bernard mentioned a debate between HDL designers and ESL engineers as the methodology shift has impact on the design population.

Bottom line ESL synthesis and virtual platforms, combined with some performance analysis were the main drivers outlined among the panelists. The following discussion was largely moderated by Wally. The biggest factors to drive towards ESL adoption cited were management of design complexity, productivity and time to market pressures. For Prakash at Rambus the ESL performance models enable education of customers and even sales support. SystemC was quoted as the biggest advancement in EDA to make ESL possible. All panelists confirmed that SystemC TLM-2.0 is an essential step and ready for adoption right now.

In summary this panel gave a good update on the different areas of ESL usage – it is here today! ST pointed out that in some of their divisions 90% of the new IP blocks are now designed with high-level synthesis! SystemC TLM-2.0 came out as the unquestioned next important step at the transaction level – both for hardware verification and virtual platforms enabling software development and verification. Key challenge going forward will be verification of ESL models themselves to make them golden.