feature article
Subscribe Now

New Synopsys SoC Test Features

Cell-Aware: Meet Slack-Based. And STAR: Meet eFlash.

Ah, the air has cooled. The sun lolls about at a low angle for a few tentative hours. Morning frosts seal the fate of any remaining tender plants. Here in northern Oregon, the Gorge winds blow random gale-force patterns, making it unnecessary to sweep the leaves off of the patio. And, slightly farther north, it’s ITC (that would be the International Test Conference) season, in Seattle this year.

Which means it’s the season for test announcements by EDA companies. Synopsys made some noise, but not with one big blockbuster new thing; rather they assembled a couple of newsy bits that, summed together, merit some discussion.

Just to organize my thinking here, so that I don’t get us lost, there are two basic announcements: Cell-aware+Slack-based testing and STAR for eFLASH. The first involves two subtopics that we should review first.

Cell Awareness

Critical to any test strategy is the notion of coverage. Did you cover all the things that could go wrong? Well, that question leads to another immediate one: “What are all the things that can go wrong?” And this brings us to the world of fault modeling.

Back in a more innocent time, this was easy. You assumed that a fault meant that some line was either broken (so it wouldn’t receive a signal sent to it and would be stuck at some value) or shorted to VCC (outdated “CC” intentional) or ground. And so we had “stuck-at” faults. Nice, but far from comprehensive. (It’s no fair claiming high test coverage by using a model that exposes few faults.)

Since then, fault coverage models have become much more elaborate, including lines bridged together and resistive shorts and such. And those are just the static faults. We also do dynamicfaults for at-speed testing: signals arrive at the right value, but they take too danged long to do so.

These kinds of models depend on the logic of the function being tested. You can create a black box and generate the list of faults to be covered, but those faults are uninfluenced by how the circuits are physically laid out. Line adjacencies and such can create the risk of specific faults that can’t necessarily be intuited from outside a black box. Fin defects are another specific target for this. You might get lucky and find that the new faults are already accounted for in your existing set of tests, but you can’t count on it.

 Figure_1.png

(Image courtesy Synopsys)

This is what Synopsys refers to as cell-aware modeling, and we took a more detailed look at it a few years ago. We’ll keep things at this higher-level review stage here: according to the cells you use, specific additional faults (and tests to find them) will be added that stress the idiosyncratic weaknesses of those particular cells.

Synopsys also has a utility to identify possible cell-aware issues. It’s not an auto-generator, but it does identify fault candidates, from or to which a test engineer can remove or add faults.

Slacking

Meanwhile, over in another corner, we have what Synopsys refers to as slack-based testing. This is something we haven’t looked at in the past in any detail, although, in and of itself, it’s not new.

The idea is that a fault along a path that branches farther down the line may cause a fault along one branch and not the other. Here we’re talking timing faults – some sort of soft defect that causes a slow-down. The idea is pretty straightforward: if one of the two branches is closer to its timing limit (i.e., has less timing slack), then an upstream slow-down is more likely to cause that branch to fail timing, rather than another branch that has more margin.

 Figure_2.png

(Image courtesy Synopsys)

Pretty straightforward. Except that, apparently, standard test algorithms pick the shortest branch – that is, the highest-slack branch – for observation. Because that branch has more margin, it might forgive a slight delay upstream, so you might not notice that there is this delay. That is, until the longer branch fails in a system somewhere. Which isn’t particularly helpful.

So slack-based testing involves taking the longest, or lowest-slack, branch and testing it instead. Note, however, that this applies only to faults occurring before the branch between two paths. If there are faults on the individual paths after the branch, you’d need to test for those separately. Of course, you’ve already tested the longest path, so one test captures faults both before and after the branch, as shown below (Fault sites 1 and 2 between nodes a and c).

Figure_3.png 

(Image courtesy Synopsys)

Note, however, that, thanks to the magic of converging (or reconverging) logic, Fault 2 may also lie along another path. It might be that Fault 2 doesn’t push path a-c beyond its limit, but it also needs to be tested for the other path that includes it – it might break that one.

The figure below shows an alternative path that not only includes Fault 2, but another fault on a gate shared with the a-c path, but not tested along the a-c path. Even in the absence of Fault 3, if the path that comes in via that AND gate has less slack than the a-c path, then Fault 2 on its own might cause a failure even if it doesn’t do so on the a-c path. So that second branch may still need some more tests if those faults are not already covered.

 Figure_4.png

(Image courtesy Synopsys)

Cell-Aware Slacking

Neither the cell-aware nor the slack-based methodology is new. But we review them because of what is new. In the past, they’ve been disconnected, separate approaches. In particular, slack-based testing wasn’t incorporated into cell-aware testing. Or vice versa.

And now they are. In other words, when looking for a cell-aware fault, a slack-based approach can now be utilized.

Of course, then there’s the “be careful what you wish for” syndrome. It would be a bit of an ethical dilemma if you found that you were missing a ton of defects, and [yay] now you’ve identified tests for them, but [boo] it means a ton more tests and lots more test time. Do you spend the money to improve the quality?

Fortunately for Synopsys, their early customer data suggests that this isn’t an issue. In one example, the existing test creation came up with 6119 tests; adding the cell-aware-slack-based tests increased that number by only 121.

Starring eFlash

On a separate note, Synopsys markets a memory-testing infrastructure that they refer to as the STAR Memory System. Its goal is to wrap embedded memory arrays with testability logic for complete memory coverage using a minimum of overhead. It also makes these buried memories accessible to external test equipment. (We saw how a similar approach was applied to IP last year.)

All good, except for one thing: it didn’t include eFlash. Well, this year it does. They’ve added wrappers and logic that support the testing of eFlash.

 Figure_5.png

(Image courtesy Synopsys)

Why is this necessary? Well… for the same reason that it’s necessary to test other types of embedded memory. But if that’s not enough for you, Synopsys adds one more concrete reason: because the automotive standard (ISO 26262) requires the ability to do in-field diagnostics. So without this STAR support, Synopsys couldn’t do that. With STAR, they can.

 

More info:

STAR Memory System

TetraMAX ATPG (cell-aware/slack-based testing)

 

9 thoughts on “New Synopsys SoC Test Features”

  1. Pingback: GVK BIO
  2. Pingback: DMPK Studies
  3. Pingback: juegos de friv
  4. Pingback: pezevenk
  5. Pingback: cpns2016.com

Leave a Reply

featured blogs
Mar 18, 2024
If you've already seen Vivarium, or if you watch it as a result of reading this blog, I'd love to hear what you think about it....
Mar 18, 2024
Innovation in the AI and supercomputing domains is proceeding at a rapid pace, with each new advancement heralding a future more tightly interwoven with the threads of intelligence and computation. Cadence, with the release of its Millennium Platform, co-optimized with NVIDIA...
Mar 18, 2024
Cloud-based EDA tools are critical to accelerating AI chip design and verification; see how NeuReality leveraged cloud-based chip emulation for their 7NR1 NAPU.The post NeuReality Accelerates 7nm AI Chip Tape-Out with Cloud-Based Emulation appeared first on Chip Design....

featured video

We are Altera. We are for the innovators.

Sponsored by Intel

Today we embark on an exciting journey as we transition to Altera, an Intel Company. In a world of endless opportunities and challenges, we are here to provide the flexibility needed by our ecosystem of customers and partners to pioneer and accelerate innovation. As we leap into the future, we are committed to providing easy-to-design and deploy leadership programmable solutions to innovators to unlock extraordinary possibilities for everyone on the planet.

To learn more about Altera visit: http://intel.com/altera

featured paper

Reduce 3D IC design complexity with early package assembly verification

Sponsored by Siemens Digital Industries Software

Uncover the unique challenges, along with the latest Calibre verification solutions, for 3D IC design in this new technical paper. As 2.5D and 3D ICs redefine the possibilities of semiconductor design, discover how Siemens is leading the way in verifying complex multi-dimensional systems, while shifting verification left to do so earlier in the design process.

Click here to read more

featured chalk talk

The Future of Intelligent Devices is Here
Sponsored by Alif Semiconductor
In this episode of Chalk Talk, Amelia Dalton and Henrik Flodell from Alif Semiconductor explore the what, where, and how of Alif’s Ensemble 32-bit microcontrollers and fusion processors. They examine the autonomous intelligent power management, high on-chip integration and isolated security subsystem aspects of these 32-bit microcontrollers and fusion processors, the role that scalability plays in this processor family, and how you can utilize them for your next embedded design.
Aug 9, 2023
26,721 views