Spyglass MBIST – is it BIST? or something else…
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.
Stumble It!
John,
I don’t understand how you can do a MBIST that is independent of the physical SRAM part. A lot of tests involve setting a bit to one value and then writing the opposite value to all it’s adjacent neighbors before checking to see if the original bit is preserved. How could you design that test without knowing the actual physical layout of the SRAM? A vendor could have several variants of a SRAM cut with different aspect ratios. They could be designed so that each variant needed a different bist test.
RTL insertion is the only way to go. MBIST sims are huge and you need to be able to debug your sims in RTL. Do not try to debug these in gates, it is a huge waste of time. You also need to run all of your RTL checking tools on the mbist and catch dft and clock crossing issues.
I don’t see what their tool does that we weren’t doing with a perl script years ago.
John Eaton
John,
I must confess that I do not know a lot about the Atreneta solution, but I respectfully disagree with the “vendor independence” point in your blog.
Most BIST tools from EDA vendors allow the user to define and load custom BIST algorithms. Further, the tools can model the physical attributes of the memory that affect memory BIST (address/data scrambling, etc.). These parameters are the keys to defining the effectiveness of the BIST test for any memory.
You can be memory vendor independent using commercial EDA tools if you have the recommended algorithms and physical information. My experience is that all major memory providers (except for one) will readily provide this information to the end-user.
To be honest, I do not understand the trend of memory providers also providng BIST tools. IMHO, the BIST problem has already been solved by the EDA vendors, and re-solving the problem takes an enormous amount of resources and energy away from the IP provider’s core competency – designing robust memories.
I believe the memory providers should just provide the BIST models and BIST alogoritm files for each of the comemrcial EDA tool solutions. One exception to this might be CAM’s. But even a CAM can be tested as an SRAM, and supplanted with DMA functional tests.
-Joe
Further, the tools can model the physical attributes of the memory that affect memory BIST (address/data scrambling, etc.). These parameters are the keys to defining the effectiveness of the BIST test for any memory.
You can be memory vendor independent using commercial EDA tools if you have the recommended algorithms and physical information. My experience is that all major memory providers (except for one) will readily provide this information to the end-user.
———————————-
Joe,
My experience has always been that we would have the silicon vendor do the mbist test. We would spec a max defect rate and they could make the trade offs whether or not adding a better bist or repairable srams would improve yield or reduce test escapes enough to justify the cost. There were also some issues with how you handled srams during atpg tests that were better handled when one person was responsible for both tests.If you are going to hold a ic vendor accountable for defects then you have to let them make the decisions that affect test quality. You cannot penalize them because you created a lousy mbist test.
It’s also cleaner in production. If you find sram test escapes during your
ramp then you need to modify the test to catch them. Whoever designs the mbist must provide production support.
Is there an industry standard for how to provide this information about the srams?
John Eaton
I do see much emphasis on the BIST generators, however, we ought to ensure that BIST logic have diagnostic capabilities. I am not sure what solutions are available such that, DFM(Design for Manufacture) defects can be diagnonised with failure mechanisms graded as per the fault models, due to either mask defects or early life failures.
We have embarked on at speed BIST testing. Therefore diagnosis of failure locations and mapping onto the fault models would be vital. As we progress onto smaller geometries, with the memories occupying largest proportions of real estate. Such failures analysis capability could provide a vital input back to into the foundaries, as the fabrication process ramps towards maturity.
Mohamed Alarakhia
Great comments, folks! I agree w/ Joe that vendor independence was a puzzling term to use – I was relaying that from Atrenta, BTW.
I think they were saying that no matter who designed the BIST, they could insert it, given the right information. But Joe is right, most BIST solutions are user programmable so that they are independent of memory vendor, which is a slightly different thing in this case.
This is a great conversation about a design-for-test product. Who’s missing from it? Atrenta?
JMF
Hello all,
Thanks for all the great comments and taking the time to read the press release and the white paper. As an application engineer at Atrenta, I have been involved in helping support and deploy this tool for our customers.
This project was initiated as a collaborative effort between a memory vendor and Atrenta to replace the gate level BIST insertion and repair solution to the RTL. True, the BIST algorithms are proprietary and suitable for the memories they provide (both being supplied by the memory vendor). However, once all of these are encapsulated in library cells (we leverage the vendor independence from this point onwards), our tool does the following:
(i) memory identification followed by matching with appropriate BIST,
(ii) insertion of BIST repair components
(iii) insert various controllers at various levels of hierarchies and finally establish all the connections
(iv) prepare scripts for formal equivalence in functional mode
(v) prepare testbenches for BIST-mode simulation. Keep in mind that the RTL designer does not want to provide the post-BIST RTL to the memory vendor.
While working with several providers, we came across various ways of associating Memory with BIST engines, need for various types of sanity checks on the way. We needed to modify our tool
from time to time. But, we observed a basic framework of supplying Memories, BIST and generating/validating modified RTL. As an EDA solution provider we wanted to capture this opportunity.
Thanks again for your interest in this topic!
== Aloke K Das
Thanks again for your interest in this topic!
== Aloke K Das
———————————–
Aloke,
How does your tool handle bist groupings? Can you group srams together with their nearest neighbors?
John Eaton
John,
Sorry to be late in responding.
We take a table lookup approach. We need the vendor to provide the BIST IPs (memory/BIST combo) in various configurations. For example, one configuration can be a dedicated pairing of a type of memory and a type of BIST. The other could be a set of memories sharing a BIST.
The tool will identify all the memories at various level of hierarchies and suggest a suitable BIST IP to replace a set of memories (independent of the hierarchy). Adjacency of the memories plays a role in the selection of the BIST IP. The process is also interactive in the sense that the designer can override the tool suggestion if wanted. Also, it may be possible to result into multiple matches and the choices are presented to the designer. In that case designer needs to provide a unique choice of grouping.
Pl. let me know if this answers your questions.
Best regards,
== Aloke
aloke@atrenta.com
Pl. let me know if this answers your questions.
————————
Not really. The chips that I have worked on usually have at least two types of srams, one for high speed and the other for low cost. There is a mixture of single port and dual port and write enables are either bit,byte or word enabled. On top of that you have a complete array of data widths and address sizes.
We usually see from 30 to 50 sram cuts. Some will be large enough to use memory repair on them. You can have all srams with their own bist or any combination of two srams sharing a bist and that could easily run up to 3,4 or more srams per bist. Then you can mix them with some having one sram per bist, some having two etc.
The number of possibilities can quickly run into the 10’s of millions. I don’t see anybody creating all those lib parts for your tool to use.
If your designers are burying their srams deep in the hierarchy then you are doomed from the start. You create a standard interface for an sram and all designers must separate their srams from their synthesizable code using this interface. Use a “Correct by Construction” toolset to add the srams and you can easily support random bist groupings and changing vendors.
John Eaton
“You create a standard interface for an sram and all designers must separate their srams from their synthesizable code using this interface.”
Hello John,
I was not clear about the description of the BIST IPs. Our BIST IPs merely describes the association of the BIST engine/controller with one or more specified number of memories. The RTL designer does not need to have any knowledge of the BIST IP, nor they will require to adhere to any standard interface. Memories can also be instantiated at any levels of hierarchies.
Suppose, the designer instantiates one memory (M1) at a level of hierarchy and another memory (M2) at another level of hierarchy. Lets say that there is a BIST IP in the library that associates a BIST engine (C) with two memories M1 and M2. Our BIST match report will indicate that these two memory instances can be hooked up with C in the BISTed RTL. Note, the hierarchies of the memories are not going to change, but the location of the new element C can be chosen by the designer.
What you may be suggesting is that there are designated BIST engines in the vendor provided library and they can support one, two, four etc. memories. The tool can make a decision about the grouping and subsequent connectivity. This is what we do not do today, but we understand this is a requirement we may need to address in future.
== Aloke
For the record, all of the functionality John Eaton is referring to is covered by LogicVision’s ETMemory solution. The solution automatically allocates memories to BIST controllers based on various constrants including physical location, clock domain, size, max average power and others. It also takes physical layout info about the memory and supports user programmable algos to ensure full defect coverage. In regards to the comment about the silicon vendor being the one who should provide the BIST, both TSMC and IBM have recently announced that they were endorsing LogicVision’s ETMemory solution to their foundry customers. They provide the algo guidelines and redundancy requirements but leave the actual BIST implementation to the experts.
So, Atrenta and LogicVision have products that only stitch the user’s BIST IP into the design – cool. What does Mentor offer in this category? Are there any commercial trade-offs when using IBM’s BIST vs. third-party BIST?