Benjamin Franklin, “I didn’t fail the test, I just found 100 ways to do it wrong.” I was reminded of this line during a joint Mentor-ARM seminar yesterday about testing ARM cores and memories. The complexity of testing modern SoC designs at advanced nodes, with multiple integrated ARM cores and other IP, opens up plenty of room for error.
The seminar was a full house with nearly 100 attendees. Steve Pateras, product marketing manager at Mentor, presented first. He described the conditions that are driving new strategies for test and repair. Both ARM and Mentor realized that their customers were integrating single or multiple ARM processors into their SoCs, and teamed up to provide a fully automated DFT strategy. They’ve been working closely for over 7 years. The Cortex A-15 is the core for which they ironed out a full DFT reference flow, which includes documentation and command scripts for test insertion, synthesis, and automatic test pattern generation. The reference flow is available now for the ARM Cortex A15, and will be available for newer ARM cores going forward.
Pateras also described their support for testing memories on a shared bus used in ARM cores. They continue to add automation for things like generating the library files that the MBIST insertion flow needs for each ARM core. Customers can now automate the creation of the core lib file, and will soon have automation for the logical lib file. The physical lib file is created by the ARM compiler.
The second presenter was Richard Slobodnik, product engineer at ARM. He described the ARM core architecture and gave a nice review of the history of ARM core test strategies that eventually led to their standardized MBIST Shared Bus interface. Blocks with a shared bus and with memories on the bus (memory clusters) have a shared test interface to the bus (see the figure).
The shared bus lets multiple memory arrays be serviced with a single BIST interface. This means you don’t need a BIST wrapper for every memory block. They have thoughtfully added these so they don’t impact design performance, and so you can run at-speed tests.
Mr. Slobodnik identified some of the problems that have arisen over the years of developing the shared bus flow, including the difficulty of manually creating the BIST input libraries. Mentor added automation to solve that problem. Another snag is in not being able to trace memories behind the shared bus. This could result in missing some of the memories during BIST insertion. A workaround was described using Mentor’s ETChecker tool, and Mentor is working on providing fully automated support.
A key message I got from this seminar is not only about the complexity of testing SoCs, but that success for the designers depends on extensive cooperation between EDA and IP vendors. Mentor and ARM realize that for their customers to succeed, it truly takes a village.
To learn more, check out the Mentor whitepaper High Quality Test of ARM® Cortex™-A15 Processor Using Tessent® TestKompress® and a high-level pitch of the shared bus support in this video titled Mentor Graphics support of ARM IP.