PAD Frames

Hello,

I am a somewhat experienced Cadence user, however I am doing a PAD
Frame for fabrication for my first time. My question is that why do I
recieved tens of thousands of errors when running DRC on the pad
frames? My layout works just fine, but is it normal to recieve so many
errors? Has anyone fabricated a chip and simply ignored all of these
errors? Why do they show up in the first place?? Any answers or
further insight to this problem will be MUCH appreciated.

Also, I have gone to the following website for the schematics on my pad
frames and components (I am using the AMI C5N technology):

http://microsys6.engr.utk.edu/ece/bouldin_courses/651/ami06pads.pdf

However, this does not list all of the available components and their
schematics, and it is also quite out of date. Does anyone have a
newer, more complete list available? Thank you very much for your help!

 

may the PAD have different DRC rule as the core area have. Normally,
the foundry may provide the IO design rule alone .

 

Not to step up as a "good" example, but I've taped out several times and
we always run DRC/LVS without the pad frame and cross our fingers that
the pad frame is correct. We usually triple check the pad frame by eye.
There must be a better way because people who came before me in my
group definitely got chips back with pad frame problems (things like
gnd-vdd short in the ESD). So, it is an option, but it's a scary one.
Ned

 

First off, thank you both for replying, because I am the only one in my
lab group, so I don't have anyone else to ask.

sunkey, you mentioned that the lDRC rules are different for the PAD
frames. Well, my pad frames are from MOSIS, and the foundry they will
be sent to is MOSIS for fabrication. However, I can't find any
different DRC rules on this site... although I have to admit, I'm not
very good at searching through it. If this is true, does anyone else
know where these DRC rules may be?

Ned, when you run LVS, you don't get problems like merged nets that
tell you the GND and VDD are connected together? I haven't tried LVS
yet because I have been trying to fix DRC, however I thought LVS would
have so many problems that it wouldn't even run.

Does anyone know how to set up the pad frames so that they don't give
us errors? I've actually heard of people creating their own pad frames
(professors, of course, who copyright them or something) so they don't
have these problems, but shouldn't the ones supplied by MOSIS work?

 

To answer that, we would have to know:

1) What rules are being flagged.
2) What layout is generating those flags.

The flags might be false, they might be real, you might be
missing a tag layer that identifies some structure as "pad"
and changes the rule in question, etc.

-Jay-

 

Jay,

The errors I recieve are all due to the pad frame, and these are as
follows:

====================================================
******** Summary of rule violations for cell " " ********
# errors --> Violated Rules
12646 --> (SCMOS Inst) Edge not on grid
122 --> (SCMOS Rule 10.4) pad to unrelated metal2 spacing: 30um
72 --> (SCMOS Rule 10.4) pad to unrelated metal3 spacing: 30um
320 --> (SCMOS Rule 2.5) active of different implant spacing: 0 or 1.20
um
15750 --> (SCMOS Rule 3.1) poly width: 0.60 um
40 --> (SCMOS Rule 7.2) metal1 spacing: 0.90 um
18600 --> (SCMOS_SUBM Rule 3.2) poly spacing: 0.90 um
8 --> (SCMOS_SUBM Rule 9.2) metal2 spacing: 0.90 um
176 --> Improperly formed shape - active, nactive or pactive
40 --> Improperly formed shape - metal1
352 --> Improperly formed shape - metal2
88 --> Improperly formed shape - nselect
88 --> Improperly formed shape - nwell
88 --> Improperly formed shape - pselect
20 --> Non-Manhattan shape - poly
6800 --> Non-Manhattan shape - poly

55210 Total errors found
========================================================

I've done some more research on this problem, and from what I've
gathered in other user groups is that everyone has this problem, and no
one (to my knowledge) has posted a solution to it yet. This problem
has been talked about for 4 or 5 years now too (according to dates I'm
finding in Yahoo! groups and elsewhere), so I think it would be a good
idea to find a solution now if possible.

Also, I've talked to the guy in charge of the Cadence software at my
university, and he said that the pad frames were initially built for
the Tanner products, and while they work(ed) for those products, they
may not pass DRC for Cadence because of some rule differences. If this
is true, this would explain the difference between the documentation on
the MOSIS website (from 1998), and the discrepencies between that and
all of the extra cells MOSIS allows us to download. What do you think
about this?

For the record, I tried placing a "pad" drawing around the pad frames
in the layout, and when I ran DRC again I got the same errors as shown
above. Jay (or anyone else), do you think I need another layer that I
don't have?

Anymore ideas on this problem? As before, thank you all very much for
your help!

 

I apologize, in the error list above, the 20 errors is due to a
non-manhattan shape for metal2, not poly. So the list should be:

 

That's pretty weird, I have to say. What if a real error slipped in, how would you tell it out of
55k fake errors?

I've witnessed cases where skipping the DRC/ERC would have led to a non-working chip so I agree with
Ned that it's quite scary to do that.

Think if I were you, I'd contact the foundry (or whoever provides the IOs) to make sure.

I never used these, so I can't be much more helpful.

Good luck,
Stéphane

 

The only pad-related rules here are the two sets of 10.4 flags.

I don't understand your confusion about the rest; if your DRM
says poly/poly space is 0.90um and you have 18600 places
where you violate that, you have to go fix them, period, end
of discussion. In the rest of your chip, do you just say "oh,
0.80um poly space is close enough"? No, you don't.

The solution is you fix the layout.

I think this doesn't really make sense. Tanner is not the wafer fab.
Cadence is not the wafer fab. MOSIS is not the wafer fab. Whoever
the wafer fab (foundry) is, they set the rules. The layout has to
follow
them.

NO, NO! Unless your tech setup is very unusual, ("pad" "drawing")
is the passivation opening for the bond pads. DO NOT DRAW IT
anywhere else.

-Jay-

 

Jay,

Yes, I understand how to fix all of the simple errors, but I'm not
going to do that if I still have hundreds of errors due to SCMOS Rules
10.1 through 10.4 that I don't understand. Your end of story is not
the true 'end of story', because there are still all of these other
errors, and I don't feel comfortable sending out a fabrication when
there are errors in the DRC. Is there not an easier way to solve this
problem? If I go through and fix 55,000 errors, I will have to flatten
the instantiated cell that I downloaded from MOSIS, then spend hours
going through the layout. I could probably create a pad frame faster
than that, from scratch. I know I can solve half of the problems or
so, minimum, just by aligning the layout to the grid, but the errors
like "active of different implant spacing: 0 or 1.20 um" don't make any
sense to me, and if I still have them after I fix all of the other
problems, I will not know what to do. Can you (or anyone else) provide
a better definition of what this means? And again, thank you very much
for the time you've spent in this post.

Thanks for the info about the pad drawing also - this being my first
time with a pad frame, I had never used it before, and I did not know
what it did.

 

UPDATE!

Simply by checking 1 box while importing the CIF files from MOSIS, I
have been able to knock down the amount of errors from over 55,000 to
just over 1,000! (Fixing all of these errors manually would take
hours, rather than seconds as it did here).

For those who need this information as well, what I did was the
following after I downloaded the latest CIF files from MOSIS:

At the icfb window:

file --> import --> CIF
<set your run directory>
<set the imput file name for your CIF file>
<set the library name you are importing your CIF files into>

click on "options"

CHECK the box that says "Snap XY to Grid Resolution". By default, this
box is left UNCHECKED, so you must check that box!!!

Click "okay" then import your CIF files. As I mentioned earlier,
judging by the errors I was getting (and viewing the layouts), it was
obvious that most of these errors are coming from the "edge not on
grid" problem. The following errors I recieve NOW are:

============================================================
********* Summary of rule violations for cell " " *********
# errors Violated Rules
114 (SCMOS Rule 10.4) pad to unrelated metal2 spacing: 30 um
72 (SCMOS Rule 10.4) pad to unrelated metal3 spacing: 30 um
320 (SCMOS Rule 2.5) active of different implant spacing: 0 or
1.20 um
176 Improperly formed shape - active, nactive or pactive
40 Improperly formed shape - metal1
352 Improperly formed shape - metal2
88 Improperly formed shape - nwell
1162 Total errors found
============================================================

I'll post more updates as I find more answers to this problem, if
possible. In the meantime, I still do not understand what the
following line means:

320 (SCMOS Rule 2.5) active of different implant spacing: 0 or 1.20
um

Any information on this would be MUCH appreciated! And as always,
thank you for your help in this problem.

 

I think it means active regions should either be touching or at least
1.2um apart. It seems you have two different active regions which are
less than 1.2u and more than 0u apart.

 

mk,

Yeah, it looks like you're right, thanks!

As for the design rules 10.1 - 10.5, does anyone know if these are just
"guidelines"? According to the following link from MOSIS, it appears
that I can ignore these errors if I want. Is this true?

http://www.mosis.org/Technical/Designrules/scmos/scmos-glass.html

 

Yup, I can.

BTW, hopefully, you've got paper/PDF documentation for the
design rules; usually there are little example drawings there.

Suppose you've got two drawn implant layers, PPLUS and NPLUS,
but you use these to generate lots of other layers (VT implant, LDD,
etc. In the generation, you might do something like:

foo = NWELL andnot (PPLUS or NPLUS).

Now, you *want* to allow PPLUS and NPLUS to abut (so you
can make butting taps), that would be 0um space.

But if you allowed NPLUS and PPLUS to be 0.1um apart, that
would generate a 0.1um sliver of layer foo, bad for mask making
and photo, you can't resolve that. The smallest foo you can
resolve is 1.2um wide.

So you have a rule that the allowed NPLUS/PPLUS space
is either >= 1.2um, or exactly zero. Overlap is not
(typically) allowed, and 0 < space < 1.2um is not allowed.

-Jay-

 

Thanks Jay. That clears up a lot of confusion. I appreciate the help!