Skip navigation


I recently blogged about the limited availability of JTAG debug tools for Intel® Architecture (IA) processors and how Intel was working with software and tools companies to expand the developer's options. For many years since the advent of JTAG there had been only a single choice of IA debugger (Arium) and I wrote that previous blog on the heels of the June announcement of a second alternative (Wind River). Arium is an Affiliate member and Wind River Systems is an Associate member of the Intel® Embedded Alliance.


While it took over a decade to go from one to two choices, in just the past few weeks two additional companies enabled by Intel have debuted JTAG offerings for IA, bringing the total to four. The two new companies entering the fray are Green Hills Software and Macraigor Systems, both Affiliate members of the Alliance. In today's blog I will highlight Green Hills and I plan to review Macraigor in a subsequent post. Note that I've chosen this sequence based on the timing of their announcements and no bias should be otherwise inferred.


Green Hills' support for IA debug comes in the form of an upgrade to the Green Hills ProbeTM. According to their published specs., the Probe debugger supports over 1,000 devices from over 30 manufacturers. I checked out the list on the website and indeed it spans several pages. Embedded IA processors supported are AtomTM, CoreTM 2, Xeon® 5500 (Nehalem), and EP80579. Multi-core debug support is provided for CoreTM 2 and Xeon®.

























Key features of the Probe include:


  • Near theoretical maximum sustained JTAG TCK rates
  • Best-in-class sustained download speeds
  • Gigabit Ethernet
  • USB 2.0 High Speed


The Probe device is tightly integrated with Green Hills' MULTI Integrated Development Environment (IDE). The company claims that MULTI supports more target processors, Operating Systems (OS), and third-party tools than any other IDE, including target configurations with home-grown proprietary OS or even no OS.








Robert Redfield, Green Hills' Director of Partner Business Development, tells me that he believes their product is differentiated in three primary areas, "high speed- approaching the theoretical maximum; the wide variety of supported target architectures; and 3 host interfaces." To the latter point, Redfield adds that the Probe family has been shipping since 2001 and has customers "in the thousands." Those existing users can simply swap the external target adapter (processor architecture-specific) and reload IA-specific firmware on their existing Probes to migrate their embedded designs to IA without compromising software engineering productivity. The importance of tools availability in the hardware selection process should not be underestimated, especially tools that are familiar to the developer.


As for availability and pricing, Redfield says that there are currently multiple beta customers using the Probe, representing a diverse set of embedded applications. If you are interested in early access, Green Hills will consider additional qualified beta customers before the product is released to general availability.


While he declined to publish a price figure, Redfield did offer that the Probe is "considerably less expensive than legacy IA probes." I am sure that your Green Hills representative will quote you a price if you are a serious buyer. Although I don't have the figures to compare, as I speculated in my previous blog it only makes sense that we would see some movement in the pricing as more competition enters the market.


As mentioned above, I plan a future post on Macraigor to round out the picture on JTAG support for IA. In the meantime, your feedback would be most welcome, either on the specific tools mentioned here or on the topic in general. As Intel continues enabling additional software and tools companies to support embedded IA developers, what would you like to see next?




J. Felix McNulty
Community Moderator
Intel® Embedded Community
(Intel contractor)






Developing realtime software is a human resource intensive process. Researchers have reported that realtime code can take 4 to 20 times as much effort per line of code as compared to non-realtime code1. Interestingly, non-realtime code when intermingled with realtime code also requires more effort than the same code developed outside a realtime setting. So how do you simplify development of a realtime embedded application?


"Divide and conquer" is one of the most powerful techniques in the developers' toolkit. It's used everyday in non-realtime developments. Splitting a large task into subtasks with a small number of data and control connections makes programming these separate modules a simplified process. Like software developed for human interaction and no realtime component, developers of embedded realtime systems need to separate realtime development from non-realtime development.


As a first step to optimizing the development process, separating the realtime development from the non-realtime development will reduce the effort required to implement the entire system. In addition, partitioning embedded systems into realtime and non-realtime tasks permits developers to offload "cycle counting" to a Virtual Machine Monitor (VMM) or Hypervisor. Apart from questions of whether or not the processor is fast enough to serve all applications on the embedded device, programmers need not be concerned with software interaction timing issues. That's all handled by the VMM or Hypervisor with its attendant scheduling algorithm. Furthermore, developers may work with an OS with which they are already familiar, eliminating a new learning curve.


>129i2931F85A9BFF2C14Virtualization is the technologythat drives this scenario.  And it can start benefiting developers even before the real platform is available. Developers can use tools that employ virtualization as a software, hardware, or co-prototyping tool.  Intel® EmbeddedAlliance Affiliate member Green Hills® Software, a long time vendor of virtualization technology, has established a new business unit: Embedded Virtualization Business Unit focused on bringing virtualization approaches to embedded and special computer systems. The embedded unit combines products: INTEGRITY Secure Virtualization (ISV) which supports hosting of Windows, Linux, VxWorks and other general purpose operating systems in secure virtual containers. The new business unit also offers development tools and engineering services to foster diffusion of virtualization technology to embedded systems engineers.




INTEGRITY provides the ability to guarantee CPU availability at both the task and address space levels. Critical tasks and address spaces will always get the CPU time they need, regardless of what any other tasks or address spaces are doing in the system.

For example, in a system with two tasks at the same priority-A and B- if task B spawns 2 subtasks, B1 and B2, INTEGRITY can be configured to force all 3 "B" tasks to equally share the CPU budget originally allocated to task B (50\%). This protects task A from losing any of its allocation as a result of another task's actions.

Software engineering productivity is a function of several factors. Some of the issues affecting development productivity are system configuration techniques and tools, supported high level languages, language specific source level debug tools, event debugging and logging, and higher level systems control.


Development tools available from Green Hills include a Project Wizard that provides a graphical interface permitting  developers to choose project attributes like:  the number of address spaces desired and whether the image will be loaded dynamically. The Project Wizard manages shared libraries, file systems, TCP/IP stacks, Resource Manager, and debug agents. Other tools include:  debug tools including remote debug, the IntegrateTM utility, the MULTI IDE's ResourceAnalyzerTM, the INTEGRITY shell, EventAnalyzerTM, and Optimizing compilers including C, C++, Embedded C++, and Ada 95.


Virtualization itself offers a critical advantage during realtime systems development. Because applications and even the guest Operating System itself can be run within a protected partition, the system can save state information even when an application has a critical fault. By permitting better monitoring of the realtime applications, virtualization aids during the integration, testing and debug phases of development.


There's more to developing embedded systems than realtime applications and operation. User interfaces and other non-realtime operations often play a critical role in the success and effectiveness of embedded systems. By dividing embedded systems components into different VMs each operating the appropriate OS, system development can proceed in parallel. More importantly, non-realtime software can be developed by the more widely available Windows programmer using standard Windows development tools and methodologies.


Adopting virtualization techniques and technologies can simplify the development of embedded systems. It allows engineers to choose the right tool for the job. Why do software development in the same old way when a powerful capability is available to ease the process?



(1) Three essetial publications document relative development costs

Boehm, Barry W., "Software Engineering Economics," PrenticeHall, 1981

Brooks, Frederick P., "The Mythical ManMonth," Addison Wesley, 1995

Tausworthe, Robert C., "Deep Space Network Estimation Model," Jet Propulsion Report 817, 1981.

In another blog I’ve talked about improving systems safety by controlling unintended software interactions. That’s one way to improve availability – remove an entire class of potential failures. Another way to improve availability is to have a second copy of software running, ready to take over in the event that the first copy fails. Termed hot standby, this technique creates redundancy by operating primary and standby systems simultaneously. Data is mirrored to the standby system in real time so that both systems contain identical information. Other standby approaches include warm and cold standby configurations. “Warm standby” mirrors data at intervals that are not realtime, while cold standby mirrors data at an even longer interval than warm standby.



To make hot standby a viable realtime technique for improving system availability, the primary and standby systems must be isolated from each other. Using a separate Virtual Machines (VM) for the primary and standby systems ensures the best isolation.


Hot standby via virtualization employing Intel® Virtual Technology (VT) works by isolating the Virtual Machines (VM) from each other, and conceptually from the underlying hardware. A standby instance of critical applications remains loaded and ready to run – data is transferred in realtime from the primary instance of the application to the hot standby instance.  In some systems, when a critical fault occurs within in the primary VM, the Virtual Machine Monitor (VMM) handles the fault exception and signals for a switch to the hot standby. Examples of this type of fault includes memory and instruction execution exceptions. Other systems approaches to hot standby employ a process that monitors a defined failure mechanism, such as a “heart beat” from the primary and hot standby systems, and switches to the hot standby if the primary system fails to delivery its heart beat on time. For hot standby operation, the standby copy of the application runs using copies of the primary application’s data. Both applications operate simultaneously on a continuous basis. In most cases, there must be modifications to the application so that communications between the running application copies can occur.


One way of implementing hot standby is by using a virtualized OS like VLX from Intel® Embedded Alliance Associate member Virtuallogix.
125i2AB34DC438B2A936VirtualLogix employs paravirtualization techniques to virtualize OS partitions within VLX. Paravirtualization means that some modification of the guest OS kernel has been done by VirtualLogix. This contrasts with full virtualization in which no OS modifications are required for the OS to operate in the virtual environment. The most often cited reason for employing paravirtualization is that the OS will run more efficiently, particularly in those portions of the application that access I/O.


Paravirtualization focuses on communication between the guest OS and the hypervisor to improve performance and efficiency. Paravirtualization requires modifying the OS kernel to replace nonvirtualizable instructions with hypercalls. These hypercalls communicate directly with the virtualization layer hypervisor. The hypervisor also provides hypercall interfaces for other critical kernel operations such as memory management, interrupt handling and time keeping.


VLX enables multiple Operating Systems, called guest OS's, to run simultaneously on the same single-core or multi-core processor. Guest OS's are isolated from each other, but communication mechanisms exist to permit transfer of data between guests. In this figure two or more RTOS partitions contain operating copies of the application, designated partition 1 and an implied partition 2. The Rich OS, designated partition n, contains user interface and other non-realtime code.


Using VLX to enable hot standby requires at least two separate RTOS partitions each with a running copy of the application, and communications from the primary application to the standby application in realtime.


Other Hypervisor configurations are also available. Intel® Embedded Alliance  Affiliate member Real-Time Systems GmcH offers a fully virtualized VMM. Apart from providing access to a wider variety of RTOSes,  their Hypervisor explicitly provides communication between operating systems. The Real-Time Systems solution provides a configurable user-shared memory as well as a TCP/IP based virtual network driver. Hypervisor is also said by the company to have zero overhead with hard real-time performance.


Hot standby has been a staple in the server arena to improve availability for many years. As embedded processors have gained increased memory, more processing power, and expended I/O capabilities, more advanced embedded systems designs have become possible. Hot Standby is one of these techniques.  Although two companies have been highlighted in this blog, there are other possibilities for hypervisor or RTOS alternatives – including a “roll your own” approach to the hypervisor functions. Intel® Embedded Alliance Affiliatemember Greens Hills Software also provides  the INTEGRITY® real-time operating system which can meet all the requirements for supporting a hot standby embedded system.


Regardless of your choice of virtualization technology, VT can be used to improve a variety of technical qualities. For a growing number of products no quality is more important than systems availability. Can your embedded designs benefit from hot standby?