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!

Earlier this week I had the pleasure attending the Freescale Technology Forum (FTF). I was there to present on the Synopsys AUTOSAR activities, but was able to get a front row seat during Rich Beyer’s key note. I must say, the first FTF key note back as a public company after their IPO in may, left me nothing less but impressed. It also made me think about who really owns the system-level knowledge these days.

Rich Beyer’s key note opened with a brief video history lesson of former Motorola and Freescale devices, to a heart-beat-like sound track, somewhat reminding of the drums in the Terminator soundtrack. Rich opened with a discussion of challenges presented by us – the end users. Specifically he talked about the internet of things, connected intelligence, devices which adapt to our needs, have all our data in a cloud and even predict what we may want to adapt to us users. In most segments Freescale’s customers were present as well – if not live on stage, then at least via videos.

The chips Freescale develops were always present somehow, but the main event was always their use in end applications. The five “Global Diamond Sponsors” were all embedded software companies: ENEA, Greenheils, Mentor Embedded, QNX and Wind River, testimony to the fact that hardware and software are getting closer.

Five key areas were presented on in more detail:

• Smart Mobile: Here it was all about tablets, cell phones and smart devices which are so easy to use “that my mom could use them”. The new quad-core Freescale i.MX6 series based on ARM Cortex A9 was demonstrated – about one week after silicon samples were back from the fab.
• Networking: This area was all about the infrastructure development. Which capital investment becoming almost unmanageable in this area, the new Alcatel Lucent lightRadio™ (one node in Rich;s hand above) was introduced, apparently distributing the towered basestations into  much smaller array of devices, reducing power and offering major savings for operators.
• Medical: Freescale presented a very cool combination of sensors – installed under the bed and measuring heart rate and turns – with apps on a tablet bringing all your medical data together and then communicating with the doctor via a robot user interface
• Smart Energy: Fujitsu announced a partnership with Freescale around the energy network in Japan, essentially monitoring the network to optimize energy consumption
• Automotive: A triple zero is a good thing in automotive! Freescale outlined a roadmap how to get to zero defects, zero emission and zero fatalities. Apps are involved as well – together with GM Freescale demonstrated apps for the Volt – switching it on and off, pre-conditioning the cockpit and sending information from Google Maps automatically to the guidance system in the car.

In all the areas it strongly looked to me that Freescale as semiconductor company has actually more system-level knowledge than I ever expected – hence the title of this post. It is very clear that the design chain from IP Providers, Semiconductors to Integrators and OEMs is undergoing fundamental changes. With IP Providers heading towards sub-systems and Semiconductor Providers taking on more system responsibility, it will be interesting to see how the design chain will look five years from now!

One thing is clear: Embedded software and system-level design together with tools and methodologies enabling them, will be a key enabler to facilitate whatever changes are ahead.

As a follow up to the DAC workshop called “Intra and Inter-Vehicle Networking in Automotive: Past, Present, and Future”, fellow Blogger Karen Bartelson and I had the pleasure of talking to Wilfired Steiner, Senior Research Engineer from TTTEch, about the challenges of the design of fault tolerant systems.

The discussion covers a variety of topics including the importance of standards, what can happen if real time systems like car’s are not fault tolerant, the design challenges, how the relationships between IP providers and semiconductor companies work, the role of software and we even touched on how much fun standardization can be. You can listen to the full discussion here at our archive of Conversation Central topics.

The technical item which fascinated me the most, is the way how TTTEch and the standardization teams have built on top of an existing standard – Ethernet – capabilities to make timing deterministic. Wilfired explains the details of how timing packets are used to synchronize all network participants in the video below. To reap the benefits, some of the infrastructure needs to be upgraded, but for example in a car the developer has the appropriate design control to account for this upgrade.

From a design tool’s perspective – the amount of software I those systems makes the use of early software development and techniques to enable it (like FPGA and Virtual Prototyping) basically mandatory. Wilfried commented on both simulation and formal techniques during the discussion we had.

It seems like BMW will start using Ethernet for rear view camera video transmission starting in some 2013 models … it will be interesting to see how the adoption of Ethernet and its extensions will evolve over the coming years.

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.

No, not social networking in cars. I’ll leave that for a different time … This is about data and control carrying networks in cars and where they are going. Yesterday I attended here at DAC the Sunday workshop on “Intra and Inter-Vehicle Networking in Automotive: Past, Present, and Future”. It seems like Ethernet has won the battle, albeit not for all areas in the car.

First of all, this workshop was well organized, very productive and interesting – a big thank you to Paolo, Arko and Haibo for putting it together, and of course Alberto Sangiovanni Vincentelli for his championship and guidance.

What networks in a car you may ask? Most of us have heard of CAN, but there is so much more as I learned in the run-up to this event. In this post here a picture from Renesas with some annotations from our team. There are really five busses to look at today:

• CAN – most spread network in the car, some limitations with 1 Mbps bandwidth and non-deterministic behavior under high load >60%.
• LIN – low cost bus for body applications with 19.2 Kbauds and a UART interface
• MOST – designed for multimedia using optical fiber with bandwidth up to 150 Mb/s
• FlexRay – high performance (10 Mbps), deterministic, and secure network, mainly used in X-by-wire, ADAS, and high performance applications
• Ethernet – mainly used for diagnostics today, high potential for more

The morning session of the workshop did the setup from the user side. Alberto Sangiovanni Vincentelli started the day off with an insightful key note on the mega trends. He also pre-counted Ethernet as “winning 5:1” when previewing the upcoming presentations of the day. One key take away of his key note was the trend to design which fully separates function and architecture, which enables OEMs to �sandwich” the Tier 1 suppliers more by overtaking a more significant portion of the functional design in software, which then can be mapped into existing ECUs if there is enough performance left. Alberto was adamant that safety critical areas should be separated fully from infotainment like video and audio, safety being the main driving issue.

Harman International continued with an insightful presentation on the AVB extensions for Ethernet – soon to be fully standardized, followed by Prof. Huss from the University of Darnstadt describing simTD, a field test in Germany for Car-to-X applications with very interesting trial results. Raj Rajkumar showed simulations from CMU’s trials on timing guarantees in Vehicle to Vehicle (V2V) networks. What I found most interesting was that CMUs simulation showed that to be effective, only 7% to 8% of the cars need to be equipped with V2V communication. Raj also showed an App, which self-parks Boss, the  autonomous driving car which won the Darpa challenge. This certainly will come in handy during Christmas shopping when it is available.

National Instruments complemented the presentation from Harman with more details on AVB for Ethernet, TTTech gave a great overview of the Ethernet extensions to make Ethernet ready for timing critical and fault tolerant use. Austriamicrosystems did present a future which will see a symbiosis for in-vehicle networks.

After the morning sessions had kicked off with the design issues around Ethernet and left me with the impression that Ethernet is winning for most areas, I kicked off the afternoon session with an overview of challenges and solutions spanning from AutoSAR based architecture analysis, through signal integrity issues when laying out the network, though Ethernet IP and software development for testing. Mentor followed with their AUTOSAR and harness related offerings, Cadence focused on Ethernet IP. Further design solutions for networking related architecture development were presented by aquintos/Vector and Mirabilis, Symtavision closed the day with an overview of migrating from CAN to FlexRay and Ethernet using their formal techniques for timing analysis.

Most valuable was the Q&A. I bluntly asked whether Ethernet is winning or not and the answer was “mostly”. Ethernet definitely has a bright future for video, audio and infotainment in general, but also for more timing critical applications. It’s only downside seem to be cost and EMC issues. FlexRay is definitely not dead it seems, as it used for some timing related applications still. I also asked what the next bus will be which we tool providers need to prepare for. One answer pointed to wireless protocols as next frontier, which makes sense, as weight of cables is a constant target for cost and fuel reduction. Finally I asked who will actually own the other side of the vehicle to infrastructure (V2I) networking as somebody needs to manage traffic and all the data collected. This seems to be an unclear issue and the parties involved in current field trials mentioned that the OEMs need to get together to stimulate that portion. Lots of government and regulatory issues are at play here. It might be easier to create this infrastructure in areas like China’s future megacities, which are just being  planned and built.

Overall a great workshop with interesting insights. Ethernet definitely seems to have a bright future in cars!

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!

I have driven what could be the future of Urban Mobility. I have driven in it, to be precise – somebody else was controlling it. The future looks exciting, a bit concerning at times, but definitely interesting. Interesting especially for electronics, because the type of developments necessary to enable future Urban Mobility is pretty mind boggling and a definite driver for semiconductors and new design techniques.

But let’s back up … what is Urban Mobility? By 2030, according to a presentation recently given by GM at the SMART Technology Conference in San Francisco,60% of the world’s population will live in urban areas, up from 50% today. Within 20 years, 80% of wealth will be concentrated in cities. And as the urban population increases, traffic congestion in large metro areas will become an even bigger issue than it is today. If you have traveled to Taiwan, you have seen scooters everywhere. Similar scenarios are true in Chinese metropolitan areas with bicycles. As congestion improves, Urban Mobility becomes a real issue and concepts like GM’s EN-V may offer a solution.

Courtesy of GM-Ventures I was able to check out two of the rare concept cars in their Palo Alto office. The picture here shows me in the EN-V Miao (Magic). The one I was actually able to drive in is called the EN-V Xiao(Laugh). Quite cool. It feels essentially like an enclosed Segway for two people. When starting, it lifts off and balances on two wheels (here is a pretty cool animation of the chassis and drivetrain).

In terms of electronics, the EN-V is a goldmine for future electronics. It features GPS, a smart phone for remote parking and retrieval, a forward vision sensor for object and collision detection, and forward range sensors for slow speed object and collision detection. The En-V drives autonomously so that passengers can relax and do video conferences with friends and family while on the way to work. It finds parking spots itself and communicates with other vehicles on the road, for example, to negotiate access while approaching intersections. I have seen videos (animated that is), in which the EN-V approaches a four way intersection without stopping – all courtesy of object detection and inter-vehicle communication.

The design challenges in a complex system like that are huge and offer great potential for more and improved design tools. Just think of laying out the network within the device and all the cross-talk effects. The protocol and software effects for networking within the vehicle as well as between vehicles are a definite challenge. The coordination of all the information necessary for driving and presenting it using a Human Machine Interface (HMI) is a very complex task in itself. And of course bringing together all the mechanical and electronic effects will require complex cross-domain simulation.

The EN-V is a concept vehicle today. If it becomes a reality then automotive electronics will create even more complex challenges and require new design techniques. The industry is definitely well aware. If you want to hear first hand about some of the requirements, challenges and potential solutions, there will be a full day workshop called “Intra and Inter-Vehicle Networking in Automotive: Past, Present, and Future” at the upcoming Design Automation Conference in San Diego. I will be there and give a presentation how Synopsys enables design for automotive applications. Join us for the discussion, I am looking forward to seeing you there!

The embedded systems conference is a mystery to me. It always has been. And this year it has been the weirdest of all. A dinosaur? Really? Yes, really, I too the picture of “Samson” below …. Something is not right here. Aren’t they a sign of extinction? I must have missed something in my marketing class. Or the engineer in me is finally trying to break free again and does not get it. No wonder, according to the “Specimens of Tyrannosaurus” Wikpedia page, I also had missed the eBay auction in 2000 in which “Z-rex” was not sold for $8 million and then was subsequently renamed. Oh well.

While the technical conference program looked great – the tutorials have become the main attraction of ESC and are definitely worth their money – attendance on the show floor was light but steady, at least on Tuesday, when I attended for some analysts and partner meetings. Walking the show floor, the exhibitors varied from software programming, lifecycle tracking, compiler, OS, small and bigger board companies, chip and microcontroller vendors to the multi-core zone and the “close-to-embedded” EDA companies Mentor, Cadence and Synopsys.

We at Synopsys had a small booth, we focused on showing our FPGA prototyping, FPGA design tools as well as our embedded offerings around processor development and virtual prototypes. We did not make any announcements. Mentor was present with their “Mentor Embedded” division and announced their integrated development environment based on the GNU Toolchain based on the technology and tools previously acquired from CodeSourcery. In addition, Cadence announced what they call their System Development Suite.

At Synopsys we are serving the market needs of system designers and embedded software developers for a while now. We have made significant investments via several acquisitions. It is nice to see that another big EDA player now also follows and validates this market. The actual announcement was well executed and is naturally anchored on their strength of emulation and RTL simulation. Building on those incrementally the two elements of FPGA based and virtual prototyping, makes perfect sense from where they are at. We will see how a Linux-centric, “hardware-out” approach will work for users when the actual tools come out “later this year”. Undoubtedly the need for better system design tools and more productive software development is strong, as is the need for connections from the system-level to implementation and verification. Synopsys is just wrapping up a worldwide seminar series in which we demonstrated a complete systems to silicon verification solution.

At the end of ESC Mentor took home the VDC Embeddy Best Software Product award. And on Wednesday, just to close the loop back to dinosaurs and times long passed, something unexpected happened in San Jose. While I was happily (and slightly chilled) traveling in Ontario, temperatures in San Jose crept up enough to cause a rolling power black out. As I later heard via phone, my wife was in the midst of a press briefing when the conference center turned pitch black. The effects are nicely described by Bernhard Cole in his Editor’s Note at embedded.com. I guess the only one happy and comfortable in his natural, electricity-free habitat, was probably Samson …

The bottom line from ESC? Diversity is king in embedded! The mix of software tools, OS, board, chip, microcontroller and EDA companies still offers an interesting dynamic. I will definitely be back next year, but will be just as happy without Samson.

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!