Archive for January, 2009

This is the first part of a multi part series of Blog posts. There are simply too many misperceptions about virtual platforms out there. The most common ones are about speed, accuracy and development effort. I will comment on those in upcoming posts. However, some misperceptions are about the type of software development which virtual platforms support.

A recent article called “Unified Verification for Hardware and Embedded Software Developers” Lauro Rizatti of Eve talks about the advantages of hardware assisted verification. And I fully agree … hardware assisted verification is an important process in the design flow. That’s why Synopsys acquired Synplicity and, more recently, the ChipIt business unit of ProDesign. There is one important but infortunately common misperception in the article, which needs correction:

“In recent years, a new breed of tools, collectively called virtual prototyping platforms based on a high-level of design abstraction, have been introduced in an attempt to start software validation well ahead of silicon availability. While some may have achieved the scope of jump-starting software development, they only address application programs that do not require an accurate representation of the underling hardware design. They fall short when testing the interaction of the embedded software with hardware, such as firmware, device drivers, operating systems and diagnostics. For this testing, embedded software developers need an accurate model of the hardware to validate their code, while hardware designers need fairly complete software to fully validate their application specific integrated circuit (ASIC) or SoC.”

So we could mince words here and look at the wording as referring to the “testing” aspect only, i.e. separating the development of embedded software from its testing. Perhaps that is meant. However, that would not properly represent the importance of virtual platforms in pre-silicon software development. While there is no “physical” proof for one or the other side here, our experience of more than 60 commercial virtual platforms in active use and developed using Synopsys’ tools (Innovator), models (DesignWare System-Level Library) and services, shows the situation as completely reverse to the quoted statement. While there is some application development, the majority of the software development on virtual platforms is spent on firmware, device drivers, operating system porting and diagnostics. And that is not – as one could assume – on cycle accurate models, but on functionally accurate models with only essential timing, the type of models called loosely timed (LT) in SystemC. In contrast, application software is developed more often than not using completely hardware independent techniques, including cross compilation from the host development machine using development kits like Apple’s iPhone development kit.

As indicated in this figure, the software layers closer to the hardware essentially provide an efficient abstraction layer, which allows to provide middle ware functions like codec calls and APIs which make the application development completely independent from the hardware registers. As a matter of fact, in product families like TI’s OMAP, NXPs nExperia or ST’s Nomadik, the intermediate layers provide abstraction in a way that the applications can be re-used without modification because the layers between the application and the hardware can be updated when the underlying hardware changes.

More specifically, this figure illustrates the schematic representation of a Mobile Chipset Hardware and its associated software stacks. The typical development tasks we have seen are outlined in the following table for the application subsystem and the modem subsystem, respectively.

Some of this has been publicly documented by examples with Texas Instruments, Freescale and Marvell, in which these development tasks were actually finished prior to silicon being available and when RTL was finally available, the OSs had been ported and the bring up took days instead of weeks or months.

So, before this escalates into a “Lauro said vs. Frank said” battle, I am the first one to admit again, that hardware assisted verification is important as part of the design flow. However, virtual and hardware based approaches both stand in their own right contributing lots of value. As I recently wrote here, they are best used in hybrid use models, combining the best of virtual and hardware assisted worlds.

So I hope I busted the first virtual platform myth here given the public examples and the experience from the more than 60 virtual platforms. Speed, accuracy and development effort myths look out, I’ll get to you soon …

As always, comments are highly appreciated. I look forward to your thoughts and reports on your experiences.

Happy New Year! Are we really in 2009 already? It feels somewhat unreal … I started my pre-spring cleaning at home and found some old statistics which reminded me of a couple of posts on statistics I have seen recently in the Blogosphere. We probably all have heard of Mark Twain’s “Lies, damned lies and statistics”. My variation of it is my golden rule to only trust statistics which I had a chance to influence myself (there are probably more cynical ways of putting this).

Recently, Grant Martin was trying to bust a couple of myths related to numbers. First, Grant was taking on the “70% goes to verification” rule. He then was asking later for data to validate that the 80/20 rule is true for development as well, i.e. that 20% of the effort can determine 80% of the development properties, like power, cost etc.

Well, trust us Germans. Some of us measure everything. No, I won’t disclose my actual weight and height of 10 years ago, but one related item I ran across was a set of measured data as it relates to development efforts. It was created between 1991 and 1994 in four projects in the video encoding and decoding domain.

Anyway, at the time we – a team at the Technical University of Berlin working for the German Telekom on HDTV Motion Estimation chipsets – were also measuring very precisely our development efforts, i.e. which part of the development was taking up which effort. All this was driven by Christian von Reventlow, who wrote his Ph.D. thesis on the topic of complexity measurement for hardware development projects. I picked up some of his work later. The objective was to gather enough data to eventually find out which complexity measures correlate well with actual development efforts for hardware blocks. We came up with a hardware equivalent of the well know function points used in the software world.

So back to Grant’s question, at least for the verification piece I can offer some more hard data, albeit somewhat dated. This figure shows the effort distribution across four chip development projects. The first four elements are architecture definition, specification, RTL development and schematic entry. Yup, we are talking 1994, we did not use synthesis yet. After the bar we have the verification tasks, manual code inspections, validation by simulation and validation against a software reference (in only one chip). If we look at this as design vs. verification, then the verification effort even for these relatively small chips – they were all between 90K and 200K gates – was 54%, 44%, 46% and 45%.

Is 70% for verification out of the question? Not really. Scaling above data up to more complex designs can easily add 20%. In addition the data above was dominated by design and verification of the IP blocks itself. If one now takes into account the system integration, i.e. the connection of the IP blocks to make up a system or a system on chip, then verification of that integration will easily add some more verification complexity.

Bottom line this data seems to confirm that 70% effort for verification is a realistic number. My real interest today, however, lies on the software side. I better get on from here to proving that it is not a myth that increasingly the software development effort dominates the hardware development effort …

Let’s get 2009 started on a good note. Happy new year to everyone and I hope it will bring you what you are looking for.

By now, we all know that 2008 was a recession year and analysts are forecasting that it will continue into 2009. So, should we expect a bumpy year in general for people designing hardware and software? Most likely the answer is “yes.” But, I also believe that such years are a good platform for discussing and evaluating what needs to change. Hardware and software design should not be left out of this. A recent NPR report made me think about the opportunity these tough economic times provide.

The report was about recycling. With the economy slowing down and being in a recession, the demand for recyclable materials has been reduced and recyclable material is being stored in warehouses until the demand increases again. The point of the report that was interesting to me was not necessarily the recycling aspect, but the fact that the people interviewed were talking about how they needed to adapt and change the way things are done in this industry with one interviewee pointing out that an economic downturn was necessary to force the change.

So, does this apply to electronics (hardware and software) design? Why wouldn’t it? It absolutely should be the time for the industry to review and implement new design and development approaches. Traditional approaches using RTL and using physical hardware have reached their limitations, but without the pressing need to reduce costs due to high demand, the industry may not have felt compelled to strongly research and implement the required changes. Now is the time, multicore designs are creating havoc, cost reductions and doing more with less resources is pushing it forward.

Let me know what you think!