• Previous message: Alireza Moini: "array and subcell cif/gds generation"
• Maybe in reply to: Alireza Moini: "array and subcell cif/gds generation"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear Ali,

> It is a long time since I have been removing the CIFGenSubcell and
> CIFGenArrays from the CIF and calma write functions, .. for two reasons. 1-
> They break the hierarchy and speically for hierarchical DRC/LVS tools they
> make the job harder. They significantly slow down the cif/gds generation
> process, as a flat search has to be done at every layer of the hierarchy
> (for a 2Mpix sensor the gds generation comes down from around 2 hours to 3
> minutes!!!!).
> 
> It would be nice to see that these two eventually find their way out of the
> code, may be initially as an option.

I will be interested in hearing the experiences of others with magic's
subcell and array "patching".  In general, I think it does the "right
thing", which is especially useful in certain cases, such as when select
or well areas don't quite connect between subcells;  if the design were
flat, these would be merged.  The patching behavior takes care of this.

On the other hand, there are enough instances in which magic screws up
the design with its behind-the-scenes routines (for instance, the recently
cited situation of catecorner wells), that one might not miss much by
removing the routines entirely.  I have no problem shifting these routines
into a CIF/GDS option which can be turned off by those who don't want it,
and can probably get that into the next revision.

> The only thing that may be affected is the behaviour of "cif see" command,
> and how it is dealt with.

I don't anticipate any problem regarding "cif see".  Interestingly, about
a month ago, I ran into the first instance I have ever seen in which I got
truly bad GDS output from magic where the instances of an array were narrow
and spaced more closely together than some of the CIF grow/shrink rules.
I got small pieces of n-well displaced to the left of an array, where there
was no layout!  The most curious aspect of this is that none of the bad
tiles show up with "cif see"---the only way to see them is to write out
CIF and read it back in again.

> One particular problem with magic is that it is too easy to generate big
> contacts. The resulting cif/gds turns into a monster. One solutions that
> most commercial tools use is to use arrays instead of repeating the contacts
> over and over. To do this in magic the "square " generation needs a bit of
> rewrite, but doesn't seem impossible.
>
> For every defined "square" command in cifout section a unique cell should
> be created, which then can be arrayed.

The reason this is so is that CIF has absolutely no method for dealing with
arrays.  Because the GDS write routines are essentially a quick hack to
translate CIF output into GDS output just before writing to the file,
nobody seems to have thought about the efficiency of the resulting GDS
file.  This doesn't seem to be especially difficult to implement, however.
And some thought should be given to the reading of contact arrays in GDS,
too;  if these can be detected and flattened, then most of magic's problems
reading non-magic-generated layout files would be eliminated.

						Regards,
						Tim

• Next message: Adam Fedor: "Non manhattan geometry behavior"
• Previous message: Alireza Moini: "array and subcell cif/gds generation"
• Maybe in reply to: Alireza Moini: "array and subcell cif/gds generation"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]