Random Patterns… A Test Blog

By Alan Sguigna
Vice President Sales and Marketing
ASSET InterTech

Seconds on alphabet soup, anyone?

I’ve been in the test engineering industry for over a decade and the concept of test coverage has always been of great interest to me. How do test engineers quantify the amount of test coverage they get on a particular board design? We know from experience that every design is different and, therefore, every design needs a slightly different test strategy. That’s what makes our jobs as test engineers ever-changing and fresh. We’re always learning about new test strategies, technologies and methodologies and applying them to the task at hand. So as boards get bigger, denser, faster and more complex, we apply our creativity to keep test coverage apace with the changes.

Sometimes I wonder, is this science or black magic? I believe it’s both. One scientific innovation I’ve seen recently is the adoption of PCOLA/SOQ/FAM by iNEMI. Yeah, I know that’s a lot of letters strung together, but here’s what it means. iNEMI is the International Electronics Manufacturing Initiative and it is spearheading an industry effort to scientifically characterize test coverage. And that’s what PCOLA/SOQ/FAM is. Here’s what the alphabet soup means:

Component Scoring Guidelines

Interconnect Scoring Guidelines

Functional Scoring Guidelines

The PCOLA/SOQ methodology was pioneered by Agilent in the 1990s, and now iNEMI has added a functional (FAM) component to it. This is innovative because it moves test engineers beyond the limitations of the “shorts-and-opens” fault spectrum and forces us to consider a broader fault spectrum. It also creates a framework for a broader level of defect discovery by introducing additional test technologies as solutions to fill the gaps in test coverage. I’ll blog more on this in the next issue.

Comments? Click here to send an email. 

Now leaving the station: the PCI Express!

I often wonder how engineers are testing PCIe on circuit boards. I mean, the speed of PCIe Gen2 has increased to five gigatransfers per second (GT/s) and the emerging PCIe Gen3 tops out at eight GT/s, effectively doubling the bus’ throughput. For structural testing, putting test points on these PCIe nets is not a good practice. A test pad can have an adverse effect on signal integrity, jeopardizing the launch date of your product. And even if you could put test points on PCIe, you wouldn’t be able to test for opens because PCIe is an AC-coupled bus and, unfortunately, the IEEE 1149.6 standard for testing AC-coupled buses is not always supported by devices on each side of the PCIe port. That means that boundary scan is often not the answer here.

You might consider regular functional test, but this typically won’t even give you diagnostics down to the lane level, which you’ll likely want. For example, you could have an open on the bus and an eight-lane PCIe link will drop back to four lanes. And since the differential signals on PCIe use common mode, these types of defects are often masked from functional test. So, the lanes might look like they’re working just fine, when in fact they are actually defective with eroded eyes and higher bit error rates. If your functional test misses these types of signal integrity deficiencies, you could be looking at failures in the field and customer dissatisfaction down the road.

For test coverage and diagnostic granularity on PCIe, some savvy engineers have turned to low-level functional test applications like ScanWorks’ tools for processor-controlled test (PCT), Intel® Interconnect Built-In Self Test (IBIST), or PLX visionPAK. There are really no other good alternatives for merchant silicon.

Comments? Click here to send an email.

Keep an eye on those watchdogs

There are two types of electronics designs: those that do some forensics when a system hangs and those that don’t.

It’s just really that simple. What category does your design fit into?

When a system hangs, some sort of watchdog typically located in an FPGA, service processor or baseboard management controller (BMC) will start a timer. When this times out, the watchdog knows that its master has gone insane. In the simplest designs, the watchdog just bites its master by rebooting the system. But some clever designs have the watchdog do some sleuthing as to the root cause of the processor hang before it initiates a restart and loses all that diagnostic data.

A good way to do some sleuthing is to connect the service processor to the debug port of the CPU. Then, when the watchdog times out, the service processor can take control of the main CPU and dump memory, stack pointer, instruction counter and other registers of interest.

Having the service processor hooked up to the CPU debug port also allows breakpoints to be set in the system’s code which can be extremely useful for debug. The faults that show up can be either in software or hardware.

This of course requires some design-for-test (DFT) considerations early in the design phase to provide hardware support for the forensic routines.

This kind of capability is very important for mission-critical, high-availability systems. Finding the root cause of intermittent hardware/software defects can be instrumental to improving overall system reliability and reducing the No-Trouble-Found (NTF) issue.

Take a look at the schematic for the design you’re currently testing and ask yourself: does it have the necessary DFT? If it does, ASSET can drop some PCT technology into the system to do forensics. Ask us for details.

Comments? Click here to send an email.

Naughty, naughty BSDLs

For over a decade, ASSET, as the market leader in boundary scan test tools, has waged a campaign for better boundary scan compliance. Engineers familiar with boundary scan know that the effectiveness of this technology depends on the quality of IEEE 1149.1 implementations in chips. If a chip’s BSDL (Boundary Scan Description Language) file, which describes the boundary-scan implementation in that chip, does not match the silicon or the silicon itself is not compliant with the IEEE 1149.1 standard, then developing an effective boundary-scan test for a circuit board with that chip on it is going to be difficult. This has led to lots of time wasted as engineers struggle to implement a good test. In some cases, bad BSDL can render boundary scan useless for a given board design and, unfortunately, test engineering must resort to older, less effective and more costly test strategies. The results for your product would be higher costs, lower yields and poorer quality.

How widespread is this issue? Industry studies conducted by iNEMI and ASSET indicate that 52 percent of all devices are not verified to the 1149.1 standard. And 95 percent of all ScanWorks users have encountered a problem with chip-level boundary-scan implementations at one point or another.

Recently ASSET ratcheted up its efforts to attack this issue by partnering with SiliconAid Solutions, Inc., to provide a comprehensive 1149.1 and 1149.6 verification and validation strategy for chip designers. To read more about it, click here.

I for one certainly hope that more IC design and test engineers take advantage of these products and services. It’s getting to the point in the industry where boundary scan is no longer an option. It’s a must-have! And we at ASSET would like to see it done right.

Comments? Click here to send an email.

A gamer’s dream or Nightmare on Elm Street?

Intel finally went public with its new hexacore chip (codenamed Gulftown) which is based on a 32 nanometer (nm) process. Now it is known as the Core i7-980X. If you follow the Intel roadmap in the news, you’ll know that this is a Westmere chip. In Intel-speak, that’s a “Tick” or a die shrink from the company’s Nehalem “Tock”, which was a new micro-architecture. Gulftown has a whopping six cores, twelve threads and 1.17 billion transistors in 248 square millimeters of die space. Awesome! You can buy one at retail for $999.

This chip is designed to be overclocked. Gamers love this because it allows them to squeak out the utmost performance from their systems. Why is this important? Well, if you’re engaged in an online Modern Warfare 2 fight to the death, you want whatever edge you can get!

But herein lies a trap. Game responsiveness depends on many factors in a high-end gaming machine. CPU speed is only one small piece. The system will need fast Internet access, a high-end graphics card, gobs of memory and super-fast, sparkling clean buses for all that graphic data traffic moving through the system. Relative to the tidiness of those system buses, the most important factor will be the throughput of the Intel® QuickPath Interconnect (QPI) lanes which handle all traffic from the CPU to the IOH (Input Output Hub) which leads to the rest of the board. What if the signal integrity on those lanes is sub-par? The system will run Slow, SLOWER, S-L-O-W-E-S-T.

Do you know if your gaming board’s signal integrity was verified with Intel® Interconnect Built-In Self Test (IBIST)? I mean, you’d hate to spend big bucks for a high-end LGA1366 motherboard, then shell out another $999 for a Gulftown, and your system end up poking along like an old Core 2 Duo! What a bummer that would be, dude!

Comments? Click here to send an email.

And now for the weather…

As Mark Twain once said: “Everyone complains about the weather, but no one does anything about it." Or, as famous statistician and quality expert George E. P. Box once said: “All models are wrong, but some are useful.” (Glenn Woppman mentions this quote from Mr. Box in his “Observations” column in this issue of Connect. Don’t miss it. It’s an interesting read. Click here.)

I’ve met many engineers who rely on models and simulation to validate their designs and who don’t do any testing. Sometimes they get away with it and sometimes they don’t. There’s been a lot of news lately about companies that rely solely on simulation. As I said earlier, it’s tough to know how much testing is “good enough” and how much is overkill and needlessly costly. Understanding that fine line is the essence of our profession.

Comments? Click here to send an email.