GDSII problems with arrays/mosaics from CATS

[Dustin D.]

At my company we use the tool Flying Cats (I believe that's the name,
although I'm not very familiar with the tool) within our mask
engineering department to do data fracturing and preparation for
sending the GDSII data to the fab. One thing I've noticed in the data
Cats generates is that it attempts to simplify duplicate data by
creating arrays/mosaics. So when we use Cadence to dump out our final
GDSII to send off for final prep before going to the fab, the data is
read into Cats, simplified with these array structures, and dumped
back out as GDSII and sent to the fab.

The problem is, these array structures do not seem to integrate well
with Cadence. If I take a GDSII file that has been generated by Cats
and import the stream into Cadence, the arrays are completely messed
up. Sometimes the array has all of the structures stacked on top of
each other (i.e. an offset of 0), sometimes the array is extended in
the x-axis (as columns) when it should be in the y-axis (rows). Thus,
the data looks corrupted.

With the fabs we use, we haven't had any problems with corrupted data
related to this array situation screw up a set of waifers (yet). So
I'm assuming most tools used by the fabs can read the arrayed
structures from Cats just fine. But for whatever reason, Cadence and
the pipo streamin procedure doesn't translate the data properly. This
has set off alarms, as now many are concerned that our data is being
corrupted by Cats.

Does anyone know of any solutions to this, or has anyone seen this
same problem? It appears the data is useless for Cadence once it has
been touched by Cats because of this problem with translating the
data. The simple solution would be to force Cats to preserve the
GDSII and not convert to arrays, but according to our mask engineers,
this isn't possible.

I'm 99.9% sure it's a Cadence translation issue because we haven't had
any failed tapeouts due to this problem, and all of our data goes
through Cats as a last pass before going to the fab.

Any ideas?

Thanks,
Dustin

P.S. If responding by email, please respond directly to
dustin_atm_99@n-o_s-p-a-m.yahoo.com (note: remove the nospam part of
the address)

 

[gennari]

That's interesting. I believe that Cadence doesn't like arrays that are
non-Manhattan, arrays where the elements are diagonal to each other instead
of offset by only X in one direction and Y in the other direction, i.e. 45
degree rotated arrays. I've never seen arrays like this though, and I don't
think a real design would have them. Can you send me an example of a GDSII
with arrays that Cadence doesn't understand? Maybe just a simple test case
with a small file that doesn't disclose any IP? I have a viewer that I
wrote, and I can extract the exact AREF data records and compare them to the
GDSII standard to see if they are legal. Just because other programs can
read these arrays doesn't mean that they adhere to the standard.

Oh, and I think the "Flying Cats" software you are talking about was a
product of Numerical Technologies, acquired by Synopsys. The website is now:
http://www.synopsys.com/products/ntimrg/cats_main_ds.html

Frank

"Dustin D." <dustin999whoop@yahoo.com> wrote in message
news:1306b50.0406191917.758001de@posting.google.com...

At my company we use the tool Flying Cats (I believe that's the name,
although I'm not very familiar with the tool) within our mask
engineering department to do data fracturing and preparation for
sending the GDSII data to the fab. One thing I've noticed in the data
Cats generates is that it attempts to simplify duplicate data by
creating arrays/mosaics. So when we use Cadence to dump out our final
GDSII to send off for final prep before going to the fab, the data is
read into Cats, simplified with these array structures, and dumped
back out as GDSII and sent to the fab.

The problem is, these array structures do not seem to integrate well
with Cadence. If I take a GDSII file that has been generated by Cats
and import the stream into Cadence, the arrays are completely messed
up. Sometimes the array has all of the structures stacked on top of
each other (i.e. an offset of 0), sometimes the array is extended in
the x-axis (as columns) when it should be in the y-axis (rows). Thus,
the data looks corrupted.

With the fabs we use, we haven't had any problems with corrupted data
related to this array situation screw up a set of waifers (yet). So
I'm assuming most tools used by the fabs can read the arrayed
structures from Cats just fine. But for whatever reason, Cadence and
the pipo streamin procedure doesn't translate the data properly. This
has set off alarms, as now many are concerned that our data is being
corrupted by Cats.

Does anyone know of any solutions to this, or has anyone seen this
same problem? It appears the data is useless for Cadence once it has
been touched by Cats because of this problem with translating the
data. The simple solution would be to force Cats to preserve the
GDSII and not convert to arrays, but according to our mask engineers,
this isn't possible.

I'm 99.9% sure it's a Cadence translation issue because we haven't had
any failed tapeouts due to this problem, and all of our data goes
through Cats as a last pass before going to the fab.

Any ideas?

Thanks,
Dustin

P.S. If responding by email, please respond directly to
dustin_atm_99@n-o_s-p-a-m.yahoo.com (note: remove the nospam part of
the address)

 

[Dustin D.]

Thanks for the info Frank. I'll try to get a testcase together, but
unfortunately the only testcase I have right now is an entire chip,
and I don't have easy access to Cats to try and recreate a smaller
testcase. I'm currently converting the GDSII to text and trying to
trim it down where it's a little more manageable, so as soon as I do
I'll see if I can get something for you.

Thanks again.

-Dustin

"gennari" <gennari@eecs.berkeley.edu> wrote in message news:<cb4vli$sso$1@agate.berkeley.edu>...

That's interesting. I believe that Cadence doesn't like arrays that are
non-Manhattan, arrays where the elements are diagonal to each other instead
of offset by only X in one direction and Y in the other direction, i.e. 45
degree rotated arrays. I've never seen arrays like this though, and I don't
think a real design would have them. Can you send me an example of a GDSII
with arrays that Cadence doesn't understand? Maybe just a simple test case
with a small file that doesn't disclose any IP? I have a viewer that I
wrote, and I can extract the exact AREF data records and compare them to the
GDSII standard to see if they are legal. Just because other programs can
read these arrays doesn't mean that they adhere to the standard.

Oh, and I think the "Flying Cats" software you are talking about was a
product of Numerical Technologies, acquired by Synopsys. The website is now:
http://www.synopsys.com/products/ntimrg/cats_main_ds.html

Frank

"Dustin D." <dustin999whoop@yahoo.com> wrote in message
news:1306b50.0406191917.758001de@posting.google.com...
At my company we use the tool Flying Cats (I believe that's the name,
although I'm not very familiar with the tool) within our mask
engineering department to do data fracturing and preparation for
sending the GDSII data to the fab. One thing I've noticed in the data
Cats generates is that it attempts to simplify duplicate data by
creating arrays/mosaics. So when we use Cadence to dump out our final
GDSII to send off for final prep before going to the fab, the data is
read into Cats, simplified with these array structures, and dumped
back out as GDSII and sent to the fab.

The problem is, these array structures do not seem to integrate well
with Cadence. If I take a GDSII file that has been generated by Cats
and import the stream into Cadence, the arrays are completely messed
up. Sometimes the array has all of the structures stacked on top of
each other (i.e. an offset of 0), sometimes the array is extended in
the x-axis (as columns) when it should be in the y-axis (rows). Thus,
the data looks corrupted.

With the fabs we use, we haven't had any problems with corrupted data
related to this array situation screw up a set of waifers (yet). So
I'm assuming most tools used by the fabs can read the arrayed
structures from Cats just fine. But for whatever reason, Cadence and
the pipo streamin procedure doesn't translate the data properly. This
has set off alarms, as now many are concerned that our data is being
corrupted by Cats.

Does anyone know of any solutions to this, or has anyone seen this
same problem? It appears the data is useless for Cadence once it has
been touched by Cats because of this problem with translating the
data. The simple solution would be to force Cats to preserve the
GDSII and not convert to arrays, but according to our mask engineers,
this isn't possible.

I'm 99.9% sure it's a Cadence translation issue because we haven't had
any failed tapeouts due to this problem, and all of our data goes
through Cats as a last pass before going to the fab.

Any ideas?

Thanks,
Dustin

P.S. If responding by email, please respond directly to
dustin_atm_99@n-o_s-p-a-m.yahoo.com (note: remove the nospam part of
the address)