Tools, Testing, & Virtual Systems

Using Static Analysis to Improve Product Quality, Earlier and Cheaper

By Bill Graham

Fixing bugs is expensive. Fixing bugs is more expensive the later you leave them, in fact, its been shown to cost a magnitude higher with each major phase of development. The famous defect cost chart from Capers Jones shows the cost of a bug going from $25 at the coding phase to $16,000 in development.  Not only that, but most of the bugs are introduced into the system at this stage yet very little of them are found. Logic says we should fix them earlier to save money.

  (Source: Applied Software Measurement, Capers Jones, 1995)

 

Static analysis tools such as those offered by our partner Coverity Inc.  provide an easy, non-obtrusive way to detect defects in the source code – as it’s being coded. These tools can find all sorts of defects even before the code is submitted to version control or compiled into your integration builds. Significant and dangerous errors such as buffer and integer overflows, format string vulnerabilities and poor coding techniques can be found in your source code.  Static analysis tools are integrated into your build environment as part of your nightly integration builds, for example.  What is also extremely powerful is the integration of these tools into our Wind River Workbench. Developers can quickly and easily check for bugs in the code in the integrated development environment. A quick click and the current code file you are working on is checked for bugs.  Developers are understandably skeptical but success rate for static analysis tools is high and the technology has improved to where false positives (detected bugs that turn out to not be errors) are very low, typically less than 5%.

Using tools like Coverity’s Static Analysis in addition to automated test tools (Wind River Test Management, IPL’s Cantata++, for example) are great ways to improve the graph we see above.  Imagine the return on your investment – every bug you find and fix at the developer’s desktop saves you $1000 if you are lucky to catch it during integration or even $16,000 if it makes it into customer hands.

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.  

Making a Faulty Serial Port

By Jakob Engblom 

As noted before, one common use case for Simics is doing fault injection.  Fault injection is typically added to an existing system without changing it, since the goal is to maintain a fundamentally fast simulator when not injecting faults.  There are a range of mechanisms available in Simics to implement fault injection. This blog post will take a look at two such mechanisms and how they are used in the context of injecting faults on a serial port.

We will look at two ways to induce bad behavior into a serial port in the system shown below:

First, we introduce faults in the interface between the serial port and the processor using it.  I.e., on the register bank of the serial port that the software on the system processor(s) use to send and receive data from the port.  This simulates a device with flaky interface circuitry, or a bus that would sometimes fail to correctly pass the data from the device to the processor.  It does not directly correspond to a faulty device, since the device operation is not affected (unless of course an error is injected on a transaction that targets the configuration or control registers of the device and have unintended side effects).

On the surface, this might seem trivial to implement: just pass all transaction from the main memory map through an intercept module, and have that module corrupt the transactions as it sees fit.  However, this would burden all transaction with a cost and remove the ability of the simulator to cache values and optimize accesses to memory and other devices which are not affected by the fault injection. Instead, in Simics, we can introduce a level of indirection and intercept only accesses to the serial device.

As shown in the picture below, we do this by introducing a private little memory map for the serial device. The mapping in the main memory map is set to point to this new memory map, and it in turn maps the serial device.  The new memory map has an intercept module attached to it which can see and modify both read and write transactions.

This target system modification can be done in a few lines of Simics scripting, even in the middle of a simulation. Simics allows arbitrary reconfiguration of the simulation system at runtime, and the changing of the memory map to point to something new and the introduction of a new memory map and fault injection module can both be done and undone at runtime.  Using a module instead of just a script for the injection work makes the fault injection more robust, and ensures that the injection of faults is part of checkpoints and allow for reverse execution.  Any Simics user can create such modules themselves, using the Simics Extension Builder product.

If we program the fault injector to replace some output characters with other characters, we get something like this:

Note how the output is suddenly corrupted with a bit of L337-style text.  This is achieved by changing the values written to the serial port transmission register, on their way from the processor to the device. The processor is not affected, only the data in flight.

A second fault injection pattern hooks into the back end of the serial device. The serial device has a front end that handles the registers facing the processor, and a back end that handles the transmission and reception of characters (transactions) on the serial line.  The front end and back end are tied together by the core device functionality.

The back end implementation has the serial device modeling talking to a model of a serial console (or other hardware attached to a serial port) using the Simics "serial interface".  Note that the serial device does not interact directly with a user, but rather it expects some other model in the simulation to provide this service.  In this example, it is a serial console, but it could just as well be another virtual machine. It can also be a fault injection module that puts itself into the path of the data, as shown below:

Unlike the previous case, here we put the fault injection module on the actual data path.  The fault injection module actually receives all data and passes it on to the other side of the connection. It is not selective in the same way as an intercept module. Just like with the intercept module, making this an explicit part of the simulation enables checkpointing and reverse execution to work during fault injection.

In the code, each output from the serial device calls a function in the serial interface of the fault injection module, which in turn calls the same function in the serial interface on the serial console. If data is just forwarded, neither the serial device nor the serial console sees anything different.  However, the fault injector can do anything with the data as part of passing it on, including changing data and dropping data. 

It is also possible to introduce spurious data transmissions, simulating random noise on the line that looks like actual data transmissions to the devices in the system.  Note that since Simics does not actually simulate the analog encoding on the serial line, a model of random works by generating entire characters - essentially simulating a case where noise is interpreted as valid data by the receiver circuitry.  The intercept module used in the previous example could also create transactions, but would have to make use of additional interfaces to do it (it would essentially perform its own independent memory accesses).

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.  

Introducing Performance Studio

By Emeka Nwafor

What is Performance Studio? Is it:

1. Some kind of hair product

2. A new "clinic" for MLB players

3. Full name: : Wind River Linux Performance Studio for Intel® Architecture; a new add-on product for Wind River Linux that helps you get the most performance out of your embedded Linux device software running on Intel hardware 

If you correctly answered "3", give yourself a round of applause.

Our portfolio of development solutions have long addressed a broad set of embedded device development concerns in the areas of system definition, bring-up, software construction, integration & test, and maintaining and retro-fitting embedded device software and hardware. Now, with the introduction of Performance Studio, we not only have the broad development solutions portfolio but also further extend it with capabilities that enable us to go deeper into the platform and obtain the best performance out of embedded Linux software running on Intel® Core™, Xeon™, and Atom™ processors. 

Performance Studio integrates the Intel C/C++ Compiler to generate hardware optimized code, the Intel Integrated Performance Primitives to adapt your algorithms to take advantage of Intel acceleration capabilities (SIMD, AVX, AES, SSE, …), and VTune to help pinpoint areas in the application that are candidates to be optimized.

Want your software to run faster on your Intel embedded platform? Concerned with getting the most out of your Intel embedded hardware? Need to optimize a computational-intensive algorithm? Thinking about portability to future platforms? Need to get deeper insight into where your CPU is spending time, wasting time, or simply waiting?

We invite you to learn more about Performance Studio and its integration with Wind River Linux and Wind River Workbench. Also, check out a great blog posted by my colleague in the Wind River Linux Developer Community that provides some additional technical insights into this product.

Many thanks to the teams in the Intel Developer Products Division and in the Wind River product group for the effort in bringing this solution to market.

I also want to use this time to wish our readers best wishes for this holiday season and peace, health, and happiness in 2012.

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.  

 

Simics for Networked Systems: An Interview with RTI

By Jakob Engblom

Networked systems is one of the primary application areas for Simics. Simics can run many machines inside a single Simics simulation, and apply all Simics features to the system, not just to a single machine inside the system. This is something that Dan Poirot from Real-Time Innovations, RTI, has made quite extensive use of recently. It is a pretty cool use-case for Simics, so we arranged to interview Dan about his use of Simics.

Jakob Engblom: We start with the basics. Can you introduce yourself?

Daniel Poirot: Hello! My name is Daniel Poirot. I am the RTI Senior Field Applications Engineer covering the Southeast US. I came to RTI following 13 years selling development tools in the embedded industry. Prior to that I worked for 15 years as a developer in the NASA Johnson Space Center community.

JE: That's a very impressive bio, I only have about 14 years myself in the embedded space.

JE: So, what does RTI do?

DP: Realtime Innovations sells tools and services supporting and extending the Object Modeling Group (OMG) Data Distribution Service (DDS) standard. RTI DDS accelerates the integration of real-time, mobile and embedded applications with each other and with enterprise and legacy applications. RTI DDS provides the developer a data-centric, dynamically configured, fully anonymous, publish/subscribe system with many powerful Qualities of Service (QoS). Applications can be written needing very little knowledge of the deployed system ahead of time.

JE: How do you use Simics?

DP: I have used Simics at RTI as well as at positions with two earlier companies. In each case, Simics has provided a binary compatible representation of networks of different CPU types running different target operating systems! Simics is also a great way to prototype a system of systems or service oriented architecture. Additionally, Simics gives RTI a robust platform for testing our products during development.

 JE: So you simulate multiple target machines in a single Simics session, right?

DP: Yes indeed, including heterogeneous systems. I have used Wind River VxWorks and Wind River Linux as well as ‘kernel.org’ Linux on a number of simulated machines at the same time. I started with a single Power Architecture target and have progressed to different Power Architecture and Intel Architecture targets.

Simics offers the developer (using Windows or Linux on their PC) access to other chips (including Intel, Power, MIPS, ARM) running other operating systems (VxWorks, VxWorks 653, WR Linux, and others).

RTI offers a common API (OMG DDS) and interoperable network wire protocol (OMG RTPS) allowing applications written in different languages (C, C++, Java, .NET, Ada) to communicate seamlessly on these targets.

If we put this together, by using Simics, we can demonstrate and test these combinations on a single PC, no need to cart around a case of different development boards.

Here is an example screenshot (click to enlarge):

We see lots and lots of windows in a system where we are simulating multiple boards for use with Windriver Workbench.

‘Simics Control’ shows the configuration of two dual-core p2020 RDB boards, ADAM and BERTIL. Their serial consoles are on the left displaying typical VxWorks 6.8 operations.

Also included is CESAR, a p2020 DS board. It’s serial console is at the bottom left. It is showing WR Linux 4.0 commands.

The ‘Simics Command Line’ window is used to configure the running system. Here we enter commands such as ‘connect-real-network-host’. Errors are logged here as well results from as my successful configuration.

To the far right we see the ‘Advanced Device Development’ perspective of Windriver Workbench configured with Target Servers for the simulated boards.

The ‘Host Shell’s at the bottom of the screen are attached to the Target Servers for ADAM and BERTIL. Here we see similar but different VxWorks output.

In a typical development use case, RTI DDS may be loaded as a series of shared libraries and the target application.

Each of the VxWorks windows shows the RTI DDS libraries, libnddscore, libnddsc and libnddscpp, as well as an application, either ‘rtiddsping’ or ‘rtiddsspy’.These Ping and Spy applications are used initially to confirm proper network connectivity.

JE: Yes, using Simics like that can simplify both testing and demonstration of solutions. The final product obviously has to run a specific physical piece of hardware, but a large part of the development can be done in a virtual world with much more convenience, as you noticed.

JE: What kinds of network topologies are involved?

DP: RTI DDS supports a wide variety of standard networking protocols as well as shared memory and ‘disadvantaged or intermittent’ links. RTI DDS applications can communicate using shared memory, UDP, TCP, DTLS, TLS, IPv4 and IPv6 without having to program directly to those protocols. Using Simics we can create networks of subnets and show how applications communicate.

JE: So,you are not only using multiple machines, but also multiple network links inside of Simics?

DP: High speed, reliable communications across networks is fundamental to the RTI DDS product. It has be a challenge to setup a good demonstration of several networks. I always seem to need ‘n+1’ computers! With Simics we can virtualize the machines needed. The target operating systems are configured as they would on ‘real’ hardware. Testing and demonstration of a system of systems or service oriented architecture can actually be realized with different networks and different network IP numbers – just like in the ‘real’ world.

JE: Virtual  networks are convenient, I must say. The fact that  you can always add another machine without having to scavenge for lab hardware is something we have heard from many places as being a very valuable property of a virtual system compared to a physical one. 

JE: Was there anything else in Simics that helped you get your tests done?

DP: The high fidelity of the Simics targets allows us to use standard development tools such as Windriver Workbench. We are also able to use RTI networking tools such as Analyzer and Monitor to visualize DDS information. Open source tools such as Wireshark can even be used on the simulated networks.

JE: So you also connected the virtual machines to the outside physical network?

DP: Yes. I was pleased to see that Simics uses popular network simulation tools. We use OpenVPN at RTI so adding additional virtual interfaces using TAP-Win32 is very straightforward for me. The tools are all scripted so the details only need to be set once.

JE: Thanks for your time! This has been very interesting, seeing how Simics is applied to this kind of distributed networked system.

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.

Leveraging Virtual Platforms to Improve the Intel Product Lifecycle Process

By Eddie Glenn

An Interview with Atul Kwatra, Principal Engineer at Intel

My colleague Jakob Engblom and I had the opportunity to meet with Atul Kwatra, Principal Engineer at Intel recently.  Atul is responsible for driving virtual platform strategy and technical direction for the Intelligent Systems Group (ISG) at Intel.  ISG focuses on products for the embedded, networking, and communications markets. 

Specifically, we wanted to learn more about Atul’s vision on how Intel leverages virtual platforms to improve their product lifecycle to reduce risks, time to market, and costs.

Eddie Glenn: Atul, what are your main responsibilities at Intel?

Atul Kwatra: I provide technical leadership for ISG’s Virtual Platform efforts including functional modeling, performance modeling, high level synthesis, and external customer enabling. I am responsible for driving cross-disciplinary efficiencies across the architecture, design, software, and validation organizations using Virtual Platforms to improve the overall product development flow.

EG:  What do you think are the primary product development challenges that semiconductor companies face in today’s world?

AK: The embedded and communications market is very fragmented with several strongly entrenched and successful silicon solution providers.  To win in this market, semiconductor companies need to be agile enough to provide multiple application specific products with a low cost and extremely fast time to market. Increasingly, products require an efficient integration of hardware and software to win on the basis of time-to-market, power, and performance metrics. 

Jakob Engblom: How can virtual platforms address those challenges?

AK:  Virtual platforms provide a critical ability to optimize both hardware and software during the very early stages of the product development cycle.  This is essential for delivering optimal products with the lowest possible development cost and time to market.

JE: How has Intel leveraged virtual platforms to improve its product development lifecycle?

AK: At Intel, virtual platforms enable cross-functional efficiencies across Architecture, Design, Validation, and Software disciplines to improve the overall product development cycle.

EG: What are the main benefits that you see Simics bringing to the table?

AK: Simics provides a capability to enable full-system simulation very early in the product development cycle.  In addition to being a very fast simulator, Simics provides several advanced capabilities including full-determinism, multi-system synchronization, reverse execution, fault injection, and checkpointing (Editor’s Note: checkpoints provide the ability to save the complete system state & then later resume execution from the exact same point in time). This allows development teams to efficiently complete their validation and production software development in the pre-silicon timeframe and thus reduces the amount of time it normally takes to integrate hardware and software once Silicon arrives.  This also allows our customers & partners to get early access to a full platform prior to silicon thus enabling an overall improvement in end customer Time-To-Market.

JE: What are virtual platforms used for at Intel?

AK: Virtual Platforms are typically associated with a functional modeling capability for software development.  At Intel, in addition to register accurate functional modeling, virtual platforms are used for performance modeling, power modeling, simulating hybrid systems involving a mix of simulation and emulation/FPGA implementations, and early customer enabling. 

JE: How early can you start working compared to when you had no virtual platforms?

AK: The product development flow based on virtual platforms involves early development of functional and performance models at the architecture definition phase.  The functional models are initially used by the architecture definition team including both hardware and software architects to validate the architecture itself.  The functional models of individual system components are later plugged into a virtual platform for the development of pre-silicon & post-silicon validation collateral; and early SW enabling. Before virtual platforms, hardware-software integration did not start before availability of stable RTL models that could be emulated, so virtual platforms provide a multi-month advantage.

JE: Which types of virtual platforms do you use (TLM, CC, ...)?

AK: We develop and use virtual platform models at various levels of abstraction.  Several of our models have been developed in a non-proprietary simulation infrastructure based on industry standards (OSCI TLM – Open SystemC Initiative Transaction Level Modeling). We use the LT (Loosely-Timed) models for functional modeling and AT (Approximately-Timed) models for close to cycle accurate performance modeling.  These models can be plugged into the Simics simulation infrastructure to complement the vast library of native-Simics functional models.

JE: What kind of data do you collect from the virtual platforms?

AK: In addition to using virtual platforms for developing software early in the product development cycle, we use them in conjunction with performance and power models to project and optimize performance and power characteristics of next generation products.

JE: What is the typical work flow?

AK: Typically, for ISG products, we leverage Intel’s core technology developed by the CPU and Chipset teams as much as possible and strive to innovate at the seams.  We start with a core platform (CPU core, memory sub-system, Graphics – if needed) and add additional internal and/or external IP components required to provide the specific features for the embedded, networking, and communications markets. Our products include multi-core SoC’s and companion chips that go along with standard Intel platforms and provide hardware acceleration capabilities for market specific workloads.

JE: What kind of models do you write yourself, and which do you get from other parts of Intel?

AK: We usually get the CPU core models from other parts of Intel and develop models for components required to provide the specific features required for the embedded, networking, and communications markets. 

JE: How do you validate the platforms?

AK: One of the key internal goals of virtual platforms is to enable development of the validation test suite early in the development cycle.  This has the added benefit of validating the virtual platform itself based on running legacy tests from prior platforms and newly-developed focus tests for new features and capabilities.  The virtual platform simulation environment also allows integration of RTL blocks to provide a system level context for newly developed IP blocks or blocks with pre-existing RTL.  This allows validation of new IP blocks in a full-system environment. The RTL blocks can be synthesized into an emulation/FPGA system and connected to the virtual platform for speeding up the overall simulation as well.  

JE: How important is TLM modeling compared to detailed modeling?

AK: Transaction Level functional models and detailed cycle-accurate performance models both have their places in the development flow. Functional models are used for early SW enabling, while performance models are used to optimize the micro-architecture and for early performance projections.  Models derived from the functional/performance models are also fed into High Level Synthesis tools for studying power, area, and performance trade-offs much earlier in the development flow.

JE: Do you model actual boards, or just the core chipset?

AK: The goal is to model a complete system using an incremental phased approach.

JE: What types of engineers use the models?

AK: The models are used by hardware, software, and validation engineers.

EG: What is the primary business value that Intel receives from Virtual Platforms?

Atul: Virtual Platforms can help significantly improve product development efficiency and enable early HW/SW development.  This leads to lower development costs and faster TTM/TT$ for Intel and its customers.

EG: How do you see Simics fitting into the Intel Virtual Platform strategy?

AK: Simics is an integral part of Intel’s Virtual Platform Strategy going forward.  As it is relatively new to Intel, its role will continue to evolve over time.  The goal is to deploy Simics as a fast functional simulation tool that provides a full-system capability and incrementally add new features to support additional usages.

Thank you Atul for your time!  We look forward to working with you more in the future.

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.  

 

Why Simics Won't Run Super Mario

By Jakob Engblom

Emulating old computer gaming systems is a popular consumer-market application of simulation technology similar to Wind River Simics. There are a large number of emulators out there, emulating everything from old arcade games to the home computers of the 1980's to gaming consoles.  These emulators might seem quite similar to Simics on the surface, but in practice, the simulation technology employed is quite different.  You will never see Simics simulate an old Super NES running Super Mario Bros. 

It all comes down to the level of timing accuracy required.

To accurately run games written to run well on the very limited hardware of the 1980s, you need a fairly detailed simulation of the hardware circuits and their timing.  Game programming on 1980's and early 1990's was a matter of writing code that was very tailored to the hardware and intimately depended on the hardware timing.  A typical trick applied on many system was to change the color palette, display mode settings, or even the contents of the screen buffer during the time that it was being redisplayed on the TV. Since every unit shipped was identical, this was a viable strategy.  I wrote code like this myself on my old ZX Spectrum, achieving increased vertical color resolution, by changing the color data in the graphics display while the graphics "system" was sending display data to the attached TV.

ArsTechnica ran a very interesting article in August of 2011, about the most accurate emulation yet of the Super Nintendo Entertainment System (SNES) (or Super Famicon as it was known in Japan).  The article describes how successive generations of SNES emulators have got closer and closer to the actual hardware timing.  The timing that needs to be simulated can be very detailed indeed, such as the interleaving of bus accesses between different hardware units.  At the same time, hardware requirements for running the emulator has increased hundredfold from the first emulators from 1997 until today. Precision costs compute power, and this is essentially about using 100 times more computation cycles on the host to run the target system just as fast.

As described in the article, the latest "BSNES" emulator is about 10 times more resource-intense than the previous "ZSNES" simulator, for an increase in accuracy of 10.  That is actually very impressive, usually precision tends to be exponential in cost.  However, the really interesting statistic is that this only gives you a few more playable games.  ZSNES manages to run about 95% of all games, for a much lower cost in computation and implementation. Only in a few cases is the additional accuracy of BSNES absolutely needded in order to correctly run games or render graphics effects correctly.

This is all very interesting, but in which way is the emulation of old video games relevant for what we do today with Simics and virtual platforms in the embeddded systems field? It offers a neat illustration of the tradeoff between speed of execution and level of detail (and accuracy) of the virtual platform model.  Simics is not trying to be BSNES, it is much more like ZSNES or its predecessors. 

Simics is designed to emphasize speed of execution over detail of model. This is a deliberate choice, and it has proven critical in enabling the usage that Simics is seeing today.  By being fast enough to real-world software workloads in a reasonable time, Simics is acceptable to software developers as a daily tool. Interestingly, this was echoed in a DAC 2011 panel on ESL - without sufficient speed, software developers will not use a virtual platform. It is a crucial enabler.

The trade-off is pretty drastic: adding just a little detail to a simulator can quickly cut your speed down by a factor of ten. The diagram below has been shown in any number of variants in any number of venues, and the crucial fact that the curve is not straight. It drops very quickly initially as you go from left to right.

The reason that building a fast simulator in the Simics style works is that current software does not rely on the physical system timing in the same way that old console games do. The hardware today is very variable in its timing (processor pipelines, multiple levels of cache, branch prediction, multiple processors competing for shared resources, etc., all conspire to make execution-time variable and unpredictable). With the proliferation of levels of software abstraction, code that is tightly coupled to the hardware is almost impossible to write in general.  Instead, hardware-software interfaces have become event-driven, using interrupts to signal completion, or using poll loops on status bits for handshakes.  Code is also supposed to live across several generations of hardware, discouraging coding that is too tightly dependent on the characteristics of any particular hardware platform.

This is much more simulation-friendly since there is no need to know exactly how long an operation would take on hardware, as long as the simulator latency is of the right order of magnitude.  For most use cases, adding more detail than that just makes the simulation run slower, limiting its usefulness for the majority of software developers. It also makes the development of the models more expensive, since building a very accurate and detailed model is many times more costly than building a good enough model.

There is certainly software that does depend on the precise timing of the hardware. In real-time-critical software like signal processing and low-level firmware, there is hardware that does have very predictable timing, and software that depends on this timing.  Still,
such software is but a small part of the overall body of software that we run on today's systems. When needed, you can often build small workarounds into a simulator to make the software run right - just like the many game-specific patches in ZSNES discussed in the ArsTechnica article.  This is overall much more efficient than always simulating at a high level of detail just to make the really picky software happy.

In our experience, it is more valuable to run all of the software at a sufficient level of detail, than to run a small part of the software with a very high level of detail.  And just like we see with the ZSNES simulator, you can cover a very large base of software without going into too much detail on the hardware side. 

I hope you now understand why Simics is not likely going to run Super Mario at the level of fidelity of BSNES - and why doing so really does not make sense for most uses of a virtual platform. But I still applaud and admire the effort and dedication that went into building BSNES, and the way in which this is preserving an important part of our digital heritage. 

 

 

Catching up at IDF 2011 - An Embedded Chat with Intel ECG

By Eddie Glenn

In case you missed it, the Intel Developer Forum (IDF) was held last week in San Francisco.  The Simics team was busy at IDF with multiple Simics-related events being held.   At IDF, we handed out free memory sticks preinstalled with Simics, models of Intel devices, and a hands-on tutorial.  This is a great way to quickly learn about Simics first hand.  We had a few left over, so if you want one, email us (simics_info@windriver.com) and we’ll send one over, while supplies last.

At IDF I had the pleasure to sit down with Tian Tian, a Senior Technical Account Platform Architecture Engineer at Intel.  He’s part of the Data Center and Connected Systems Group focusing for the embedded market segment. Working with customers on almost a daily basis has given Tian some great insight into what their current issues and challenges are.

Eddie: Hi Tian, describe the kind of work that you do.

Tian: I have been involved in developing network/packet processing solutions and most recently I have been working with Intel® Architecture customers and helping them design their products.

Eddie: You work with customers on almost a daily basis.  What kinds of issues do you see them have with embedded systems?

Tian: With embedded computing systems, the products tend to have very unique characteristics and special requirements. They often require customized boot process, special OS and software solutions. To make things more interesting, these systems often are running mission-critical tasks non-stop. It is also common to see a rather long life cycle of the products.

Tian:  Common issues that designers encounter are related to the complexity of the system and interactions of hardware and software. It is a long and rigorous process in order to get the whole system from a concept to a launched and high quality product.

Eddie: How is Intel trying to helping customers with those issues?

Tian: Intel has extensive and complete design-in services that help customers along the process and deliver winning solutions. The customers also benefit from many choices of tools and software and a strong developer community and ecosystem. We are also constantly on the lookout for up and coming new technology ingredients that can benefit our customers. Wind River Simics® is one of these technologies we think that is going to give our customers a new weapon to tackle the increasingly complicated computing paradigm.

Eddie: What are the three biggest problems that keep embedded customers from getting their products to market when they want to?

Tian:

• Serial development process of hardware debug -> BIOS debug -> Software/OS development -> Test 
• Dealing with a huge archive of legacy code base and trying to migrate to new architectures and adapt to new technologies
• Increasingly more and more complex computing environment (multicore, virtualization, security…)

Eddie: What exactly do you mean by the first problem? Why is this a problem for your customers?

Tian: This is associated with the dependency introduced by this serial approach. If hardware is not stable enough, it limits the scope of work BIOS team and software team can work on. The BIOS team cannot make forward progress if hardware cannot even get beyond boot vector. Software team cannot work on the new driver if BIOS is having trouble discovering and properly enabling the new device.

Eddie: How long have you been working with Simics?

Tian: I have been leading Simics activities for our next gen IA® products for over a year.

Eddie: What are your impressions of Simics?

Tian: I have first-hand experience that the tool is making a real impact and returning values to real product development. For example, with this environment, we were able to discover several issues with next-gen BIOS releases that were still under development. This avoided negative impact on project schedule and saved effort debugging on real platforms. We have seen many other examples associated with other aspects of product life cycle and witnessed benefit it brings to the table.

Eddie: How do you think Wind River Simics can help address the problems that your customers are facing?

Tian: This is a very promising technology with proven commercial success. On top of that it has professional services provided by Wind River. This is a nice combination when you have a good product combined with good service. We are very excited that our customers will be able to access this environment and adopt the technology and the methodology. They will quickly recognize the positive contribution and in the long run this will really change how project teams tackle design problems and accelerate product development and time to market.

Eddie: Referring back to when you said that one of the 3 main customer problems is the ‘Serial development process of hardware debug -> BIOS debug -> Software/OS development -> Test” issue; how do you think Simics can help address that?

Tian: With Simics, BIOS team and software team will be able to make forward progress and verify functional operations in the simulated environment even when hardware is not available or not stable enough. Test teams will be able to develop test suite to a point that it is almost ready when hardware and software become available to test engineers! This technology not only reduces the time to market, it also improves the product quality because of early discovery of issues. This will translate to faster time to revenue and greater customer satisfaction.

Eddie: Thanks Tian!  We’re already looking forward to IDF 2012!

 

Stop, Think, and Tie Your Shoes Right

By Jakob Engblom

I was sent a link to a past TED talk about how to tie your shoes. It is worth watching, and from the discussions I have seen on Facebook around the video, it seems that most people do it the "wrong" way.  I have actually started to try to do it the "right" way, and the result is real improvement. 

Tying the "right" way does make the bands look better. However, it did require a little bit of practice and a conscious effort to change. 

Shoe tying is admittedly somewhat away from embedded systems development, but the principle is general.  Doing things in a better way requires three things: understanding that there is an issue with how things are done today (bad knots), knowledge of a better way of doing it (good knots), and the time and effort to change your habits (dedication).

In our world of embedded systems, you will always find issues with how things are done.  Too slow, too expensive, too many bugs...finding problems is the easy part.  What is harder to find are better ways of doing things, and what is really hard to find is the time and motivation to actually effect change.

A speaker at a Cadence event I attended last year pointed out that life is tough for hardware engineers.  In addition to doing their current job of designing hardware, they are supposed to start thinking about how to support software development.  How would you find time for that?  You are already too busy doing your assigned hardware design work to find time to care about the overall product design process.  To really make change happen, you would need room to stop, take a step back, and think about what you should do and how to do it.

We often encounter this when introducing Simics virtual platforms to new users.  Simics certainly seeems to provide many useful abilities and has the potential to change development processes for the better (browse through other Simics blog posts for more on what Simics does).  Turning that potential into actual process improvement requires both understanding how it work, and the time to implement and change habits.

In the end, it comes down to leadership and management.  Individual engineers have to be given the time and incentive to try new tools and new ways to use old tools.  Some things could be as simple to implement as a better way of tying your shoes -- while others are more like gathering 1000 people and convincing them all that they really should use shoes with bands rather than velcro-based sandals and to tie these newfangled shoe things in a particular way. There are also people who have not realized that shoes have laces, and the reason that they are constantly tripping and hurting themselves are those loose laces. The good thing about such cases is that tying the shoe ever which way is an improvement.

By the way, for some reason most of my swing dancing friends already knew how to tie shoes the right way. I guess shoe-tying matters more in some cases. If you want to look sharp, you have to invest the time to do things right!

 

Surfing the Web with Netscape 4

By Jakob Engblom

While looking into our old SPARC server targets for our new SPARC legacy offering, I  opened up a Simics demo checkpoint that we have had around for a long time (at least eight years). This demo is an UltraSPARC II running Solaris 9, and it shows how web browsers looked around 2001.  I used real-network to connect the machine to the Internet, and tried the default webbrowser - Netscape 4.78, built in June of 2001.

Since the Javascript implementation in the browser is pretty poor, and its CSS support terrible, the main Wind River home page would not basically not render in any useful form. Our blog page at http://blogs.windriver.com/wind_river_blog/simics/ does render - but maybe not in the expected way:

As a friend of mine commented on Facebook - is the problem that there are too many Jakobs there?

For all its shortcomings, we also have to admit just how revolutionary Netscape was. I still recall using version 1 to look at the few pages of the nascent world-wide-web when I was still a university undergraduate... And I am writing this blog using Firefox 6, which essentially is the latest in the line of development leading up from Netscape 4.

While it makes for some laughs to visit the past in this way, it can also be very useful.  If you have some old applications still living on an old machine like a Solaris 9 SPARC, what do you do?  Sometimes you can port the applications to more recent systems, but there are cases where it is just simpler, cheaper, and less risky to use a virtual machine to keep it running.  For example, if the source code is lost, the application is just a binary, the application depends on some device driver (which we can run on the virtual platform, since we run the complete OS stack), or even when there is source it has annoying word-length and endianness problems.

Note that if we would have liked to see a web site like it was back in 2002, we could have added a server to the virtual network to serve the pages like they looked back then. Preferably, running a contemporary web server on a contemporary OS to make it more "authentic."

 

 

EOL Headaches! Simics SPARC Virtual Platforms to the Rescue!

By Eddie Glenn

OK, I’m going to date myself here and admit to my geeky side…

Back in 1993 (or was it 94?), I remember the excitement of my first SPARC workstation log-in info.   The company I was working for at the time was developing Ada compilers (yes Ada, not ADA, not A.D.A!) and Ada development environments.  Our customers almost exclusively used SPARC for our products, so having that power at my disposal was awesome…but it did take up quite a bit of my desk space!

For years, this was the predominant host platform that customers used to run our software.

Then times changed.

We began receiving requests to support Linux on an x86 host (surely, these ‘personal computers’ weren’t powerful enough to run OUR software, were they?)  But sure enough they were…and they ran our products darn well.

Fast forward to the present.

I now work for Wind River… specifically, on the Wind River Simics team.  In case you’re not familiar with Simics, it’s a full system simulator which simulates any target hardware system.  The Simics simulated target hardware (aka virtual platform) is then able to execute the exact same target binary as would run on the physical target hardware.

When I was interviewing for a job on the Simics team 6 years ago, I was a bit skeptical of this claim (and I later learned it’s a similar sentiment shared by many of potential customers too).  But, to my amazement, the CTO fired up a Simics SPARC virtual platform and there it was: a SPARC Solaris (not x86 Solaris, but SPARC Solaris) virtual machine running on top of a regular x86 Windows laptop.

I watched in astonishment as the Solaris login scrolled by…watched him log into Solaris…and then watched him run a few SPARC Solaris applications.

Wow.

Many of yesteryear’s Solaris applications are being replaced by applications running on Linux/x86 machines as SPARC machines come to their end of life.  However, there are some applications that simply cannot be ported to a different OS and/or host architecture because of expense or the fact that no one is around that still knows how they work, or the source code has been lost. 

What’s going to happen to these applications and more importantly, the users of these applications?

Traditional approaches would have you just buy up a bunch of old hardware & hope that through spare parts you can keep things running for a while (1 year, 5, 10, 30 years????)  But, this is a pretty risky path because there are no guarantees that this band-aid approach will work.  In addition, what do you do if you have 5 or 100 users that need to access this platform?  Can you support that many SPARC computers in this manner?

Well, maybe a Simics SPARC virtual platform might be an effective alternative here.  It runs on the latest x86 hardware and operating systems (Linux and Windows).  It doesn’t contain any parts that are going to burn out.  It won’t take up any additional desktop or server room space either. And it runs the same SPARC Solaris software as what runs on an existing SPARC physical hardware. 

While Simics isn’t designed specifically as a SPARC platform replacement nor as high-performance database server or fileserver replacement, it could be a very nifty solution for handling those occasionally-used SPARC applications that just can’t practically be ported to a new architecture.

Furthermore, instead of having a few high-powered, but aging, SPARC platforms sitting in a locked lab somewhere, why not just provide local access (i.e. a Simics SPARC virtual platform) on every user’s local desktop PC?   There are several benefits of this: IT resources aren’t required to keep the aging SPARC hardware running, expensive server room space isn’t needed any longer, and users have access to their SPARC applications whenever they need it.

In addition, because of the configurability and scriptablity of Simics, users no longer have to remember how to log into the SPARC machine and run the SPARC application…just click an icon on your PC desktop and Simics can bring up a window with the SPARC Solaris application already running.

Since this is a new way for users to use Simics, Wind River is offering a limited time free evaluation of Simics.  You can find more information on this program, here.  

And by the way…if you want to see the video of that SPARC virtual platform demo that I viewed many years ago  during my Simics interview, you can view it below.