feature article
Subscribe Now

Taming IP Test Interconnect

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

One thought on “Taming IP Test Interconnect”

Leave a Reply

featured blogs
May 18, 2021
Since I was a kid, I’ve always been a fan of technology making life better. When I was 8, I remember programming the VCR to record the morning cartoons so I wouldn’t miss the good ones after the bus picked me up from school. When I was 10, I made mixtapes of my fa...
May 18, 2021
原文出è•: Please Excuse the Mesh: CFD and Pointwise ä½è…: Paul McLellan Cadence於今年四æˆæ”¶è³¼äº†æµé«”動力學公司Pointwiseã‚å¨æˆ‘的前ä¸ç¯‡æ–‡ç« æŽ¢è¨Ž PointwiseãPCIeã...
May 13, 2021
Our new IC design tool, PrimeSim Continuum, enables the next generation of hyper-convergent IC designs. Learn more from eeNews, Electronic Design & EE Times. The post Synopsys Makes Headlines with PrimeSim Continuum, an Innovative Circuit Simulation Solution appeared fi...
May 13, 2021
By Calibre Design Staff Prior to the availability of extreme ultraviolet (EUV) lithography, multi-patterning provided… The post A SAMPle of what you need to know about SAMP technology appeared first on Design with Calibre....

featured video

Introduction to EMI

Sponsored by Texas Instruments

Conducted versus radiated EMI. CISPR-25 and CISPR-32 standards. High-frequency or low-frequency emissions. Designing a system to reduce EMI can be overwhelming, but it doesn’t have to be. Watch this video to get an overview of EMI causes, standards, and mitigation techniques.

Click here for more information

featured paper

Designing TI mmWave radar made easier using our third-party ecosystem

Sponsored by Texas Instruments

If you are new to radar or interested in replacing your existing sensing technology with radar, there can be a significant learning curve to both designing your product and ramping to production. In order to lower this barrier, Texas Instruments created a third-party ecosystem of radar experts who can provide solutions no matter how much help you need.

Click to read more

featured chalk talk

RF Interconnect for 12G-SDI Broadcast Applications

Sponsored by Mouser Electronics and Amphenol RF

Today’s 4K and emerging 8K video standards require an enormous amount of bandwidth. And, with all that bandwidth, there are new demands on our interconnects. In this episode of Chalk Talk, Amelia Dalton chats with Mike Comer and Ron Orban of Amphenol RF about the evolution of broadcast technology and the latest interconnect solutions that are required to meet these new demands.

Click here for more information about Amphenol RF Adapters & Cable Assemblies for Broadcast