Apply within: four embedded instrumentation approaches

Anyone who has been around technology consortia or standards bodies will tell you that the timeline from inception to mainstream adoption of a new embedded technology is about 5 years, give or take a couple dream cycles. You can always tell the early stage, where very different concepts try to latch on to the same, simple term.

Such is the case with embedded instrumentation. At least four different post-silicon approaches have grabbed the term and are applying it in very different ways. Here at SemiWiki, our team has begun to explore the first two, but I found a couple others in Googling around.

The basic premise of all these approaches is how to see inside a complex design comprised of multiple IP blocks. All borrow from the board-level design world and the concept of IEEE 1149.x, JTAG. By gathering instrumented data from a device, passing it out on a simple low pin count interface, and connecting those interfaces to an external analyzer, a designer can gain visibility into what is going on without intrusive test points and broadside logic analysis techniques. (JTAG is also handy for device programming, but let’s stick to debug and visibility in this discussion.)

A quick snapshot of these approaches:
IJTAG, IEEE P1687– Internal JTAG targets the problem of IP as a “black box”, especially when considering the problem of 3D and importing a block wholesale. The standard tries to reign in proprietary test methods using differing and incompatible methods into a single, cohesive framework. By standardizing the test description for an IP block, using Instrument Connectivity Language (ICL) and Procedure Description Language (PDL), a P1687-compliant block can connect into the test structure. If IP providers start adopting P1687, IP blocks plug-and-play in test development packages such as ASSET InterTech ScanWorks and Mentor Graphics Tessent.

IJTAG, Testing Large SoCs, by Paul McLellan
Mentor and NXP Demonstrate ITJAG …, by Gene Forte
One pager on IEEE P1687, by Avago Technologies

Tektronix Clarus – Tek has come at the same problem from a different direction, working on the premise that RTL is RTL, and an optimized approach which looks at an RTL design and inserts analysis instrumentation seamlessly during any EDA flow. Tektronix Clarus is built around the idea of inserting a lot of points – perhaps as many as 100,000 – but not taking a lot of real estate. Instrumentation is always collecting data, but the analyzer capability uses compression and conditional capture techniques to bring long traces on just the signals of interest. This approach is more about improved analysis and deeper visibility under functional conditions.

Tektronix articles from SemiWiki

Nexus, IEEE-ISTO 5001 – Recognizing that processors, especially multicore parts, are getting more complex and software for them is getting harder to debug, Nexus 5001 creates more robust debugging capability than just IEEE 1149.7 JTAG offers. Defining a second Nexus auxiliary port with five signals, and adding higher bandwidth capability extends the capability for operations like reading and writing memory in real-time. There is also a port controller which combines signaling for up to 8 cores. The latest revision of the standard in 2012 adds capability for the Xilinx Aurora SerDes, a fast pipe for large traces. (This is one of those standards taking a long time to get traction – membership in Nexus 5001 has waned a bit, and still seems focused on automotive MCUs with staunch backing from GM.)

Nexus 5001 forum
IPextreme Freescale IP

GOEPEL ChipVORX – GOEPEL Electronic has looked at that problem of different IP using different interfaces and tried to create a proprietary solution using adaptive models that can connect software tools to various target instruments. There’s not a lot of detail, but the GOEPEL Software Reconfigurable Instruments page has a bit more info.

Different technologies emerge to fit different needs, and these approaches show how deep the need for post-silicon visibility and multicore and complex IP debugging goes. Which of these, or other, embedded instrumentation approaches are you taking in your SoC or FPGA designs?