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.  

In order to give software developers the ability to profile the impact of software changes on energy consumption, the underlying execution target needs to expose the energy consumed by the different components that make up the system – over time and ideally through the perspective of software activity. Therefore, the profiling environment needs to be able to quantify the energy contribution from the different platform components.  However, development boards with power measurement probes are only accessible for a handful of software engineers, and are typically made available too late in the design cycle to allow development and testing of the power management software functions.  Moreover, they are not available to the community of application software providers whose software has significant influence on a battery’s mileage.

The virtual prototypes that are typically used today by software developers have no notion of power. Their models are purely functional, abstract in their timing behavior and with no link to implementation or silicon process technology. If you claim that VPs can still be very helpful for software developers to get energy under control, it is likely that hardware engineers will view you as a charlatan since, from their perspective, gate-level simulation is a minimum requirement to gain a decent impression on the energy footprint of the system. This is somewhat true, but the hardware engineers have a different problem to solve. Software developers do not intend to optimize logic circuits. Instead, they need to make sure they utilize the system power management features in the best possible way. A debuggable, repeatable, deterministic, scenario-driven trend-based analysis of the system’s dynamic power consumption is more relevant for them, then the ability to derive the exact energy consumption of the system (uWh). This task is perfectly feasible with a VP.

Here, the characterization of the important power states and events in the system components is the most relevant task. For example, a CPU can switch to the lower power idle state if software synchronization is performed via a semaphore rather than a spin-lock style active wait. The LCD brightness can be reduced if no user interface interaction is required. A position update can be done via 3G or GPS with different power states and durations. Exposing the power states is of great benefit to the software developer, but even energy-trend estimation can be accomplished with coarse grain, state/event-based characterization from datasheets.

The question is will the incorporation of power data into system simulation simply increase the complexity of the modeling problem? In addition to making sure that we have all of the functional models, do we now also need all of the associated power models? The answer is no. Power and functionality can be orthogonalized. With VPs, power models can be provided as an overlay to the functionality of the VP.  Through the introspection capabilities of a VP, functional models can drive power model overlays through observable properties such as signals, registers or other instrumentation. This allows the user to create power models for only the aspects of the system s/he is interested in.

A single VP can be characterized to reflect the energy dynamics for very different system flavors. A functional Ethernet model can be characterized to mimic different hardware vendor parts and can be even characterized to mimic the dynamic power of a WiFi radio. A WiFi radio may transmit/receive in low power or high power state depending on the data rate requested by the software. Such a coarse grain WiFi power model can be driven by inspecting the data rate of the generic Ethernet model.  This is sufficient for many software design decisions and proven by the success of the Power Tutor Android Application. This Android application comes with power models for various hand-sets (e.g. HTC Dream/Magic), and implements such a WiFi model with surprising accuracy. In this case, the power models are driven by embedded software.

Here lies another big opportunity for VPs. We can use embedded software functions (e.g. driver suspend, resume, send) to realize power models for parts of the system that are not even functionally modeled in the VP. Now we are starting to use VP as an enabling tool for software developers, rather than a pure simulation model of a piece of hardware.

In the future, we expect that temperature will become part of the puzzle for the software developer. Power consumption is highly temperature dependent. Interestingly, this impacts the software developer in the choice of CPU idle management strategy (Run-Fast-Then-Stop or Dynamic-Voltage-Frequency-Scaling).

There is much more to say with regard to this topic, even going beyond the software perspective and how VPs can help to architect power friendly platforms. Also, there are a lot of imperfect aspects such as standardization of formats etc. However, already today, there is a great chance to get some aspects of the pest under control using virtual prototyping.

Have a relaxing christmas!

Some engineers will care about power, but most will care about energy efficiency. Some engineers will look at just a single block, while others care about processor subsystems and entire platforms. Some software engineers focus on a single piece of software, others care about the entire software stack.

So instead, we need to approach it from the software engineers’ intent. For example, software stacks using Android with multiple tens of millions of lines of code implement various power-saving strategies on almost every software layer, starting at the OS kernel and ending up in the application layer. A software power inefficiency or malfunction can quickly cause a 5x drop in device standby time. A Google example shows that a simple RSS feed application that wakes up the phone every 10 minutes for just 8 seconds at a time to do some updates, via the Internet, can cut the standby time of the phone in half. An almost endless list of battery drain problems reported by end-users can be found here. Of course, the most prominent example is the recent iOS bug. Why is so difficult to get this under control? Let’s examine some of the key issues:

 1. Profiling the impact of software changes on energy. A software developer needs to be able to determine the relative impact of his implementation choices on energy. For example, is it “better” to use a spin-lock or a semaphore in the Android sensor poll function when waiting for accelerometer data from the hardware? A spin-lock is faster, but does not allow the CPU to go idle while waiting. The developer needs to find the right balance between responsiveness and energy consumption. While this example only looks at the CPU, most cases are concerned with the efficient use of the other HW components, too.

Here’s another example: In an application that requires location information, is it “better” to use coarse-grained updates from the GPS, or fine-grained updates for 3G? The data needed to compare the two options are as follows: 1) the time it takes to complete the task, and 2) the power level to compute the energy (e.g. GPS: 25 seconds * 140mA at about 1mAh, Network: 2 seconds * 180mA  at about 0.1mAh). Again, the decision cannot be made only by the energy savings. It also requires an understanding of the performance demands of the particular service. Are we looking at a driving navigation or a walking navigation? Both would have different requirements on the precision.

 2. Interference and side effects of local software changes on other modules. An application or service that requires a periodic network update can trigger a cascade. Other less important services may just be waiting for a connection to be established. So instead of doing a 1 second update every 10 minutes we may easily trigger a 1 minute online activity caused by waking up background applications. Here, the software developer needs to understand those cascades through an energy profile that shows an unexpectedly high peak and an estimation of the resulting standby time. Handset makers face this interference challenge when integrating multiple software modules from various suppliers.

 3. Ensuring that multiple concurrent power management frameworks collaborate. System-wide and runtime power management are just two examples in the Linux kernel that need to collaborate. The former turns the whole phone into a suspend state and wakes it up without loss of data. The latter controls power states of hardware components while the phone is used. A typical issue is when a component that has been shut down by the runtime power-management  prevents the device from going into a system-wide suspension because it needs to be woken up first. Power management debugging can easily become a nightmare, because even debugging and tracing services are impacted and may shut down during suspend/resume phases. Moreover, wrong settings in the constraints for the voltage regulator drivers can even result in lasting hardware damage.

 4. Many inefficiencies and malfunctions only appear in usage context sensitive scenarios. Energy inefficiencies or power malfunctions are highly context-sensitive. The context is defined by how the device is interacting with the environment. Next to the user, the device and the software stack are linked to the environment through network 3G, WiFi, NFC/Bluetooth, cameras and many other sensors (acceleration, orientation, magnetic field, proximity, temperature, etc.). When optimizing software for energy, the usage scenario that drives the stimuli to the device needs to be repeatable in order to get deterministic and comparable results. Testing requires automation of those scenarios along with a certain level of randomization. During testing, developers need to check that all applications/services are implemented according to the coding guidelines (e.g. for application using the sensors, the programming reference says: “Always make sure to disable sensors you don’t need, especially when your activity is paused. Failing to do so can drain the battery in just a few hours. Note that the system will not disable sensors automatically when the screen turns off.”)

 Looking at the above challenges, it becomes clear that to effectively debug and optimize power using virtual prototypes we have to look beyond it as just a way to instrument the models with power information. In my next blogs I will explain how the four important requirements mentioned in this blog can be successfully addressed using virtual prototypes. Maybe we can tone down those software bugs’ appetites.

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?

Whenever VPs are mentioned in the context of debugging, it’s claimed that they offer many debugging advantages over real hardware. It is said that VPs have better controllability, visibility and provide determinism. But is this really true? And what does this really mean for a software developer?

For many people, a VP is nothing more than a piece of software simulating a HW/SW system. This software (the VP) can be debugged on the host PC of the user. Using the host’s software debugging tools, or VP vendor-specific tools, the user is able to inspect all aspects of the platform such as memories, registers and signals. Also, he/she can suspend the simulation in the host debugger, and above all has full control over the VP. The next time anyone executes the VP it is likely that it will perform the same functions in the same order as before, and that its behavior will be fully deterministic (as long as there is no interaction with non-deterministic external components such as the user). This all sounds great, but it does not consider the real needs of a software developer.

“Run-mode” software debugging using a VP

While a software developer is definitely thankful for inspecting the hardware beyond what is possible with a software debugger, in the first place he/she will still need to debug software.  This is of course also possible with a VP. Most VPs do contain virtualized interfaces such as USB, Ethernet or UART. Those interfaces allow a software debugger to connect to an embedded software agent. This agent establishes the connection between the debug target and the debugger. Now a VP can be easily combined with arbitrary software debug tools and even integrated into SDKs. As an example, the Google Android SDK connects to the debug target through Ethernet. This works perfectly with a VP.

Interestingly, this is not any different from the way it is done with real hardware. But unfortunately, also no real advantages exist. The praised controllability, visibility and determinism has to be re-evaluated. The control is now with the software debugger. When you suspend using the SW debugger, the VP will keep running. Timers, watchdogs and other SW processes continue to work (so called “run mode” debugging). In order to inspect the HW and correlate the platform state with the software state, you would need to suspend the VP. But, if you suspend the VP, then the debugger communication will likely time out. Remember, the embedded software agent is also halted.  Also, the agent itself influences the execution of the overall system and has side effects. Now, the determinism is also gone. But, there is a solution to combine the best of both worlds.

Virtual prototypes as debug servers

To marry the advantages of VPs and software debuggers, the VP simulation framework needs to take over the task of the software agent and act as a debug server. The debug server establishes the link between the software debugger and the VP simulation. Now we can take advantage of the VP’s “view from the top” and serve even multiple software debuggers with information from all over the platform. The debug server also orchestrates the control and makes sure all debug views are synchronized. The debug server itself does not interfere with the execution of the platform. Neither the hardware models, nor the software, can tell whether they are debugged or not. Now the VP can really play its hand and deliver all the advantages to the software engineers.  Summarizing, it is important to recognize that a VP is more than a model. A VP requires tooling to make it useful beyond simulation.

Coming back to Android and my previous post: The 21 steps to set up a debugger to debug native code can now be reduced to two. Using a VP with a debug server, you set a breakpoint at the address and process that you are interested in; afterward you simply connect the software debugger. No more worries about when and how to launch the gdb-server agent.  But VPs even help in the context of using run-mode debugging of Android native code libraries. The user of the VP can easily inject an endless loop within the start-up code of an embedded software process just by writing the instructions into the VP memories. No change and recompilation of the embedded software is needed, as required in the best practice.

I am spending a reasonable amount of my time helping our users to bring up Android on their chipsets or devices. I am not an Android expert, I gathered my limited knowledge about Android mainly during debugging. I must admit that the first tool I am using when a problem appears is a Google Search. This brings me to the respective expert forums where I hope somebody else has already done the job for me. With Android, this works reasonable well as Android produces an extensive debug log from which I can copy and paste messages into the search bar. With more than 7000 users and 16000 messages just in the Android porting group, chances are high to find something useful. Often the solution to the problem is already there for me.

Android forums did sometimes also the opposite and put me and a completely wrong track. The fact that a symptom is the same, it does not imply the root cause is also the same. Android is a huge SW stack sitting on-top of Linux, which runs on the HW. A bug is often only triggered because of a special combination of Android/Linux version & patch  combinations and the specialties of the underlying HW platform. How to get back from Googling into Thinking? Today, I try to force me limiting my Google Search debugging to 20min.  After this time I get my hands on into debugging the problem.

Hurdles of using a SW debugger for Android applications and the Android platform

Let’s start debugging the problem. Unfortunately, it is not just launching the software in a debugger and step through the code as we are used to for desktop applications. There are quite a number of hurdles to overcome before we can actually debug. When porting to new hardware, the root cause can be everywhere. Even proven applications, stable Android runtime modules or Linux drivers cannot be excluded.  I have often wasted a lot of time debugging when I have refrained myself from investigating SW modules that are said to be stable. Of course, the stability of a module has to be considered, but one should not hesitate to question and debug those as well. Just recently I have found a defect in the Android Apps installer, which has been triggered by a very specific kernel version and filesystem type (http://tinyurl.com/3b3szbj, could only reply my fix directly to the author). Debugging is not exactly easy with Android. Not because Android is so complicated, but just from a pure practical perspective it can be very hard to setup  a debugger.  For application developers, the Android SDK is providing very convenient debugging capabilities for the Java layer. The companion NDK (native development kit) allows developers to package native code libraries with their applications. But, only one year after its first release in June 2009 it actually provided support for native code debugging.  Beyond the NDK and SDK, when the whole Android platform is subject of debug, then things get much more complicated and solutions are sparse. A very useful guideline for debugging I have found in the web, it still requires 12 steps to set up the debug session and another 9 steps to connect the debugger.

Why is setting a debug session more difficult with Android?

What applies to Android may as well apply to many other integrated SW stacks. Each high level device function is delivered by the interaction of many distributed software entities, some of them may be written in Java, others in native code. Most of them executing in the user space, but a fair amount of functions of course also reside in the OS and its drivers.

Another challenge is imposed by the fact that processes and threads are launched and terminated by other processes automatically. First of all you do not know which processes are contributing to a high level device function, and even if you know, the process is often terminated already before you had a chance to connect a debugger. In order to solve that,  the best practice is to add an busy wait loop into the code and recompile the respective module.  This will give you the chance to connect the debugger at the right point in time and before the bug has eventually passed. The same technique is required when debugging on the Java/C boundary as there is no way to auto-step from Java code down to native code within the debugger. Once you can connect a debugger, it all works pretty well as long as you stay in one software module. But, it is a very tedious process as it requires to modify and rebuild software module, bundle new filesystem images, reproduce complex scenarios each time you want to debug another piece in the puzzle.

If you do not know which SW function to debug, you may add those halts to many places with dangerous side effects. Halted processes may cause time outs or simply impact the sequence of events in the system masking the bug. Many more challenges exist, but I want to stop here as I would like to switch over to talk about some solutions to these problems.

What’s next?

In my next post, I would like to introduce how Virtual Prototypes (VP) can help to overcome some of the debug challenges appearing with SW stacks such as Android. As a simple example, the controllability of a VP will help us to intercept the execution of a single SW process. Moreover, I will show you how to inject a halt without modifying the software using a VP. But beyond fixing deficiencies in debug flows, VPs enable much more if used in the right way. A VP can act as a debug server which significantly eases the debug setup and turns you much quicker from an experimenting/guessing mode into systematically analyzing the problem.

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.

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!

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

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

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

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