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
Jun 1, 2023
Cadence was a proud sponsor of the SEMINATEC 2023 conference, held at the University of Campinas in Brazil from March 29-31, 2023. This conference brings together industry representatives, academia, research and development centers, government organizations, and students to d...
Jun 1, 2023
In honor of Pride Month, members of our Synopsys PRIDE employee resource group (ERG) share thoughtful lessons on becoming an LGBTQIA+ ally and more. The post Pride Month 2023: Thoughtful Lessons from the Synopsys PRIDE ERG appeared first on New Horizons for Chip Design....
May 8, 2023
If you are planning on traveling to Turkey in the not-so-distant future, then I have a favor to ask....

featured video

Automatically Generate, Budget and Optimize UPF with Synopsys Verdi UPF Architect

Sponsored by Synopsys

Learn to translate a high-level power intent from CSV to a consumable UPF across a typical ASIC design flow using Verdi UPF Architect. Power Architect can focus on the efficiency of the Power Intent instead of worrying about Syntax & UPF Semantics.

Learn more about Synopsys’ Energy-Efficient SoCs Solutions

featured contest

Join the AI Generated Open-Source Silicon Design Challenge

Sponsored by Efabless

Get your AI-generated design manufactured ($9,750 value)! Enter the E-fabless open-source silicon design challenge. Use generative AI to create Verilog from natural language prompts, then implement your design using the Efabless chipIgnite platform - including an SoC template (Caravel) providing rapid chip-level integration, and an open-source RTL-to-GDS digital design flow (OpenLane). The winner gets their design manufactured by eFabless. Hurry, though - deadline is June 2!

Click here to enter!

featured chalk talk

Analog in a Digital World: TRIMPOT® Trimming Potentiometers
Sponsored by Mouser Electronics and Bourns
Trimmer potentiometers are a great way to fine tune the output of an analog circuit and can be found used in a wide variety of applications. In this episode of Chalk Talk, Patricia Moorman from Bourns and Amelia Dalton break down the what, where, how, and why of trimpots and the benefits that Bourns trimpots can bring to your next design.
Feb 2, 2023
15,209 views