The MEMS Testing Quagmire
Players are Increasingly Looking for Extrication
Testing is an unfortunate but important requirement for being in the chip business. Unfortunate because it’s expensive and, well, annoying. Important because no one would trust electronics that had never been tested. And systems builders would end up throwing a lot of useless stuff away. It’s the “failure costs 10x as much for each later stage at which it’s caught” thing.
Bashing Bugs
Horrendous quote of the day – “27% of the industry requires 3 or more spins.” This is the headline on a slide from Harry Foster, of Mentor, based on a large worldwide survey of silicon and FPGA implementers and their verification problems, conducted by Wilson Research in 2010. OK, the positive side is that 73% get it right by second spin, and a further 23% by the fourth time round. But with spins costing multiple millions of dollars, you have to have a huge market for a chip to justify that number of spins, and a market that is prepared to wait for the chip to arrive, since, by most estimates, a re-spin is going to take three or more months. And re-spins are only part of the reason why 66% of projects are delivered late.
Not Your Father's JTAG
Before we start – a little word association test. What is the first thing that comes into your mind when I say JTAG? If you think of boundary scan and board testing – you are a hardware engineer. If you think of debugging, in circuit emulation, and programming flash memory – you are probably a software engineer. But if you think of both at the same time, you are probably an embedded engineering super-hero running a dual-core mind. (And if you are saying J-What, read on for an introduction to some of the trends in debugging and testing in the age of high speed processors and high speed serial communication.)
Two Conversations at Once
octoScope Reduces the Cost of MIMO Testing
Two can be a really useful number. In fact, if the goal is minimal plurality, then two is optimal.
I mean, just think about it. The aesthetics of bilateral symmetry aside, many of our bodily sensors work in pairs. Two eyes give us stereoscopic vision. Two ears let us triangulate the sources of sounds. Two nostrils… well, maybe that’s simply redundancy for when one of them is afflicted by the obstruction of a cold.
Necessary and Sufficient?
A Closer Look at Cell-Aware Modeling
Chip testing is always a delicate balance between testing enough and not testing too much. In reality, you want to find the “necessary and sufficient” set of tests for best quality at the lowest test cost. That’s a tough thing to get right.
Throw on top of that goal the fact that SoCs and other modern digital chips require automation to generate test vectors. Even if you find that perfect test balance, if you can’t figure out how to craft an algorithm to implement that balance automatically, it becomes an academic exercise.
Are You Covered?
Software Test Coverage Isn’t as Straightforward as You Might Hope
LDRA issued a press release sometime back on their work with the Mathworks; I addressed the overall topic at the time, but there was something else that caught my eye.
In the press release was the statement, “The LDRA tool suite provides full code coverage whether statement, branch or decision, linear code sequence and jump (LCSAJ), or modified condition/decision coverage (MC/DC) of code created from Simulink models and hand-written code.”
Cell-Aware Fault Models for IC Production Test Outperform Gate-Exhaustive Fault Models
Physical defects within ICs, such as shorts and opens, can occur during manufacturing at any step along the fabrication process because of the complexity of modern CMOS technology nodes. The conventional approach to test for these physical defects includes structural tests using classical fault models such as stuck-at (SA), bridging [1,2], and transition faults [3]. This approach has efficiently addressed defects between standard cells and defects at input and output ports of library cells.
A Sweetener for Research Labs
Rhomap Tries to Simplify Magneto-Transport Measurement
For many people, the arrival of the fall holiday season means that treats are on the way. And, for that extra bit of fun and “I made this myself” pride, there’s nothing like making candies and fudges and other confections at home.
But working with sugar can’t be taken lightly. In order to get good, consistent results, it takes a steady hand and – most importantly – good temperature control.
Controlling Power During IC Production Test
Many of today’s integrated-circuits (ICs) are designed to operate in low-power modes to accommodate greater analog-digital integration, faster operating frequencies, and battery-powered applications. During semiconductor manufacturing test, the majority of logic is often activated concurrently to facilitate detection of many faults within a small set of patterns to reduce test time. Activating all the logic at once uses more power than these low-power devices were designed to function under, which can cause them to fail or burn out during test.
This divergence in functional power versus test power means that the test application has to allow power thresholds to be set so that overstressing devices beyond the functional design and operation is avoided.
Integrating Hardies and Softies
Winston Churchill once said that the United Kingdom and the United States are two nations divided by a single language. Sometimes it seems like that in an embedded development environment. In the green corner - the hardies. These are people who think in volts and transistors and will spend enormous effort to reduce watts burned by a system. In the red corner – the softies. Their thinking is dominated by efficient code execution time. The difference between the two is nicely encapsulated in the story of a UNIX based system that was burning excessive power: the processor never seemed to go into any form of standby mode. The hardies naturally blamed the softies, who in return disclaimed all responsibility and also pointed out it would be very hard to find a culprit in the vast number of lines of code in the system.