Verification for test Andy White, Nujira ltd
Outline Introduction to Nujira Our design flow How DfT and VfT fits into our flow Device verification metrics Analogue verification coverage
Nujira Company overview Fabless IC vendor, founded in 2002 Refocused from infrastructure to handsets in 2009 35 employees, $100M of equity funding to date European cleantech and technology VCs Envelope Tracking IC s are company s focus Improves battery life & signal quality Cuts heat dissipation Applicable to 3G, 4G/LTE and 802.11ac/WiFi 250+ patents granted & pending Most extensive ET patent portfolio in the industry Headquartered in Cambridge, UK Sales in US, Germany, Korea & China
What do we do? An overview of Envelope Tracking Conventional PA DC/DC Converter Fixed Supply Voltage Dissipated as Heat Baseband / RF up converter Power Amplifier Transmitted Envelope signal ET Power Supply chip Supply Voltage Dissipated as Heat Baseband / RF Up converter Power Amplifier Envelope Tracking PA Transmitted
How we used to do DfT Do the design Write test spec document Maybe run some sims Maybe add expected results to test spec Hand it over to test team for implementation Paperwork-intensive Our experience is that this approach ends up with designers at the bench making tests up Wastes valuable designers time Might not have all the hooks needed to perform a particular test
How we try to do it now Minimise extra paperwork Aim for executable specification approach Shift production test focus to the earliest possble point in the design cycle We re not claiming this is a unique approach but we think it s the best way for us
Verification for Test So we try to consider production test and bench debug as important as mission mode It s the one mode you can guarantee will be used for each chip We ensure test access is designed into each block early in the flow Verification of the design from a test perspective gives us confidence that the design will be properly tested and ensures we know what results to expect
Design flow Digital control block Analogue circuitry Hard-wired voltage sources pwl sources to sequence enables etc va module reads text file with reg updates Digital verilog implementation simple register writes Full digital rtl Simple behavioural views va implementation (ideal) va implementation (executable spec) Transistor-level schematics Extracted
Simplified Digital block example Verilog file drives simulation block1_ena = 1; writemipi;... //% Enable block1 //% Update registers mode[1:0] = 1; //% Select mode 1 bias[4:0] = 3; //% This is the bias_1 value determined in earlier test comp_1[4:0] = 16; //% This is the expected value of comp_1 ftrim_1[3:0] = 3; //% This is the ftrim value determined in earlier test block2_bias[4:0] = 20; //% This is the expected value of block2_bias writemipi; //% Update registers #10000; //% Wait 10us before taking measurements Run digital sim and generate analogue voltage sources based on sim output to stimulate analogue blocks Replace digital block with these sources so we have a fully analogue flow once the initial step s done Saves licences during design iteration phase Swap in RTL or gate level digital block later in the flow
Production test Digital control file Circuit control Analogue circuitry TB control Top level TB sources, loads etc Production tester schematics postprocess Ocean postprocess Expected results, limits
Production test control files block1_ena = 1; writemipi;... //% Enable block1 //% Update registers mode[1:0] = 1; //% Select mode 1 bias[4:0] = 3; //% This is the bias_1 value determined in earlier test comp_1[4:0] = 16; //% This is the expected value of comp_1 ftrim_1[3:0] = 3; //% This is the ftrim value determined in earlier test block2_bias[4:0] = 20; //% This is the expected value of block2_bias writemipi; //% Update registers #10000; //% Wait 10us before taking measurements $fdisplay(oceanfilehd,"t5 = getcrossingtime(mod_out) %t %t 1.55 rising",$realtime,$realtime+1000); //% time when rising edge crosses 1.55V $fdisplay(oceanfilehd,"t6 = getcrossingtime(mod_out) %t %t 2.05 rising",$realtime,$realtime+1000); //% time when rising edge crosses 2.05V $fdisplay(oceanfilehd,"t_rising_mode1 = 0.5/(t6-t5)"); //% Calculate slew rate of rising edge (V/s) $fdisplay(oceanfilehd,"t_rising_mode1_vperus = t_rising_mode1/1e6"); //% Convert to V/us $fdisplay(oceanfilehd,"checklimit(t_rising_mode1_vperus min=217.8 max=378.8)"); //% Check against test limits Verilog file to drive analogue, TB and generate postprocess t5, 0.000557305 t6, 0.000557307 t_rising_mode1,301806568.427075922 t_rising_mode1_vperus,301.806568427 t_rising_mode1_vperus_min,217.800000000 t_rising_mode1_vperus_max,378.800000000 Sim results after postprocess Zip up with block diagram etc to form test spec
Verification device-level checking We have high voltages in our design, and concerns about reliability. va module + FET replaces FET across whole design (or block-byblock) Circuit is electrically identical in operation as the FETs are the same Checker module logs device currents and voltages through the simulation Per device: Or va Activity level (std. dev of node voltages) Power dissipation, Currents, expected lifetime etc
Power dissipation MCORE.ANALOGUE T OP.BUCK.OS.PSLICE 1.PDRIVER 3.M1 MCORE.ANALOGUE MCORE.ANALOGUE T OP.BUCK.OS.PSLICE OP.BUCK.OS.PSLICE 1.PDRIVER.PDRIVER 1.M1 2.M1 MCORE.ANALOGUE T OP.BUCK.OS.PSLICE 1.PDRIVER 4.M1 MCORE.ANALOGUE T OP.MODULATOR C ORE.ERR 0.5 1 1.5 Normalised Log10 scale : 64=max 10 20 30 40 50 60
Verification Can use this method to estimate accumulated damage using foundry HCI lifetime data Has proven its worth by detecting LV devices in HV circuitry overstressed at a stage where it was easy to re-design Can look for hot spots of power dissipation by logging Pdiss
Verification and test coverage We can use the checker to track verification coverage Log Vds / Vgs standard deviation per device across a set of sims If the sim worked, and the device Vds/Vgs varied by more than a min threshold, we consider the device to be covered So we can estimate area of chip that s checked in production tests Untested Area could be a good indicator of likely field failure rate by considering foundry defect density - So we can accumulate through the sim rather than postprocessing a waveform
Coverage example driver-only sim 1600 1400 1200 1000 800 600 400 200 0-0.5 0 0.5 1 1.5 2 2.5 3 3.5 Vgs std dev (Vth~=0.6V) Vgs stdev > 0.3V percentage devices whose vgs varied by more than the min level was 37.0 percentage devices whose vds varied by more than the min level was 24.6 percentage devices whose vbs varied by more than the min level was 14.6 area of chip as % of active device area whose vgs varied by more than the min level was 47.519
What would be useful to develop the methodology further Production test hardware suppliers - Behavioural views of production tester sources and measurement devices EDA tools - Parsing / compilation tools to convert verilog to testerese Foundry data - Improved reliability estimate Validation that the coverage methodology is itself valid (or not)
Copyright Nujira 2015