I didn’t read it that closely, I suppose, because it did say “Atrenta’s SpyGlass®-MBIST (memory built-in self test) insertion solution”… [emphasis is mine]  I missed that word insertion. Oops.

But that’s it.  This tool serves the niche where a company, usually an IDM (Integrated Device Manufacturer), has a homegrown BIST implementation that needs a better integration path – in RTL.  In a white paper provided by Atrenta, the prime motivation behind this tool is the benefit of inserting MBIST at the RTL stage of development – independent of vendor.

The “vendor independence” is really the differentiator.  LogicVision, Mentor, and SynTest all insert memory BIST – but it’s their own BIST IP that is hoooked up.  Virage and ARM also do the same, for their own memory IP.  All in RTL (most of them support gate-level insertion as well).  But if you’ve designed your own memories, and your own BIST to fit them – Spyglass MBIST could be the tool for you.

And they all have it right – RTL is the way to go, especially for verifying the BIST.  These tests, at the gate-level, are prohibitively long.  But there is one thing: I don’t think any one of these tools supports SystemVerilog.  So if your designers are itching to use some of the more advanced features of SystemVerilog, for logic design (not just verification) – be forewarned, the automation will break down.  Of the companies I have asked about this – they’ve all said it’s on their roadmap, for next year.

As luck (or Murphy) would have it, just when we thought we had the at-speed logic test problem licked, along comes all these power problems. But no need to panic (at least not for this…) because as it turns out, there are a bunch of techniques you can use to deal with this growing challenge.

In a nutshell, at-speed logic test techniques, both BIST and ATPG-based by the way, can cause power variations that don’t occur during functional operation. These variations often cause inaccurate testing or possibly worse, harm to the device under test. These power variations come in two (not very appetizing) flavors: instantaneous power variations, typically seen at the beginning of a pattern or timing sequence, and average power variations, due to different circuit activity levels. The instantaneous flavor is often referred to as a di/dt issue because a sudden change in circuit activity caused by the application of a test pattern or sequence causes a sudden change in the current through the device power network. This sudden current change is opposed by the inherent inductance in the network and causes a drop in the voltage level seen by the transistors. The average power problem is often referred to as an IR-drop issue. Here, increased circuit activity during test causes higher average current which due to the resistance of the power network causes once again a drop in the voltage level seen by the transistors. In both cases, the drop in the voltage level at the very least affects circuit timing and thus the quality of any at-speed tests. In the worst case, the drop will cause the circuit to fail and result in throwing away a possibly good part.

To avoid the IR-drop issue, the test approach has to go Green and use less power. There are a number of simple things and a few less simple (er, complex) things that can be done to achieve this. The simple things include turning off I/Os, de-selecting embedded memories, and applying tests to the device in stages (usually by hierarchical region) while disabling the clocks and/or loading constant values in blocks not currently under test.. A more complex approach is to limit the amount of circuit toggling activity that occurs during scan as this tends to be much higher than during functional operation. One way to achieve this is to reduce how often consecutive bit values toggle within each scan pattern. This can be done during the test pattern generation process if ATPG patterns are used or by controlling (biasing) the output of the PRPG if logic BIST is being used. Another approach is to gate the functional output of high-fanout flip-flops during the scan process. This however results in additional overhead and affects the quality of at-speed tests on some of the longer paths.

Avoiding the instantaneous power issue is a little trickier. There are two general approaches to this: wait long enough for the di/dt effect to subside before capturing the test result OR ramp up activity slowly enough to avoid the di/dt effect altogether. Consider the following: the typical approach to apply an at-speed scan test is to load a pattern using a relatively slow scan clock (say at 50 MHz) and then once the pattern is loaded apply two consecutive functional clock cycles (often in the 100s of MHz range) to perform the at-speed launch and capture. The di/dt effect occurs here due to the sudden transition from the scan activity to the much faster functional clock pulses. The problem is well documented in several papers including this one from Intel. One way to avoid this problem is to use a technique called BurstMode which allows multiple functional clock cycles to be applied after the scan operation but before the test response is captured. The additional functional clock cycles provide enough time for the di/dt effect to subside before capturing the circuit response.

Power constraints during test are here to stay. There are many existing techniques and many more in development for dealing with these pesky issues. So the bigger challenge will be to keep current on available solutions and then choose the right mix for your design.

[Steve Pateras is VP of marketing at LogicVision. Steve performed his graduate work in test and has spent his entire career involved in either using, defining, or marketing DFT and BIST products and technologies]

The May/June issue that just arrived in my mailbox this week did not disappoint – it was part 2 of the special issue on IEEE Std 1500 and Its Usage – I blogged about the first part in February: Get to the core of the matter – how will you test that core?. I tacked the discussion in the magazine onto other discussion that had taken place in the LinkedIn groups I had been watching.

Part 1 of the 1500 coverage in D&T aimed at bringing the reader up to speed on the objectives of the standard, the core test infrastructure and the language that expresses it, CTL (Core Test Language, itself an IEEE standard), improvements in core isolation, and some usage examples in the industry and EDA tools.

Part 2 tackled automation and verification of the standard, as well as some analysis of test data volume of modular (i.e. 1500-like) vs. monolithic testing. Also interesting was an article about core-based test of a mixed-signal SoC.

I guess the idea behind these two magazine issues was to show that core-based test, and in particular IEEE 1500 test, really is making its way into the mainstream, both with respect to industry acceptance and automation provided by EDA tools. Not that many people read what I write – but I have asked the question before, more than once, that if this really were a practical methodology, then, where are the tools? If it’s such a great way to go, why doesn’t everyone I talk to say “yeah, of course we’re doing that?”

So where are the tools? Between the two issues, there are two articles from folks representing EDA vendors: SynTest and Cadence. The SynTest article describes “Turbo1500″, a suite of tools for automating wrapper and scan insertion for a core-based SoC. The Cadence article also describes an automation methodology and a supposed tool-set to address IEEE 1500. Neither company has made announcements or document these tool-sets on their websites, so I guess the articles were more forward-looking than anything else. But great! At least someone’s working on them, right?  Right?

In all fairness, there are some companies that do use the 1500 infrastructure as part of tool-sets that serve other purposes.  That’s a start.

The article that most interested me was offered up in part 2 concerning test data volume: Test Data Volume Comparison: Monolithic vs. Modular SoC Testing, written by Sinanoglu, Seghal, Marinissen, Fitzgerald and Rearick (from a variety of places, so I’m guessing they were all involved in the standards work). The article set out both conceptual and mathematical arguments confirming that the benefits derived from approaching SoC test in a modular way far exceeded the cost of implementing core wrappers and the extra time required to access them.

That’s good news – for those who have the foresight to pursue modular test and test mechanisms from the start of your project – the payoff is there…

John Cooley in his post on DeepChip – entitled, “What Mentor-LogicVision merger means for digital scan test“, perfectly illustrates the typical viewpoint of the general population of EDA watchers. As if “digital scan test” came even close to describing what the deal was about.

His first statement, “There’s massive overlap between the LogicVision and Mentor product lines….”.  Gabe Moretti, on his blog Gabe on EDA, in his blog post on the subject, seemed to think the same: “On the surface it looks like there is significant overlap between the products…“.

To Moretti’s credit, at least he tried to dig deeper into a real comparison of the product lines, however unclear he seems to be on the concepts.  Cooley, on the other hand,  appears to have visited the company websites, and scanned through the product list:  “memory test – check…  Logic BIST – check… compresion, check…”,  and then counted the check-marks.

But it’s not my objective to pick on these guys.

Seriously folks, the existence of a tool does not imply a strength, and using somewhat the same name for a tool does not make an overlap.  I’d be pointing out the obvious to say that the analysis went a bit deeper as the deal was considered.  I don’t deny there is overlap.  The companies do sell similar tools.  But maybe it’s easier to compare their strengths:

For sure, the flagship product of Mentor’s IC Test offerings is TestKompress - compression IP generation and ATPG (TK works just like FastScan if you turn off the compression part of it).  Combine that with YieldAssist to provide the feedback path to the Calibre physical database, and you have the the pieces around which Mentor has put a significant amount of effort: yield analysis and volume diagnostics.

LogicVision, on the other hand, is focused squarely on BIST: memory BIST, Logic BIST, mixed-signal BIST. Even its so-called compression tool is a variation on its logic BIST.  ScanBurst is an attempt to meet die-hard ATPG users half-way and offer some of the advantages of the logic BIST infrastructure. BIST, BIST, BIST…

LogicVision’s yield analysis tool (Yield Insight) exploits failure data from their BIST tools.  Mentor’s yield data comes from ATPG failures.  Mentor, with yield data from both logic and memory will now have a complete solution for volume diagnostics, right?  And, the whole picture is available whether you choose to do deterministic scan, logic BIST, or both.  To my knowledge, Mentor does not have linkage between its BIST tools (memory or logic) and the physical database for this purpose.  I believe that this is really what Mentor wanted.

Both companies offer boundary scan tools, but like all companies that do, these tools are minor products, more or less, that serve mostly to generate IP for various test access to their BIST implementations – the boundary scan part of it is standards driven, so there’s no real secret sauce there.

I blogged the announcement when it happened a couple weeks ago, and received 2 comments wondering why Synopsys hadn’t been the one to pick it up, still citing the overlap, and one even wondering if Synopsys had been outbid by Mentor.  I don’t know – I have no special insight or inside knowledge.  Maybe the commenter is right, I should see what thought, if any, Synopsys has on the situation – maybe when the deal goes through, I’ll see if I can get a comment.  But it seems like Synopsys was busy picking up analog IP…

As an engineer with a day job that has less to do with design automation or tool support, and more to do with nut-and-bolts DFT planning and implementation, there’s a slim chance that I will be traveling to this show as a representative of my employer.   On the other hand, as an EDA Blogger, I like to go to DAC to check out what’s happening in EDA, talk to DFT vendors, blog whatever fascinating things I see, and maybe meet up with some other bloggers.  I met JL Gray two years ago, and a few others last year in San Diego.

But here’s the thing:  I scanned through the DAC program, got to the end and said, “wait, what? No DFT?” [this is not unusual for DAC] I scanned again, and found a couple of talks that are test-related.  But then again, many times when someone from the “greater EDA community” says “test”, they mean “verification testcase”.  Hmmm… what about exhibitors?  Well, yeah, the bigger EDA companies are there,  and 3-4 DFT or test-related folks like SynTest, WinterLogic and TSSI.  But with no technical content at all, I think I’ll bypass DAC and stay in Carmel for my vacation instead (this pleases my wife, for sure! ).

All this reminds me of something that Lou Covey keeps saying to me: DFT EDA should probably be shown at SemiCon, not DAC.  Well, SemiCon is more testy than DAC, but DAC is so much more designy than SemiCon.  What’s a poor DESIGN-for-TEST guy to do?  Well, go over to the Semicon website and have a gander at the exhibitors, the program – I don’t think DFT really fits in.

I like reading Lou Covey – I think he shoots straight – calls it the way he see’s it.  But I just don’t agree with him on this.  As much as I carry on about how DFT stands on its own, the “greater Test community” is huge - much bigger than DAC.   Seriously, design automation is software, and at its very worst, math.  But Semicon runs the gamut from software to mechanical and chemical engineering, robotics, construction – I could go on.  It’s hardcore.

So no, in my opinion, DFT is not for Semicon – maybe, just maybe, only as it ties into DFM – Semicon is a manufacturing showcase.  In fact, many of the ATE vendors pulled out of ITC years ago in favor of Semicon – it makes sense.

But before anyone starts to think that I lament for a place for DFT – stop – there are plenty: ITC, VTS, ITSW, SWDFT… those are just some of the ones in the US – the truth is there are many places in the world where the subject of design-for-test is a key topic.  The venues are smaller, because compared to other disciplines in the industry, the number of practitioners is small.

This is a niche blog – no, really! 

Both companies, when contacted, were reluctant to provide any more details until the deal is done, however Stephen Pateras of LogicVision did say,

“We feel the merger makes sense for both LV employees and LV’s customers. For the most part our products are complimentary to Mentor’s DFT products.”

I guess I’d have to agree with Steve.  As far as being beneficial to LogicVision employees, it seems like a win for them.  Mentor’s stock, for the last couple of months, has finally started recovering from its downhill tumble that started around the time of Cadence’s failed takeover bid in June of last year.  LogicVision stock, on the other hand, has been pretty consistently hovering around $1/share since Virage’s failed takeover bid for them, in December.  So LV stockholders can hitch a ride on Mentor’s ascent… takeover targets make good bedfellows?

There’s not a whole lot of overlap between the DFT products of the two companies – well, they both market MBIST, LBIST tools, and boundary scan tools – but in my opinion, LV brings more experience to the table here.  Mentor has always been thought of as a 1st-tier DFT provider, but its BIST and BSD tools have taken a back seat to its scan and compression tool, TestKompress, with which they continue to improve the amount of compression possible, and use it as the feedback link in their strong DFM offerings.  LogicVision also brings mixed-signal BIST tools to the table (ETSerDes and ETPLL), as well as a more mature IEEE 1149.6 BSD tool.

There’s also a case for existing synergy as well, since LogicVision has been marketing ScanBurst, an at-speed clocking infrastructure that works with TestKompress.

David Stannard of Cadence [formerly of Mentor - he actually taught me FastScan, many years ago!] provides a very thoughtful assessment of the deal in Daniel Payne’s blog post “Mentor Acquires LogicVision“, and concludes it this way:

“I feel that this is a win for Mentor, a win for the old LV customers, and increased pressure for Synopsys and Cadence. IMO, Mentor is #1, consolidates its ability to be #1 for existing customers and with the majority of the remaining market being held by Synopsys.”

So there you have it.  If the deal goes through, it is planned to ba a “reverse triangular merger” (which I’m pretty sure Kobe Bryant can do on the b-ball court) where a piece of Mentor will be absorbed into LogicVision, which will then become a wholly owned piece of Mentor, which makes me think that we’ll still be seeing the LogicVision logo on products for some time to come – but that’s my own conjecture.  Either way, I think Mentor has anchored itself as the major DFT player in the industry.

So, why would anyone want to advertise on DFT Digest? There are many EDA websites, news outlets and portals to choose from, many with a much larger audience. But perhaps you’re looking for a more direct run at your customers. This is what DFT Digest offers.

DFT Digest is targeted squarely at the Design-for-Test professional. It’s been up and running for just over 3 years, and in that time has consistently grown in readership (doubling each year), world-wide, as the word has spread. The DFT community, as compared to the whole of EDA is much smaller, and frankly DFT doesn’t get much attention in the mainstream of EDA media at all. That’s the reason I started DFT Digest – a one stop shop, if you will, for all things Design-for-Test – and don’t forget, we also have DFT community participation in the DFT Forum.

All that is a long way to say what Ron Ploof has said before in one sentence: “Old Media fires random messages at “eyeballs.” New Media presents relevant messages to “eyeballs that CARE.”

More and more companies are finding that the best way to get and keep customers is to have a direct conversation with them. DFT Digest and DFT Forum provide this by creating original DFT-related material as well as inviting contributed content discussing the issues addressed by tools that are (or should be) offered by EDA vendors, in a non-vendor-specific way. Customers are better cultivated by information, not direct sales pitches.

So how do we do this? The bigger EDA sites offer many levels of sponsorship opportunities that run well into the thousands of dollars per month. DFT Digest offers a simple but very targeted and affordable approach to your DFT professional, so let’s talk about it! e-mail me (John) at jford@dftdigest.com for site stats, ad sizes and rates.

Probably one of the hottest design topics these days is power minimization. This is not surprising given how much we love our high-performance mobile and wireless toys. But what does that mean to BIST solutions? Well, low power requirements affect BIST solutions (and DFT in general) in two separate ways. First, it’s important to ensure that any functional power constraints are met (or at least adequately managed) during BIST execution. Second, it’s necessary to ensure that a BIST solution is compatible with whatever low-power design techniques are being used. Since my last post was on memory repair, I’ll complete that topic here with a discussion on power management. In my next post, we’ll turn to logic BIST features and techniques for supporting low power designs.

If you recall from John’s post on Memory Repair Basics, the self-repair process involves determining the repair info for each repairable memory on the die using built-in repair analysis (BIRA) logic and then shifting and burning this info into a centralized eFuse array. Then each time the device is powered up, the repair info is shifted out of the eFuse array and back into each memory’s repair register. This last step typically uses a single serial shift register that is routed to all memories that have redundancy. Using a single serial register, greatly minimizes routing overhead and simplifies the management of the repair data. This simple approach, however, breaks down when voltage islands are used.

Use of voltage islands, an increasing popular power management approach, involves using a separate supply voltage for each core (or, possibly, group of cores) within a design. Each resulting island can then be shut down when it isn’t needed and re-activated when it is. As you might have guessed, all of this powering up and down activity poses some serious problems with repairable memories. When a sleeping island is re-activated, the repair information for the repairable memories in that island will have been lost and will need to be reloaded. The challenge here is twofold: the reloading has to occur without disrupting the already active islands, and the reloading can’t be affected by the fact that some islands may still be inactive.

To handle these constraints, the self-repair process described above has to be augmented to provide at least one repair shift register for each voltage island. Each shift register can be of arbitrary length. A functional power management unit indicates to the self-repair controller which shift register(s) need to be loaded. The other shift registers are kept in a stable state as they might contain repair information of active voltage islands. When multiple islands are re-activated, the controller will generally need to load them sequentially according to a default priority defined at design time. The operation is sequential since all repair information is typically stored in the same eFuse array. If the loading order needs to be changed, the power management unit simply needs to re-activate each island one at a time in the desired order. One possible performance improvement suggestion is to have a flag set by the controller as soon as a repair register has been loaded so that critical memories can be used immediately–without waiting for all memories to be repaired.

[Steve Pateras is VP of marketing at LogicVision. Steve performed his graduate work in test and has spent his entire career involved in either using, defining, or marketing DFT and BIST products and technologies]

I trip upon the following interview in Test & Measurement World – with Joseph Sawicki of Mentor (GM of the Design-to-Silicon Division), and in response to the first question, he says, “DFT is really the fundamental driver of the economics affecting the IC design chain.”

Beautiful! As a DFT guy, I love this. Finally. No one ever talks about DFT in the EDA press or blogosphere (except for me).  Even T&M World talks mostly about oscilloscopes, IMHO.  But Sawiki hits the nail on the head. If there is a linchpin in the profitability of an electronics enterprise, it’s Test, and DFT drives the efficiency of the test solution.

I like this quote so much, I tweet it. I tweet random stuff like this every once in awhile – nobody really notices. But today, John Blyler of Chip Design Magazine picks up on it, and tweets back, “Joe said that? You sure he didn’t mean DFM? or DFY?“.  Chris Edwards (of the Shrinking Violence blog) points out in a blog post almost immediately (before I get back from lunch) that Mr. Sawicki has spent the last ten years driving Mentor’s DFM strategy, and surely folks think I have misquoted him.

In the same blog post, Edwards mentions something that ARM CTO Mike Muller said during his DATE ‘09 keynote – that one class of EDA tools he is most thankful for is DFT/test automation. He was referring to the automation part (stitching scan chains) but also mentioned DFT tools role in yield analysis – DFT tools are the data collection part of DFM, right?

Edwards tweets at myself and Blyler: “Mike Muller (ARM) also very keen on DFT right now – it’s all to do with the yield analysis and management features“. Blyler, still unbelieving, tweets back at Edwards: “‘ARM keen on DFT.’ Can you point me to a recent article? And why call it DFT? Does it affect test more than manufacturing?” I suppose he is talking about the data collection.

But the interview with Sawicki really only touches on DFM briefly – the main topic is Mentor’s DFT tools – he talks about scan, boundary scan, memory test and logic BIST.  And the follow-up to his first sentence that I tweeted – explains his statement. Here’s the whole thing:

DFT is really the fundamental driver of the economics affecting the IC design chain. It’s the primary method of eliminating defective parts. If you do a poor job of test planning or if you introduce ineffective tests, you risk damaging product quality and your company’s reputation. Test costs also have a direct impact on the cost of goods sold, which is why it’s essential to prevent inefficiencies in manufacturing tests that cause false rejections and reduce yield. There’s a major trend toward leveraging test and diagnostic information over a product’s life cycle to improve yield and company profitability.

There you have it.  Quality and efficiency of test go straight to a company’s bottom line, and its reputation. DFT has always been about manufacturability – since way before the term Design for Manufacturability was coined.  And its a key piece of your new DFM flow that nobody ever talks about…

I don’t get no respect! No respect at all!

- Rodney Dangerfield, surely one of the first DFT engineers