What, Me Worry? : Is Your Design Team DFT-aware?

This post came about after reading John Ford's post about the value of a DFT education for designers. Forget appreciation, DFT is usually the least-understood specialization in the ASIC design flow.

In my opinion, DFT is not that easy to "get" primarily because it requires a viewpoint different from synthesis, timing and place-and-route. In those fields, you usually worry about timing, area and power. It's easier to apply your knowledge from synthesis to PNR. In DFT, you worry about fault coverage, controllability and observability; concepts alien to the rest of the ASIC design flow. It gets worse. More often than not, project and design managers are from a place-and-route, synthesis or timing background. Not many DFT engineers managing projects out there. Ergo: A clear understanding of DFT is lacking at most higher levels of the engineering hierarchy. Is it any wonder that DFT is the least of the design team's priorities?

What are your options? This list is AND'ed not OR'ed (do (1) AND (2) AND (3)...).

• Have a set of non-negotiable DFT rules that everyone has to follow. This would include ensuring controllability of resets and clocks, etc. I think it's important to have a list that is not open to negotiation (or else the DFT engineer ends up having to explain each and every rule to each and everyone). This is not a enlightened approach but it saves both DFT and non-DFT groups time and energy.
  
• Have a DFT checklist like John's that can be used by all designers to ensure DFT compliance. This list would be a checklist form of the aforementioned non-negotiable rules.
  
• Use a tool like Atrenta's Spyglass-DFT to check your RTL for DFT issues. Automated approaches to verify DFT compliance is so much more error-proof than looking through millions of lines of uncommented code.
• Have a very well-defined handoff mechanism between DFT and other functions to ensure minimum confusion for the non-DFT folks. The idea is to give them what they can use without knowing the first thing about DFT. Don' t explain the differences between scan shift, scan capture and scan transition modes to the STA engineers; give them a set of appropriate constraints (comes straight out of Tetramax, if you have it) that they can use as-is. Don't explain how to identify scan chains for re-ordering to the PNR engineers; give them a scandef file that can be read both in Synopsys and Magma.

Tags : Methodology, DFT, ASIC, VLSI

Will It Blend? : Combining ASIC, FPGA and Structured ASIC On A Single SoC

The availability of structured ASIC IP for use within standard SoC creates yet another option for ASIC design houses seeking to balance NRE, per-unit cost and time-to-market. You can see the announcement by ChipX here. If this trend keeps up, the options available to ASIC design houses when it comes to design implementation will be a blend of implementation technologies where designers choose the optimal mix of FPGA, structured ASIC and standard cell technologies to hit their target NRE-UC-TTM sweet spot. There was at least one company, Leopard Logic, that created FPGA IP that could be embedded into a standard SoC. Just a short hop to a company offering all three technologies on the same die.

Think of the advantages that each approach bring to the table:

• FPGA : Highly configurable, Fast Time-to-Market , Low performance
  
• Standard Cells : Zero configurability, High time-to-market, High performance
• Structured ASIC : Medium configurability, Medium time-to-market, Medium performance

Can we have the advantages of all the three if a SoC is built using all three technologies? Just flip the equation.

• Blocks that require configurability but can live with low performance : use FPGA IP
  
• Blocks that require high performance : use Standard cells
  
• Blocks that require medium configurability but only medium performance : use structured ASIC IP

Are we heading towards the universal ASIC design flow that can handle all three technologies on a single die?


Tags : Methodology, FPGA,ASIC, VLSI