|
|
Magic Mailing List |
|
From: cfk (cfk AT pacbell DOT net) Date: Sun Sep 28 2003 - 19:09:42 EDT
Thanks Tim:
The reason I got into this in the first place today was because of
Graham's announcement of his new scalable library of standard cells on the
newsgroup on Friday. So, I spent most of yesterday studying them. Having a
source of cells which should scale from 0.25um through 0.18um & 0.13um
through to 0.09um (or 90 nanometer) would be a wonderful thing to have
access to for Magic research.
In looking at his invertor (the simplest cell), I can see there are DRC
violations around every genericcontact. So, I thought looking at some of
those implications might be useful to the group.
It looks like his genericcontacts all have rule 7.1 and 7.2 violations.
What I dont know is if those violations are real, or a symptom of
genericcontact itself. He drew the library using Alliance and exported it to
Magic. I really like his ideas and the accompanying spreadsheet graphics are
very interesting.
If we can get to where several folks are willing to work with his
library, it seems like another way to help others along and to have some
test circuits that we all have access to as we check various new features in
Magic.
Glad to see you are back from storm-land.
With highest regards, Charles
----- Original Message -----
From: "R. Timothy Edwards" <tim AT stravinsky DOT jhuapl.edu>
To: <cfk AT pacbell DOT net>
Cc: <magic-dev AT csl DOT cornell.edu>
Sent: Sunday, September 28, 2003 3:22 PM
Subject: RE: Genericcontact
> Dear Charles,
>
> "genericcontact" is basically a stopgap solution to various contact
> problems in magic. In the "scmos" tech, there is hardly any information
> regarding genericcontact other than a drc width and spacing rule, which
> probably aren't valid for any technology. Thus, DRC for any layout
> containing genericcontact in the default scmos rules should not
> necessarily be trusted.
>
> In Jeff Sondeen's newer techfiles, the genericcontact has a more
> useful place. Namely, it covers situations where an input file may
> declare a contact cut, place it in a cell, then use this cell over
> (say) pdiff and ndiff, which would normally be illegal in magic.
>
> In both cases, however, it should be noted that genericcontact
> defines a contact *cut* instead of a contact area (the idea of a
> contact area representing both the cut and the layers it connects,
> called the "residues", is I believe unique to magic, and comes with
> its own benefits and drawbacks). So where a typical magic contact
> type will be 4 by 4 lambda, the generic contact will normally be
> 2 by 2 lambda and require a 1 lambda surrounding of the two
> residue types. This is true for the scmos techfile, but there are
> no defined DRC rules insisting upon an overlap of any layer with
> the genericcontact.
>
> The plane on which the contact is defined, called the "home plane",
> is another issue altogether. That was one of the primary targets of
> my 7.3 version of magic, which basically ignores the whole "home
> plane" concept except for some trivial internal record-keeping.
>
> There are probably a thousand subtleties to the whole generic
> contact/generic via story, but the main point to remember is that
> generic contacts and vias represent the cut only. One consequence
> is that a row or array of contacts, which can be represented with
> one rectangle using magic's "normal" contact types, requires a
> separate 2x2 rectangle of type "genericcontact" for each cut.
>
> I hope that clears up most of your confusion.
>
> Regards,
> Tim
|
|
|
|