Comprehensive PCell Verification System Using Taguchi Method MT Lau Victer Chong National Semiconductor Corporation 00-(606)-2306632 MT.Lau@nsc.com Victer.chong@nsc.com CDNLive! 2007 CONFERENCE 2007 Santa Clara, CA Session Track 5 Session# 5.3
CDNLive! 2007 CONFERENCE 2007 Santa Clara, CA Comprehensive PCell Verification System Using Taguchi Method MT Lau, Victer Chong National Semiconductor Corporation Abstract PCell verification is always a challenge for developer. A good testcase that covers comprehensively across all the pcell parameters over the operative range is always prohibitive because of the size of the testcase, runtime and hardware limitation. The noise issue in pcell development are being discussed in this paper namely the float representation error. The issue appear sporadically in a non-continuous parametric range mandate that the parameters are swept grid by grid. Millions of pcells will have to be generated that may drain computer memory, stretched to the limits of the DBU/UU and runtime. An enhanced PCell testcase generation program is developed to ensure testcase generated will not drain the computer memory and hits the DBU/UU limits set by the tools. There is not a way to measure the memory usage in the IC51 environment and a utility is developed for Linux base machine to monitor memory usage. The number of pcells generated could further be reduced by applying the Taguchi Method to ensure comprehensive parametric coverage without having to exhaustively generate all the interaction between the parameters. This method significantly reduces the number of pcells generated. A testcase of millions of pcells could easily be reduced to just over couple of 10K; a reduction of almost 90% of pcells and saving runtime from days to hours. 1. Introduction. This automation program is an enhancement over the methodology that was developed previously by Jason, Michael and VR presented in ICU2004. The objective is to generate comprehensive pcell testcase that is DRC and LVS ready. Comprehensive pcells testcases are equivalent to generating the testcases by sweeping grid by grid for length and width in the operative range allowable by the manufacturing specification. Comprehensive testcases are critical to surface out the noise that may cause the pcells to fail DRC or LVS as explained in section 2 of this paper. Not only pcells are placed systematically by sweeping parameters grid by grid, it also ensures the following constraints: a) The background tubs are generated in the layout to match the common tub. This is particularly prevalent for pcells that do not have explicit terminals such as the bulk node that were commonly shared among other devices. In some cases, the common background layer needs to be added to encompass all the pcell instances. For processes that require more complicated background treatment like SOI trench, background layer that need to cut holes for every instance must be able to be implemented. b) The schematic are placed simultaneously to save time. The ports are named systematically in incremental that match between layout and schematic. Ports or pins are placed directly on the symbol terminal and using the same layer on the layout. This will minimize the need of routing. c) The pcells placement will not exceed the maximum limit as determined by the DBU/UU and limitation imposed by the ASSURA tools. d) The physical memory are not exhausted that may cause core dump. The amount of instances generated for exhaustive comprehensive pcell testcases is very huge as shown in section 2. The Robust Design or also called Taguchi method is used to reduce the number of instances generated. Robust Design/Taguchi method is central to improving engineering productivity. This method is pioneered by Dr. Genichi Taguchi after the end of the Second
World War. Taguchi method provides a technique for designing and performing experiments to investigate processes where the output depends on many factors (variables; inputs) without having to tediously and uneconomically run the process using all possible combinations of values of those variables. By systematically choosing certain combinations of variables it is possible to separate their individual effects. (See reference 6 from Peter Wooding). Robust Design focuses on improving the fundamental function of the product or process, thus facilitating flexible designs and concurrent engineering. Indeed, it is the most powerful method available to reduce product cost, improve quality, and simultaneously reduce development interval. The above have been addressed and presented in this paper. However, ACPD flow that was incorporated in the previous automation will be left out and will be checked and verified with other method. ACPD flow is not necessary to have comprehensive testcases for verification. 2. Noises Parameter Diagram, Robust Design/Taguchi method. Float representation error is one of the noise issues that are difficult to catch. Its behavior is nonpredictable and happens sporadically in a noncontinuous manner. For example, when a float number 11.5 is subject to be round to integer, it may be rounded to 12 for one instance but for another instance it may be rounded to 11. This is due to the number 11.5 may not able to be represented exactly as 11.5 but 11.50000000000001 for the first instance and 11.4999999 for the other instance. This is just like the irrational number in the decimal system that 1/3 is not able to be represented exactly in float. We get 0.333333333333333.. For another example, 0.1 when represent as binary will be 0.00011001100110011001100110 01100110011001100110011 and to represent such a number in computer, the number of digits after the decimal point will truncated at some decimal places limited by the number of bits resolution. It is not uncommon to experience to see a pcell that is failing DRC at value 10.95u, 39.75u, 40.95u but are clean for most of the value for the parameter when sweep from 1um to 50um. It is therefore crucial to sweep the parameter grid by grid over the operative range. Such a comprehensive testcase could grow to millions of pcells to be generated especially, if the number of parameters to be exercised increases. For example, for an NMOS pcell that has 2 parameters, length and width. To generate a comprehensive testcases that length from 0.13um to 50um and width of 0.15um to 50um with full interaction between the 2 parameters for a grid size of 0.005um would produce a total of Total Instances = n length. n width n length = (50um 0.13um)/0.005um + 1 = 9975 Similarly, n width = 9971 n length. n width 99 million This is a huge testcase to be generated and not a feasible way. We use Taguchi Method to reduce the interaction of the parameters in such a way that the interaction of parameters is covered when both are in incremental and also inversely proportion. Graphically, we could illustrate as follows: length width Figure 1: showing length sweep from 0.15um to 50um in y-axis and 0.13um to 50um for width in x-axis. The shaded region is the full interaction for length and width generated. The red dots show the incremental and inversely proportion and also min/max sweep for the other parameter held at minimum. Using the same example of NMOS discussed previously, the total number of instances generated becomes: Σ n length + (n width -1) + max(n length, n width )*2 3 39892 Comparing this number of instance with exhaustive case, this is merely 0.004% of 99 millions. Appendix 1 illustrated the Parameter diagram for a Robust Design of an experiment. The same method
is use to illustrate the design of the Pcell Taguchi method. The desired output is to generate a testcases that is able to surface out instances of pcells over the operative range that may cause DRC/LVS error due to the float representation error. 3. Physical and Software Limitations. Physical limitation basically is the physical RAM installed on the computer as well as the SWAP space. When generating the testcase with millions of pcells, it could easily exhaust all the RAM and SWAP space and potentially generate a core dump. Therefore, it is crucial to monitor the memory usage while the testcase is being generated. The memory usage of the pcell instances depend on the polygons the pcell is going to generate associated with the pcell parameters. Therefore, it is difficult to estimate the memory usage by the numbers of pcells to be placed on a layout. A dynamic way to monitor the memory while the testcase is being generated is required. In Linux, the memory for both RAM and SWAP space could be monitored at /proc/meminfo. A small SKILL routine could be written to calculate the percentage of the memory usage. One point that needs to be noted is that you may need to add the cache memory as unused memory as the memory management in Linux is making use to any unused RAM for cache. An example would be illustrated in Appendix 2. It is important to note also that icfb will not release back memory to shell despite the testcase (schematic/layout) is saved and purged using skill commands. We have to restart the icfb in order to measure the memory usage properly. In order for the placing of instances to restart and continue from the last placed instances, we need to save the list of instances to be placed into a file and saved the state of the last placed instance as a plain ASCII file. The state of the instances placing are saved and communicated to the next icfb. Another limitation is the DBUperUU limit. This limit determines the maximum extend of the layout in Virtuoso. For a DBUperUU of 1000 on a system and software that support 32 bits, the maximum extends of a layout is basically determined as follows: 2 32 / 1000 200cm = +- 100cm For Assura, the limit is roughly 2 31 / 1000 20cm = +- 10cm The Pcell verifications system should not generate testcases beyond the memory and software constraints as illustrated above. The system will save and close the layout and schematic and a new testcase (layout/schematic) will be generated before the constraints of memory and DBUperUU are hit. 4. Graphical User Interface (GUI) START Prompt user for library name and PCell name The program to determine the PCell s terminal and parameter property Store setup/alias Generate layout that consists of all PCell s parameter combinations with appropriate terminal, background layer and pin configuration for DRC/LVS verification Generate schematic that consists of all PCell s parameter combinations with appropriate terminal configuration for LVS verification Post-layout skill routine END Figure 2: Flow Chart for PCell QA Automation. This program requires a number of inputs from user in two interactive GUI forms. User needs to select the targeted PCell of a primitive library in the first form as shown in Figure 3. A main program GUI as illustrated in Appendix 3 will then be prompted with the PCell s terminals and parameters property when Apply button is clicked. It is a daunting task if the user has to exercise all the parameters minimum and maximum values for every PCells in order to have better test coverage. The main program will search and display each parameter s minimum and maximum values, unless the Skip Min/Max Search button is toggled. Otherwise, skipping the search will bring you to the main program with defaulted parameter values or previously set values via saved setup/alias file(s). User may as well clear the form and activate the
Min/Max search in the main program by selecting Clear Form and reset to Min/Max Range button to restart setup with valid minimum and maximum parameter values. Figure 3: drclvspcell() startup GUI form. 5. The main program The automated QA program drclvspcell() is made intuitive and utilizes GUI that helps user to select the desired items from cyclic fields, radio and toggle buttons using mouse thus reducing typo errors. For example, the PCell s parameters property available in the user s library as Component Description Format (CDF) that could be accessed with the following command: cdf = cdfgetbasecellcdf(ddgetobj(libname PCellName) As shown in the flow chart in Figure 2, the drclvspcell() requires terminals, background layer and pins configuration in addition of the intended parameters sweep range in order to pass both DRC and LVS verifications in Taguchi coverage. The configuration can be saved and retrieved by using Save Setup and Last Saved Setup buttons respectively. User may have multiple terminal and parameter configurations limited by the PCell s callback dependency if any. These configurations will be stored as setup files (aliases) in the path specified in Setup Directory editable field. Different configurations of a particular PCell can be generated by specifying the aliases separated by semicolon(s) in Run the following alias only field. User may use other user s setup by changing the Setup Directory field accordingly. This program has few features to enhance the testcase generation performance and management for troubleshooting convenience in verification later on. There is a possibility whereby user wants to generate testcase for DRC only. User can toggle or switch off Generate Schematic feature in the main GUI. In order to generate the testcase in huge amount, the program was built with memory monitoring feature and a control over the maximum amount of instances per cell. The testcase will be generated in multiple cells, not exceeding maximum amount set in Max Instances/cell field. Toggling the Monitor Memory Usage will make sure the generation is performed under memory (RAM) utilization of not more than 80%. This is to allow the IC tool (icfb) to release the unused memory back to the system in order to measure the amount of memory used correctly in the program. Turning this off will not monitor memory and there will be no pops-up of icfb repeatedly. It is the risk of user to ensure the generated testcase will not crash the system. This program also informs user the default grid size defined for the selected design package or library. This helps user to determine the step size of parameter(s) such as the PCell s length and width. This value could be accessed with the following command: techgetmfggridresolution(techgettechfile(ddgetobj(libname)) Total number of instances is updated on the fly when the swept parameters section is updated for both Exhaustive and Taguchi sweep methods. It serves a quantitative comparison between these sweep methods. Appendix 3 for example shows that more than 643 million instances are required in order to fulfill coverage of the selected parameter combinations exhaustively. This amount can be represented using Taguchi method with only less than 48 thousand instances. The lower section of the main program as shown in Figure 4 extracts all editable parameters from the PCell s CDF by using cdf~>parameters command. The first column represents the non-editable sequence number of the selected parameter to trigger PCell s callback. The sequence number is generated automatically when a parameter is selected via a boolean button on the third column. This sequence is important as this controls the behavior of callback triggers which snap its value to default or previous valid value when it is violated based on the parameter s limitation and dependency. The second column is the parameter name and the third column is the boolean field that indicates chosen parameter to be exercised in the testcase generation. The sequence of clicking this boolean button determines the sequence number generated in the first column. The fourth column in Figure 4 specifies the data type for the parameter. Subsequent 3 columns specify the sweep information. Numeric parameter is filled with min and max values limited by available callback when Min/Max Search is activated.
Otherwise, it will be filled with hard coded predefined values. Non-numeric parameter could also be swept by entering the string delimited by semicolon. generation. The batch program is realizable by parsing the required arguments to the following procedure after the sweep information as shown in appendix 4 has been setup in previous GUI mode: Syntax: drcpcell( list( <PCell1> <PCell2> ) <libname> <setup_dir> <method> <monitor_memory> ) Figure 4: Lower section GUI of the main program This numeric parameter could be swept from higher to lower value if the step is of negative value. This is useful if there are other parameters that depend on this parameter to give enough room without violating the limit set by the callback due to some kind of parameter dependency enhancement as shown in Figure 5. The step size ( Step ) is set to grid size by default if the parameter is of lengthmetric unit. Changing step size will cause the generated number of points ( Pts ) for this parameter to be recalculated. The number of points could be changed and To value of the parameter will get recalculated. This serves flexibility in sweeping the selected parameter. Example: drcpcell( list( "NMOSHVI" "NMOSI" ) "optimos2" "~/.drcpcell" "Taguchi" t ) Batch mode basically requires five arguments. They are PCell(s) name list, library name, setup directory s path, sweeping method and lastly the trigger value for memory monitoring. The third, fourth and last argument may be priory set via the GUI mode. Batch mode allows these three arguments to be overwritten. The third argument directs the program where to look for the listed PCell s setup file that is by looking at /setup_dir/libname/pcell1 path for PCell1 and so on. Therefore, this path must contain the setup file which is the sweep information for all the listed PCell(s). Fourth argument lets user choose between Exhaustive and Taguchi method for sweeping the parameter(s). User can also turn on the monitor memory feature by simply passing a true value ( t ) as last argument, or nil to deactivate it. Figure 5: Example on parameter sweeping From higher to lower value. 6. Running in batch mode The previously described interactive GUI mode serves only one of two methods for running the program. The second method, batch mode is another flexibility provided by the program in order to enhance productivity on multiple PCells testcase Figure 6: A governing file of all PCells aliases for testcase generation in batch mode. User may have multiple parameter aliases for a particular PCell. Multiple PCells with varying configurations for every one of them can be generated in batch mode by a governing file named aliaslistfile as shown in Figure 6 above. The
PCells aliases were set priory in GUI mode delimited by semicolon(s) in Run the following alias only field (Appendix 3). User may also use other user s setup by changing the setup_dir argument accordingly with the listed PCells setup file(s) available. 7. Reports and Results Taguchi method in drclvspcell() generates PCell(s) testcase in a large scale and big test coverage. Therefore, an informative generation report is crucial in helping user measuring and managing the run time and performance for a better quality and cycle time. Figure 7 shows an example of a testcase in Taguchi method with 6 thousand cells which requires only less than 6 minutes to generate that is equivalent to 1.7 million cells when in exhaustive mode. User will be informed with the generation progress in percentage and the corresponding time taken. The Max Instances/cell that was set during setup will divide the total cell amount to a few cell names in order to ease the troubleshooting process later on. swept. The Tried value is the one that user has intended to sweep the parameter with. But the program will make sure this value is valid by triggering the PCell s callback and returning the Actual value. Each PCell s terminals will be connected with the pin that was specified earlier in the main program s terminal section. The specified background pin serves as the connectivity to substrate and N-well. User may finally do some work around to the basic layout by passing in the post layout skill file. For example, an N-well ring with a deep N-well background layer has been incorporated to the generated layout shown below (Figure 9). Figure 9: Example of the generated testcase layout. Figure 7: Information on testcase generation that is produced by the program in CIW. Figure 8: Report file that is produced by the program in text form. This program produces a report (Figure 8) telling the user what and how the parameter values being Figure 10: Example of the generated testcase schematic In the corresponding generated schematic shown in Figure 10 above, every PCell s symbol terminals will also be connected the same way as explained for the generated layout in order to pass LVS verification
successfully. Both generated schematic and layout will be appended with the swept parameters information and total generation time spent on that particular cell name. Library manager as shown in Appendix 5 illustrates all the generated cells in pcellqa library. Cell name with drc_ prefix was generated with either Generate Schematic switched off or whenever the PCell does not equipped with a symbol which obviously intended for DRC verification only. Other wise, cell name with drc_lvs_ prefix will be generated for both DRC and LVS verifications. 8. Conclusions A pcell verification system that is able to sweep parameters comprehensively is developed base on the outline in this paper. The problems that this automation surfaced out is beyond our expectation as we tends to sweep more parameters and larger combination of parameters due to its abilities to overcomes the constraints illustrated above which the old system could not overcome. The pcell verification could further enhance to include auto run of DRC and LVS after the testcase is generated in future. 9. References 1. ICU 2004 - The Methodology and Implementation of Automatic PCell & ACPD Flow QA. 2. R. Sreenivas Rao, R.S. Prakasham, K. Krishna Prasad, S. Rajesham,P.N. Sarma, L. Venkateswar Rao (2004) Xylitol production by Candida sp.: parameter optimization using Taguchi approach, Process Biochemistry 39:951-956 6. http://www.isixsigma.com/library/content/c0203 11a.asp 10. Information for abstract submissions - List of Cadence products in this paper : Cadence SKILL compiler, Analog Design Environment, Virtuoso Schematic, OCEAN. - Name & title MT Lau, CAD Engineer; Victer Chong, CAD Engineer - Company name : National Semiconductor Corporation - Address : Batu Berendam Free Trade Zone, 75350 Malacca, Malaysia. - Phone number : 00 (606)2515-632 - Fax number : 00 (606)2323-687 - Email address : MT.Lau@nsc.com; Victer.Chong@nsc.com - Speaker biography : B Sc from National University of Singapore in 1992. Joined National Semiconductor Corp (Malaysia) in Oct 1995. Currently, working in Analog Mixed-Signal CAD Group, which is part of corporate Analog Mixed-Signal Tools & Library Development Group. - Co-author biography : M Sc from National University of Malaysia in 2005. Joined National Semiconductor Corp (Malaysia) in July 2007. Currently, working in Analog Mixed-Signal CAD Group, which is part of corporate Analog Mixed-Signal Tools & Library Development Group. - Estimate time required for presentation : 30 minutes - Type of audio/visual aids required: Projector. 3. Leon, R V; Shoemaker, A C & Kacker, R N (1987) Performance measures independent of adjustment: an explanation and extension of Taguchi's signal-to-noise ratios (with discussion), Technometrics vol 29, pp253-285 4. Moen, R D; Nolan, T W & Provost, L P (1991) Improving Quality Through Planned Experimentation ISBN 0-07-042673-2 5. Nair, V N (ed.) (1992) Taguchi's parameter design: a panel discussion, Technometrics vol34, pp127-161
Appendix 1: Parameter Diagram for Taguchi Pcell Testcase: Noise Factor: Float representation errors Input factors: Sweeping all PCell parameters length, width, fingers, parallel/ series, area PCell QA Testcase Desired Output Clean/Failed PCell code. Identify noise factor compensation area. Controlled factors: PCell Coding. Compensation algorithm for rounding/float errors.
Appendix 2: An example of skill routine for measuring the memory usage: procedure( chkmemusage(@optional (monitormemory t) ) let((memfile availmem usedbyapp (usage 0.0) theline cache freemem) when(monitormemory if( isfile("/proc/meminfo") then memfile=infile("/proc/meminfo") while( gets( theline memfile ) cond( (rexmatchp("^memtotal:" theline) availmem = atoi(cadr(parsestring(theline))) ) (rexmatchp("^memfree:" theline) freemem = atoi(cadr(parsestring(theline))) ) (rexmatchp("^cached:" theline) cache = atoi(cadr(parsestring(theline))) ) ); cond ); while if( availmem && freemem && cache then usage = 100.0*(availMem-freeMem-cache)/availMem ;printf( "Avail=%d \tfree=%d \tcache=%d\n" availmem freemem cache) else usage = 0.0 ); if else printf("** memusage file not found!\n") ); if ); when usage ); let );
Appendix 3: Graphical User Interface of the Main Program drclvspcell().
Appendix 4: Setup file for a PCell that is done via main program GUI and stored in /setup_dir/libname.
Appendix 5: Library manager GUI showing the PCells testcase being generated in pcellqa library.