Verification for test. Andy White, Nujira ltd

Size: px

Start display at page:

Download "Verification for test. Andy White, Nujira ltd"

Austen Glenn
5 years ago
Views:

1 Verification for test Andy White, Nujira ltd

2 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

employees, $100M of equity funding to date European

company s focus Improves battery life & signal quality Cuts

11ac/WiFi 250+ patents granted & pending Most extensive ET

3 Nujira Company overview Fabless IC vendor, founded in 2002 Refocused from infrastructure to handsets in 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 ac/WiFi 250+ patents granted & pending Most extensive ET patent portfolio in the industry Headquartered in Cambridge, UK Sales in US, Germany, Korea & China

4 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

5 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

6 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

is designed into each block early in the flow Verification of the design from a test perspective

7 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

8 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

9 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

10 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

11 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, t6, t_rising_mode1, t_rising_mode1_vperus, t_rising_mode1_vperus_min, t_rising_mode1_vperus_max, Sim results after postprocess Zip up with block diagram etc to form test spec

12 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

PDRIVER 1.M1 2.M1 MCORE.ANALOGUE T OP.BUCK.OS.PSLICE 1.PDRIVER 4.M1 MCORE.ANALOGUE T OP.MODULATOR C ORE.

13 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 Normalised Log10 scale : 64=max

14 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

covered So we can estimate area of chip that s checked in production tests Untested Area could be a good indicator of likely

15 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.

16 Coverage example driver-only sim 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

17 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)

18 Copyright Nujira 2015

Design and Verification of High Efficiency Power Amplifier Systems

Design and Verification of High Efficiency Power Amplifier Systems Sean Lynch Platform Engineering Manager MATLAB EXPO 2013 1 What is Nujira? Nujira makes Envelope Tracking Modulators that make power amplifiers