Multicore competency
Freescale Semiconductor’s test engineers deliver the data necessary to get the company’s six-core network processors to market.
By Rick Nelson, Editor in Chief -- Test & Measurement World, 11/1/2009 1:00:00 AM
Austin, TX—Freescale Semiconductor is addressing the processing needs of wireless broadband equipment vendors with devices such as its MSC8156, a six-core DSP based on the company’s new SC3850 StarCore technology. The high-performance, power-saving device leverages 45-nm process technology to deliver performance equivalent to that of a 6-GHz single-core device. To do that, it combines six fully programmable SC3850 DSP cores, each running at up to 1 GHz with an architecture optimized for wireless infrastructure applications, enabling near-term, mainstream adoption of next-generation wireless standards such as 3G-LTE, WiMAX, HSPA+, and TDD-LTE.
|
Not surprisingly, these complex devices present significant test challenges. The test engineers have to deal not only with the device complexity, but also with the challenges of working with the 45-nm state-of-the-art process. Their efforts extend from working with the design teams on DFT (design-for-test) strategies all the way to generating the data that can help drive yield improvements. Along the way, they perform the characterization and validation steps necessary to ensure that both the cores and the various high-speed serial I/Os perform properly—both at the PHY layer and within the protocol stacks. In addition, they rely on DFT and ATE (automated test equipment) strategies to isolate faults and fix them, often without resorting to physical failure-analysis techniques.
To learn how Freescale’s engineers meet those challenges, I spoke with Robert Bollish and Scott Walker. Bollish is test engineering manager at Freescale and has served 26 years as a Freescale/Motorola employee. Earlier, he worked at Texas Instruments. He has been involved in test, product engineering, and business operations, most recently in the baseband business, and he moved over to the networking business about four months ago. He has responsibility for all the network processors in the company.
Scott Walker is a test manager working under Bollish. He, too, worked at Texas Instruments before joining Freescale/Motorola, where he is responsible for products having QorIQ network processors, which offer power efficiency and programmability while providing a coherent multicore migration technology.
Bollish emphasized the complexity of the ICs that Freescale’s engineers are working with. “We now have multiple 45-nm SOI [silicon-on-insulator] products that we are currently sampling. Scott’s team is working on the 8156 DSP, which is a six-core DSP used in the networking infrastructure space. It’s got six 1-GHz DSP cores. There are some accelerators on board in addition to the processors. The kind of applications it supports are WiMAX and HSUPA,” he said, adding, “I’ll give some statistics—the device has half a billion transistors, 2.5 billion vias and contacts, and greater than 2 miles of interconnect. The complexity is relevant to what we do, because we have to validate all aspects of the device to ensure the integrity of the design and to make sure we ship quality products.”
Design and process
Bollish said the test challenges begin with the fab process, noting, “In general, working with the new 45-nm technology has its challenges. Sometimes you ask yourself, are you debugging the parts or are you debugging the processes?”
Said Walker, “We have always had to separate out whether something we are seeing is the result of a design marginality or a process variant.” Bollish noted, though, that working with fabs has become easier as fabs and semiconductor companies learn to talk to each other. “There are some industry-standard directivity terms that translate regardless of who you are working with—D0 [defect density] curves, for example—and as long as we work with that common language, usually we get squared away very quickly.”
Bollish explained also that “the other thing that is important in the early phases of a fab bring-up is that we will probably use some kind of a shared test vehicle, for which we and the foundry both have access to the same results.” The test vehicle represents a common piece of IP, he said, with both parties interested in sharing data. He said the foundry will continue to run some of those test vehicles even when it begins running Freescale’s products. That, Bollish said, establishes two sets of data that let Freescale and the foundry monitor correlation events. Eventually, he said, the test vehicles are eliminated, and the Freescale products themselves become the sole drivers for yield learning at the factories.
|
|
Beyond fab issues, the Freescale test team needs to ensure that the structural and functional tests they develop provide adequate fault coverage with reasonable test times. Walker commented on the specifics of what needs to be tested, including 45 Mbits of RAM and several high-speed serial interfaces along with the six cores. “Combining the high-speed serial interfaces as well as high-speed DDR interfaces within one monolithic IC is always a challenge, and the combination of power and speed our chips run at makes it all the more challenging,” he said.
Added Bollish, “Just the transistor densities we are dealing with present problems with the concurrency of test. You can’t get test done just by doing things one step at a time; you’ve got to get a lot of things going at once to be able to meet the test-time budgets that are established for products like this.”
Walker said the on-chip memory presents one opportunity in this regard, saying, “We use BIST [built-in self-test] engines to get a lot of the memories tested concurrently.” The cores themselves, he added, are tested primarily by broadside scan, and two or more can be tested concurrently. Layout and other issues preclude testing all six at once, but he noted that designers do try to accommodate concurrent test as much as possible.
Although scan serves for the bulk of the processor tests, Freescale relies on functional testing as well. Functional tests can help test critical paths, they can measure parameters like fMAX, and they can test interdomain connectivity. They can also close gaps in analog-block test coverage while providing additional visibility into a device.
Multiprotocol HSSI test
Bollish highlighted one feature of the parts that presents particular test challenges: “Our products are multiprotocol—they’re not just ASICs serving one application.” The multiprotocol parts, he said, help control inventory costs and eliminate the complicated logistics that would arise if Freescale produced, and customers purchased, many different types of single-protocol devices.
Unfortunately for the test team, the complexity moves onto the chip. Walker explained, “What we will do is stack buses, so one channel might be used for PCI Express, but if you flip a bit, it might become an SRIO [Serial RapidIO] channel.”
At the protocol layer, Walker said, parallel data goes through a Freescale interconnect serializer/deserializer IP layer on its way to and from the PHY. “And this interconnect layer between the protocol stack and PHY is more complicated to test than a part where it’s just PCI to the PHY and out. Because our devices support multiple protocols on the same links, whether it’s SRIO or PCI Express or SGMII [Serial Gigabit Media Independent Interface], we not only have to verify that the protocols are good, but we also have to verify that the protocol block that is upstream from the PHY layer and the interconnects are all good.”
Walker said that over his career he has seen an evolution in DFT that has made testing the HSSI (high-speed serial interface) easier. To help simplify testing, he said, Freescale designers “do a really good job of putting DFT into the PHY and into the protocol block ahead of the PHY. But we still always validate that the whole package works,” including the interconnection between the two. “That’s an area where we are putting a lot of emphasis,” he said, explaining, “We are actually using ATE capability to close the gap between what the DFT provides and the coverage we need, but we are constantly improving our DFT.”
Walker outlined how the process works, explaining that the ATE can send a serial signal through the PHY to the protocol layer, and on-chip DFT can verify that the protocol layer decoded the serial input properly. Similarly, the chip DFT can initiate an output that the ATE can then read and validate. Finally, he said, a loopback mode enables the ATE to validate the performance of the DFT.
ATE complements DFT for FA
The test engineers often have to balance ATE and DFT capabilities to fully understand what they are seeing. “We often provide additional functional-based coverage to validate that the whole system works as it’s expected to,” Walker said, adding that as the team gains confidence, “we start to rely more and more on the DFT.”
Walker praised the efforts of Freescale’s DFT engineers, saying, “Their particular method is quite good. It can enable us, without doing any FA [failure analysis], to know which areas of the circuits are performing the way they should. Or it shows us that we might need to review the limits that we have set for one area of the circuit, and we can determine through re-simulation whether we have to make adjustments. Perhaps the limits need to be widened, or perhaps we have to go back to the lab and make more detailed measurements. Or maybe we are just dealing with a process variation. All this adds up to a lot of test engineering activity that is going on behind the scenes.”
Bollish elaborated on failure analysis, noting that increasingly sophisticated DFT is enabling test engineers to pinpoint and often fix problems without resorting to physical failure analysis at all. In the rare cases where physical failure analysis is required, the DFT can quickly pinpoint a specific flip-flop within a particular IP block on a particular scan chain. “Years ago,” said Walker, “you would need a half a dozen or two dozen functional patterns to try to figure out what area of your circuit was broken.” Now, said Bollish, “Tools in that space continue to get better and better.” He added, “I have been involved in several IC bring-ups where we never placed a probe or used an e-beam.”
Bollish said that he is starting to see commercial tools coming into play that are increasingly powerful, in contrast with the home-brew roll-your-own tools used a generation ago. “I think that trend will continue to get stronger and stronger, and the feedback cycles are going to get shorter and shorter,” he said, adding that he has seen demonstrations of commercial EDA tools and ATE systems that support speed sorts at a flip-flop level using scan patterns. “The vendors are linking our design databases in almost real time to the execution of a test on a tester,” he added.
Walker emphasized the nuances that test engineers face, saying, “A lot of people tend to look at things in terms of black and white, but in test engineering, there is a lot of gray. We have to look at how robust a circuit is, what its marginal performance is, and whether it has some abnormality, such as a shmoo hole. So, while maybe everybody else is thinking in digital terms of good and bad, we see things that are sometimes purely test artifacts, and we have to answer whether things we see are real or 'Memorex.’ We need to be confident about the feedback that we give to our product engineering team or our design team or the process team, so they can make adjustments to make sure we meet our power and speed goals.”
For example, Walker said the test engineers may encounter anomalies in a shmoo plot of voltage vs. frequency. The abnormalities may be artifacts of the DFT in a part that’s actually good—a fact that functional patterns from ATE can verify. “If we find the DFT piece was less robust, then we come in and use more of the brute-force ATE method to cover that.” He noted that companies using less-capable ATE might not have that option and might face the costly need to re-spin a mask for a part that’s functionally good.
Bollish added, “The whole process of having to judge performance involves a lot of analog measurements that give you various gradings of the part—various speed sorts, for example.” Such gradings, he said, can enable Freescale to serve the mass market as well meet the special needs of certain customers.
Meeting time-to-market constraints
The test engineers’ work extends well beyond characterization and development of production test suites, Bollish said, noting that their judgments are felt throughout the life of the product. “It’s very challenging to decide how to make judgments,” he said, adding, “Test engineers are interesting people who are willing to throw their opinions out there based on the data they’re collecting and the science of what they are observing. They need to balance their observations against the needs of getting to market. All of the test engineers that I’ve met in the high-speed test area really understand that it’s not a go/no-go world—they are willing and able to make those judgment calls.”
The judgment calls are made more difficult by the complex devices Freescale has to test. “These parts are bleeding-edge from a process standpoint,” said Walker, “and we are always trying to push the performance.” He pointed out that the devices’ state-of-the-art packaging has implications for load-board design and handler-temperature control.
Bollish noted that for the multicore DSPs, the same test platform serves for wafer probe and final test, “so the test suite we write for one translates back and forth, minimizing correlation issues.” Nevertheless, with systems deployed at Freescale and at subcontractors overseas, he said, “There is some statistical variability within the instrumentation from tool to tool. We have to determine where the variability is coming from, and our measurements give us a big database to do correlation studies.”
Walker added that the test team has to take into account various factors, ranging from instrument variation to burn-in and final-test temperature control. “We put them all into the same mixing bowl and get results under a time constraint,” he said, adding, “That’s really where the challenges for the test engineer come into play.”
To meet those challenges, test engineers deal with a multitude of data. Said Walker, “The design, product-engineering, and yield teams are all looking for us to provide data. We have multiple customers all hungry for the piece of data that will help them look at and see what they’ve just produced and determine how they can improve it or fix it and modify it. We try to make them all happy.”
Added Bollish, “One of our colleagues likes to say that the test engineers are the toolmakers, and we have a whole bunch of people that use our tools. They are the product, the factory, and the validation teams, and they might be all over the world. It’s a multidisciplinary set of people that are using the data sets that are coming off our tools.”
Of course, test engineers are consumers of data as well. Said Bollish, “Our principal data sources are twofold. The first ones are the design engineers because of the enablement they do with the DFT. The design team is one of our critical partners in enabling us to perform the characterization and to bring a test suite to production. The second source is the product engineering team, which is doing the yield analysis and interfacing back to the foundries—tuning and tweaking and trying to get additional yield performance. A lot of times we coach the product engineers on how this [device] parameter might be associated with that fab parameter.” He noted that such interaction isn’t new—it’s the amount of data involved that has changed.
The test engineer’s role
Bollish commented “Maybe some companies don’t appreciate the test engineers, but at Freescale we certainly do appreciate them.” Test engineering, he said, is where a lot of the extra work is happening to bring together all the different variables necessary to get a high-quality product to market. He added, “One thing that has been true of test engineers all along is definitely true now. With these devices getting more and more complex, you need the curiosity to go solve problems, and you also need to know what questions to ask and how to work to get the answers. Some of this you can’t teach. Some of it is innate, some is picked up in the environment that we put our engineers into. The good ones always seem to come up with those skills, whether they had them before they got here or acquired them from the environments we put them in. They form a hypothesis and perform the follow through.”
He commented, “The classic engineering approach of saying, 'oh we’ve got a circuit out and it’s time to get a test engineer involved’—those days are long gone, there’s nothing new there.” What is new, he said, are the increasing time pressures involved in getting complex products to market quickly, especially, he added, “given how fast today’s design-automation tools are completing the designs of very, very large circuits.” Test engineers must work hard to keep up with the other engineering domains, he said, adding, “That’s the key point—it really, really becomes challenging to stay out of the critical path.”
Steady as she goes
08/01/2008Testing right from the start
07/31/2009MEMS create 3-D inspection challenges
06/01/2008
-
FLIR offers IR camera for under $3000
-
Don't let the economy compromise quality (Guest commentary)
-
Danaher speeds up restructuring, acquires life-sciences businesses
-
Agilent’s Cover-Extend technology eliminates need for physical test points for in-circuit test
-
So many combinations: Testing a switch-matrix board
View All Webcasts
