Archive for the 'Embedded Software' 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.

 

In the last month, I had the opportunity to get some hands-on experience with hardware virtualization and hypervisors. My knowledge so far on this has been mainly limited to what I could read about it and what other people are saying about it. However, the PowerPoint slides I’ve seen leave a lot of white fog between the bullet items. This didn’t make me feel very comfortable talking about this topic myself; but, there was no escape. Hypervisors play an increasingly important role for system designers in context of supporting multiple guest operating systems on the same device, or taking advantage of ARM¼’s new big.LITTLE^TM processing. The fog is not all gone, but let me provide you some insight on what I found out. As a disclaimer, I’m not going to (and I cannot) write an expert almanac about all the aspects of virtualization covering Xen, VMWare, etc. Instead, I’m going to focus on my personal experience that I believe will be relevant to you as well. This post is the starting point for a series on this topic in this blog.

Clearing up terminology confusion

The fact that this whole concept is (also) called “virtualization” is high on the list of the top challenges I was facing when explaining it to my colleagues, or management. As a background, I am working in technical marketing in the area of “virtual prototyping,” and our product is called “Virtualizer.” In order to avoid the same confusion here, let’s separate those terms in context of embedded systems:

1. Virtual prototypes/Virtual platforms (VP): A virtualized embedded system in the form of a simulation on a host PC for the purpose of developing the embedded system (HW and/or SW).
2. Virtualization using hypervisors: An embedded software (ESW) layer between the operating system (OS) and the embedded system hardware. The hypervisor can serve multiple guest operating systems and bridges differences of the real underlying hardware and the target hardware for which the OS has been built for.

I used a VP on my desktop PC to bring up ARM Linux along with an embedded hypervisor. Using a VP, I’ve been able to integrate, run and debug a software stack including Android, Linux and a hypervisor on an ARM big.LITTLE processing-based system. The VP integrates Fast Models from ARM to simulate the processors.

big.LITTLE processing?
The first example of this processing concept combines a high performance ARM Cortexℱ-A15 MPCoreℱ processor along with an energy efficient Cortex-A7 processor. The two main use-models which have been introduced by ARM are called “big.LITTLE Task Migration” and “big.LITTLE MP.” Those use models are nicely described by the Linaro organization.

The so called big.LITTLE Task Migration use model is that the software can seamlessly migrate from one processor to the other, depending on the use context and resulting performance requirements. It sounds like this requires a heavy re-write, or modification of the software stacks (e.g., Linux/Android) to support this; in fact, it doesn’t. This task migration is achieved by having the software run not on the hardware, but on-top of a new layer. This layer operates in the hypervisor mode and performs the task-migration without Linux/Android even knowing about it — although, the Linux/Android power management will initiate it as illustrated in the next figure.

Hypervisors and Interrupts
The task of the hypervisor software layer is to shield the hardware and payload (e.g., Linux/Android) software from directly communicating with each other. We call Linux/Android payload, as it is the software the user is intending to run. Why is a hypervisor needed? Interrupts are a good example here. Let’s assume we run multiple guest OSs on a system. Interrupts coming from the hardware could be for either one of the OSs. Therefore, a hypervisor needs to first intercept the interrupt from the system, and then decide to which guest OS it was addressed. For big.LITTLE processing it’s the other way around; here, we have multiple processor clusters sharing the same interrupt controller. The hypervisor (open source example available here) ensures the transparency of the clusters for the OS and does the task migration. But, the hypervisor needs its own interrupts and should not interfere with the OS.

Hardware Supported Interrupts Virtualization
In order to enable interrupt trapping in the hypervisor, ARM provides specific hardware support in its processors. In the processor’s hypervisor mode, a higher privileged exception vector allows trapping interrupts even before the OS can react on it. Thus, when an interrupt come in, it is the hypervisor that first handles it. If it is for the OS, then it will configure a virtualized interrupt controller, which is a replicate of the real interrupt controller seen by the OS. The OS will then handle the interrupt as if there was no hypervisor in between. Here, the MMU (Memory Management Unit) virtualization plays an important role as well. More about that in my next blog.

Interestingly, an interrupt has quite a way to go before it arrives at the user’s application, all the way from the hardware, through the hypervisor, into the OS. Virtual prototypes are extremely useful for debugging this chain, as all aspects of the system can be observed and traced as shown in the figure below. 

Keeping the overview on what is going on and having a bird’s eye view to assess where things go wrong are really helpful here. Where does the interrupt stop? Stuck in the hypervisor? Not arriving at the interrupt controller? The VP ensures that at any time the different layers of the SW and even HW can be traced and debugged to spot and identify software integration bugs. First of all you have clarity on which CPU is currently active. Second, you can spot the time where the actual interrupt arrives from the hardware. Next, tracing of the system is possible across the layers of the software, from the hypervisor up to Android. The VP tracing and debugging is aware of the hypervisor layer by tracking the mode that is exposed from the underlying CPU models (ARM Fast Models). Furthermore, debugging services are always available, because debugging does not depend on any embedded software daemons to function. This is very useful for debugging the interaction between the hypervisor and the Linux kernel. You can simply have one debugger attached to the hypervisor, and another one attached to the Linux kernel. This becomes really compelling when debugging the task migration. Even during phases where one CPU is powering down and the other is powering up, debugging and tracing is possible without limitation. This is a delicate phase as the entire context of one CPU is saved and subsequently restored by the other CPU. This can result is obscure and hard to find defects, for example,  if the context saving is incomplete because it forgets about saving the secure mode registers. I will write more about the task migration, in context of energy/performance optimizations in a follow up post.

If you’d like to see a live demonstration and explanation of all this, we’re presenting at the DesignWest Conference (formerly called the Embedded Systems Conference) in San Jose in the ARM Partner Pavilion and also in a joint technical session with ARM as part of the Android Summit. You can also see a demonstration from ARM and Synopsys at SNUG Silicon Valley this coming Monday, March 26^th at the Designer Community Expo or Tuesday, March27^th in the afternoon tutorial of the Systems track.

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.  

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.

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!

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!