Hardware emulation facilities are an essential part of developing, debugging, and validating software for customized Intel® Atom™ processor E6xx chipsets. The standard E6xx chipset includes an Intel Input/Output Hub (IOH) that provides the essential mechanism to provide boot load capability for the processor. But the standard configuration is not the only way to make an E6xx-based system operate.
ADI Engineering (1) offers a standard two-chip compact board based on the E6xx processor and associated Hub. But ADI took an alternative approach to building boards using the Atom processor. Unlike previous Intel architecture processors which relied on the Intel-proprietary Front Side Bus (FSB) to interface with the companion chipset, the E6xx processor uses the open PCIe bus interface between the processor and the rest of the system. That openness provides the basis for a different spin on low cost systems developments.
The one factor that stops the E6xx from being a single chip solution is the lack of a boot mechanism inside the processor chip. Instead, the Intel Hub provides that function. But the standard Hub chipset has a lot of functionality that isn’t required for dedicated designs like digital signage (see my blog on digital signs ).
Furthermore, such applications often don’t use the flexibility of a full BIOS, either.
The ADI Engineering design for “thin single chip” digital signage and other applications that don’t require a full BIOS could reduce BOM costs for a dedicated function system. For larger volume applications that cost savings can be significant both for the manufacturer and customer. But with that specific cost reduction technique goes the functionality of some development tool choices. For example, the lower end of software debug tools commonly relies on BIOS functions to provide the needed infrastructure to run the debugger. That infrastructure may be eliminated with the single-chip, low cost approach.
Looking at the entire range of hardware and software-based products offers some insights into how and when the various hardware-centric debug and verification tools are best used.
For our purposes, portions of in-circuit-emulation and functional tests are relevant to hardware/software integration and software debug. Choosing from among the various standard product-based tools is a big job that is not straightforward. But there is one factor different about customized IOH replacement chipsets: engineers are no longer starting their hardware debug with known functional silicon for the customized chip. This is a bigger concern for an ADI management chip which drives memory access. At first glance, there should be no conceptual development difference between a customized peripheral and a custom replacement for the IOH However, if there is a problem bringing up the board then taking the first steps is more difficult because there is no known good mechanism to load and run basic debug tools. This circumstance argues in favor of planning a full suite of logic analyzer style hardware tools. These engineering aids allow signals states and transitions to be recorded and possibly used as triggers for additional analysis. Logic analyzers and signal probes were discussed in a blog on development tools <url>.
Developing alternate bootload images is one strategy for dealing with initial board bring-up, manufacturing test, and field service. In this approach the Thin E6xx processor software load is different during initial debug and in production. Providing there is enough room for a full customized BIOS image, the bootloader may load the larger and more complex BIOS for debug, and a separate reduced services version for production. Some systems may require a larger memory for loading a full BIOS image as compared to a production software load. Planning to potentially accommodate a special version of the board can save time and effort during initial bring-up, and provides for future flexibility by permitting larger memories to be used in the board if the feature set grows in size.
ADI Engineering’s “Thin E6xx” simplifies the design of customized management chips through its OpenIP program. On-board OS boot Flash using a low-cost ADI-developed LPC-to-NAND CPLD interface implements a mechanism to permit booting from a flash device without the size, cost, and complexity of a full IOH device. Users of the ADI OpenIP design for Thin E6xx devices are put at the same development point as engineers who choose to use Intel’s IOH. But, there may be software customization required if a full BIOS is required.
ADI has developed a suite of diagnostics that rely on either BIOS or their royalty free boot loaders developed using Intel Boot Loader Development Kits for the E6xx. This code requires that the target hardware be correctly configured and initialized by the relevant boot loader, which of course requires that the boot loader be correctly implemented and validated before hardware bringup, validation and testing can begin.
BIOS is a strange piece of software that can create surprising difficulties. Complications can range from the closed source nature of BIOS to the relative scarcity of experienced BIOS software engineers. According to ADI Engineering, BIOS becomes a relatively difficult critical path schedule constraint, often with limited visibility and control. Identification and mitigation of early product bring-up issues can be hampered by ambiguity of cause between the boot loader, hardware and test application.
Hardware/software Integration hardware spans a wide range including breadboards using a base processor and custom hardware to JTAG-based emulators. The integration stage of systems development relies on emulation technology. JTAG is one of the most flexible and powerful technologies used to debug hardware/software interactions. This was the topic of an earlier blog, <url> but JTAG has a critical role for designers choosing to replace the IOH with a custom management chip.
Comparing E6xx to its predecessor Z5xx, the Z5xx processor and its System Controller Hub (SCH) were required in a system design. Since the Z5xx system memory controller and boot flash controller were both on the SCH, it was critical to attach a debugger to the SCH. This is especially important for board bring up and initial debug. This tight coupling of the Z5xx processor and the SCH chipset as a two-chip CPU solution required tight JTAG coordination:
- Both chips shared common "internals," and the JTAG ports of both the Z5xx and SCH were implemented with LVCMOS 1.05V I/O. This allowed the JTAG ports on the two devices to be chained together and connected to an Intel Architecture debugger.
By comparison with the Z5xx, in an E6xx system the EG20T (IOH) has no functions critical to initial board bring-up. Additionally, the IOH is interfaced via the PCIe port. Most debuggers allow you to probe the PCI bus, eliminating any compelling reason to attach a debugger to the IOH to assist in bring-up, validation or initial testing.
The IOH JTAG port also serves as a Boundary Scan port. The IOH JTAG port is biased to 3.3V, so there is not a simple way to directly connect the E6xx and EG20T JTAG ports together on the board. For JTAG Boundary Scan tests, an additional test port is required in the tester. But, this is not a critical requirement for board bring-up or hardware/software integration testing.
The Z5xx generation of embedded low-power Atom chipsets required debuggers to support both the CPU and the SCH chips to facilitate initial board bring-up, validation and test. But the E6xx architecture is different - there is limited need for the debugger to directly connect with the IOH. JTAG voltage difference between the E6xx and EG20T require level shifters. The main benefit of connecting the IOH and E6xx JTAG ports is to support boundary scan manufacturing test, but the extra level shifter cost can make this a questionable strategy. Instead, it is more cost effective to use a second JTAG port with built-in level shifters on the load board, if necessary, to accommodate Boundary Scan testing for the IOH.
The biggest implication of the foregoing discussion is the absolute open nature of the IOH functions. ADI Engineering recognized the implications of using the PCIe bus for interfacing with the IOH. The result is a single-chip IA processor with low power and high performance.
Intel’s design choices ensure that most standard development tools will work with the E6xx processor. By opening the interface between the CPU and the IOH (or its replacement) Intel maintains compatibility with industry hardware and software development tools. That means Development Software and tools from Microsoft Corporation (2), Green Hills Software (3), Wind River Systems (4) and third party JTAG emulator vendors will work with the E6xx processor and IOH or a custom chip to replace the IOH.
With the ability to replace the full blown IOH with a purpose designed management chip, there’s no limit to what you can accomplish. You can start with a known good design for the management device from ADI Engineering, or roll your own from scratch.
What can you imagine for your next embedded design using the E6xx and a custom management device?
1. 1. ADI Engineering is an Associate Member of the Intel® Embedded Alliance
2. 2. Microsoft Corporation is an Associate Member of the Intel Embedded Alliance
3. 3. Green Hills Software is an Affiliate Member of the Intel Embedded Alliance
4. Wind River Systems is an Associate Member of the Intel Embedded Alliance
Roving Reporter (Intel Contractor)
Intel® Embedded Alliance