Methods for checking the integrity of device parameters in LVS files

Abstract

This invention discloses a method for checking the integrity of device parameters in an LVS file, comprising: Step 1, extracting device parameter definition data from the LVS file and storing it in a first register; Step 2, reading the data of the parameterized unit and extracting the simulation parameters of each device in the simulation tool, and storing the simulation parameters of each device in a second register; Step 3, cross-comparing the device parameter definition data in the first register with the simulation parameters of each device in the second register to determine the integrity of the device parameters defined in the LVS file. This invention eliminates the need for manual visual inspection and post-simulation result-based checks, enabling rapid and thorough inspection, and is well-suited for rapid process iteration.

Description

Technical Field

[0001] This invention relates to a method for manufacturing semiconductor integrated circuits, and more particularly to a method for inspecting layout and circuit principles. Figure 1 Methods for verifying the integrity of device parameters in layout versus schematics (LVS) files. Background Art

[0002] LVS (Limited View Validation) is an essential part of the circuit design process, quickly helping designers check the fit between the circuit and the layout. Generally, LVS verification files provided by foundries, in addition to checking circuit and layout consistency, typically calculate additional device parameters needed for device model simulation in the later simulation process. These parameters include transistor source / drain junction area (S / D Area) / perimeter (Pj), STI (Length of Diffusion, LOD) effect, and well proximity effect (WPE). These parameters cannot be directly checked by comparing with the circuit; they generally require manual visual inspection or verification based on later simulation results. A single LVS verification file typically defines nearly a hundred device types, each with dozens of parameters. Traditional checking methods are prone to omissions and cannot adapt to rapid process iterations. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a method for checking the integrity of device parameters in LVS files. This method does not require manual visual inspection or inspection based on subsequent simulation results, and can achieve rapid and complete inspection, which can adapt well to the rapid iteration of the process.

[0004] To solve the above-mentioned technical problems, the method for checking the integrity of device parameters in LVS files provided by the present invention includes the following steps:

[0005] Step 1: Extract the device parameter definition data from the LVS file and store the device parameter definition data into the first register.

[0006] Step 2: Read the data from the parameterization unit (Pcell), extract the simulation parameters of each device in the simulation tool from the data of the parameterization unit, and store the simulation parameters of each device into the second register, so that the second register includes the simulation parameters of all devices.

[0007] Step 3: Cross-compare the device parameter definition data in the first register with the simulation parameters of each device in the second register to determine the completeness of the device parameters defined in the LVS file.

[0008] A further improvement is that, in step one, the device parameter definition data includes: device name, device parameter name, and its location in the LVS file.

[0009] A further improvement is that step one also includes a step of compressing the device parameter definition data stored in the first register, in order to merge multiple device parameter definition data based on different structure definitions for the same device.

[0010] A further improvement is that the compression process includes:

[0011] Multiple device parameter definition data with the same device name and device parameter name are merged into one device parameter definition data.

[0012] Multiple device parameter definition data with the same device name but different device parameter names are merged into the device parameter definition data corresponding to the device parameter name with the largest number of parameters.

[0013] A further improvement is that, in step one, after the compression process is completed, the following steps are included:

[0014] The location of the discarded device parameter definition data in the LVS file when issuing an alarm prompt.

[0015] A further improvement is that, in step one, the device parameters in the device parameter definition data are used in the back-end simulation process.

[0016] A further improvement is that, in step two, the parameterization unit outputs the front-end circuit simulation netlist through the simulation tool.

[0017] A further improvement is that, in step two, the simulation tools include a variety of types, and the simulation parameters of each device in the second register are integrated to merge the simulation parameters of the same device in different simulation tools.

[0018] A further improvement is that the types of simulation tools include: spectre_view, hspice_view, and cdl_view.

[0019] A further improvement is that, in step three, after the cross-comparison is completed, a comparison report is output;

[0020] The comparison report includes: whether the device types are consistent, whether the device parameters are consistent, and the line number of the calibrated error area in the LVS file.

[0021] This invention utilizes data from parameterized units capable of front-end circuit simulation to extract simulation parameters for each device in the simulation tool. These parameters are then cross-referenced with the device parameter definition data in the LVS file. Since the simulation tool includes all the simulation parameters required by the device model, this cross-reference can ensure the completeness of the device parameters defined in the LVS file. Therefore, this invention eliminates the need for manual visual inspection and post-simulation result-based checks, enabling rapid and comprehensive inspection and adapting well to rapid process iterations. Attached Figure Description

[0022] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments:

[0023] Figure 1 This is a flowchart of a method for checking the integrity of device parameters in an LVS file according to an embodiment of the present invention;

[0024] Figure 2 This is a detailed flowchart of a preferred embodiment of the method for checking the integrity of device parameters in an LVS file according to the present invention;

[0025] Figure 3A The device parameter definition data stored in the first memory in the method for checking the integrity of device parameters in an LVS file according to a preferred embodiment of the present invention;

[0026] Figure 3B This refers to the device parameter definition data stored in the second memory in the method for checking the integrity of device parameters in an LVS file according to a preferred embodiment of the present invention. Detailed Implementation

[0027] like Figure 1 The diagram shown is a flowchart of a method for checking the integrity of device parameters in an LVS file according to an embodiment of the present invention; for detailed procedures in a preferred embodiment of the present invention, please refer to [link / reference needed]. Figure 2 As shown; Figure 3A The image shows the device parameter definition data stored in the first memory in the method for checking the integrity of device parameters in an LVS file according to a preferred embodiment of the present invention; as shown... Figure 3B The image shows the device parameter definition data stored in the second memory in the method for checking the integrity of device parameters in an LVS file according to a preferred embodiment of the present invention. The method for checking the integrity of device parameters in an LVS file according to the present invention includes the following steps:

[0028] Step 1: Extract the device parameter definition data from the LVS file and store the device parameter definition data into the first register 101.

[0029] In this embodiment of the invention, the device parameter definition data includes: device name, device parameter name, and location in the LVS file.

[0030] It also includes a step of compressing the device parameter definition data stored in the first register 101, so as to merge multiple device parameter definition data based on different structure definitions of the same device.

[0031] The compression process includes:

[0032] Multiple device parameter definition data with the same device name and device parameter name are merged into one device parameter definition data.

[0033] Multiple device parameter definition data with the same device name but different device parameter names are merged into the device parameter definition data corresponding to the device parameter name with the largest number of parameters.

[0034] After the compression process is completed, it includes:

[0035] The location of the discarded device parameter definition data in the LVS file when issuing an alarm prompt.

[0036] The device parameters in the device parameter definition data are used in the backend simulation process.

[0037] In some preferred embodiments Figure 2 In the detailed flowchart, step one corresponds to Figure 2 Steps S001 and S002 are as follows:

[0038] S001. Extract the device parameter definitions from the LVS file and store them in register A (including: device name, device parameter name, and location in the LVS file). Register A is the first register 101.

[0039] like Figure 3A As shown, Figure 3A The data stored in the first register 101 before and after data compression is also displayed. The data extracted in step S001 corresponds to... Figure 3A The data stored in the first register 101 before data compression only represents the definition data of 6 device parameters. It can be seen that:

[0040] Taking the data “nch wl ad as pd ps sa sb sd sca scb scc line_250” as an example, “nch” represents the device name, such as representing an N-channel device; “wl ad as pd ps sa sb sd sca scb scc” are all device parameter names; and “line_250” is the position, i.e., the line number, in the LVS file.

[0041] S002. Since the same device may be defined multiple times based on different structures in LVS, the data in register A is compressed as follows:

[0042] (1) Combine several devices of the same type and with the same parameters into one device.

[0043] (2) For several devices of the same type but with different parameters, the device definition with the largest number of parameters is selected by default, and the device with fewer parameters is discarded. The specific location of the alarm message is displayed in the file for later evaluation and correction.

[0044] Step S002 corresponds to the compression process described in step one above. From Figure 3A As shown, before compression, positions “line_250” and “line_370” are both devices of the same type and have the same parameters. Therefore, they are merged. After merging, the first register 101 below retains only the device parameter definition data corresponding to “line_250”, and uses the description “Merge:line_370” to provide a prompt alarm, indicating that the data of “line_370” has been merged.

[0045] Similarly, before compression, positions "line_280" and "line_410" are both devices of the same type but with different parameters. "line_280" has more parameters, so the two are merged into the data of "line_280". The data of "line_410" is discarded, and an alarm is triggered with the description "Error:line_410" to indicate that the data parameters of "line_410" have problems and have been merged.

[0046] Step 2: Read the data from the parameterization unit (Pcell), extract the simulation parameters of each device in the simulation tool from the data of the parameterization unit, and store the simulation parameters of each device into the second register 102, so that the second register 102 includes the simulation parameters of all devices.

[0047] In this embodiment of the invention, the parameterization unit outputs the front-end circuit simulation netlist through the simulation tool.

[0048] The simulation tools include various types, and also include the integration processing of the simulation parameters of each device in the second register 102, so as to merge the simulation parameters of the same device in different simulation tools.

[0049] The types of simulation tools include: spectre_view, hspice_view, and cdl_view.

[0050] In some preferred embodiments Figure 2 In the detailed flowchart, step two corresponds to Figure 2 Steps S003 and S004 are as follows:

[0051] S003. Read the Pcell data, extract the parameters from the simulation view of each device, and store them in register B. Register B is the second register 102.

[0052] like Figure 3B As shown, Figure 3B Simultaneously, it displays the data stored in the second register 102 before and after the integration process, i.e., data merging. The data extracted in step S003 corresponds to... Figure 3B The data stored in the second register 102 before data merging is only representatively shown for the six simulation parameters. It can be seen that:

[0053] Taking the data “nch wl ad as pd ps sa sb sd sca scb scc spectre_view” as an example, “nch” represents the device name, such as representing an N-channel device; “wl ad as pd ps sa sb sd sca scb scc” are all device parameter names; and “spectre_view” is the simulation tool type.

[0054] S004. Since different simulation tools may have different simulation parameters, it is necessary to further integrate the parameters in various simulation views and merge the data in register B according to the device type.

[0055] The merging process in step S004 is the integration process described above. From Figure 3B As shown, before the integration process, there are three simulation parameters with the device name "nch", which correspond to different simulation tools: "spectre_view", "hspice_view" and "cdl_view". Since the devices corresponding to these three simulation parameters are the same, they are integrated into one.

[0056] Similarly, the simulation parameters of the three devices named "nch" are also integrated into one.

[0057] Step 3: Cross-compare the device parameter definition data in the first register 101 with the simulation parameters of each device in the second register 102 to determine the completeness of the device parameters defined in the LVS file.

[0058] In this embodiment of the invention, an alignment report is output after the cross-alignment is completed;

[0059] The comparison report includes: whether the device types are consistent, whether the device parameters are consistent, and the line number of the calibrated error area in the LVS file.

[0060] In some preferred embodiments Figure 2 In the detailed flowchart, step three corresponds to Figure 2 Step S005 in the process is:

[0061] S005: Cross-compare the data in registers A and B by device type. Output a comparison report, including whether the device types and parameters are consistent, and indicate the line number of the erroneous area in the LVS file for subsequent correction.

[0062] right Figure 3A and Figure 3B By comparing the data below, we can see that Figure 3A The device parameters of the device named "nch" in the middle and Figure 3B The device parameters of the device named "nch" are the same, so the device parameters of the device named "nch" are checked and the result is correct; similarly, the device parameters of the device named "pch" are checked and the result is correct.

[0063] Similarly, when the LVS file contains hundreds to thousands of device parameters, the method of this embodiment can perform a fast and complete check of the device parameters in the LVS file.

[0064] This invention utilizes data from parameterized units capable of front-end circuit simulation to extract simulation parameters for each device in the simulation tool. These parameters are then cross-referenced with the device parameter definition data in the LVS file. Since the simulation tool includes all the simulation parameters required by the device model, this cross-reference can ensure the completeness of the device parameters defined in the LVS file. Therefore, this invention eliminates the need for manual visual inspection and post-simulation result checks, enabling rapid and thorough inspection and adapting well to rapid process iterations.

[0065] A parameterized cell (Pcell) is a variable parameterized cell drawn according to the minimum design rule. In addition to providing various combinations of device structures, it is also responsible for outputting the netlist for front-end circuit simulation. Its simulation view contains all the simulation parameters required by the device model.

[0066] As can be seen from the above, based on the characteristic that the parameterized unit has complete simulation device parameters, the embodiments of the present invention provide a method for checking the integrity of device parameters in LVS files: extracting and processing the device parameter definitions, their locations, and the parameter definitions in various simulation views of Pcells in the LVS file, and then performing cross-comparison, thereby ensuring the integrity of device parameters in the LVS file, which can greatly accelerate the development speed of LVS verification files.

[0067] The present invention has been described in detail above through specific embodiments, but these are not intended to limit the invention. Many modifications and improvements can be made by those skilled in the art without departing from the principles of the invention, and these should also be considered within the scope of protection of the present invention.

Claims

1. A method for checking the integrity of device parameters in an LVS file, characterized in that, Includes the following steps: Step 1: Extract the device parameter definition data from the LVS file and store the device parameter definition data into the first register; Step 2: Read the data from the parameterization unit, extract the simulation parameters of each device in the simulation tool from the data of the parameterization unit, and store the simulation parameters of each device into the second register so that the second register includes the simulation parameters of all devices. Step 3: Cross-compare the device parameter definition data in the first register with the simulation parameters of each device in the second register to determine the completeness of the device parameters defined in the LVS file.

2. The method for checking the integrity of device parameters in an LVS file as described in claim 1, characterized in that: In step one, the device parameter definition data includes: device name, device parameter name, and its location in the LVS file.

3. The method for checking the integrity of device parameters in an LVS file as described in claim 2, characterized in that: Step one also includes a step of compressing the device parameter definition data stored in the first register, in order to merge multiple device parameter definition data based on different structure definitions for the same device.

4. The method for checking the integrity of device parameters in an LVS file as described in claim 3, characterized in that: The compression process includes: Multiple device parameter definition data with the same device name and device parameter name are merged into one device parameter definition data; Multiple device parameter definition data with the same device name but different device parameter names are merged into the device parameter definition data corresponding to the device parameter name with the largest number of parameters.

5. The method for checking the integrity of device parameters in an LVS file as described in claim 4, characterized in that: In step one, after the compression process is completed, the following steps are included: The location of the device parameter definition data discarded for alarm notification in the LVS file.

6. The method for checking the integrity of device parameters in an LVS file as described in claim 1, characterized in that: In step one, the device parameters in the device parameter definition data are used in the back-end simulation process.

7. The method for checking the integrity of device parameters in an LVS file as described in claim 1, characterized in that: In step two, the parameterization unit outputs the front-end circuit simulation netlist through the simulation tool.

8. The method for checking the integrity of device parameters in an LVS file as described in claim 7, characterized in that: In step two, the simulation tools include various types, and the simulation parameters of each device in the second register are integrated to merge the simulation parameters of the same device in different simulation tools.

9. The method for checking the integrity of device parameters in an LVS file as described in claim 8, characterized in that: The types of simulation tools include: spectre_view, hspice_view, and cdl_view.

10. The method for checking the integrity of device parameters in an LVS file as described in claim 2, characterized in that: In step three, after the cross-matching is completed, a comparison report is output; The comparison report includes: whether the device types are consistent, whether the device parameters are consistent, and the line number of the calibrated error area in the LVS file.

Images