CDC for MBIST: Who Knew?

Now and again, I enjoy circling back to a topic on which I spent a good deal of time back in my Atrenta days – clock domain crossing analysis (CDC). This is an area that still has opportunity to surprise me at least, in this case looking at CDC analysis around MBIST logic. CDC for MBIST might seem strange. Isn’t everything in test mode synchronous with a single clock? Not quite. JTAG runs on an independent and relatively slow clock whereas MBIST runs on a system speed clock. On the first day of Synopsys Verification Day 2021, Wesley Lee of Samsung gave a nice overview on the details of this unique application of CDC analysis.

Who cares?

CDC is for functional mode problems surely. Who cares if a synchronization error occurs in MBIST testing? Samsung does and good for them. MBIST isn’t just for bring-up testing. High safety level auto electronics now launch periodic inflight testing to check all critical blocks are functioning correctly. MBIST testing would be included in that checklist, but it wouldn’t be very useful if it might be susceptible to synchronization errors. Best case it reports an error on a good memory and your car keeps demanding it be taken in for service. Worst case it fails to report an error on a bad memory…

What’s special about MBIST CDC?

First, Samsung do before and after CDC analyses. “Before” is with master and slave TAP controllers and connections inserted, though with JTAG disabled and without MBIST controllers. “After” is with JTAG enabled and MBIST controllers inserted. Wesley’s rationale for this is that the MBIST logic alone represents a significant addition to the rest of the design. He wants first to flush out problems without MBIST to simplify analysis when MBIST is added.

He mentioned finding value particularly in Machine Learning-based analysis for clustering violations around common root-causes. I remember the early days of combing through thousands of violations, trying to figure out where they all came from. The ML extensions represent a **huge** advance.

Exception analysis

The thing that really stood out for me in Wesley’s talk was optimization of the analysis through quasi static assignments and other constraints. You can be slapdash with these assignments in CDC, but Wesley’s approach is very surgical.

In functional mode, the JTAG interface is obviously static, whereas in MBIST mode, some interface signals can be case analyzed (set to a fixed value). Some signals from slave TAPs to the corresponding MBIST controllers counts as effectively synchronized because they are qualified by an enable signal which is synchronized.

More interesting still, some MBIST signals interface with the slave TAP controller without synchronization or qualification of any kind. You should understand that this design uses a 3^rd-party MBIST controller, so Wesley can’t just walk down the hall to ask why. They needed a meeting or two with the supplier to figure out why they considered this approach OK. The supplier explained that the controller knows how long its analysis will take. It counts for that number of clocks, plus a margin and then transmits these signals. In effect the signals are quasi-static until the slave TAP reads these values and again quasi static beyond that point.

Wesley’s summed up by saying that sometimes you must understand programming sequences. Not all quasi-static assignments have no-brainer rationales. Sometimes you really need to dig into the functionality.

A very interesting review of CDC analysis around MBIST. You can learn more from the recorded session. Wesley’s gave his talk on Day 1.

Also Read:

AI and ML for Sanity Regressions

IBM and HPE Keynotes at Synopsys Verification Day

Reliability Analysis for Mission-Critical IC design