[Magic-dev] Importing GDS from Astro into Magic?

[R. Timothy Edwards]

Dear John,

> Has anyone tried importing a stream file generated by Synopsys Astro
> Place&Route into Magic?  I'm using the Oklahoma State University flow to
> generate a layout and am trying to read it back into Magic, and I'm
> encountering some issues:

No, but I do have extensive experience importing various 3rd-party GDS
files into Magic, and the issues are generally the same.

> 1. The gridsize is changed when I read the stream file back into Magic to be
> 2 lambda.  Is this due to the fact that Astro puts things on half lambdas?
> Maybe this is a feature rather than an issue.

Sometimes if some non-physical geometry is placed on a half-lambda grid,
Magic will rescale to accomodate it, even though no final geometry in Magic
is on the half-lambda grid.  If this is the case, then use "gds rescale false"
to prevent Magic from changing its grid size during read-in.

> 2. The top level cell is empty.  I can find the necessary logic
> in a subcell called "toppo".

This is just a feature of GDS files.  They don't have top-level cells like
CIF files do.  If magic writes a GDS file, it knows how to read it back in
such that the top-level cell is loaded into the window.  But it can't do
that with 3rd-party GDS files.  You can, however, do the command
"cellname top" to find out which cell or cells is on the top of the
hierarchy, so you don't have to search around for it blindly.

> 3. Looking at the "toppo" subcell, there are DRC errors because adjacent
> cells are placed 1 lambda apart and the well spacing rule is violated.

There are a couple of choices here---(1) try to get the placer to abut
the cells properly, instead of inserting space, and (2) don't parse the
nwell in a GDS read-in.  In this case, I would expect that you really
ought not to have gaps between the nwells created by the placement.
But, where you know that the standard cells are correct, just ignore
the nwell and let magic auto-generate it on GDS output, at which time
the layers will get merged together by the grow-shrink rules.

What I do for standard-cell read-in is to use the "gds readonly true"
option for the standard cells themselves, and I sometimes read in a
very limited set of layers so that I don't get DRC violations within
the cell or between cells due to technicalities of the way the "cifinput"
section of the Magic techfile is written.  You should only do this if
you're sure that the standard cell set is correct and all errors are
false positives.  The "gds readonly true" preserves the GDS database
for the cells read in under that setting, such that when the cells are
written back out to a GDS file, the original layout is preserved exactly.
This prevents Magic from screwing up known good 3rd-party layout.

> 4. The "via" subcells $$M2_M1, $$M3_M2, $$M2_M1_1500_1500_3_1 and
> $$M2_M1_1500_1500_3_3 are not getting instantiated properly in the "toppo"
> cell and connectivity between layers is lost at these points.  Does magic
> have issues with cell names that start with "$$"?

It's not supposed to.  Tcl/Tk treats "$" as a variable name indicator,
but because Cadence uses this nomenclature a lot, I have specifically
written code to check for the double-dollar-sign.  You might want to
check Magic version 7.5 (the current stable distribution), which is
more up-to-date than 7.4.  The more likely possibility is that the
"cifinput" section expects a via size that has a larger overlap than
the subcells created by the router.  This is often the case where the
Magic rules have been written for a more relaxed set of design rules,
and the router uses a more aggressive set of rules to squeeze out every
last nanometer of available space.  The cifinput routine may simply
decide that there is not enough space in the cell to generate a contact,
and therefore fail to generate one, leaving an open circuit where there
should be a contact cut.  The solution to this is to rewrite the
cifinput rules, and possibly the DRC deck as well, if you don't want
the tighter rules showing up thousands of DRC violations in the design.

If you have any remaining issues, send me some layout and the corresponding
techfile, and I can figure out what's going wrong with it.

					Regards,
					Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: tim at opencircuitdesign.com    |
| Open Circuit Design, Inc.	 | web:   http://opencircuitdesign.com |
| 22815 Timber Creek Lane        | phone: (301) 528-9364               |
| Clarksburg, MD 20871-4001      | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+