[Eda-dev] Eda-dev post from jmann at mannvlsi.com requires approval
tim at opencircuitdesign.com
Fri Oct 20 15:16:19 EDT 2017
> I am trying to bring up Qflow on a vendor process that is 180 nm. I
> set up my own bare-bones Magic technology file for the process since
> I only want to do synthesis, place and route with Qflow and go back
> to working in my own tool set. I have everything working except the
> wires used for routing are only 3 lambda wide and in this process
> lambda is 0.01 um.
> The vias and metal around the vias are all correct (28 x 28 lambda)
> but the wires between vias are very thin. (see the attached screen shot.)
> Where do the routing wire widths get set?
> The .par files has entries for metal like:
> width M1 24
> width M2 28
> width M3 28
> and the LEF file for the process has entries like:
> LAYER M1
> TYPE ROUTING ;
> DIRECTION HORIZONTAL ;
> PITCH 0.56 0.56 ;
> WIDTH 0.24 ;
> OFFSET 0.28 0.28 ;
> So I can’t figure out where it is coming up with 0.03 um or 3 lambda.
First, if your own tool set is able to read DEF format, then you don't
need magic for anything, and can go straight from the DEF output of
qrouter to your own tools.
Otherwise, if you require GDS, say, then the magic techfile will need
to be reasonably complete with a "cifoutput" section to give the GDS
rules. On the magic web pages there is a script and set of files for
reading in an unknown GDS format file, picking out all the GDS layer:
purpose pairs, and then building out a simple techfile that uses a
one-to-one mapping between GDS mask layers and magic database layers.
But to answer your questions directly:
(1) The .par file information is nearly useless, as it is more of a
guide to the placement tool than any exact measurement would
require. Values are centimicrons but have little impact on the
(2) The LEF technology rules are "golden", but make sure magic is
reading them by reading the LEF technology file first, followed
by the standard cell LEF macros, and then the final routed DEF
I usually make for myself a little script called "load.tcl" in the
layout directory that just contains a few lines like "lef_read"
and "def_read", followed by the "grid" command to set the grid to
the route pitch, which helps see what's going on.
3 lambda is the default SCMOS rule for wire widths, so I expect what
happened is that you didn't read the technology file and so magic used
the minimum width DRC rule for the wire width, which is its fall-back
position. If you have the database scalefactor set so that one internal
unit (lambda) = 0.01um, then you can fix this by changing the DRC rule
widths in the "drc" section appropriately. However, reading the tech
LEF file should override that.
If you did a quick hack of the existing SCMOS tech file and have left
most/all DRC rules to their original SCMOS lambda units, then a good
thing to do is in the "load.tcl" script or in the ".magicrc" file, set
"drc off", because otherwise the whole layout will be splattered with
false DRC violations.
P.S. For continued communication, please register for the eda-dev
mailing list. I have been attempting today to stick spamassassin
into the email group pipeline and I seem to have disabled my ability
to approve posts from non-members. CC directly to me to be on the
safe side. Hopefully I'll have the problem fixed by tomorrow.
| R. Timothy Edwards (Tim) | email: tim at opencircuitdesign.com |
| Open Circuit Design | web: http://opencircuitdesign.com |
| 19412 Cissel Manor Drive | phone: (301) 528-5030 |
| Poolesville, MD 20837 | cell: (408) 828-8212 |
More information about the Eda-dev