Archive for 2010

It’s Christmas time. My yearly cookie baking event has been canceled this year due to a broken oven and delays in my house remodeling project. Thinking of recipes, it turns out that one of the missing items preventing adoption of system-level design is the absence of a canonical system-level flow, a pre-defined recipe how to get from an idea to hardware and software implementation. We are getting closer, but every customer I talk to has their own different system-level flow, which prevents scalability. As an added bonus for reading I will publish my favorite Christmas Cookie Recipe at the end of the post.

Flows are an interesting thing. From RTL to Implementation we now have arrived at a state that there are canonical flows. They can be automated. Users are automating them and they are generic enough that EDA companies help to automate them too, like in the case of the Lynx Design System. Are we there yet for system-level design? Not quite. Do we know the ingredients and part of the recipe? Absolutely!

Here is a simple flow diagram to go from “Idea” to “Product”. The first step is to figure out the architecture and the partitioning of hardware and software. As indicated in my previous post on Application Driven Design, in some application segments like wireless (iPads, iPhones, Droids etc.) software is king and the hardware is largely designed to optimize its execution. Still, defining a properly partitioned isn’t trivial. Ingredients for success are trace based analysis and models of the “system-to-be” which are independent from implementation. As an output of this phase we get specifications for hardware, software and their integration. These specifications can be executable, i.e. for the blocks this may be C code or graphical representations as used in model based design.

The hardware design phase is pretty well understood, especially once we have RTL. It’s lynxable so to speak. From the hardware specification the flow is all about blocks. There are various ways to get them, the two main categories are to reuse them or to implement them as differentiated blocks. That can be done by hand, as configurable processor, as custom coprocessor or via high-level synthesis. All these techniques have different advantages, but it is hard to completely automate the block creation flow. There is no pre-defined recipe.

Then the hardware and the software have to be integrated. First, the various hardware blocks need to be integrated. At the transaction level the integration can be used to create virtual prototypes to enable first interaction with the software. Once RTL is available, hardware based prototypes – FPGA based or Emulation – can be used, again enabling software execution. As part of the architecture exploration phase the interdependence of the block hopefully has been analyzed. The RTL can now be integrated and assembled, and finally be fed into the “lynxable” hardware implementation flow.

Now that I have written this it does not sound all that bad. However, only the ingredients are pretty clear, users will need “Block Design” with high-level synthesis and processor design, “Block Reuse” based on IP libraries, “Architecture Design” at the transaction-level and “Prototyping” using virtual and FPGA  prototypes. The recipe though, i.e. how they connect and how they are assembled within a flow, highly depends on application domains and individual customers.

When will we get there? There is hope. First incarnations of ESL flows are emerging, like the TSMC ESL Reference Flow. Once the ESL flows get to a state that we can create something like a Lynx Design System for them, we will know that we have passed this hurdle for adoption!

A recipe that always works: Nutty Christmas Cookies

And now to my favorite Christmas Cookie. Every year since my daughter has been two years old, the “Annual Schirrmeister Christmas Baking” takes place on the fourth Sunday before Christmas, in Germany we call it “1st Advent”. This year it has been canceled due to a broken oven, but just imagine 10+ kids unleashed on hand-prepared cookie dough. While the kids are more into shapes and sprinkles, the following cookie has become the universal favorite amongst friends and family. Enjoy!

Ingredients:

• 375 g ground hazelnut (Trader Joe’s has a good selection)
• 125 g ground almonds (Trader Joe’s has a good selection)
• 500 g powdered sugar
• 2 eggs
• 1 egg yolk
• 1 pinch of salt
• 1 tablespoon sale
• 1 tablespoon flower
• 1/2 lemon, juiced
• 1 tablespoon water
• 1 pack of Dr. Oetker Vanilla Sugar (carried at Cost Plus, don’t ask, it’s a German thing …). This may be replaced by a couple of drops of vanilla concentrate but I have never tried that.

Recipe:

• Mix ingredients in a big bowl using a mixer, the hook works best. At the end it is best to finish the dough off with your hands to mix it completely. The dough needs to be evenly mixed, use flower as appropriate while kneading.
• Roll out or flatten the dough finger-thick and cut it into long 1in wide stripes and cut into 1in x 1in squares or 1in x 1.5in rectangles.
• Pinch crosses with the back of a knife into the top of the cookie.
• Distribute the pieces on cooking sheets and bake in pre-heated oven at 200 C / 392 F for 15 minutes. Keep distance! They should remain at light color.
• Cookies have to be taken off fast and while they are warm a mixture of vanilla-sugar and lemon needs to be applied using a brush immediately. For the lemon mixture use100g of powdered sugar and mix it with 1 pack of Dr. Oetker Vanilla Sugar, the lemon juice and a tablespoon of water. Mix it in a way that it can be applied using a brush.
• The cookies should be kept in air-tight boxes so that they do not dry out and stay moist. In order to keep their moistness, an wedge of apple in paper can be put into the box with the cookies. But no worries, they won’t last long anyway …

Happy Holidays!

With the year coming to an end faster than I really can comprehend (have you started on your Christmas wish list yet?), I am looking back to what I said would be important going into 2010.  In my Electronic Design column’s forecast “2010 Will Change The Balance In Verification” i suggested that software development would change how verification is done. Well, looking back I can confirm that this is happening, albeit not only the way I had suggested.

I have previously quoted Janick Bergeron, my fellow blogging colleague on verification, that the “solution to the verification problem lies in the design process”. 2010 validates for me that this is really becoming a reality. Simply put, design is changing and one of the main reasons is verification. To enable successful chip and system design while also enabling the different participants in the design chain from IP providers through semiconductor vendors, Integrators to OEM, three components are required. Developers need to be enabled to

• re-use as many blocks for chip design as possible and have tools to create new, differentiating blocks as fast as possible
• assess whether the integration of blocks  (new and re-used) will work correctly when integrated
• prototype the “chip to be” for early software development, hardware-software integration and verification

The last item is successfully addressed today by virtual platforms and FPGA prototypes, depending at which point of the design flow the project team or their customers decides to require enablement for software developers and verification. The integration aspect is addressed by IP-XACT based tools at the RT-Level (for RTL assembly) and architecture design tools at the transaction-level (to understand bus bandwidth, impact of software mappings into multiple processors etc.). To efficiently enable blocks we have a striving Implementation IP licensing market and various tool options for high-level block design and synthesis, which brings me back to the topic of verification.

The main reason for high-level design of blocks is not a faster path to implementation, better coding efficiency or re-use and connections to system-level models. The main reason for high-level design of blocks is verification!

I have used the picture on the left in a previous post on high-level synthesis already. It shows the various options a user has to implement a block once the idea for a the block is born. The options range from dedicated hardware implementation – read “inflexible” – to full software implementation – ready “flexible”. There are various grades of flexibility in-between.

Especially in consumer applications flexibility has become a key issue today. In order to meet changing standards and to be able to support different versions of algorithms with the the same intent (like en- and de-coding video or audio), mixed hardware/software implementations are very attractive. Two of the implementation options have profound impact on verification and a re worth to be singled out as verification actually seems to be the most important driver for their adoption:

• High-Level Synthesis (HLS) for fixed hardware blocks is on a path to real adoption, especially for data-path oriented designs, but also for control. Besides the advantage of getting to the actual implementation faster, verification also changes and makes HLS attractive. The basic idea is that more verification can be done at higher-levels of abstraction, i.e. TLM, and then the implementation path is automated. This is the same reason why the industry switched for digital design from gate-level design to RT-level design quite some time ago. In my first project I entered the blocks of an FFT chip at the gate-level, but already verified them in RTL. If logic synthesis would have existed the way it does today, I would have not even touched the gate-level.
• High-Level Synthesis for custom processors has emerged as an attractive option to get from idea to implementation. Flexibility of the implementation is key here. In contrast to a fixed hardware block and its high-level synthesis, the main functionality runs in software on a custom processor, which is automatically synthesized from a high-level architecture description language. This is a great approach to address the implementation of standards which have not been finalized yet as well as implementation of algorithms which are similar in nature (like different video standards). It turns out that verification is an even bigger motivator to adopt this approach because it eliminates the fundamental shortcoming of having to verify hardware blocks: Prior to taping out the design for ASIC implementation, the design’s functionality has to be verified in full using hardware oriented test-benches, which include for a video algorithm for example all variations of bit-rates, frame sizes etc. Custom processors, or Application Specific Instruction Processors (ASIPs) offer a very unique, fundamentally different alternative for verification. Given that the actual functionality – which drives the majority of the verification effort – is actually not implemented in hardware but has moved into software, now the correctness of the custom processor hardware itself can be verified independent of the function it executes. As a result of this separation of structural and functional verification, they also can be separated in time. Specifically, once the actual correctness of the custom processor execution is verified, the implementation can proceed and functional verification can be done fully in parallel using software.

Well, all this happened faster in 2010 as I had expected and is really driven by verification. To close this post and to come back to my original 2010 prediction on verification, I was correct in principle with my prediction. We have more customers using embedded software and directed tests written software for verification of hardware blocks. It is now the second most adopted use model for virtual prototypes (besides early software development). The adoption of high-level design for blocks – custom processors and fixed hardware alike – is further changing the verification dynamic, especially for block verification.

It will be interesting to see how this will play out in 2011. Interesting times!

Now that I am back from honeymoon, the obligatory post-honeymoon-email-catch-up-marathon and then some business travel, I find myself in lots of discussions around application domains and the specific characteristics how system integrators, chip vendors and software vendors interact. How can one visualize the interaction between the different participants in the design chain? Is it applications driving the hardware or hardware enabling applications?

One way to illustrate design chain interactions are the “ASV Triangles”, which Alberto Sangiovanni-Vincentelli created in the late 90’s while I was product manager in the Felix/VCC team. Cadence VCC of course is described in “A Prescription for Electronic System Level Methodology” as one of the “Trailblazer Projects”  for system-level design (Synopsys Behavioral Compiler being the other).

I remember seeing the original triangles sometime in 1999. The transition to platform based design was in full swing with platforms like Texas Instruments OMAP, Philips/NXPs nExperia and ST Microelectronics Nomadik under development. A hardware platform would be equipped with software APIs to allow application development to be relatively independent from hardware. This way video decoding was for example provided as a software API about which the application developer would have not to worry anymore. At the next revision the hardware provided underneath could change and as long as the API remained the same, application software would be compatible. This is illustrated with the upper set of triangles in the graph on the left. A range of applications can be mapped to hardware platforms with software APIs. Underneath different hardware architectures within a platform family support the applications.

This is where application specificity comes in because different application domains are driven by different requirements. The ITRS differentiates various product classes and design styles. They are SoCs, MPUs, Mixed Signal and Embedded Memory, with Networking, Consumer Portable and Consumer Stationary as sub-categories of SoC. In terms of driving markets the ITRS differentiates between Portable/consumer, Medical, Networking and Communications, Defense, Office and Automotive. In Networking for example it is all about increasing processing performance at constant die area, while in SoC Consumer Portable die size is actually shrinking and low power is the biggest issue.

As a result the ASV Triangles can now – roughly a decade later – be adjusted as I suggested in the lower portion of the graph on the left. The hardware platforms have become more programmable with multiple cores and software distributed among them driving the applications. The next step is to find application specific programming models which can be mapped from pure application design into programmable hardware architecture. This is what I would consider application driven design, in which hardware architectures enable different types of applications. Grant Martin and I wrote an article back in 2002 about the design chain effects called “A Design Chain for Embedded Systems”

Are we there yet? No. The time constants in the design world are pretty long and we are just now approaching mainstream adoption of the automation from the C-Level to hardware implementation. Virtual prototypes and architecture design as it stands today enable software driven development today, but it is largely manual, i.e. hardware platforms are provided as virtual platforms and software is developed on them after architecture decisions are made.

The next step will be to automate the partitioning of software across multiple cores – for which virtual prototypes already greatly help the debugging aspects today. However, completely automating the software partitioning is still some time away, even though the industry has figured it out for specific niches like HPC with technologies like NVidia’s CUDA.

As always – I am looking forward to your comments. It’s fun to be here in EDA. Times of transition are always offering many opportunities!

In  gearing up towards the Synopsys Synposium – our very first own virtual conference – I am thinking back to all the types of virtualization I am using myself. I am wondering how right Billy Joy was in his famous Wired Article “The Future Doesn’t Need Us”. Well, we have a long time to go, I think, and we as humans are not quite yet an endangered species, at least for a while.

So what types of virtualization was I involved in recently? Well, there is a bunch:

• In day to day life at work I am involved in providing virtual representations of hardware to software developers and hardware verification engineers. This type of virtualization allows to work with a representation of the hardware a long time before the hardware is actually available. It provided real time to market savings.
• We are re-modeling our house. With Google Sketchup we are using a full 3D model of the house to decide on how to decorate (see the upper left picture). Two effects kick in here. First, the world really is flat. It would have taken me a couple of weekends to become fully proficient on Google Sketchup’s modeling capabilities. It did cost me less than $200 to virtually hire a firm to provide me a fully functional, accurate model of the house within a couple of days. There are plenty of firms worldwide providing Google Sketchup services. The second effect is one of time and cost savings. Pre-viewing things virtually in the virtual house allow us to make decisions faster and to get highest quality at the end – we are avoiding surprises at the very end when for example the cabinetry is built.
• I am using Facebook and LinkedIn pretty regularly. It allows me to keep – virtually – in touch with friends and colleagues.
• I have run several virtual trade shows now – we started last year. They allow to reduce cost on all side. Vendors reduce show preparation and execution cost, attendees reduce travel time and cost and can be very selective in what they look at. The next virtual show we will be doing here at Synopsys is the Synposium from August 31st to September 2nd.

So, why am I optimistic that the future will need us after all? Well, with all virtualization the human element still remains at the core. All virtualization technologies reduce cost, time to results, improve the quality of the end result and make the interaction more efficient. But all the actual content comes from us – humans – and will come from us for quite some time. Even in a virtual tradeshow the most value can be achieved by actively interacting with the vendors present for instant messaging like communication. While Billy Joy argues successfully in “The Future Doesn’t Need Us” how robotics, genetic engineering, and nanotech are threatening to make humans an endangered species, I don’t think virtualization is contributing to this trend given that it just makes interaction more efficient. But then again, I may be wrong. Let me know what you think!

So see you next – virtually – at the Synposium, a Synopsys Virtual Event, to chat about the benefits of virtualization at our virtual system-level design booth. In addition, the virtual show will allow you to learn from the comfort of your desk about Synopsys EDA software, IP, prototyping and services used in semiconductor design, verification and manufacturing. Until then I am off doing non-virtual activities during my honeymoon

This is a follow up post to my July 7th Blog entry called “Dealing with Moving Targets in Interesting Times”. In response to Nokia selling its modem division to Renesas I had thought about who the actual customers for system-design tools are in a landscape of consolidation and change. It turns out that there are actually more parties involved these days, which increases the potential for business but makes the interaction a bit more intricate. We are about to close the loop to manufacturing even tighter, just like we did in the days of PKS – Physically Knowledgeable Synthesis – back a decade ago.

I remember those days quite clearly – has it really been ten years? When searching for “PKS” I found headlines like “IBM Integrates Envisia PKS Into Its ASIC Design Flow”, “Cadence’s Ambit PKS speeds tapeout at EmpowerTel Networks” and “Cadence Envisia Physically Knowledgeable Synthesis Selected by Ericsson Microwave Systems AB; Cadence Envisia PKS Used For Successful Million-Gate Production Design”. These headlines were all from about mid 2000. I am getting sentimental – at that time I was the product manager for Cierto Virtual Component Co-Design (VCC), which was probably 10 years ahead of its time. Somehow corporate had hired a leftover consultant to rename all or products to sound like cars. And I remember being somewhat jealous of my colleague’s situation in synthesis, because unlike us in the “Cierto” system-level flow, the “Envisia” guys in synthesis just had found a way to connect to the main business of layout and implementation. They made the next level down in abstraction – layout – part of their flow. The static predictions of what the impact of layout on timing would be, were simply running out of steam. Layout and synthesis would be integrated, or at that time, at least synthesis became layout aware. From a business perspective this meant that the next abstraction level up – logic synthesis – was connecting directly to the main business.

So ten years later I find myself looking at an ever changing landscape of customers. System Houses like Nokia abandon hardware and do only software. Semiconductor houses like TI, Marvell and Freescale provide more and more software as part of their complex platforms. IP providers like Tensilica combine their IP and software to provide sub-systems. In that changing landscape we are now starting to connect the manufacturing of foundries with the system-level world of transaction-level models – we are closing the loop just like ten years ago logic synthesis did. The picture on the left illustrates what is happening. Properties like power, performance and area (PPA) are characterized at the foundry level and annotated into system-level transaction-level models. As a result the design flow becomes more predictable and decisions can move up in the design chain to the user who defines the architecture, more and more the system house based on the software architecture.

Here are two examples which underline this point:

• TSMC recently announced Reference Flow 11, in which users for the first time ever now can get a foundry defined reference flow for system-level design. In the examples users can analyze their technology choice’s impact on power at the transaction-level the effect  .
• At the Interoperability Breakfast at DAC, Subramani Kengeri (Global Foundries) presented together with John Cornish (ARM) and Joachim Kunkel (Synopsys), how IP Providers, Foundries and System-Level Tool Providers interact more closely to provide technology characterizations into transaction-level models. All of this is meant to raise the level of abstraction at which design decisions happen. Global Foundries was specifically pointing to Virtual Prototypes as “Application optimized Integrated Platforms and Collaborative System Design Solutions” at the system-level combined with “Automated Precision Manufacturing (APM) and Early enablement of System level views” at the silicon level.

History repeats itself! Ten years on I find myself in the same situation as my “Envisia”colleagues were ten years ago. We are starting to close the loop from system-level to implementation! All this is great news and probably yet another indicator that the marker for system-level design tools is finally moving towards mainstream.

By Johannes Stahl

In his book “Hot, Flat and Crowded” the author Thomas Friedman gives us a comprehensive perspective on the fundamental equations this planet operates from. He connects population, natural resources, energy and information technology into these equations. One of his conclusions for energy production and consumption balance is to have a systemic approach, which optimizes the system from the top level with intelligent energy generation, distribution, storage and consumption. He warns that our current system for energy production and distribution is largely overdesigned for delivering peak capacity 24/7.

Nobody designs electronic products from a power perspective with the same energy waste today. Energy is either very limited (mobile devices) or expensive (infrastructure). Semiconductor companies are doing a lot to optimize energy consumption from using the best low power silicon processes, efficient micro and macro architectures and advanced, software-driven power management. By implementing all of these approaches at the software, RTL and transistor levels, semiconductor companies have been able to squeeze an amazing amount of processing power onto single chips.

Is that enough? Have we managed power every way possible in the best possible ways? Maybe not. Here are a few experiments for the undecided:

· 1st: Use your smartphone to browse, comment on, and update your Facebook feed and see how long it takes to empty your battery that way.

· 2nd: Take several HD videos of your incredibly entertaining kids . I recommend keeping a sharp eye on your battery level and wearing a glove on the hand holding the device.

· 3rd (for next year): Use your LTE enabled smartphone and stream a movie from the internet.

What is going on here? Clearly high-speed video and the related high-speed wireless access are the main power drains on you battery. This trend is only going to accelerate in the future, as 3D video and LTE-A will be experiences consumers will want to pay for.

All of these experiences have one thing in common – Lots of digital signal processing. The only way to achieve the best signal processing algorithm is to start telling the algorithm designers that they have to be power conscious and optimize their algorithms much more than they used to for performance and power.

So if you want to save big, go and talk to your algorithm design teams. They need both some recognition and some well-deserved pressure to save your day. As Friedman said, “either we are going to rise to the level of leadership, innovation, and collaboration that is required, or everybody is going to lose big.” The winners in the semiconductor space will be those that rise to the challenge of designing to save energy at the algorithm level.

Well, yesterday’s announcement that Nokia is selling its modem division to Renesas makes me reminisce how interesting from a technology perspective the world we live in is. EDA has a huge impact on the overall consumer electronics industry by enabling electronic design. But over the period of less than a decade electronics companies like Nokia have been completely transformed. So who is actually the customer when the environment we operate in changes so fast?

We are definitely within a transformation of the value chain, and what makes this so interesting for us in the “system-level design space” is the fact that our customer targets are shifting. Take the simplified view in the picture of this post. What used to be – like in the case of Nokia – a vertically integrated environment in which companies provided the silicon, the hardware and the software, has now changed into a separated set of design and value chain participants. After Nokia had transferred parts of its IC operations to ST Microelectronics back in November 2007, it has now essentially fully transformed into a company focusing on the software for their phones, fully moving the chip development into suppliers. The picture on the left tries to illustrate what the different design chain participants are focusing on. The software development, from lower level firmware through OS, driver, middleware and application software, essentially changes ownership. More and more of it is pushed to semiconductor providers and IP providers, which have to provide software with their devices.

I had run across a more elaborate analysis of the “Strategic Options” for Nokia as part of a Sloan MIT Lecture on Technology Strategy back in 2005. The section on Nokia provided by Professor Rebecca Henderson shows on page 6 the ecosystem from chipset manufacturing to network operation and service provisioning. It looks like the current situation is closer to the “nightmare” option on page 14 than the actual suggested vision on page 21, in which market share growth was accomplished with more vertical integration.

So why do I care in particular? Well, given all the transformation leaves the big question who the target customer really is for somebody in the “system-level design space”, or ESL. Take virtual prototypes for example. As software development tools they are right at the border between silicon and software. Who uses them? Who develops them? Traditionally virtual prototypes have mostly been used by software developers, in system houses and semiconductor companies. With the transformation of the user base, system houses gain more and more influence in demanding virtual prototypes used as software development tools. That means, different dynamics in the value chain and new customers for us in the system-level area of EDA. Interesting times indeed!

Writing this Blog post feels like being Sally Bowles in the musical Cabaret when she sings "Maybe This Time". Since at least ten years the industry has been looking at the annual Design Automation Conference (DAC) and thought it would be the beginning of an era of system design, only to then realize next DAC around that most system-level design technologies have not yet crossed the chasm. Something feels different this year around. Here are my top five reasons why this is the year of system-level design, in a Letterman count down style:

FIve: Technology consolidation has begun. Well, it has accelerated. What has happened over the last year is that Synopsys bought CoWare, VaST and Synfora – enhancing their technology arsenal for for algorithm design, ASIP processor design, high-level synthesis, architecture design and virtual prototyping. Cadence has bought Denali – trying to catch up somewhat to Synopsys’s position in IP. The way we look at system-level design involving Systems on Chip and Chips in Systems is fairly straightforward. Users need lots of blocks in their designs. They need to either be able to re-use them or make new onesfast. They then need to integrate them into one or multiple chips in the system, assess whether their connections are properly architected and provide prototypes of them as early as possible to provide links to embedded software development. This results in needs for IP and various views of it (including system-level models), needs for technology to create new and differentiating blocks fast, to efficiently integrate blocks and finally to provide prototypes for software development. With the accelerated consolidation of technologies it becomes easier to optimize flows across different technologies. See us at the Synopsys System-Level Booth to check out the technologies we have in this domain.

Four: Design Chain enablement becomes a key requirement. Pressure for enablement across the design chain has increased tremendously. In the chain from semiconductor IP providers, to semiconductor providers, to system houses and finally software developers we increasingly see the respective next element of the chain driving the previous one in supplying the right models. A great example are virtual platforms, which allow system houses and semiconductor providers to more efficiently interact. See our suite demos on virtual platforms to find out more.

Three: Standards enable interoperability. The standards-enabled ecosystem (see picture on the left) has grown tremendously since last year. Standards like Accellera’s IP-XACT and OSCI/IEEE SystemC TLM-2.0 enable a strong ecosystem which allows to make sure that system-level technologies can interoperate properly, allowing users to create repeatable flows. Check out our partners at the Synopsys Standards booth to see how SystemC TLM_2.0 enables interoperability.

Two: Links to Verification find adoption. Being on the move to higher levels of abstraction is now combined with strong links back into verification. A fair portion of the system-level design market has been “ESL Verification” for a while, i.e. connecting transaction-level models to verification. Over the last year we did see the trend continuing and more and more developers now make software part of their testbenches for hardware verification. Check out the paper we co-authored with Infineon called “High Speed Models for Automotive Microcontrollers: Verification of the TriCore AUDO FUTURE TC1797 Virtual Prototype”.

One: Foundries are starting to incorporate system-level flows. Not only links to verification but even links into semiconductor technology data find their adoption. Performance, Power and Area (PPA) data characterized at various technology nodes can now be made available to drive decisions at the system-level. For example, in the TSMC system-level reference flow we recently announced, users can see with data created using virtual platforms at the transaction-level how the software will impact power consumption at different technology nodes. Check out our system-level reference flow at the TSMC booth.

Time will tell when and how system-level design technologies will cross the chasm and find mainstream adoption, but in a Sally Bowles “Maybe This Time” fashion it certainly feels different this time around. See you in Anaheim!

By Johannes Stahl

When Carver Mead and Lynn Conway published their famous statement about the ‘tall thin engineer’ in their book "Introduction to VLSI System Design" in the early 80ies, designs had about 5,000 gates. Their vision was to change VLSI design into a process, that was repeatable and also that designers could understand the entire process well enough to create chips starting with the knowledge of the design intent down to the final mask set. If we look into the reality 30 years later, the opposite has become true. The SoC design process has been decomposed into a number of major categories: System-level design, Software development, RTL design, RTL2GDSII, Design for Manufacturing with vastly different knowledge disciplines.

In this View From The Top we of course do not look down to DFM, so we are definitely not the prototype of that tall thin engineer. At best we can see that our end point from a hardware implementation perspective is RTL for implementation and some reference model or test vectors, we provide to the RTL designers.

So how should system-level tools support hardware implementation flows? First of all the role of system-level tools is to make sure that the design intent is completely specified and is validated in the system context. Second the tools should facilitate an easy way of getting to RTL.

How do system-level engineers know, if their specification of design intent is complete? The best way for them is to express their specification in a way that is intuitive, allow for reuse of their knowledge and manages complexity through encapsulation. This is the essence of model-based design. In the domain of communication systems design any algorithm designer today will start with a conceptual block diagram and for simulation use C-models to explore the overall system performance. Block diagram based tools with a large amount of proven models, such as SPW and System Studio, are the default way for design teams today.

Once designers have captured their system using this model-based approach, the complete power of the high-performance simulation tools for performance exploration, specifically going to the required fixed-point precision is at their disposal. At a minimum this model-based fixed-point specification is a reliable, easy to understand meet-in-the-middle reference for RTL designers and algorithm designers. However with the proven Synopsys tools for implementation, algorithm designers can take it one step further: They can either rely on proven DSP implementation building blocks, built-in C to RTL translation technology or high-level model-based synthesis using Synopsys’ Synphony to automatically create RTL which can go straight into RTL2GDSII flows. Hundreds of thousands gates blocks are being designed every day with these flows, retargeting from FPGA to SoC included.

The basic questions of how much implementation expertise and algorithm design engineer needs and how much domain expertise an RTL designer needs does not have a fixed answer. Design teams will always need to stretch to bridge the gap. Synopsys can help to make the stretch easier!

Well, productivity is an interesting issue. While ghost writing an article earlier this month I reviewed the ITRS roadmap and its predictions. The ITRS states that in order to keep up with the increased complexity of electronic developments over the next ten years, automation needs to provide more than 26 fold improvement on the hardware side and almost 50-fold for software. That’s quite a challenge. That makes me wonder whether these types of productivity improvement have been seen anywhere before …

First of all, my own Blog productivity has been miserable. My last Blog post two month ago? Ouch. Sorry for that. My excuse: We were very busy with the integration of the various acquisitions we made. However, the discussion on design productivity makes me think back on the two most memorable EDA speeches I have heard. One was in 1997, Joe Costello was talking about “negative target fixation” as part of a seminar tour. Productivity and how Cadence addresses its improvement, was the topic of the rest of the speech. At the time I was an EDA user and the speech helped convince me to join EDA. The other speech was given by Aart De Geus at DATE, I think in 2000 or 2001. I vividly remember going home with the thought “now that the Genome is deciphered, the design productivity gap is the next big problem to figure out. Let’s get to it”. And we did! According to the ITRS since 2001 design productivity has been improved through automation more than 18-fold for hardware and it has more than doubled for software.

So what does this all mean for us in EDA? The main message ITRS gives us in 2009 remains: Cost (of design) is the greatest threat to continuation of the semiconductor roadmap. Without the productivity improvements provided by tools, development cost would simply explode. The graphic on the left tries to illustrate this and is based on ITRS data. The overall semiconductor development cost – hardware and software – is kept in check under $100M. In order for that to happen, certain productivity deltas have to be achieved. Over the next ten years – until 2011 – this will have to lead to an overall, cumulative 50 fold productivity improvement in software development and a 26 fold productivity improvement in hardware development.

50 fold productivity improvements are hard to imagine at first. For my planned house re-model taking about 50 days, the equivalent would be to do all of it in a day. The involved design technology improvements cited by the ITRS are the “Intelligent test bench”, a “Concurrent software compiler” helping to automate the partitioning across processor cores, “Heterogeneous massive parallel processing”, “Transactional Memory”, System-level Design Automation” and ultimately a “Executable specification”.

So are those productivity improvements even feasible?

A good reference comparison from manufacturing would be automotive. The first production Ford Model T was built in 1908 in Detroit. It did cost about $850. This being $17,000 in 2007 inflation-adjusted dollars makes this about the same price of a new Ford Focus. This is comparable to the consumer industry. For the same price or less, users are getting much more functionality in their devices like cell phones and compute devices. Production time wise the first Model Ts rolled off the band about every 12 hours in the early days, every 93 minutes in 1914, once per minute in 1920 and at its peak every 24 seconds. That’s a 1800 fold improvement in manufacturing productivity within a decade or so. The item difficult to gauge is the car development complexity. I did not find real data here, but GM introduced the first Engine Control Unit (ECU) with a microprocessor in 1979. Combine that with the fact that today’s cars easily have more than 50 ECUs in them, suddenly the factor 50 no longer looks that out of the question anymore.

At the end of the day the challenges for the next decade to achieve the required productivity improvements seem to be doable. Given the mix of hardware and software changes our increased attention here at Synopsys on software development certainly seems to be timely and correct.