CURRENT FEATURE ARTICLES

Almost Instant Replay
Mentor Announces Codelink for Debugging Processor-Driven Tests (Bryon Moyer)
The Spirit of Standardization
IP Re-use Takes Center Stage (Kevin Morris)
Accommodating Change
Cadence Announces a Front-End ECO Tool
(Bryon Moyer)
Making Quality Everyone’s Business
A Quick Look at isQED (Bryon Moyer)
Methods for Reducing Marketing Jitter Through Filtering of Marketing Noise in Conference Presentations
(Bryon Moyer)
Attacking Abuses of Power - Part 2
(Bryon Moyer)

JOURNAL WEBCASTS

NEW!! CHALK TALK Lowest Total System Cost With Xilinx Spartan-3. Amelia Dalton chats with Mark Moran of Xilinx about reducing your overall system cost with Xilinx Spartan-3 family of FPGAs (Xilinx)

CHALK TALK Low Cost FPGA with Serdes Lattice ECP2M. Amelia Dalton talks with Bertrand Leigh of Lattice Semiconductor about low-cost FPGAs with multi-gigabit SerDes interface capability. (Lattice Semiconductor)

CHALK TALK Crossing the Gap between Algorithm and Hardware Implementation. Join Amelia Dalton as she learns how C++ and Catapult C Synthesis can accelerate the design, implementation, and verification of complex system-level algorithms. (Mentor Graphics)

Approaching Yield in the Nanometer Age - DFM Methodology. As we dive deeper into the nanometer era, we must rethink the way we design. Tools, techniques, and methods that once worked without fail cannot hold up at the 65 and 45 nm depths, making it more challenging than ever to achieve yield. This tutorial explores these challenges within both the business and historical context of the IC design and manufacturing process. (Mentor Graphics)

CHALK TALK Accelerate SoC and ASIC Verification Using FPGA Prototypes. Join Amelia Dalton as she explores methods of ASIC verification available today and why FPGA-based prototypes offer the most affordable and most powerful solution. (Synplicity)

CHALK TALK Advancing SoC Verification Methods.
Join Amelia Dalton as she talks with experts from Mentor Graphics on processor-driven test and other techniques for solving your system-on-chip verification problems. (Mentor Graphics)

Almost Instant Replay
Mentor Announces Codelink for Debugging Processor-Driven Tests (Bryon Moyer)

It’s 4th and goal, 0:15 to go in the last quarter. The ball is snapped, the quarterback steps back, finds his receiver, and throws. Seeing the play develop, the defender runs to cover the receiver. They both jump in an aerial pas de deux; the ball dances elusively into the air, spins tantalizingly near outstretched fingertips, and falls harmlessly to the ground. While the defender gyrates around in a rather improbable new display of exultation that he hopes will sweep the nation, the receiver cries interference and looks to the referees for justice. The referees call upstairs for a replay so they can judge what happened. To their amazement, they’re told, “Um… we weren’t filming. We can’t see what happened.”

“So, what are we supposed to do?? How are we going to resolve this?”

“Well, I know this is going to sound strange, but the teams are going to have to completely replay the second half, exactly as it happened the first time, so that we can watch that pass more closely.”

It’s one thing to be able to run a live debug session on an actual executing processor, where you have access to detailed information like symbol tables and event traces, whether abstract or low-level. You can interactively work with your debugger to step around code, play with memory, and alter actual execution in an attempt to locate and fix a problem. It’s quite another to debug problems uncovered in validating a new SoC using processor-driven tests.

Processor-driven tests take advantage of the fact that the chip being tested has a processor inside. So rather than relying solely on an external tester with limited access to internal signals to provide all of the testing, you can make use of the internal processor to provide more thorough testing. You write your tests in C (breaking up the code as necessary to fit the code store of the SoC) and have the tester load and execute a chunk of code at a time until the tests are complete. Of course… that’s assuming the processor itself is working properly – the old test-the-tester problem. In reality, if you’ve done a reasonable job of getting the processor right, then processor-driven tests may uncover problems in the rest of the chip or in the processor itself; you just have to be careful not to make the assumption that the processor is always right (an assumption you might make with a tester).

A major consideration is the fact that when you’re signing off an SoC, you don’t have a real processor; you only have a model of a processor. And for sign-off, that model is very accurate – it’s very detailed, operates at the RTL or gate level, and can take a long time to run, on the order or 20 to 50 instructions per second. And if you’ve done most of the detailed checkout on various parts of the chip, you’re not going to be sitting there with eyes glued to the CRT while the tests run. You’re going to run an automated suite of regression tests (that’s “reg” – hard g – test to those of us who are cool enough to be worthy of jargon) overnight or over the weekend. And you’re going to show up in the morning bright and chipper with your steaming hot cuppa joe, expecting to see “Passed” on all the tests and to receive that well-earned pat on the back.  [more]