Posted by frank schirrmeister on February 9, 2010
I have been interacting with a lot of colleagues from legal and corporate business development lately. They were wondering what Electronic System-Level Design – or ESL – is all about. Like in a previous post on hotels in Bali, I have been using analogies a lot to explain the advantages of ESL and the reasons for it becoming more and more necessary. Now seems to be a good time to start a series of blog entries to liken system-level design to some real world challenges. This first entry will focus on the challenges motivating while design has evolved over time.
Imagine you are Slartibartfast. Yes, that’s a major nerd-alert here.But then again, I am writing this at 5:30 am before my daughter gets up so I can geek off all I like. Slartibartfast is this cool character in Hitchhiker’s Guide to the Galaxy, who’s task it is to design earth. He is famous for the design of the fjords found on the coast of Norway, won awards for it, but I digress. Imagine you are Slartibartfast, you are standing on Mount Hamilton and your task is to design the Bay Area. How would you go about it?
So your design canvas looks like the picture in the attached. The landscape is done and cannot be changed anymore. Now your task is to create the cities. Your customers come with key requirements, like how many cities they want, how big they have to be, which functions they serve and how they connect to the rest of the area (i.e. how many bridges there are into Marine County etc.).
You have had this task since 1979. It is 2009. After 30 years you are thinking about retirement but your intern is asking you how to prepare for the next 10 years of design. That makes you think about your retirement even more because you are wondering how you survived the last 30 years of challenges. You had to deal with huge changes with respect to sheer complexity, speed and power consumption and things are getting way worse going forward.
Let’s compare the task at hand with Chip design. Back in 1979 your customer had commissioned this design called 8088. The basic building block you were thinking about during the time was called a “transistor” and the 8088 had 29,000 of them. About 104 of those were making up a set of 4 town homes to store things (i.e. 4 bit registers in chip lingo). That means that the Bay Area in version 8088 had roughly 1000 houses (if it were only houses). With connections and other essentials those were only about 500 houses or so to deal with. Sounds manageable.
Almost 30 years on, in 2008, you had to deal with a design of the Bay Area called “Tukwila”. It had about 2 billion of those basic “transistor” building blocks. To put this in perspective, these summed up to about 10 million houses you had to cram into about the same area. You also had to do it in about the same time they had given you for Bay Area version 8088. Of course the design automation tools to design all this have evolved, but still, your personal productivity has had to improve quite a bit too. Your intern came back from visiting the oracle called ITRS and apparently about 12 years from now, in 2022, customers are expected to ask you to cram about 500 million houses into the same are. Time to retire!
Complexity is not the only challenge. Speed is another on. To operate our imaginary Bay Area there is a master “clock”. Everybody listens to it like to the drummer on a Roman battleship defining the rowing speed. Compared to the clock in 1979 in Bay Area 8088, in 2008 the clock runs about 300 to 400 times faster. Now you know why living in the Bay Area’s pace sometimes feels like living in a blender:) This speed is the equivalent to clocks determining the speed of digital chips. The 8088 in 1979 started at 5MHz and we are looking at about 1.2 to 2 GHz for Intel’s Tukwila in 2008.
The third element is power consumption. In 2008 Tukwila’s top end parts consume about 170 Watts, compared to about 1W for the 8088. If you compare this to the number of transistors, the power consumption per transistor has gone down by a factor of 400. If you have looked at your PG&E bill lately, that is quote some energy efficient design.
Bottom line, if they would have been chip design, the design challenges for Slartibartfast have become over the last 30 years a couple of 10,000 times more complex in terms of sheer magnitude if basic elements to deal with, things have become about 400 times faster and designs had to become about 400 times more energy efficient. That’s quite an improvement. In the next part I will look at tools to automate the design and the abstraction levels at which Slartibartfast can enter data into them.
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.