Archive for the 'Hitchhiker’s Guide to ESL' Category

Well, after the last post caused some controversy on much assembly re-use enables versus how much one should build from scratch, i did get a question on what the difference between hard and soft re-use is all about. I made sure in a brief huddle with a colleague in our IP team that these are really the only two categories worth mentioning. It all comes down to the abstraction levels and how much automation a designer still uses to implement the IP.

Hard IP has been already targeted to a specific implementation technology – TSMC, Global Foundries etc. Generally this happens for blocks that are already optimized, in the digital world these may be ARM cores for TSMC, in the analog and mixed signal world these can for example be physical interface IP (PHY IP) pre-ported to target technologies. For example, the Synopsys DesignWare USB 2.0 PHY IP has been ported to over 50 processes and configurations ranging from 180nm to 28nm.

Soft IP has not yet been targeted to a specific technology node but is instead available as synthesizable, pre-verified RTL, which the user can target to a technology of their choice using logic synthesis. A good examples is the Synopsys DesignWare IP Solution for AMBA Interconnect, which comes with synthesizable IP for the interconnect fabric, DMA controllers, memory controllers and peripheral IP, along with verification IP to make sure the design works in its context and tools to assemble the IP at the RT-level

So what does this mean in Slartibartfast’s world of designing the San Francisco Bay Area? They key difference between hard and soft and IP is shown in the picture at the left. Soft IP is delivered at the equivalent to the Street-Level in a textual form. Slartibartfast’s designers describe how many houses the customer needs, how they are connected to each other etc. They do not describe the actual layout, i.e. where to place these items. They don’t even describe the actual number of houses, sizes and connections because it all depends on how many people have to use the houses and streets as well as how often they need access. Form this textual description logic synthesis now creates the actual placement of the components, how they are connected etc. Another set of automation tools lays the different components out across the landscape. The final description – the blueprint how to build everything including all walls, electricity, plumbing etc. is then sent to manufacturing.

For hard IP the process is different. Instead of using automation to get from the street level textual description to the actual blueprint on how to layout everything across the landscape, everything is custom made. The Oakland Harbor used in the last Hitchhiker’s post is one example, for which the characteristic of how the water behaves over time, what type of ships arrive etc. cannot really be changed. It’s fixed like the line characteristics for USB PHY’s are and it has to follow certain protocols like USB Controllers have to. While the digital portion typically is synthesizable, the actual interface to the analog world is hard to implement in an automated fashion. For this purpose hard IP (interfacing the water) is an actual implementation at the blueprint level, which can be place and it has been already optimized and verified for the technology chosen to implement the Bay Area.

So why do both exist? Hard IP is not flexible but instead optimized for a specific technology, so it will be at best area, power or performance. In cases like Analog IP it typically is the only option of delivery. Soft IP is offering flexibility – users can choose more options in the area-power-performance target domain. Soft IP is typically configurable with parameters and users can even extend the RTL to add custom functionality. The latter comes at a cost – users have to verify that the additional functionality didn’t break the original design, which is typically pre-verified and comes with verification IP.

Regardless of which type of IP was chosen, IP Reuse in general is crucial to increase design productivity!

To deal with the complexity increases, the abstraction level at which the design entry happens, has evolved over the last 30 years. In my first blog posts I had reviewed the evolution from transistors to gates to RTL and now to the transaction level. In Slartibartfast’s world this evolution of granularity (the level at which designers think) is equivalent to designing at a building floor plan level, house level, street level and city-level as indicated in the graph on the left.

In the good old days, Slartibartfast’s employer was an integrated design house called Texas Instrumentus, TIUS. They were doing everything from the design to the actual manufacturing of the projects to be used on various planets. TIUS at the time even had a set of design tool developed in-house, helping Slartibartfast to design the 500 houses and connections they had to do at that time in average. The automation tools were purely graphical and once a design was finished, a data file (called GDSII) was sent to manufacturing who would produce the specified worlds en mass.

Given the complexity increase from 500 houses 30 years ago to 10 billion today and a projected 500 billion in 10 years, productivity had to increase quite a bit. The oracle ITRS does not only think stuff up about the future, they also have a team of historians documenting the past. Just yesterday Slartibartfast had pulled up some of the old ITRS records to explain to his intern, that in the last 15 to 20 years alone design productivity has improved 580% through re-use and 336% through methodology improvements. And yes, in addition engineers have become “tall, thin and smarter” too

Design automation had a major role in productivity improvements. Back in 1979 Slartibartfast and his teams were drawing each house individually using schematic entry, defining the exact positions and connections manually. Design automation soon invented automated layout. Only the positions needed to be defined and then automated layout tools would automatically create the connections. Later on, at the building and street level, logic synthesis allowed to describe the intended design using a language defining all the houses, functional units and their individual connections. The logic synthesis tools would then suggest an implementation of the desired functionality based on speed, area and power consumption constraints set by the user.

In addition, re-use played a crucial role. Instead of designing each portion of the bay area by hand, the basic building blocks were pulled from pre-defined libraries. At first, for “small block re-use”, libraries of basic design elements were introduced in about 1997: kitchens, bathrooms, hallways, gardens, doors etc. Later, for large block re-use starting about 1999, complete houses, town homes, theatres, schools, streets and intersections increased productivity even further. Very large block reuse really just found its adoption  a couple of years ago around 2007. Now re-use happened at a much larger scale. For specific interfaces, like for example the interface to the sea called USH (Universal Serial Harbor), it really did not make sense to design it from scratch every time. There were Intellectual Property (IP) providers, who could provide design teams with pre-defined USH designs ready to be included. They typically had even tested them using various manufacturing technologies so that Slartibartfast and his teams did not have to worry about it. The Oakland harbor is a good example, Slartibartfast fondly still remembers the negotiation with SYNOPYSOS, the biggest supplier of connectivity IP, from which he had bought the Oakland USH interface and it immediately worked perfectly.

Design for sure has changed over the last 30 years and at times if had been difficult for Slartibartfast to keep up with all the new tools and methodologies. The next installment of this series will deal with simulation and verification. Not only does the bay area need to be implemented fast and on time, but it also has to be verified and validated. That means it has to do what the specification requests and it also needs to meet the customer’s intent. In order for this to happen, we will discuss technologies for simulation and verification in the next blog post.

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.