Snapback avoidance design flow for a memory technology Wesley H Kwong Owen W Jungroth Magnolia M Maestre Sean P McDermott Karthik Srikanta Murthy Intel NVM Solutions Group (TMG-NSG) Hello, my name is Wesley Kwong, and today, I’d like to talk about a snapback checking flow that the NSG CAD team has developed. I’d like to thank my colleagues who helped contribute to this work – Owen, Maggie, Sean, and Karthik, who all were important in the development of this flow. As part of our circuit design activities on a very particular technology, the potential for triggering snapback became a major issue that the design and CAD teams took on for the first silicon tape-in on this technology. So let’s get into the presentation.

Overview The snapback problem and what is different for NVM Solutions. Flow overview and details. Results, conclusions, and future work. Here’s the outline of today’s presentation. First, I’ll briefly describe at a high level what snapback is and why a unique solution had to be created here for NSG’s design. Then I’ll discuss an overview of the flow and some of the details about the rule determination and how the different portions tie together. Finally, I’ll discuss results, conclusions, and future work we see here.

Snapback problem Five regions of device operation: Cutoff, linear, saturation. Add snapback and failure. High bias conditions on drain and gate nodes initiate problem. Feedback loop  power dissipation  SNAPBACK So this a very brief description of snapback. The snapback region of operation is the region beyond saturation where impact ionisation generates holes flowing to ground due to high bias conditions on the drain and gate. The holes may flow either through a pwell into a ptap, or through the substrate itself. In any case, this lowers the source / body barrier, which is effectively forward biasing the parasitic bipolar device that exists between the two, such that a positive feedback loop occurs, which leads to a sudden power dissipation and catastrophic failure of the transistor.

What is different here? Snapback region is always considered for design of robust ESD protection circuits. Mitigation strategies well established. Memory technology requires high bias conditions on supporting transistors. Entire analog portions possibly impacted. Need automated approach to check for snapback. Up to this point, all approaches are manual. The snapback region is well known for ESD circuits, where the methodology for avoidance is long established. ESD circuits, are primarily found at the I/O portions of a design, with a standardised layout and processing steps (channel implants) to ensure ESD protection. In this memory technology, transistors strewn throughout the entire analog section requires very high bias conditions on the drain and gate for the technology to function correctly. The NSG CAD team has developed a methodology and supporting flows to allow for robust and automated checking of mask layout, once circuit simulations and design reviews that take snapback into account are completed. To our knowledge, aside from manual human reviews, there is no flow currently to automatically and robustly check for such a critical layout issue on the basis of direct circuit simulation results.

Overall flow The flow to check for snapback can be broken into four steps. First, snapback avoidance rules must be first generated and then implemented as associated design collateral for circuit simulation, mask layout, and physical verification. Then, the designer must then run the simulation with the avoidance rules, which allows the designer to determine the risk level for his transistors. The designer can then either redesign the most heavily impacted portions, or annotate his schematic transistors with the appropriate risk levels. The risk level is then used to generate annotated netlists, recognition layers, and trigger the appropriate layout checking rules in DRC and LVS.

Snapback rule generation Over bias ranges, simulations done to compute Isub. Impact ionization current and transient induced capacitive currents Several simulations are run for each circuit and the maximum current level is used to set the risk level. Current density is then computed: Isub divided by device width. Worst case IR drop is dependent on tap spacing. A simple worst case model assumes all of the current flows in a straight line from the transistor to the tap without spreading. The worst case assumes that all transistors in that path are producing their maximum substrate current at the same time. IR drop added to get effective resistance. For a NMOS devices in a non-epi wafer or for any device in its own well, the substrate current must flow to substrate tap. If the resulting IR drop is too large, snapback may occur. Calculating the IR drop for a general layout with many devices switching is difficult. The current may spread out and flow in many directions. Here we assume the worse case condition where all of the current flows in one direction and that all of the devices in that path are switching at the same time. 2D and 3D models were made of these worse case conditions to find the maximum distance between a transistor and its substrate tap. Circuits are simulated either by themselves or as part of larger full chip hierarchies, with the SOA / assert checks included in the simulation netlist. It is important that all transistors switch at some point. The amount of impact ionization current is set by the values of VGS and VDS during the switching events and can be reduced by cascoding the devices. The ramp rate of the nodes will affect the amount of capacitive currents seen.

Rule level determination Resistance is categorized into snapback risk levels (SNPR) SNPR = 3 is for the maximum substrate current density and requires a substrate tap next to the transistor. SNPR = 2 is for medium risk substrate current densities and allows a ~3X greater spacing to the tap. SNPR = 1 is for low substrate current densities and allows a ~7X greater spacing to the tap. Rules are generated from the above categories. SOA / assert rules for circuit simulator. SOA / assert compares the current density to the allowed value. DRC and LVS rules for physical verification tool. LVS checks the that every device gate has the correct SNPR ID layer DRC checks the spacing from SNPR ID layer to substrate tap The choice of three snap back levels is arbitrary, but seemed to work well in practice. The highest risk level requires taps adjacent to the transistors, in order to ensure a low enough resistance path to substrate. Lowest risk level uses a standard CMOS tap density. A new variable called snpr is generated, with an snpr value corresponding to each risk level. Several things are then produced: SOA / assert rules for inclusion in the circuit simulation, with a corresponding rule for each snpr value. Modifications to pcells to automatically generate the appropriate snpr recognition layer. DRC rules to check for tap spacing on the basis of a recognition layer that corresponds to each snpr value. A mixture of risk levels of different devices is also handled properly. LVS rules to ensure the correct snpr recognition layer is used. The snpr variable is also incorporated as an instance parameter for each transistor device on the schematic, which is used to generate the snpr recognition layer in layout, and also netlisted out for LVS purposes.

Example rule implementations SOA / assert rules DRC rules .setsoa label="SOA: NHV ISUB > SNPR=1 Maximum" + M NHV IB(*.B)/(D(*,M)*D(*,W)*0.05)=(-ISNPR1,*) .setsoa label="SOA: NHV ISUB > SNPR=2 Maximum" + M NHV IB(*.B)/(D(*,M)*D(*,W)*0.05)=(-ISNPR2,*) .setsoa label="SOA: NHV ISUB > SNPR=3 Maximum" + M NHV IB(*.B)/(D(*,M)*D(*,W)*0.05)=(-ISNPR3*((0.6+ABS(VS(*)-VB(*)))/0.6),*) snpr3_1tw { @ "snpr3_1tw: If triple nwell device SNPR=3, gate to tap spacing < X" FLATTEN (gate_s3_ntw NOT ptap_pwell_os45) } So on the left hand side is an example of the SOA / assert rules being used in the circuit simulator, which is basically taken as a function of the substrate current over the drain width multiplied by multiplicity and a scale factor. ISNPR? variables represents the legal current values being used. On the right hand side, one can see an example DRC rule implementation. At this stage, derived layers would be checked, after boolean operations with the appropriate snpr recognition layers. So it’s time to discuss how these would be tied together, by walking through the flow itself.

Simulation and schematic annotation Simulation with SOA / assert Include circuit SOA / assert rules. Review violation report Also dump into Excel snpr levels reported. Annotate schematic snpr property The designer then uses the SOA / assert snapback rules as an include file in his netlist and runs the circuit simulator. This then produces a report of known violations that the designer must then review. While it’s possible to automate the result annotation back onto the schematics, at this stage a designer may wish to revise his or her circuit topology to reduce the snapback risk, so if the designer wishes to do that, s/he runs the simulator again and then reviews the results again. Once the designer is satisfied with both the topology and simulation results, s/he will then annotate the impacted transistor instances in the schematic database by changing the snpr property value from 1 to whatever risk level is needed (or leave it at 1 if the risk is none or very small). The schematic database is then saved with the updated property values, which is used in the next step.

Layout and physical verification Mask layout with snpr layer MMLOWVT1 net057 sdin2 sdinb vcc phvlvt m=2 W=75.00u L=12.0u SNPR=2 MMLOWVT0 net056 sdinb sdin2 vcc phvlvt m=2 W=75.00u L=12.0u SNPR=2 DRC and LVS check In layout, the pcells use the snpr value from the device instances in the schematic database to generate an appropriate recognition layer around the device layout. This layer is then used to trigger the appropriate DRC rule for checking the appropriate tap spacings for the drawn devices. The problem is how does one know that the tap spacing rules are indeed being followed, and someone surreptitiously changed the recognition layer in order to meet other rules and time schedules? To ensure compliance, the snpr value is also printed out for each device instance in the source netlist used for LVS checks, and LVS checks to ensure that the snpr value on the netlisted device instance is consistent with the corresponding drawn device in layout. If LVS fails due to the wrong recognition layer being used, DRC was likely run for the wrong recognition layer, and hence the results would be invalid. The recognition layer is never used in tape-in for mask generation, and is only used by DRC and LVS for snapback checking. Netlist with snpr value Snapback risk parameter generates recognition layer in pcell. CDL netlist uses snpr property to be recognised by LVS. Tap compliance is checked in DRC, recognition layer correctness checked in LVS.

Results and conclusions To this point, NO known methodology to check automatically across layout. Also important as this ties circuit simulation results to layout. Previous reliability history for this technology and predecessors: Chip 1 (2006): Complete failure of chip at high bias voltages. Failure mechanism ultimately concluded as snapback. Chip 2 (2010): No failures, but nearly three weeks of manual checking by each team member for snapback violations. Chip 3 (2012): No failures so far found in design validation, first use of this flow. Minimal impact to tape-in schedule. Flow is deployed for future projects on this technology. As mentioned earlier, up to this point, the team is unaware of any flow currently to check for snapback automatically across layout. A manual layout review would have easily added an extra month of work to an already compressed schedule, and it does not take into account the impact to layout that could result from feedback occurring after layout completion, nor the human errors that could have resulted by tired engineers reviewing the layout. So far, no snapback violations have been discovered, with no layout reviews required.

Future work Work with vendors to expand SOA / assert capabilities in circuit simulators. Improve SOA / assert reporting flows for easier perusal by designers. For future work, the team discovered that not all the circuit simulators support SOA / assert in the way that was required – for example, one common simulator only checks for absolute voltage on transistor nodes without respect to time above that value, or the voltage value on other transistor nodes. This is obviously critical for determining snapback likelihood. It is probably possible to write Verilog-A and programmatically insert such instances into designs, but at many AMS summits I’ve been to, consensus is that Verilog-A knowledge is at a premium in design teams. It would have added also additional automation complexity to auto insert Verilog-A instances and would probably slow down the simulator further. So I’d like to see better support for more flexible SOA / assert mechanisms in the simulators. In addition, internally, we are working on improving the SOA / assert reporting flows to be easier to handle. We can already transform the simulator results to be reviewed in a spreadsheet. We are likely to look at automating the annotation of the risk values into the database at some point in the future, if the designer does not need to make any further topology changes.

Q&A