Archive for the 'Abstraction Levels' Category

Transaction-level models are the main building blocks of virtual prototypes, which are used for early software development. In my last blog post, I briefly introduced the different kinds of software tasks and the implications for models. Today, I want to talk about the modeling requirements for early SoC bring up. As I mentioned, understanding the software requirements correctly provides two clear benefits: 1) it makes modeling easier through a more focused application and 2) it increases the value for the software developer through more tailored modeling capabilities such as debug features.

Within the context of pre-silicon software development for SoCs, the dominate use model for virtual prototypes is the bring-up of both the operating system and the chip validation suite. To bring up an operating system such as Linux, you must consider multiple aspects: primarily the CPU architecture specific code, the peripheral device specific drivers and the SoC/platform (aka machine) specific configuration.  Once a new CPU architecture is supported, or a device driver is available, they can be leveraged by the different platforms. Still, it is surprising how much code you have to write (and validate) to support a new platform. Of course, this platform support code will need to register all the different devices and set up the memory map and interrupts of the platform, but interestingly a lot of the platform specific code just deals with clock and voltage control (e.g. TI OMAP). Power domains are defined; voltage levels and frequencies are configured all over the place. Linux provides specific clock and regulator frameworks as well as the so called CPUFREQ framework for DVFS which are also used by the various power management frameworks.  Most of the settings are managed by the board’s power management IC (PMIC), or the on chip power-reset-clock-management-unit (PRCM).

This is not just happening for advanced features such as DVFS.  These techniques are also employed to get the simplest peripherals to work such as a UART. Before the UART driver can access the UART, it has to be clocked and powered. If this is not the case, the register interface of the UART will be in an undefined state and many TLMs do not take care of this situation today. In order to have a model support these aspects of the software, the model should perform a simple check to verify any abnormal operating conditions and inform about them. This simple addition to the model will greatly improve the value of the model and make software development and debugging more efficient.

Transaction Level Model - Clock/Voltage/Reset Sensitivity

Of course, it is necessary that these models are also equipped with ports that provide information about voltage and frequency, so that the model can check whether the levels are within acceptable limits. This does not mean that we need cycle accuracy with sensitivity to the clock, but rather we are interested in supplying the model with numeric information about the frequency and voltage.

The software is driving the clock tree and power network by configuring the power reset clock management (PRCM) unit or the power management IC. Thus, our virtual prototype should have an abstract model of this component that provides an accurate register interface. The internals of this model are not relevant in this context unless we also want to develop the firmware here. All that is required is that the clock and voltage lines are driven correctly by this model and the topologies of these networks are accurate.

Power Reset Clock Management Unit

So, in summary, with three relatively simple additions to an abstract, loosely timed virtual prototype we can greatly increase its value:

• TLM should check voltage and frequency values are in acceptable ranges
• A register accurate model of the power management IC and/or power management IC
• Accurate topology of the clock, reset and voltage networks.

By the way, did you know that wrong constraints and settings of the software-driven voltage regulators can result in hardware damage? I bet you’d love to be able to just restart your simulation rather than explaining to your management why the board can now only be used for decoration in the office lobby.

In this post, I would like to share some perspectives on the transaction-level models needed for the creation of virtual prototypes. Just recently, TLMCentral kicked off a contest seeking the “best” model for a mobile phone sensor device. What actually makes a “good” model?  The most ad-hoc answer to this question has historically been that the best model is the fastest and most accurate. However, if you ask about the reason for this, you probably won’t get a very precise answer. What does “accurate” mean? What is the definition of “fast”?  Will an accurate and fast model be available early enough to start software development before hardware is available and therefore meet time-to-market demands?

 

Simulation performance and accuracy (timing and function) are for sure valid aspects.  But, there is much more to consider.  The opportunity for the “best” model arises when user requirements are understood correctly.  When this happens, model creation can be greatly simplified and sped up. The model will have more value for the end-user at an even lower cost.

 

A good model, in my eyes, is one that serves the purpose of the user at the right point, on time at a proper cost. Here, the user task has to be carefully reviewed before selecting or creating a TLM model. What is the user intending to accomplish with the model? Simply identifying that a model should be used for software development is not the right level of diversification we are looking for. It does not constrain the requirements! Thus, we would again need a model that has to be able to do everything. While this is a challenge that often has to be tackled by TLM model providers, it is not something that you want to deal with when enabling a certain class of the end-users in your project.

 

In the remainder of the post I want to provide some software perspectives on models. In context of those perspectives I would like to introduce the aspects that make a model valuable.

 

The mobile phone application developer uses models in context of emulators being a backend to SDKs. This class of users demands that the models executes at speeds closer to the real device. For interface IP models, it is necessary for the model to be connected to the real world. E.g. the develop can use his/her real “iPhone” to drive the sensor model in the virtual prototype. S/He values the fact that he is able to record and repeat the stimuli for testing. It sounds complex, but doesn’t need to be. An application developer will not look underneath the APIs he is using which leaves great room for abstraction/simplification. In the context of Android, a sensor model may be a combination of a simple middleware along with a generic interface model (e.g. a UART) that is used to send and receive sensor data. This is close to the way it is realized in the Qemu Android emulator.

 

 

 

However, if the focus is middleware-, and not application-development, then this level of abstraction does not hold true anymore. Still, we typically have fewer requirements on simulation performance. The scenarios in which we are using the model are mainly in context of short embedded directed tests. E.g. For compliance testing, Android provides small sensor test applications for developers that are creating their own sensor middleware. The middleware is interfacing with the driver of the OS. Thus, our model should be accurate up to the level of the driver’s user interfaces.  This implies that the coarse grain states of the IP are modeled correctly as those are typically reflected in how the driver is operated. E.g. the sensor is activated and configured to provide updated gyroscope values every 500ms via the file “/sys/class/sensors/gyroscope”.  

 

To enable this, it is not required to realize such a model register accurate or register complete in the first place. Only a subset of the driver needs to be realized and functions such as clock, reset, voltage control can be neglected to simplify the modeling. The middleware developer will get more value through the additional debug and tracing capabilities we can put into the model. A good model will assist the developer and inform him/her about the coarse grain operation. Why are things happening in the model, or why are things not happening? This level of visibility can be of great help for understanding the IP and debugging the embedded software.

 

Someone who develops drivers or brings up a device in context of a board configuration will need more functional completeness and accuracy. Here, an accurate representation of the register map is almost mandatory. This also concerns functions for the power management integration such as clock, reset, and voltage sensitivity to bring-up and test for the Linux clock/voltage regulator frameworks. The model has to provide the proper response when configuring it through the register interface and also trigger interrupts. Therefore, a certain level of timing accuracy is required. However, this does not refer to having the data-path of the model being cycle- accurate/-approximate. The correct operation of the IP in the system context requires responses of the model at proper times. E.g. a timer will fire interrupts in periodic intervals. But again, model abstraction can be done to simplify the task. For the purpose of driver development or board bring up, the most important aspect is the control plane. Here, e.g. the data plane of a video accelerator IP can be abstracted to just show dummy data.

 

In summary, creating a model efficiently requires careful review of the end user design task. The model development can be staged and aligned with the software development plan, to incrementally enable new software development tasks. Understanding the requirements correctly allows creating models at lower cost and with higher end-user value.  

I am involved in discussions about adoption of system-level technologies a lot. System-level design in EDA and embedded software are always intertwined as the software is the main factor changing when going beyond RTL. Given that system-level design technologies expand beyond the traditional realm of hardware, their adoption is non-trivial for project teams. The overall situation reminds me more and more of Malcolm Gladwell’s “Outliers”: for success several factors have to fall in place together, not all of them in our control.

In “Outliers”, Malcolm Gladwell describes “The Story of Success” as it relates to people. He argues very convincingly how several things need to fall in place. Amongst them is being born at the right time of year to be more mature and therefore be chosen for special training in sports. Also, the need being there at exactly the right time for a technology like computers to be needed. In addition the right background is crucial to have the ability to develop a skill – parents supporting training, education capabilities or available of excess compute time on a mainframe.

The same is true in principle for technology adoption, and most certainly for system-level design technologies. The time for adoption needs to be right. Being too early means you simply may not have enough breathing room to get to the mainstream., which almost certainly means that you will fall into the chasm instead of crossing it. Having the right technology combined with the right environment for it to be adopted, is crucial. The actual user need has to be there too. If the users can get by with traditional techniques, then the reasons to change methodologies, i.e. to drop old habits, are not good enough. Finally, when the time is right, the technology exists, the need is there, users need to know about the solution too. That’s where the power of marketing comes in.

So where are we with system-level technologies? Let’s look back 15 years. As some of you know, I cam to the US in 1997 to run the technical marketing for the Felix Initiative at Cadence. The resulting product VCC has been described  – together with Synopsys’ Behavioral Compiler – as one of the two system-level trailblazer projects in “ESL Design and Verification: A Prescription for Electronic System Level Methodology (Systems on Silicon)” (Martin, Bailey, Piziali). Were we too early? Probably. Leading customer told us though that they would need function-architecture co-design as implemented in VCC at the time. They documented with their tool purchases that they had a need. Was the technology right? Well, it worked for the early adopter designs and most of its concepts – like transaction-based design – find itself now in technologies like SystemC TLM 2.0. Were user getting by with traditional techniques? Absolutely! It was getting harder, but why abandon a methodology that’s still works? Did users know about it? Well, we marketed it quite a bit, and knowledge about system-level design approaches was growing.

So what was missing? The technical barrier to adopt the technology was simply too high. In the case of VCC we were addressing hardware and software designers with a combined methodology. We had developed techniques to abstract hardware (processors, busses, peripherals etc.), to abstract software (RTOSs, drivers and the actual functionality) and we could even create the implementations from the complete executable system-level specification. Heck, at DAC in 2001 we were demoing a flow in which the customer told us during the demo whether a task should run in hardware or software and then we automatically re-built the design and did show the resulting layout of the hardware together with the implemented software image.

The results were awesome: We achieved much faster development times and more robust designs meeting their specifications. Too bad that software and hardware developers had to change the way they are doing things completely. Also the complete ecosystem of Processor, IP, RTOS and middleware providers had to provide models to make it all work.

In the spirit of fellow Blogger Steve Leibson’s law, that “it takes 10 years for any disruptive technology to become pervasive in the design community”, I am tempted to formulate my own “Schirrmeister’s Law” as “The ability to adopt a new design technology is inversely proportional to the number of changes it requires”. Sounds trivial. Still something I learned the hard way during the VCC days and something we often overlook today.

If I could just quantify and measure it. That is hard, but here is an example: Almost 15 years later Virtual Prototyping is going through its adoption. How many changes does it require? Well, compared to VCC it is much more adoptable given that the software developers do not need to abstract anything. The real software – namely .elf files – run on abstracted hardware. The number of changes – or additional steps – is limited to the hardware developer.

So what about the other adoption criteria? Is the time right? Well, software development has probably never gotten as much attention from the EDA side as it has these days. And our customers are expressing their concerns in every meeting I am at.. Do we have the right technology combined with the right environment for it to be adopted? The successes seem to speak for themselves – we have real users achieving real results. Is the user need there, do users get by with traditional techniques? We recently did a survey of about 800 embedded software developers. One of the questions we asked was “What target execution environment are you using for your embedded software development?”. The results are shown on the left. The top four answers are pointing to hardware based techniques, so they seem to work. Probing for limitations on those techniques users confirmed issues which I have written about in this Blog before – like the ability to control and debug the execution. Finally, whether software users are aware of virtual prototyping was a question intended to check whether target users know about the technology. There is definitely room for marketing effort here as the awareness was lower than we had hoped.

Bottom line, the adoption of system-level technologies like Virtual Prototyping remains a hot topic. Certainly the industry has lowered the barriers to adoption, but there is still some distance to go. The number of changes we ask users to adopt technologies is often still significant enough to shy away from adoption, even if it means mortgaging the future …

I will think about how to measure my postulated “Schirrmeister’s Law” above with quantifiable data. As always, I welcome your thoughts.

What do the Inchron Real Time Congress this week and my last weekend home project have in common? They both are all about complexity, real-time, apps and platforms those apps run on. In automotive and consumer domains, apps are running on platforms in systems of systems. The question to me at this point is how many platforms – like AUTOSAR, GENIVI, Android, IOS, Windows Mobile etc. – as well as versions of them can an apps interested user really handle?

Let’s start with the Inchron Real Time Congress, which I was attending on Tuesday and Wednesday. After BMW talked about  the networked car with several networked sub domains. Continental then talked about how to enable Human Machine Interfaces (HMI) with one hardware and hypervisors underneath (see the graphic on the left, Source: Continental). Other presenters from Continental, Audi and Volkswagen confirmed the trend to the networked car and the discussion during the day centered around the real time aspects of car-related applications.

While my next “apps driven” car purchase is likely still some time away, my home remodel reminds me in a nightmarish way of what is ahead of us in cars and other apps driven domains. After a one-year re-modeling project and expansion, one geeky upside is that I now have CAT6 installed throughout our home. Everything is installed in-wall. I am happy (and somewhat proud) to report that the engineer in me is still present as without a problem I was able to add Ethernet plugs and such during the last weekend. If this whole system-level gig does not work out, I definitely am still capable of planning and installing home entertainment systems …

Not unlike the networked car, our house now has several networked sub-systems, in our case the home office, bed room, living room and family room. Connected via CAT6, the closet in the bed room hosts a gigabit switch to connect the video server, an Apple iMac hosted in the home office, to the rest of the house. An Apple TV (Version 1) and a Samsung Blue-Ray Player connect via a receiver to a Samsung wide-screen TV in the living room. An Apple TV (Version 2) and an iPOD dock connect via a receiver to a Sharp wide-screen TV in the bed-room. A Comcast multi-room DVR connects from the bed room to the family and living rooms.

The second Apple TV was purchased pretty much specifically to enable more “Family Guy” episodes via NetFlix (OK, Caillou and Blues Clues are found here too). As always, the Apple interface is slick and intuitive. It took me 15 minutes from unpacking the box to streaming video via NetFlix. The nightmare started when I activated the internet service on my Blue-Ray player. The Samsung “Smart Hub” updated via internet. The Netflix interface looked much different on the Samsung “Smart Hub” platform and I had to tinker a while until I had signed up for a Samsung account, registered the DVD player and got to streaming video after about 90 minutes. It took me another hour to figure out how to get to the latest revision of the Samsung platform via internet, after which all apps needed to be upgraded as well. Now the interface for Netflix roughly resembles the Apple interface, but is less slick, slower and looks different enough to notice.

How do I explain these different interfaces to my wife and daughter? I have no idea. Why are they different, even on the same platform across revisions? Ideally they should not be.

To make things more complex …. our Samsung TV also has an internet “Smart Hub” interface with apps. Comcast just sent me a advertisement on their apps. I am hesitating to unpack the Sony play station for the family room – yet another platform and yet another apps interface.

At the system-level I am musing in this Blog mostly about aspects at the hardware software interface. The experience with my home network, combined with what I hear about the future of cars, drives me to some conclusions applicable to my world at work of tools enabling software development and system-level design:

• The versioning of platforms and apps running on it, needs to be solved before the mainstream user – like my mom, dad, wife and daughter – can adopt these new technologies. Linaro is a first step for Linux. We desperately need similar activities for AUTOSAR, Android and other platforms.
• Case in point: Gadget Magazine T3 just compared the HTC Flyer, the RIM Playbook and the ASUS EEE Pad Transformer, three tablets. The HTC runs Android 2.3 with a HTC Sense custom UI on it. The RIM Playbook runs the QNX user interface. The ASUS runs Android for tablets – Honeycomb. Three fundamentally different user experiences are OK in competition, but not in the same environment (like our house, or a car). Fellow Blogger Steve Leibson recently referred in his EDA360 Insider post to a PCWorld article on why there are little Honeycomb apps. Oh well.
• To get to mainstream adoption, we may need “Uber-Apps”, both for hardware and software, which stand above the actual apps. I finally may have a good reason to get an iPad, if it could be the “Uber-Interface” from which I can control all our apps and devices.
• “Owning the user experience” is more crucial than ever. Apple has mastered the art, but you have to commit to them completely. The situation in my family room would be completely unacceptable in a closed environment like a car. That’s why the car OEMs at the end will own every interface which touches the user. They will define the platforms their suppliers will need to enable in hardware and have to run apps on.
• Given that the tools I am responsible for sit right at the interface between hardware and software, monetization on apps we enable has always been a fascinating topics. With hardware providers (like Continental above) actively thinking about hypervisors to shield the software from the hardware, monetization on apps will become even more difficult for tool vendors.

Bottom line, apps have become a central part of system-level design and are impacting every step of the design process. Getting them fully adopted and which platforms will prevail, remains an interesting question. As always I am looking forward to your thoughts and comments!

The Mentor ESL panel took place in its 9th year on DAC Tuesday in front of a very big “free-lunch-audience”. Wally Rhines kicked off the event in his usual data-driven manner, identifying the three types of design disciplines encompassing the SoC Design process: First there are “Hardware Custom IP Designers” challenged to shorten IP development and verification lead times. Second there are “Software Developers” who need to reduce software development, optimization and verification lead times. The third group are “SoC Architects and Integrators” who are challenged to design the full SoC for performance, low power and scalability.

The next generation design challenges for ESL – the drivers – are multicore design requiring virtual prototyping, system power implications and constraints requiring more than just power optimization and verification re-use throughout the flow from TLM to RTL requiring more automation and efficiency.

Turning over a new leaf, Mentor did invite a more management oriented panel from semiconductor (3),  IP (1) and EDA (1) companies.

First on stage was Gadi Singer, Vice President at the Intel Architecture Group. He focused in his slides on HLS as a key step towards, but in his words called ESL three things – (1) necessary, (2) about time and (3) having not enough critical mass yet to become the next level of design entry. At Intel ESL is considered a long-term must have, it s being used for pre-silicon software development and post silicon readiness. There are several internal activities on HLS, but for broad deployment of HLS, several technical issues still need to be addressed. Among them are standards, improved ECO flows, better ESL model validation, formal equivalence capacity between TLM and RTL, SystemC linting and an effective integration between HLS written code and hand written RTL.

John Goodenough, Vice President of Design Technology and Automation at ARM  talked about a “software first, sorry,hardware second” approach to ESL, somewhat apologetic towards the mostly hardware oriented audience. He mentiones several use cases including apps development pre and post silicon, architecture exploration, SoC design and validation and of course pre-silicon software bring up. Interoperability is crucial for ARM, SystemC offers some good starting points, but John also pointed out the still existing dilemma of running fast enough while providing enough accuracy on bus transactions.

Next up was Ken Hansen, Sr. Fellow, Vice president end Chief Technology Officer at Freescale Semiconductor. He talked about Freescale’s efforts to improve product differentiation with architecture optimization, software bring-up on virtual prototypes and co-design of hardware and software. As challenges to broader adoption he identified model availability and modeling expense, together with tool cost both for software developers and traditional EDA hardware users. He also commented on technical issues required for further proliferation, including better power  modeling, automation of back annotation from implementation data and more seamless flows between virtual and hardware execution.

Jean-Marc Chateau, Director of System Platforms and Tools at STMicroelectronics, briefly reviewed the history of ESL adoption in ST since 2002 starting with C based hardware verification before IP RTL is frozen to pre-RTL software testing and debug for subsystems in 2008 to full pre-silicon software availability since 2011. As next frontier he sees specification level models, methodologies and standards.

Representing the EDA Industry, Simon Bloch, Vice President and General Manager, ESL/HDL Design and Synthesis Division at Mentor Graphics described TLM level flows from modeling of blocks to assembly, virtual prototyping, debug and optimization and then finally re-use of TLM models both for HLS implementation and hardware verification. Simon identified software validation as leading ESL driver from Mentor’s survey, followed by faster verification for fewer bugs and faster time to verified RTL (see graph on the left).

In the subsequent discussion moderated by Wally, all panelists seemed to be quite optimistic about actual ESL adoption. Especially virtual prototyping for software development got high marks from Intel, Freescale and ST. High-Level Synthesis also enjoys quite some attention. ARM identified model speed as basic issue for lack of deployment in software development, closely followed by cost. There was quite some discussion about the cost of the model development and who can actually do the modeling. Intel, Freescale and ST seem to employ specialists team to do the modeling for both internal and external use.

Overall, as concluded by Wally, management – at least on this panel – does not seem to be the problem for ESL adoption.

The industry did it again! Once again we are tightening the loops from system-level to implementation even further. 2010 was the year in which TSMC added the system-level flow to their reference flows for the first time. This year’s TSMC Reference Flow 12 marks the second revision of a system-level flow in which we are connecting a semiconductor manufacturer.all the way up to the system-level!

In one my previous Blogs called “Disruptive Ripple Effects From Implementation to Systems” I did talk about the evolution of links between different abstraction levels over time. Originally the flows from idea were disconnected and data had to be re-entered at every abstraction level. Driven by the ever growing complexity, the industry came up with logic synthesis, inventing new description languages – Verilog and VHDL – and automated the loop leading to gates and eventually implementation. Later the implementation effects of layout could no longer be ignored and synthesis become aware of layouts, i.e. became physically knowledgeable. Then variability of implementation could no longer be ignored, extending the loop of predictability and correlation between the different abstraction levels even further.

With the recent announcement together with TSMC we now have arrived at the far right of the graph I had shown in my related Blog post. The transaction-level is now connected all the way down into implementation. The top-graph in this post shows how this looks to a user at the transaction-level. Technologies have been characterized for power, performance and area (hence the abbreviation PPA). The user can literally instantiate power analysis objects from libraries and choose a related technology too be used during analysis.

What has changed from last year’s Reference Flow 11? Well, in RF11 users would generate data at the TLM-level and then feed activity data into special tools for technology analysis. Now, with RF12, this loop has been closed and everything can be chosen at the TLM level – as shown above in “Virtual Platform Analyzer”, i.e,. the tool associated with Virtual Prototype Analysis.

In the first graph you can spot on the bottom right the terminal interacting with the virtual platform running Linux on a ARM Cortex A9 Fast Model as part of a Virtual Prototype. The actual power analysis is shown in the bottom graph of this post. Users can trace processes running in software on the multiple CPUs, track the different states of the power models and follow the energy traced throughout the CPU and associated peripherals and compute engines like the H.264 decoder in the system.

How cool is that? Now that we are closing this loop, the next level is already on the horizon … the next description level may be independent of hardware and software. UML and SysML, here we come!

The big topic these days seem to be the effects of 3D and silicon technology. Even though I am now more of a system-level guy, I do have full appreciation of technology effects given that for the first chip I developed, I had to design a three transistor memory cell which ended up in a FFT Chip for HDTV research. An interesting question I get asked more often these days is how the changes in semiconductor technology and assembly will impact the system level. My answer is: profoundly! How fast we will get there and how disruptive they will be, remains an open question to me.

When I developed the FFT chip mentioned earlier it was using Cadence Edge. Oops. I just gave away my age, did I? Needless to say, as indicated in the graph on the left, we did use RTL for verification only, had our own library of layout cells which we did assemble by hand based on gate-level schematics entered manually.

Later that decade I evaluated Logic Synthesis for the “Deutsche Telekom”. Great stuff, combining RTL and Gates and mapping from one to the other.

Well, even later that decade I arrived in the US, being very much involved in system-level already, but following closely the activities around what was at the time called “Physically Knowledgeable Synthesis”. Layout had been added to the mix and its effects were added into the logic synthesis process because the good old metrics of predicting the connections between blocks and gates had broken.

New decade, new challenge. Variability in manufacturing broke the good old flows and had to be considered as part of the equation. As commonality, in every step design predictability had been improved using characterization of lower-level technology effects.

So where are we today? Transaction-Level Models (TLM) still had been disconnected from the implementation process. That is, until last year, when we rolled out characterization of technology for low power all the way up into TLM models as part of the TSMC ESL Reference Flow. As a result the links from TLM based design to implementation are becoming tighter, predictability improves.

So back to the original premise – will technologies like 3D change design flows all the way up to the system-level? Absolutely! Are we ready from a technology perspective? Pretty much so. System-level tools helping with the “What If” decisions are pretty much agnostic to whether they deal with chips, chip-sets or systems. A good example are tools for Multicore Optimization. Their applicability goes well beyond the chip, they are used to make architecture decisions for chips, for chip-sets as well as for boards.

There is one caveat though, and it is a huge one. These tools need models to feed them and the models determine their applicability. Case in point, if the tools for Multicore Optimization are supposed to help with assessing the “what if” around 3D effects – for example how the partitioning of the memory amongst chips will impact performance – then appropriate models need to be available. Here is where the battle will be fought and the effort will have to be spent. Without models we will be lost.

Still, approaches like the TSMC ESL Reference Flow – which provides models of the technology all the way up into the level of TLMs – are a clear indicator that we are approaching the next level of integration, essentially creating predictability via characterization all the way up from TLMs to implementation. However, availability of models will determine when these approaches will become mainstream!

Before March Madness and the Final Four Butler win become too much of a distant memory, I wanted to briefly write about a different kind of “Final Four”, the four challenges which KH Kim, Executive Vice President, Samsung Electronics, Co., Ltd., presented at day three of the recent Synopsys Users Group (SNUG). The audience was in for a treat, the presentation was great in structure, content and delivery!

First, KH Kim was setting up the challenges using great examples from his ASIC view of the world. Worldwide consumer electronics sales was growing by 13% in 2010 and projected 10% in 2011 driven by smart phones, TVs and PCs, Apps are a major trend for all devices in video, gaming and business. The mobile Internet together with “apps everywhere” is accelerating smartphone adoption, which in exchange becomes the connective hub with other devices & services. TVs are becoming the hub for home entertainment, integrating gaming, internet, and video services. An finally, ubiquitous connectivity and consumers’ demand for 24×7 connectivity leads to a cloud and web-centric world. All this led to the set of graphs shown in the first picture I took here, summarizing the implications for SoC Design. Processing – the combination of CPU performance and GPU performance – Samsung sees growing by a factor of 50 from 2010 to 2012, while bandwidth requirements, the combination of memory and network bandwidth is growing by a factor of 250!

From this daunting prediction, KH Kim went on to articulate the “Final Four” Challenges in SoC Design:

• High Performance with Low Power
• Given challenges to CPU Performance and GPU Performance, SoCs can only be kept within Low Power budgets using Multicore CPUs (of course only shifting the challenges into programming), Multicore GPUs, low power design taking into account application scenarios and HPMG processes enabling transistor scaling.
• High Bandwidth
• The bandwidth challenges on memories and networks can be addressed by increasing 4G network bandwidth, the switch to serial interfaces to avoid signal skew and cross talk and Through Silicon Via (TSV) increasing electrical performance and overall memory bandwidth
• Design Complexity
• According to Samsung new features & functions have increased the IP count by more than 22x from 90nm to 28nm, gate counts have increased by more than 16x, while the chip size only doubled. As solution, process migration becomes a must to deal with the increase of chip sizes and 3D ICs with TSV seem unavoidable.
• Short Turnaround Time (TAT)
• Well, the rate of growth in design productivity is still much lower than Moore’s law resulting in increasing design times, while product life-cycles are shortening over time, which demands fast design TAT. The only way to deal with that are the use of IP,which Samsung sees evolving into sub-systems of discrete IP blocks connected through busses doing computation and communication. Software is overtaking the hardware effort and the trend toward multi-core designs further complicates software development & debug. Samsung sees Platform Based Design as a key requirement, for which virtual prototyping has emerged to enable early (pre-silicon) software development. Finally, Samsung sees ESL (Electronic System Level) design being at the early stage of adoption to close the design productivity gap!

As a system-level guy I am of course very much excited about Samsung adopting and pointing out system-level design as key solution to the fourth challenge.

High degrees of automation in architecture design, high-level synthesis, transaction-level modeling and virtual prototyping become key for faster TAT, higher Quality of Results (QoR) and earlier software development.

The photo I took of the appropriate slide is shown on the left … and the arrow used here  is very akin to the graph I used in the first blog post I ever wrote. System-level design has reached the foundries! It is not alone, but recognized as one of the key solutions to the four main challenges.

The road was long … but we are getting there!

A trip up to Mount Tamalpais can not only be fun, it can change perspectives. It did hit me again when enjoying the panoramic view from up there, that system-level design value is hard to articulate. When taking the “View from the Top” perspective, one is so far away from the actual design implementation that value is pretty straightforward to understand but hard to translate into actual dollars. That is indeed a challenge we find in electronic system-level design as well.

The bay area is certainly created in a quite stunning fashion, I am enclosing the picture above as proof. I have used the analogy of “world design” to explain system-level design before, so this was living proof.

Our day up there was meant to take our minds off the house re-modeling, specifically the issues with the floor and ceiling height in the to-be-remodeled family room. On the architectural plan everything looked straight forward. Quite a contrast now while we are in implementation. The dry-wall is off, a fact that causes immediate regret given the bad shape the ceiling beams. Not to mention the floor height being off by an inch and the ceiling height changing between the kitchen and the family room.

No problem, says my contractor. Well, good for him. At this point I really have only limited options to proceed. Stopping the project is not really an option, so I will pay the additional amount in tools and work to get it done.

It all sounds so familiar from being in system-level design for as long as I have. And yes, I will get in trouble for having had work-thoughts on this trip to Mount Tamalpais. When a design team is 2 weeks prior to tape out, they will probably put up the money for additional resources and tools to achieve timing closure, the last ECO etc. In the backend of chip design the proximity to tape out is so close to what the designer is doing, that the value of adding resources and tools is obvious. Unfortunately for us in system-level design, the value gets harder to explain the farther one is away from tape out. The same guy putting up the licenses to close on timing two weeks prior to tape out, is typically much harder to convince 2 years in advance to tape out to spend money on system-level tools.

On the software side we have done a better job articulating the value of parallelizing software and hardware development. On the pure hardware side it may turn out that the only way to get over this issue to get closer to implementation. That does not necessarily mean that everything has to be automatically created from early system-level descriptions, but the predictability and correlation of early results with the implementation details will have to increase. This means the loop of abstracting and characterizing data from the actual technology implementation will widen even more. We have seen first cases of that in last years System-Level Reference Flow 11 for TSMC, in which implementation details from the implementation technology have been abstracted all the way up to the system-level.

Back to our home re-model here – there was no way for the architect to know how the beams in the ceiling looked like. He worked under the assumption that everything had done up to code, which is the equivalent of relying on implementation details being done the right way. Sometimes double-checking and confirming can help tremendously …

Well, as January is always over I went back into the garage and checked my IEEE Spectrum from January 10 years ago to think about the predictions from that time. The topic  of the 2001 forecast issue was “Always On – Living in a Networked World”. Overall I am mighty impressed how accurate the outlook of the IEEE team of editors was!

My favorite article of the issue is The 21st Century Engineer by Joseph Bordogna of the US National Science Foundation. Although addressed to the overall engineering population, we EEs can find ourselves very well in here. Bordogna refers to five new capabilities that are shaping the future of engineering— terascale, nanoscale, complexity, cognition, and holism. All of them find themselves in our day to day world of system-level design as we refer to it in our industry.

• Terascale takes us “three orders of magnitude beyond present general-purpose and generally accessible computing capabilities”. Indeed, with the design starts shifting to smaller geometries, the overall complexity in our domain has grown tremendously. Moore’s Law would predict a 32x complexity increase over the last ten years in hardware alone. The addition of software makes it even more complex, perhaps not extending to the mentioned three order of magnitude, but still quite a bit, and certainly enough to push system-level design tools and method closer to mainstream.
• Nanoscale “will take us three orders of magnitude below the size of most of today’s human-made devices”. OK, no question there now that we are discussing 16nm/15nm technology nodes.
• Complexity to the point “where the components of a system never quite lock into place, and yet never quite dissolve into turbulence, either…” (referencing Mitch Waldrop’s book “Complexity”). Well, things lock well into place in the world I live in (and can go to layout afterwards). But still, complexity has grown so much that we are now approaching – according to latest Semico data – 57% IP Reuse in chip-design expecting it to grow to 73% in 2015. Just the number of IP blocks per chip has grown to an average of 50 in 2010 and is expected to grow to 113 in 2015. For comparison, a 2006 Semico report has the percentage of re-use in 2001 at about 10% and the average number of re-used blocks at around 10. Quietly IP Re-use has addressed over the last ten years part of the system-level design challenge, only to create new ones instead: A big portion of today’s challenge lies in IP Integration.
• Cognition, defined as “the mental process or facility by which knowledge is acquired”, Bordogna believes to be “on the verge o a cognitive revolution that may dwarf he information revolution”. I would fully agree and as a result we in the area of system-level design are thinking a fare share of our time of the right abstraction levels at which the systems we help to design can be comprehended. Thinking in transactions instead of signals is only one step …
• Holism, according to the dictionary is “the concept that an entity is greater than merely the sum of its parts”. Bordogna concludes that the “hallmark of the modern engineer is the ability to see connections among seemingly disparate components, and to integrate them in ways that exceed the sum of their respective capacities”. I fully agree and think we certainly could do that  more in my world, but I do see progress here as well. As a result I am more often meeting new people – not that there is something wrong with the ones I know – but it is refreshing to for example talk to colleagues about the system-level challenges in optics and mechanics. We often do find interesting new connections – like in the emerging world of mechatronics for automotive system-level design.

My other favorite, really interesting articles of this issue are:

• Philip E. Agre’s “Welcome to the always-on world“, in which the author talks about the outlook of email being checked anywhere, anytime, something which has become full reality for most of us (which device are you reading this on?).
• Linda Geppert’s “The new chips on the block [network processors]“, which talks about the challenges in networking which have lead to what we now know as “multicore design”.
• Elisabeth A. Bretz’s “The car: just a Web browser with tires” quotes Scott McNealy saying ““Why not think of everything as just an Internet node? So a car is just a [Web] browser with tires.” I did ride this car by now, Scott was right 10 years ago …

Bottom line it is fun being part of the engineering community and I certainly meet a lot of people fitting Bordogna’s description of the 21st Century Engineer, who “will need to be astute makers, trusted innovators, agents of change, master integrators, enterprise enablers, technology stewards, and knowledge handlers. They will need more than first-rate technical and scientific skills. They will need to embrace complex systems and the issues they present, and reach the right decisions about how huge amounts of time, money, people, knowledge, and technology are tasked to a common end.”