Performance improvement in pattern validation by MAX testbench
Kang ZhangKang.zhang@st.com
ST Microelectronics
意法半导体
Abstract
With the increase in design scale and the adoption of deep submicron technology, chip’s DFT design is becoming more and more challenging. Especially in the areas of pattern’s count, data volume and test timing to achieve higher test coverage. Thus, pattern’s validation has grown to be a time consuming and resources intensive event, comparable to traditional test patterns generation. By adopting the new technology, Max test-bench, helps accelerate the pattern validation procedure.
This article illustrates the principle, realization method and experimental project proof to conclude that validation performance can be improved by using Max test-bench.
1. Introduction
In ATPG design, test patterns are assumed to be correct and error free. All failures emerged during ATE testing are deemed to be manufacturing defeats. As the number of test patterns grows, it becomes a must within the DFT flow to validate the correctness of all patterns to ensure we are catching the real chip defeats rather than flawed pattern failures.
2. Pattern simulation
Successful patterns validation in simulation environment implies the following:
• Guaranteed library consistency between ATPG and simulation environment
Only when the library pair has the same behavior description that pattern simulation can pass.
• Tools’ or algorithm’s is bug free
Generated patterns are correct in terms of logic matching with the DUT’s netlist. Input vector produces expected output response through DUT’s netlist’s logic comparing with patterns files measured value.
• Incomplete DFT information provided for TetraMax fix
Patterns are generated to fulfill their tasks without going beyond limitations. Patterns are generated in the location which is necessary while all the unsuitable locations for ATPG has been avoided.
For example, extreme timing critical path, false path, inter- clock path under at-speed test needed to be provided. Clock, design structure and timing exception information related to pattern generation should be taken into consideration completely and precisely in the ATPG tools.
• SPF file content confirmation
Pin constrains, WFT waveform, test controlling signals can be erroneous due to manual intervention which can cause simulation failures.
Minimal classical checking procedure is suggested, such as when test_mode should be asserted, scan_en signal should be assigned to various state in different procedure. RAMs can be bypassed or replaced by behavior model, OCC setting correct for various test purpose. Test_setup procedure need to initialize all parameters correctly.
• DRC violation clean
All DFT DRC rules are respected, violations are fixed as much as possible. DRC introduced failures are eliminated.
• Simulation parameters configuration are accurate
Measuring strategy can be adjusted manually under specific design requirements. Certain output expected response can be masked out to cater for the design’s characteristics. Simulation script can guide the procedure to take control and configure internal signals accordingly.
Only if all the above factors are satisfied which pattern simulation can be completed successfully. As a result, we can conclude the generated patterns are error free.
3. Challenges in pattern simulation
The key challenges exist in the pattern simulation domain lies in the amount of time consumed and memory cost due to the large pattern data volume for high test coverage. With the increasing scale and complexity of design, test pattern count has increased significantly cover the past couple of years.
4. Different Realization of pattern simulation
In pattern simulation, similar to traditional logic simulation method, the design netlist and testbench file in which the top level of design is instantiated and stimulus are provided. Both of them are read by simulation tools, take VCS as an example, and then design is compiled, linked and run. Object files in form of *.o are generated first in VCS environment, then all the *.o are linked to produce the simv executable file. The incremental compilation only recompiles the module files modified since last compilation to update relative *.o and then re-link them to update simv. In pattern simulation, however, there exists two distinct work flow approaches which are STILDPV and MAX test-bench represent the stimulus’ source and its format.
Verilog DPV employs a PLI to directly verify ATE-ready STIL pattern which simulates with all the same data on ATE test. Furthermore, by virtue of its nature independency of its stimulus file, if STIL file alone is modified, no extra compilation and linked are required, simply rerun the simv, all the modifications can be handled by DPV PLI which is transparent to users.
The structure diagram is as follows,

Figure 1: STILDPV Work Flow
The key advantage of Verilog DPV can be summarized that due to no intermediate data format translation required, no disk space are impacted and hence memory and timing are both saved. In addition, one pattern file can supply use by two sources simultaneously, simulation validation and ATE test. Last, ease of use is realized since no manual work involved in the STIL format translation.
Verilog DPV actually plays the roles of an interface program in translating from STIL format data to actual stimulus which can be recognized by simulation tools.
In contrast, the MAX test-bench solution converts STIL pattern into verilog format simulation data file as stimulus as well as generating a verilog testbench file. Eventually, the verilog testbench feed test stimulus into DUT and checks the response.
Due to the absence of Verilog PLI , the faster simulation time can be achieved, lower memory storage can be saved and easier simulation debug can be expected. Below is the work flow of MAX test-bench

Figure 2: Work Flow of MAX testbench
All the files and their interaction involved in the MAX test-bench test are listed below.

Figure 3: Files Involved in MAX testbench test
Command related to MAX test-bench application.
• Application:
Stil2verilog
• Usual options:

5. Experimental result
Performance comparison between VerilogDPV and MAX test-bench

Experimental result analysis
• Option -nohsopt not recommended as it disable some VCS optimization
o MAXTB mostly impacted in performance
• Without -nohsopt option both STILDPV and MAXTX simulation are faster
• Simulation with MAXTB verilog test-bench is 30% faster than STILDPV verilog test-bench
• Synopsys available to fix bug which induced designer to adopt the -nohsopt option to validate GARUDA design
6. Overall conclusion
Through the validation of test, the following are the key benefits of MaxTestBench:
1: Runtime Reduction
Due to the absence of VerilogPLI, faster simulation time can be achieved. MAXTAB test-bench achieved an average 30% runtime saving comparing to STILDPV test-bench in pattern simulation.
2: Lower Memory Usage
Without the intermediate format generated by VerilogDPV stored in RAM, the memory consumed can be saved.
3: Debugging Convenience
By virtue of the stimulus maintained in Verilog format, debugging will be easier and straightforward.
4: Flexibility and Consistency in simulation
MaxTestBench supports multiple waveform tables, one pattern file feeds two end goals (Simulation and ATE) which are deemed as main advantage for VerilogDPV.
5: Multiple options in simulation tool selection Support for multiple simulation tools as VCS, NC, Verilog-XL which endowed free options for user. Based on the precedent benefits, MaxTestBnech is the recommended methodology for simulating huge pattern volume.



