Archive for the 'ESL Market' Category

How to win over the embedded software developer, their customer and their boss.

By Nithya Ruff
Achim Nohl was taking a well-deserved vacation last week and asked me to be his guest blogger. To many of you who are regular readers of Achim’s blog, I am new to Synopsys and joined only a few weeks ago to manage the Virtual Prototyping product. I came from Wind River where I managed Embedded Linux product marketing. Having come from 20+ years of managing software of all kinds, I saw the guest blog as a perfect way to talk about a software marketeer’s view of virtual prototypes and embedded software development.

I still vividly remember the manual and tedious process of debugging the operating system I had written in my computer science OS 401 class. Not only was the data not all in one place, it involved reams of paper and tracing the calls manually. Frankly, it does not feel any different these days in the world of embedded software. Every element of the device stack is put together separately, and often there is no holistic view of the entire device. Debugging and testing is more of an art than a repeatable and systematic science. Let’s look at why this is so.

Embedded systems cover everything from very small systems inside watches, to sensors in a building, to complex multicore-based core-of-the-network systems. They share the characteristic of being dedicated to a specific function and not being general-purpose. These systems often require real-time performance and a smaller footprint. Everything is customized to fit the task—the Operating System (OS), middleware and applications. Given the wide range of applications, the choice of the hardware is specific to the device being created. The software stack created is influenced by the hardware characteristics and behaviors. Hence, there are all kinds of hardware architectures, and even many variations of custom hardware used in the embedded device space. In fact, hardware is the first and a key component of the decision making process for a project. The rest is built around the hardware selection.

In the late 1990s and early 2000s the success of Linux in the server space began to bleed over into the embedded space, especially in networking. Linux was inexpensive to acquire and provided almost everything needed, such as tools, protocols and trained people. Most of all, it provided access to source code and could be modified as needed. Linux also was available on other architectures such as ARM, MIPS, and PPC and X86. This was important to embedded developers so they could select the right hardware for the task at hand. Chip vendors had started using Linux in their boot-up software and in SDKs due to its openness and broad appeal. They contributed changes upstream for their architecture and made sure architecture and chip-specific drivers and code were in the mainline kernel branches. They made it easier for the average embedded developer to use their chip sets. This adoption of Linux was just the beginning.

The next major development in the embedded space was the availability of software stacks such as Android. In 2007, when Android was released, the mobile handset software industry was fragmented with dozens of flavors of OSes and stacks to create mobile phones. Around that time, the launch of Apple’s iPhone had set the bar high for the smart phone market. Apple had managed the selection and integration process tightly from hardware, OS, apps, user interface (UI), manufacturing and even the service provider to deliver the phone. When introduced, the Android stack was another disruptive force in the smart phone market, making it possible to use a fully integrated stack aimed at mobile devices. It contained all the layers that phone OEMs in the past had to painfully put together. This enabled OEMS to focus on their differentiation at the UI and application layer to get to market faster. Seeing the Android example, other more complete stacks were created in the consumer space such as the set-top box stack and the gateway stack.

The embedded software development process historically has been a waterfall process. The chip is designed first with the OS bring-up and software development happening when the first silicon is available. Next, the semi enablement teams spend time to ensure that the tools, OSes and sample code actually work and create an SDK to ship to their ecosystems and early customers. By the time the average systems company can start developing devices it is a good six to nine months after the silicon has been released. There is also a good deal of duplication in effort on the software side between what the chip vendor does, the ecosystems and what tool companies do, as well as customers. There is delay and duplication in the value chain and no common tools, methodologies or processes used across the embedded commercial and open source ecosystems.

The increase in the complexity of SOCs and software involved in embedded designs, as well as the increased pressure to get differentiated products to market faster, makes it uncompetitive to do things serially, without some common practices, methodologies and an integrated hardware and software approach. More and more hardware companies are thinking of themselves as systems companies that need to take a user/application driven approach to designing their SOCs, and not the other way around. These innovative companies are creating integrated hardware-software teams that work together right from the start on a common design. They create a virtual prototype of the SOC as a model, which they share throughout the design process to collaborate and to ensure that not just the OS but any reference and sample applications and application software are also tested for application scenarios. Virtual Prototypes or software models of the hardware have become the common language that both teams can speak to debug and develop the platform.

Using such a common reference point avoids misunderstandings and creates a cohesive plan for the SOC. Being in software, these virtual platforms are instrumented for optimal debugging and visibility into the execution flow, providing a bird’s-eye view of a command and sequence the code is executed in. A more final prototype can be shared with lead customers months before the hardware is available, thereby winning sockets that would otherwise have been lost. The prototype also can be provided to the software enablement team and key field application engineers to get them ready for the chip launch. Often, the silicon enablement elements, such as tools and software are key criteria for OEMs in their selection of silicon. By the time the first silicon is available, the field is ready, lead customers have had a chance to evaluate the SOC and OS vendors are ready with their tools and support for the product. The impact on socket wins and cost of enablement is significant.

A common myth is that once hardware is available, the virtual prototype is no longer needed. Because the software-based prototype is easy to share, and provides more controlled debugging and wider visibility to trends, there are numerous other ways to leverage these prototypes. OEMs or systems companies can use this to extend and deepen their development, debug and test process. Just as the semi tools did, OEMs/Systems companies can use these prototypes as a common medium for debugging and communicating across distributed development teams.

Often hardware is hard to ship and can cause delay or be damaged in the delivery. The hardware complimentary virtual prototypes extend and enhance the software development process significantly. There is an increase in software integration complexity for OEMs because of the different sources of software. This makes regression and system testing very challenging. Virtual prototypes and the analysis tools that come with them provides the ability to test the whole stack with a holistic view of the flow, from the user interface down to the hardware. Imagine being able to see what the impact on power utilization is when a browser on a phone is opened—or the performance hit as a result of uploading a video to your Facebook account. All of these can help optimize applications and devices for power and performance. I wish I had these tools when I was debugging my OS in class.

So for a software geek like me, having the target hardware in a software layer is very attractive and makes it a valuable key element of the development process. It reduces the wait, provides more controls and empowers me to create a more integrated and complete device. I can see the possibilities and the transformation of embedded software development from looking at the problems with new eyes. I am won over by the benefits of virtual prototyping for embedded software development and see more of us using this to build smarter and cooler devices. I look forward to sharing more of my embedded software perspectives in the coming months as Achim’s guest blogger.

—Nithya Ruff is director of product marketing for Virtualizer Solutions at Synopsys.

 

Virtual prototypes are essential to effectively debugging a system and still meeting market windows.

In my last blogs I have been focusing on introducing the technical advantages of virtual prototypes in the context of debugging embedded software. In this blog I would like to introduce how this can impact an entire supply chain.

The increasing complexity of software in terms of code-size, functions and layers, along with multicore SoCs, also demands more capable debug solutions. Those debug solutions have to go beyond a single CPU and provide a holistic view of the entire system with all its signals and registers for internal and external communication. A virtual prototype can deliver on those requirements independent of the hardware design schedule. Early, more productive and predictable debugging provides real advantages to VP adopters today. But it becomes even more compelling when you extend these advantages to your own customer, or even the customer’s customer. In the context of a supply chain, the impact of this time advantage can be multiplied with each stakeholder.

For example, Altera recently announced availability of the “Industry’s First Virtual Target for Software Development on SoC FPGAs.” “Virtual Target” is the term used by Altera to describe the virtual prototype (VP) for its SoC FPGA. Altera has identified VP as an essential tool that enables its customers to bring up their software earlier, more efficiently and with less risk. This again enables their customers to be ready for the market faster, with better quality software.

However, what’s also important for successful VP adoption by software developers is the support of a standard software development ecosystem. Before being able to educate software developers and convince them of the value of new complementary, VP-enabled debugging methods, it is important to make sure the software developers can use the software tools they are familiar with. I have seen that users quickly realize how much more they can suddenly do with a VP. Often this requires just a few hours of sitting together and doing some hands-on exercises with the user’s software.

When VPs are used to virtualize FPGAs and enable software development for custom hardware extensions, a few more aspects should be considered. In essence, the extension of the VP with hardware such as accelerators or peripherals is important. Otherwise, the VP cannot be used for custom device-specific driver development. In this case, the extension is achieved through an FPGA-in-the-loop extension where the real FPGA is connected to the VP using a virtualized PCIe interface. The advantage of this approach is that RTL can be re-used by the customer. Peripherals can be tested with the real hardware PHYs and real I/O. Custom accelerators, for example video and wireless, can be tested with the final targeted performance in context of the software. Altera offers this extension with its new SoC FPGA in its recently announced Virtual Target.

Of course, Altera is not the first to make this connection between early software development and the supply chain’s needs. The mobile industry has been working on this for some time. As software complexity grows at even the lowest layers of the SW stack, such as the OS kernel, drivers and middleware, the benefit of early customer enablement becomes more and more important for SoC vendors.

For sure, the general concept of using simulation for supply chain enablement is not new. In the context of enabling application developers for mobile phones, simulator-based SDKs have a long history. A big success story for simulation-based SDKs is, of course, the iPhone SDK and Google Android SDK. The first phone, the HTC Dream, was released in October 2008. Currently there are 167 apps available. To a large extend this has been enabled through the Android SDK, which Google released as an “early look SDK” version in 2007. The Android SDK uses the popular Qemu emulator for ARM as a back end that simulates an ARM-based hand-set. This is similar to a VP, but in general is more generic as some HW is even functionally abstracted. Google has achieved two important goals with this:

1. Google has educated a huge SW community on its product.
2. Google got a significant amount of feedback from developers that are already familiar with the iPhone to improve Android for its 1.0 release in September 2008

Today mobile device manufacturers are continuously extending their software-based emulators to support their custom hardware and win new software developers for it. For example, Kyocera is providing add-ons to simulate its “Dual Screen” devices, LG offers support for “Real 3D” and Samsung enables SW developers for their “Galaxy” Tablet.

Again, a significant additional benefit is that customers can provide feedback much earlier about concept flaws or unmet requirements. And when using a VP this can happen early enough so that problems can still be fixed without going through silicon re-spin. While the mobile device industry seems an obvious case, it’s interesting to note that the FPGA industry’s complexity has advanced enough that Altera has invested in virtual prototyping. So, who’s next? Xilinx?

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.

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.

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.

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!

This is really a companion Blog to an article I recently wrote, called “Which Design Comes First: Hardware Or Software?”. In this article I argued that the landscape of software responsibilities is rapidly changing, and with it the way the different players can actually make money. I ended the article with the words “Chip vendors are trying to battle their way back into monetizing on software after Android essentially neutralized them. The hardware-software world remains very interesting!”, Well, this deserves some examples.

First, the neutralization piece. Neutralization may not be the best term. Equalization might be better. Bear with me for a second here. As of today, March 30th, the graph on the left is the best I could come up with to outline the dependency of silicon on end user applications. 728,084 applications is the sum of all available apps of the main application stores from the list of digital distribution platforms for mobile devices. The top six application stores are the Google Android Market, Apple App Store, Palm/HP App Catalog, RIM App World, Nokia OVI Store and the Windows Phone Market Place and they map the applications into an installed base of roughly 964.5 million users. When checking the application stores and counting which mobile devices they map to, one arrives at a total of 230 mobile devices on sale:

• A comparison of Android devices yields 106 smart phones and 42 tablets
• The Apple App Store really maps to four devices, iPad, iPhone, iTouch and iPod
• The HP/Palm App Catalog currently maps just to the Palm Pre
• The RIM App World maps to 7 phones and 1 tablet
• OVI by Nokia maps to 26 rows of 5 phones, that’s 105 devices
• Windows Market Place maps to 11 phones for version 6.5 and 6 phones for version 7

What does that mean for a semiconductor company? Well, in the Apple universe 48% of all applications map to 17% of the overall installed base but to only to four actively sold devices. It’s an “all-or-nothing” game. In the Android universe 41% of all application map to 8% of the installed base but 52% of the overall available devices. Much more room for silicon here, but a crowded space. Hence Android effectively neutralizes hardware dependency. Everybody can play!

So how does one make money here? There is selling the silicon, selling the device, selling the two year contract with it. And then there are applications. According to Techcrunch and IHS Screen Digest, “Despite 861.5 Percent Growth, Android Market Revenues Remain Puny”. Well, in 2010, Apple App Store made 82.7%, Blackberry App World 7.7%, Nokia OVI Store 4.9% and the Google Android Market made 4.7% of the $2.155 Billion made with applications. The key is the separation of software and hardware revenue. Apple, RIM and Nokia all make money with the hardware and the software as they take a cut of the application revenue. For all Android devices, the hardware is one piece, and the cut of the software revenue is separate, it goes to Google and other Android app stores out there.

So how does a semiconductor company play in this landscape? With great difficulty? Perhaps. Let’s see what the 2010 top 5 fabless semiconductor companies are doing:

• Qualcomm has embraced Android quite some time ago and has been referred to together with it as the new “Wintel”. One specific step to deal with Open Source was taken by Qualcomm in 2009, when the spun out the Qualcomm Innovation Center, specifically with the “goal of investing greater resources into enabling and optimizing open source software with Qualcomm technology [….] to enable the faster advancement of the wireless industry as a whole”. The mission is simple: Make sure Qualcomm silicon works with open source software as well as possible. Driving ports and releases of Android and other open source projects makes sure that they run well with Qualcomm Silicon.
• Broadcom now has fully embraced Android in product and at the executive level after they had been initially cautious.
• AMD is investigating Android for tablets
• Mediatek is driving Android into lower cost areas
• Marvell has enabled Android for a while already for tablets and mobile devices. It recently has made probably one of the bolder moves of the top 5 fabless players. With Kinoma they acquired a maker of software which augments Android, As quoted by the Wall Street Journal on Kinoma’s page, it allows to “better navigate media-related Web services — without having to buy a new mobile device”. From a fabless semi perspective, augmentation of Android gives Marvell an edge in the pack of chips supporting open source. Not only can they make sure Android runs effectively on their silicon (like Qualcomm as described above), they now can also drive how their chips best support Kinoma on top of Android, essentially wrestling themselves back into monetization via the software their devices enable.

It turns out that for semiconductor providers the life outside of Apple is quite interesting. Embedded software is the key enabler and as shown above the top five fabless companies have realized this and are running with it. Oh, why do I care? The system-level tools I am involved in are the bridge between hardware and embedded software. Chip developers desperately need system-level design methodologies to optimally utilize and monetize the trends above.

There is a reason why we are showing Android running on virtual platforms in our cloud demos …

As always – I am looking forward to your comments …