The military has dealt with this for years. And first responders ran headlong into the issue with 9/11.

You have a localized entity – a police department, a platoon, Red Cross folks on the front line – and it has its way of communicating internally. But when it has to work with another group – the fire department or the police from another town or perhaps a platoon from a different branch of the service – then suddenly they have to figure out how to patch all of these things that work fine on their own into a cohesive whole, getting messages from one to the other without any of it getting lost in the jumble at the boundaries.

Which is pretty much where SoC design has come to. (Sorry if that transition was too jarring… to be clear, we’re not going to be describing instances of heroic derring-do; there will be no explosions.) You’ve got these bits of circuitry called IP that, in their day, would have been chips in their own right. Were that the case, they’d be put down on a board, and all the pins would be accessible, and, between JTAG and scope probes, you could deal with each one on its own.

But that’s no longer the case. Each of these pieces of IP has its signals buried deep inside an impenetrable silicon morass. If it’s good IP, it will have been thoroughly validated in all of its possible parameterized permutations. If it’s great IP, it may have built-in test structures that can be configured and accessed through a test port.

Each piece of IP can have all of this. And it’s a good thing if they do. Of course they’re all different, so you have to manually connect and merge them all into a cohesive whole. Which is difficult and time-consuming. Which no longer seems so good. This is pretty much where things stand today.

The problem here isn’t so much about testing. Between dedicated test sequences built into blocks (e.g., BIST) and high-level test compression schemes, there’s plenty of capability out there for running actual tests, and each piece of IP can handle its own testing quite nicely on its own, thank you. The issue is rather one of initialization and configuration.

It’s also a debug issue: if you’re sitting at the JTAG port trying to get some data somewhere (yes, I know, JTAG was supposed to be only for board test, but it got overloaded with other stuff), then you need some way for your SoC-level signaling to find its way, possibly through several levels of hierarchy, down into the IP block whose contents you wish to explore. Either that’s hard to for you to do, or a designer did some hard work to make it easy for you to do. One way or the other, it’s hard for someone.

IP has been notoriously difficult to standardize. The business model for IP was hard enough to get right; it still relies heavily on protecting the contents of what goes on inside all those black boxes. As a result, much of what happens in the IP block isn’t even disclosed, much less standardized. But the recent IEEE P1687 work (it’s still a “P”; not official yet) has broken down some of that proprietary tendency in order to provide commonality at the boundaries of IP for test/debug access and configuration.

The standard is informally called IJTAG. Note: that’s a capital “i”. It’s not something that Apple’s lawyers might come after. (And, thankfully, it’s not an attempt to be trendy, like the restaurant I used to like that changed its name to “iRestaurant,” which I translated to, “iWontEatThere.”) It stands for “Internal,” although it could just as easily stand for “Instrument” since, in its world, each piece of IP is called an “instrument.”

The idea is to have a standard way of describing the access structure and the sequences required to implement various operations for each instrument. The structure is defined in a file through the new Instrument Connectivity Language (ICL). Think of it as BSDL all grown up. The access sequences are described through the TCL-like Procedural Description Language (PDL) in a separate file.

Each piece of IP has an ICL file and a PDL file. The former describes the pins and registers available for access. Nothing about the internals of the IP – not even test circuitry – is explicitly revealed, so there’s no exposure of sensitive information. The PDL file then describes what to do with that interface – which registers to write what values to, for instance – in order to do different things. Initialization sequences and test modes and such would be described here.

That’s all fine and good, but each piece of IP gets buried within layers of hierarchy. At each layer, the designer may need to provide an ICL description to describe how the hierarchy is interconnected (perhaps a separate set of registers on the boundary, for example). Meanwhile, the PDL description gets buried deeper and deeper, so that executing the instructions becomes a question of how to position the data within a stream of 1s and 0s that goes in at the top level and must somehow drop the instructions and data off at the right place many levels below.

This is where automation becomes an obvious must-have in order to manage this problem in a meaningful way. The first such tool out of the chute appears to be Mentor’s Tessent IJTAG, their ITC announcement this year. There are three things that the Tessent IJTAG tool does, two of which are available today, the other scheduled for Q1 of 2013.

The first capability is to allow IP providers to validate their ICL and PDL files. This is done by automatically creating testbenches to verify the PDL against the ICL and to verify both PDL and ICL against the circuit Verilog in what is analogous to a schematic-vs-layout comparison. That register that you describe in the ICL: does the Verilog description of the design agree that it’s there? The result is a level of certification that the IP vendor can feature as a benefit to SoC designers.

The second capability accrues to those SoC designers directly. And it gets to this whole issue of IP being buried under piles of hierarchy. Tessent IJTAG is able to “retarget” the ICL and PDL files by effectively pushing them up the hierarchy and “reinterpreting” them at each level in the context of other items at that level, all the way to the very top. Through this process, commands intended for different blocks of IP can be merged and optimized to allow setup to proceed with a minimum of clock cycles.

At the top level, the signals required can also be translated into a format familiar to whatever the driving equipment might be – an automatic tester or piece of lab equipment.

Finally, the third capability, slated for early next year, allows for actual insertion of the test structure into the design. This is a test network synthesis capability based on a definition of the network by the designer, while automatically detecting compatible “instruments” in the design and accommodating the wide range of access methods that different pieces of IP might use.

All in all, it should make it much easier to bring hundreds of pieces of IP together and get them all talking to the test or debug equipment through a common network, even while preserving design security and minimally perturbing IP vendors’ ability to differentiate their wares.

More info:

Mentor Tessent IJTAG