宋文晶,陈宰曼
(惠瑞捷半导体科技上海有限公司,上海201203)
Today's SOCs are in tegrating more and more functionalities in one chip,while in real application environment,an SOC is still part of a complete system.In this system,an SOC is connected to other devices;it will communicate to other devices by protocols via host interfaces (1).System level test,which will test the whole system in real time,is very important to improve test coverage and ensure the system work correctly in real applications.
Well designed chip level structural test,such as functional test and parametric test,can achieve good test coverage,but there are still many faults only occur in real life conditions.These faults are very difficult to be detected in structural test,for example,low battery level,or data transfer error.To identify such typical faults in early silicon design phase is crucial for time to market and quality.System level test is needed to identify such faults.Meanwhile,many complex SOC devices integrate external IPs in chip.There's no consistent DFT strategy possible to test them.On-chip CPUs or BIST circuitry may have best access to those IP blocks inside SOCs(1).
The common system test access interfaces/protocols used by SOCs include JTAG, SPI, I2C,MDIO,USB,and so on.In system level test,device under test(DUT)communicates with other part of system via protocol transaction through host interfaces.Normally this kind of system level test is done via multiple bench instruments setup in lab.Design and verification engineers will setup an emulation environment,which emulates a real application system.An evaluation board is designed with the DUT and necessary peripheral circuitry,which can be controlled by PC (via host interface protocols).Many bench instruments,such as spectrum analyzer,logic analyzer,will be used to capture and analyze data,and to do device characterization.
Although such test environments are easy to setup,they are lack of large amounts of data collection and analysis capability.For example,if users want to do 2D/3D shmoo over timing/frequency/power level/input level,etc,bench instruments can not do this;Bench instruments don't have data collection/summary tools like datalog or histogram.This makes device characterization not as easy as it is on ATE.Furthermore,the tests are manually handled.It's very time consuming and boring even if you want to test several hundreds of sample devices with such manual solution.Figure 1 is an example setup of bench test environment with box instruments.
Figure1 Bench test with box instruments
On the other hand,ATE (Automatic Test E-quipment)is very powerful at data collection and data analysis,it has powerful tools like datalog and shmoo to support device characterization,and it is designed for automatic test.ATE today is already widely used in final test and wafer test in high volume manufacturing,but it's seldom used in design verification phase.Why?
ATE's test program developing environment is quite different from design environment.Engineers need to spend weeks and months effort to setup a device test program in ATE,based on design data.This is not acceptable for design verification phase.
ATE itself is much more expensive,compared to bench instruments.And,to test device on ATE,a device specific DIB (DUT Interface Board)is needed,which costs up to 10k~20k US dollars.Besides it takes 1-2 months of time to fabricate the DIB.
During design verification phase,debug the silicon is done via host interfaces using“protocols”,to validate if the silicon is functional working.This kind of protocol transaction based test is system-like test.To perform a system like test on ATE,it must be able to support protocol based transaction,and it must be able to emulate and track device behavior(sometimes non-deterministic).Before it's very hard and indirect to deal with protocol transaction based test on ATE.Traditionally,ATE drives test patterns to DUT,and capture DUT response.Those test patterns are plain vectors generated by design simulation.If users want ATE to change a register value via host interface to DUT,the process is quite complex.This increases the difficulty of test program development and debug.Below figure 2 will show you the complexity(2).
Figure2 Typical debug scenario with plain pattern on ATE
Figure3 V93000 protocol based DUT access
Now V93000 has a new feature-Protocol Aware ATE.It simplifies protocol transaction based test program development on ATE.It enables such capabilities so that devices can be validated early in the design verification process,and to use such system-like tests to ensure device quality under real application conditions.
With this new protocol aware feature,we design a solution to enable system-like test on ATE in early design verification phase.The test program development and debug on ATE is greatly simplified by applying protocol aware feature.The solution is cost effective,no dedicated DIB is needed.Users can re-use the evaluation board,which they use with bench test.Meanwhile users can benefit ATE's strength in data analysis and automatic test,etc.
The solution includes both hardware and software.For hardware part,a generic ATE load board plus an evaluation board are all the users needed;For software part,protocol aware feature will be applied to simplify the test program development and debug.Figure 4 shows you the solution.
Figure4 System-like ATE test solution for design verification
Other benefits of this solution are:
●Engineers can validate different test methodology before implementing on production load board
●Minimize final production DIB design and fabrication risk with validation on EVB level
●Be feasible to fulfill demand for a few K's samples testing with handler
●ATE test program is setup in early phase,short en the ATE production program development cycle
We have successfully applied this solution on real devices.Let's use a real case RF transceiver device to demonstrate this solution in more details.The device uses SPI protocol.The device is on evaluation board,this evaluation board is then connected via host interface to the ATE generic load board.ATE communicates with device via protocol transactions,e.g,write registers,read registers.The basic process is:
●ATE sends out write/read register command to DUT,via protocol transaction,to set DUT in correct state
●Real test measurement is then proceeded
●After measurement,ATE will capture DUT output,calculate result
The ATE test program is created within several hours,with protocol aware feature.We get correct result from DUT within several days.This is amazing to users.This solution can be released to mass production with minor changes and limited engineering efforts.
Figure5 Real case example
This solution applies to below scenarios:
●Device characterization in design verification
●Early production ramp up
●Correlation between ATE&bench
In summary,by enabling system-like test on ATE in design verification,test coverage is improved,cost is down,and time to market is better met.
Thanks fo r contribution of Kelvin,Xia,and Liang Ge to this solution.
[1]Derek Floyd,V93000 ProtocolAware solution introduction,Verigy,(2009)[z].
[2]JoachimWinkle,MichaelMinnerop,Protocol AwareATE Transaction Based DUT Access,Verigy VOICE meeting paper,(2011)[z].
[3]Protocol Aware,SmarTest Technical Document[EB/OL].http://www1.verigy.com/help/index.jsp,2012-02-15.