Вы находитесь на странице: 1из 17

Institut f

ur Integrierte Systeme
Integrated Systems Laboratory

Department of Information Technology and Electrical Engineering

VLSI II: Entwurf von hochintegrierten Schaltungen


227-0147-00

Training 3

Physical Verification
Prof. Dr. H. Kaeslin
Dr. N. Felber

SVN Rev.:
Last Changed:

878
2012-10-10

Reminder:
With the execution of this training you declare that you understand and accept the regulations about
using CAE/CAD software installations at the ETH Zurich. These regulations can be read anytime at
http://dz.ee.ethz.ch/regulations/index.en.html.

1 Overview
In the last two trainings we have learned to use SoC Encounter and have transformed a netlist into
a physical layout. In this exercise we will deal with two important steps in the back end design flow:
Design Rule Checking (DRC) and Layout Versus Schematic (LVS) validation.
We will also investigate the final physical layout and learn more about how standard cells are designed, and what is inside them.
In the first part of the exercise we will outline the design flow for DRC and LVS for the semester
projects. In the second part we will use DRC and LVS to find and correct errors in several example
designs.

1.1 About the Style


We will try to use a number of different styles to identify different types of actions. These are summarized below:
Student Task: Parts of the text that have a gray background, like the current paragraph, indicate
steps required to complete the exercise.
Actions that require you to select a specific menu fill be shown like the following:
menusub-menusub-sub-menu

Whenever there is an option or a tab that can be found in the current view/menu we will use a button 
to indicate such an option.
Throughout the exercise you will be asked to enter certain commands using the commandline1 . The
following is an example of the linux command line.
sh > command to be entered on the linux command line

2 Physical Verification Design Flow


The goal of the back end design is to convert the structural netlist that we obtained through the
front end design into a physical layout database that essentially contains the geometrical design
information for all design layers. This information (also called the mask data) is used by the IC
foundry site as a blueprint for manufacturing. Essentially the IC foundry gets only a large database
that contains a set of geometric shapes (mostly rectangles) in different layers.
Some of the layers in the database are physical layers. That means these layers will be directly manufactured. a good example are the various metal layers used for interconnections. There are some
non-physical layers that are used as part of the design flow to identify certain structures (umcL180
uses a dedicated layer to identify resistors for example), or just for informational purposes (various
text layers)
1

There are many reasons for using a commandline. Some functionality can not not be accessed through GUI commands,
and in some cases, using the commandline will be much faster. Most importantly, things you enter on the commandline
can be converted into a script and executed repeatedly

The IC foundry defines several rules for each of the process layers. In essence the foundry would
say
If you manage to send me a geometrical database that obeys all the rules I have sent
you, I guarantee that I will be able to manufacture an ASIC that works (with some yield).
For example, in the umcL180 technology that we use in our exercises, if you want to draw two parallel
interconnections on metal-1 (the lowest metal layer), you have to make sure that the metal lines are
at least 240 nm wide and are separated by at least 240 nm between them. These rules are known as
design rules.
DRC is a rigorous process where the entire physical design database is checked against these design
rules. Over time, the IC manufacturing technology has evolved tremendously. With each technology
step, the design rules have become more complex and numerous. A modern process like umcL180
has many different manufacturing options (you could choose between high-speed or low-leakage
options for your transistors, manufacture the chip with 4, 5, or 6 metal layers, use a 2000 nm, 1200 nm
or a 800 nm top metal layer just to name a few), making DRC an increasingly complex operation. The
design rules for the process are linked under docs/umcL180 topological layout rule.pdf.
As mentioned earlier, the IC foundry receives only geometrical information on the design. Before submitting this data base, it is important to make sure that the bunch of polygons that we are submitting
indeed represent our circuit. This process is known as the Layout (the physical database that contains polygons) Versus Schematic (the design database that contains a netlist of transistors) check.
During LVS, the tool takes the physical database and identifies transistors and interconnections and
thereby creates a netlist directly from the physical database. In the second step this netlist is compared against the original logical netlist (gate level netlist) that was the basis of our design. If both
netlists match, we can be confident that the physical database that we are sending for manufacturing
contains our design, has no shorts or missing connections2 .
We will be using the Calibre tool from Mentor Graphics for both DRC and LVS in our design flow as
illustrated below:

Note that this only ensures that the layout corresponds to the final gate-level netlist, whether or not the gate-level
netlist actually does what we expect it to do is an entirely different manner that is handled by design verification.

TCL script for export


encounter/scripts/
exportall.tcl

Cadence SoC

Physical Layout

Verilog Netlist

encounter/out/final.gds

encounter/out/final.v

SPICE includes
verilog2spice
Calibre DRV

calibre/lvs/spice.inc

Verilog includes
calibre/lvs/verilog.inc

SPICE Netlist
calibre/lvs/final.sp

Runset file

Runset file

calibre/drc/runset.drc

calibre/lvs/runset.lvs

Antenna Runset file

Calibre DRC

Calibre LVS

calibre/drc/antenna.drc

Labels
calibre/lvs/lvs_labels.txt

2.1 Getting Started


Student Task 1:
Start by copying the example files into your directory by issuing the command
sh > cd
sh > /home/vlsi2/t3/install_t3

This will create a cockpit hierarchy in the directory training 3. The design that we will use in the first
part of the exercise is the one we have used in training 1, we have included only the relevant parts of
the design database3 . There is a second small design called sbox which contains several DRC and
LVS errors. We will use this design in the second part of the exercise.

You can also use your own semester thesis as an example for this exercise.

2.2 Accessing the Layout

Hierarchy
Display

Layout Display

Layers

Depth
Display

We will use the M ENTOR G RAPHICS C ALIBRE DesignRev (DRV) tool to access
the gdsiifile produced

by C ADENCE S O C E NCOUNTER . Start the tool either by clicking on the Calibre DRV button of the
cockpit 4 , or manually change to the directory calibre and use the command line5 :
sh > calibre-2009.3 calibredrv -dl .init/L180.layerprops
The -dl option specifies a configuration file that will load change the layer information so that the
colors of the layout looks similar to that you have seen in SoC Encounter.
Student Task 2:
Load the final gdsii file. Select FileOpen Layouts.. to bring out a requester.
Change to the
 directory
 ../encounter/out where our outputs are located. You will have to
change the File type at the bottom of the requester to ZIP (*.gz, *.Z, *.z) in order


to be able to see our file t2.gds.gza .
a

4
5

Most tools will be able to read compressed (.gz) files without a problem.

you can start cockpit by typing icdesign umcL180


do not use a & to run this program in the background, as it needs to access the console

You should now see the layout in the main window as shown in the previous figure 6
Student Task 3:
Familiarize yourself with the editor, try displaying all levels of the hierarchy, zooming, maneuvering, displaying only certain layers.
Note that, unlike in SoC Encounter you have full access to the layouts you can examine
individual standard cells as well.
Take a piece of paper, and looking at the layout draw the the transistor level schematic of
the following cells including the transistor dimensions: INV1, BUF1CK, ND2, OA12.

In the previous step you have managed to extract the circuit looking at the geometric information, this
is exactly the same way that Calibre will extract your circuit during LVS phase.
Student Task 4:
View the full chip again.
You can also extract nets. Try to determine the connectivity of some nets. By default
you can only extract on the top-level, you
change this behavior by by selecting Edit
 can 
Preferences...
choosing
the
tab
Nets

and selecting All Levels for the option


a
Search Depth .


Try this feature. Select one net. Click


 with the right mouse button to get a small context
menu. You can select Extract Net from this menu.
a

Note that if you select the supply nets, the extraction will take very long. There will be an Abort  option
visible during the extraction on the bottom left corner of the DRV.

2.3 Running DRC


In this section we will perform a DRC on the layout we have just loaded.
Student Task 5:
Select Verification Run nmDRC.. to bring out a requester. You will be asked to
select a runset filea . Click on the ... to bring in a file requester and choose the file runset\
.drc from the directory calibre/drc.
a

If you have had previous DRC runs, all previous runset files will be available for you to choose from. Be careful
when selecting a file, since in most cases a cockpit structure is used, the names will generally be very similar.

By default Calibre DRV will draw an outline around each instance and will write its name inside the box, while
this is sometimes very useful, it will make the screen very cluttered. You can disable this, by selecting Edit \
Preferences... and deselecting the option Draw reference outlines from the requester that comes up.

The main DRC window contains four main configuration steps which are available on the left hand
side7 :
Rules Defines the run file and the run directory. The runset file sets both options here
Inputs Tells where to find the layout file. The default is to export it from the DRV viewer. This is a
waste of disk space, since we used the viewer just to look at the gdsii file. We will change this
in the next step.
Outputs Specifies where the output will be written (the defaults should be ok)
Run Control Allows you to set some options about the run.

If any of the configurations is not valid you will see the content of the field in red colour.
Under the menu Setup Select Checks you can examine which design rules will be checked
with the current run. Notice that not all checks are selected as some of the checks are for different
fabrication options.
Student Task 6:

Select the Inputs tab on the main DRC window on the left hand side. We will change the


default There is no need to save the layout information once again. Disable Export from layout viewer


button, and select the gdsii file (encounter/out/t2.gds.gz) using the file requester.







There is a fifth one DRC options which is not enabled by default. You will have to go to the menu Setup and







enable the DRC Options . However the default values should be sufficient for most cases

Student Task 7:

Run the DRC by pressing Run DRC on the left hand side of the DRC window. This
operation will take several minutes to complete. A second (RVE) window will open showing the results of the current checks. If there are any errors from any of the completed
checks,
After all checks are complete you will see a third win you will already see them.

dow ( DRC Summary Report ) will appear. At this point, if you have any errors, they will be


shown in the RVE window.


If you scroll to the end of the DRC Summary Report window, you should see the following summary


(actual numbers may be slightly different).
--- SUMMARY
--TOTAL CPU Time:
TOTAL REAL Time:
TOTAL Original Layer Geometries:
TOTAL DRC RuleChecks Executed:
TOTAL DRC Results Generated:

123
74
274986 (16225226)
466
0 (0)

The summary tells us that there were 274986 geometries, and they were checked for 466 different
rules, in the end the important part is the last line TOTAL DRC Results Generated, which tells
us there were 0 violations.
We are almost complete. For our technology the antenna rules8 have to be checked using a separate
runset.

you can read more about antenna rules on page 527 of your textbook.

Student Task 8:
Run a second DRC, this time by using the runset calibre/drc/antenna.drc. You can load a
new runset through the menu File Load Runset.
It is very important to have a completely error free DRC run for your semester project. We will practice
on how we can fix errors in the second part of the exercise

2.4 Running LVS


In this section we will run LVS on the same design. Note that both DRC and LVS have to be repeated
whenever, there is a change in the layout.
Before we start the LVS, we have to prepare the data. We already have the layout, what we need is
to generate the schematic (the S of LVS). We have the final verilog netlist that we have saved in SoC
Encounter. This netlist contains all modifications and additions (clock tree, buffers, filler cells) of the
back end design flow. This netlist does not contain the transistors within the standard cells. We will
use a simple script to generate a transistor level netlist (in SPICE format) that contains all necessary
information for the schematic.
Student Task 9:
If you still have the DRC window, close it, we will not need it for a while.
Using a console change to the lvs directory calibre/lvs. You will find the script verilog2spice
there. Execute it using:
sh > ./verilog2spice ../../encounter/out/t2.v t2.sp
[sh] This will convert the verilog netlist under ../../encounter/out/t2.v into a SPICE netlist
named t2.sp in the current directory.
You will see several warning messages of the type:
Warning: Module instantiation XXX has pin mismatches with module YYY
These messages come from instantiations where all defined outputs are not connected to
a net. This is not tragic, and can be ignoreda .
a

For your own designs you should always investigate what these messages are. For this exercise we have made
sure that there are no surprises.

Now we have our schematic we need to start the LVS. Unlike the DRC, there are several additional
files that control the LVS flow. The t2.sp file will include the file spice.inc which in turn includes the
SPICE level definitions of all the libraries and macro-cells.
The runset file runset.lvs among other things includes the file lvs labels.txt. This file puts two labels for
VCC3O and GNDO the power and ground signals for the I/O cells. Throughout the backend design we
have only used VCC and GND as the only power signals. In reality, there are several other independent
supply nets, and these have to be taken into account for the LVS. The labels are positioned on the
correct I/O supply pads9 and help identify the additional supply nets for the purpose of LVS.

Unless you have deviated from the power pin template given.

Student Task 10:


Select Verification nmLVS.. in the calibre DRV main window to start the LVS. You
will have to load the runset file located under calibre/lvs/runset.lvs.


Once again make the changes in the Input configuration so that the layout is not exported


from the viewer but is taken directly from encounter/out/t2.gds.gz.


You will notice that the input configuration is still red. You should also notice that there are


multiple tabs in the configuration area. Currently the layout has been selected. Click on


the Netlist and bring up the file browser by pressing ... . You should be able to select the
SPICE netlist file that we have created named t2.sp.


The next issue is to tell the Top Cell: name for this design. The default name selected is


chip. In our case this is not correct. You can find the correct name from the verilog netlist,
from the SPICE netlist, or by browsing the instances within the file by clicking on the ... 
button.


All other options should remain the same. Start the LVS run by clicking on the Run LVS 
button on the right hand side.


The LVS run will also produce two windows, the RVE and the LVS Report File . This time there


should be two dangerous sounding extraction warnings:
WARNING:

Short circuit - Different names on one net

This is a mistake within the RAM macro that we are using. If you examine the warning closely you
will see that the net has two different labels. However, the names are similar, essentially one of the
net names is missing the first character. Text labels placed within the layout can help the LVS tool to
identify the structure of the circuit. In some cases, such mistakes could mislead the LVS tool. In our
case, the exact name is not important and we can ignore these two warnings10 .


In the RVE window you can now select Comparison Results on the left tab. You will see a green


smiley and the Cell chip Summary will show you the comparison results.
Until now we have seen how to run DRC and LVS with example designs. However, in both cases we
did not encounter any problems. In the next section we will briefly talk about what we can do when
we find problems, and how they can be solved.

3 Finding and Fixing Errors


The first question that may come to mind is Why should there be errors?. Afterall we have only
used EDA software to create the final layout, and have also performed both a Verify Geometry


(essentially the equivalent of a DRC) and Verify Connectivity (basically an LVS) and had no errors


there. There are a couple of explanations
10

In the exercises we frequently tell you that the warnings are not important. This is not always the case. Even in
production design flows, such mistakes, and errors are commonplace. You have to be careful to examine each warning
and error to ensure that there is nothing wrong with your design.

10

While we did not use it in our design flow, it is possible or sometimes even necessary to make
additional changes on the layout, after SoC Encounter. This may be required to add logos,
bonding pads, chip corners, additional process control monitors, including IPs for which there
are no design views (lef, lib) for SoC Encounter etc. In some cases these additions will be done
manually, which is a very error prone operation.
SoC Encounter may produce errors, which it can not detect. This may be a bug in Encounter
(there is no guarantee that there will be none), or (more likely) a mistake in one of the technology
files that tell customize Encounter for a given technology.
SoC Encounter works with abstract views of macro-cells and standard cells. These cells only
include relevant information for the cells, such as pin locations and obstructions within the cell
but not everything like transistors. Some errors may only show up when the real cells with full
layouts are used.
IC foundries will only accept data if it passes DRC with a certain tool. In our case we have to
make sure that the Calibre DRC run reports no errors, otherwise the foundry will return the chip
back to us for fixing.
And last but not least, ASIC design is a very costly process, additional verification by a second
tool would increase our confidence in the overall design.
The next question might be So what happens if we actually find an error?. The obvious answer is to
fix it. But before we start we need to understand the error. Especially modern processes have many
processing options, and many conflicting rules, so the first order of business is to identify the problem
and verify that it actually violates a design rule that needs to be fixing.
In our case, most of the time we will be violating various Metal Coverage rules. However, we
have an agreement with our IC foundry that stipulates that the IC foundry will perform a metal filling
step that will get rid of all problems with Metal Coverage so we can safely ignore these errors.
The second step is to try to determine what caused the error. If at all possible it is better to find a
fix that can be implemented in earlier stages (i.e. in SoC Encounter) rather than fixing the problem
manually11 . Sometimes this will not be possible, the reason may not be clear at the time, or there
might be significant time pressure to finalize the design as soon as possible, and you might be forced
to correct the error manually.
In this section we will pratice finding and fixing errors for a set of crafted examples that contain errors.
We will use a much smaller design, to reduce the run times, and make it a little bit easier to debug
the circuits12 .

11

12

As mentioned earlier, manually altering the layout is a very error-prone process. In addition, the design might require
another iteration (for a completely different reason) leaving you to fix the same error over and over for subsequent
iterations.
If your semester project designs have indeed errors, you can use them as examples as well.

11

3.1 DRC
Calibre opens many windows while running, it might be easier if you quit Calibre and close all windows
before starting the second part of the exercise
Student Task 11:
Start Calibre DRV and load the design encounter/out/sbox.gds.gz.
Run DRC (normal DRC, not antenna) on this design, just like you did the previous section.
You will get several errors.
The RVE window should look similar to the figure below:

In this DRC run there are ten DRC errors (RVE calls them results) violating six different rules (RVE
calls them checks). In the figure we have selected the second check named 4.13B.a13 and at the
bottom there is an explanation of the design rule:
Minimum space between ME1 regions is 0.24um where MET1 width < 10um
For a given check, multiple results can be listed (like the one in the figure). The RVE window is
connected to the DRV window. Once you double click on any result, you can highlight the error
location on the DRV window, alternatively you can select one result and press H, or use the right
mouse button to show a context menu. The highlighting will be made using a new layer in the DRV
window. You can treat this layer just like any other layer and hide it if necessary.
We will now locate and correct all the errors. Since this is an exercise we have made sure that the
errors are easy to locate and fix.

13

The name corresponds to the section of the design rule manual. In our case it is on page 28 of the design rule manual
accessible under docs/umcl180 topological layout rule.pdf, which is section 4.13, rule 13B.a

12

Student Task 12:


Let us start with the error 4.13A, select and highlight the error.
You will see the error marker, showing the region where the error has been encountered.
However we do not see the complete layout, only the top level of the hierarchy. You can
change the number of hierarchy levels visible by pressing >. Press > at least three times
to make the first 4 levels of hierarchy visible.
Currently many layers will be visible. We have an error that only concerns metal-1. Figure
out how you can disable the layers, and arrange that only metal-1 (and the error marker)
remains visible.

Select "Move"

only "edge" is selected

Leave "metal1" visible


and turn all others off

Measure the width


of the rectangle

Select this edge


move this edge
down by 0.2 m

make sure "Depth"


shows all layers

Student Task 13:


Now you should see the problem much more easily. The design rule says that Metal-1 lines
have
tobe at least 0.24 m wide. Determine the width of the offending part by selecting a

Ruler

and measuring the width.
We will now have to modify the rectangle so that its width is at least 0.24 m.
 First
 disable
all the selection options on the top right side of the DRV menu except for edge . This will


allow you to select a single edge of a geometric object. Change the tool to Move and try

to move the bottom edge of the polygon by the required amount.

You will notice that you can not move the object by the amount you want. There is a
grid setting of 0.1 m that restricts movements by this amount. Change this preference by

13

selecting Options Grid Setting from the menu. Make sure that the Spacing is set


to 0.01 um. Now move the edge by the proper amount.
Calibre DRV gives some simple commands to edit the layout. It is important to adjust the layer, grid,
and selection settings continuously to work effectively. As a general rule, never use a fine grid if you
can also work with a coarse grid. In case you make a mistake there is always Edit Undo:.
Student Task 14:
Rerun the DRC after fixing the error. 
Please note that you havemodified the layout, and
this time you want to make sure that Export from layout viewer option is selected in the


Input tab of the DRC window.

If you did everything right, the error should disappear.


Student Task 15:
Try to locate the 5 violations of the rule 4.13B.a. This rule finds metal-1 structures that are
too close to each other. In the first error you will see that the metal-1 line almost connects,
but falls shy. The problem could be solved in two ways, either we connect the structures, or
we leave sufficient space (0.24 m) to make them two separate structures. DRC does not
care about connectivity information, that is the job of LVS.
Errors 2, 3 and 4 have the same cause. These are called notch errors. Although the
structures are connected, any U type shape must still satisfy the minimum distance rules.
Error 5 is slightly different, the problem is on a piece of Metal-1 that is within an instance (a
via instance). You can resolve the problem by moving the instance.


To be able to select the instance, you need to make sure that the selection criteria is ref 
.
Then you need to make sure that you are displaying the hierarchy level where the instance
is visible (as outline) but its contents are not visible. Use the < and > keyboard shortcuts
to adjust the hierarchy visibility.
The via instance contains both Metal-1 and Metal-2. You can not only rely on seeing Metal1 in this case but you must make sure to see Metal 2 as well.
In a lot of cases, one DRC or LVS error may cause a series of others. Furthermore, while fixing one
error, it is possible to introduce more errors. Depending on the run time of DRC, you may decide to
check and correct other errors first or go one by one. No matter which way you choose, fixing DRC
errors requires patience and concentration.
Student Task 16:
Correct all errors until you have a clean DRC.
Make sure that you save the end result, since we will use this for the LVS.

3.2 LVS
We will continue with the layout that has all DRC errors corrected.

14

Student Task 17:


Prepare the SPICE netlist for the sbox by using the verilog netlist encounter/out/sbox.v.
Now run the LVS check following the first part of the tutorial. We need to make a small
change in the runset file. For the previous exercise we used a small file (lvs labels.txt) to
add two labels for the pad power and pad ground signals. This file should not be used
for this second part. You can either comment out the contents of this file, or use the runset
calibre/lvs/runset sbox.lvs.
If you have not introduced additional errors while correcting the DRC errors, you should have 10
Discrepancies as a result.

Note that, it is not easy for the tool to determine which one of the two inputs: the layout or the
schematic is correct. It can just report that there is a discrepancy. LVS errors are more difficult to
locate than DRC errors, since one error can cause multiple discrepancies. In the figure above, we
have chosen Discrepancy #4. At the bottom you can see the problem. The left hand side is the
Layout side and the right hand side is the Schematic (called Source in DRV). The report can be
interpreted as follows:
In the Layout the net 291 connects to the gate of two transistors named X792/M6 and
X792/M0. The LVS tool matches this net to the n878 in the Source netlist. However, for
these two transistor connections there is not a comparable connection. Whereas, similarly there are two connections to the gate of transistors XU892/MMI 2 1 and XU892/\
MMI_3__1 in the Source netlist but not in the Layout netlist.
It is important to go through all discrepancies, and try to find one that is more obvious14 .
14

Some of the discrepancies may be misleading, keep an open mind, and look at them one by one.

15

The RVE tool has many interesting faetures that will allow you to compare the two netlists. Try clicking
on the net name. You will see two schematic windows appear. In some cases this can make it much
easier to understand what is wrong.
Student Task 18:
Start by the discrepancy where you have one net in the Layout, but no corresponding net
on the Source. There should be two such nets. Highlight the net in the DRV by double
clicking on the net number in the RVE.
One of the problems is in a single cell. This is not so easy to solve. The other one should
be much more easier. Correct the problem, run DRC first to make sure that you have not
introduced errors, and rerun LVS.
If you have done it correctly you will only have four discrepancies remaining. Problems with supply
nets usually bring in many other errors with it.
Student Task 19:
Find the discrepancy where you have one net on the Layout but two nets on the Source
netlist. This is a clear case of a short on the layout. Two nets that were separate on the
Source have become a single net, because of an error on the layout.
Highlight the net on the layout. What you see should have been two separate nets. Can
you find the short?
There are several small tools that can help you locate the short. Use the aforementioned
trick by clicking on the net name in the RVE. This will launch a schematic window in which
you can see all the instances involved. You should see that four instances are interconnected in the layout, whereas in the source there are two separate nets with two instances
each. At some point in the layout these two nets have merged. Find the short,remove it
and run DRC and LVS again.
If all is well, you should have three discrepancies remaining. Essentially the remaining three are
interconnected. You will not be able to solve them independently.
Student Task 20:
Once again use the capabilities of the RVE. Before you start, close both schematic windows. Make sure the Highlight Clear Existing Highlights is not selected.
Highlight all three errors. There are multiple problems here. Look for the mix-up in the area
where all three errors intersect.
The solution will require you change some connections. It does not really matter how you
choose to correct them, the solution could use any valid layer as long as DRC rules are
not violated. Small chanegs in the layout will also result in small changes in the parasitic
capacitances. However the changes you make, will not have an impact on the overall
performance.
Congratulations, you have successfully corrected all errors.

16

4 Conclusion
DRC and LVS are both an essential part of the design flow. Ideally, the EDA tools should produce
error free designs. However, this is not always the case. and in any case having a second opinion
from a different tool is always good.
Especially LVS errors can be tricky to locate and to correct. These exercises are not meant to be a
thorough manual on how to find and correct all types of errors, but to give you an idea on what can
be done.
It is important to run a DRC after you modify the layout, as any edit could potentially also result in
new design rule violations. Similarly, if you modify a layout that was LVS-clean, you should re-run
LVS.

17

Вам также может понравиться