Looking for references on layer color and patterns for layout.

Hi,
seems that every foundry has their own preferred colors and patterns
for layers in layout editors. I am looking for references to sources
of more information on the topic. I think every layouter has his/her
own favorite set of colors and patterns, but in the end we are all
bound by the choices done by our foundries. Anyhow, when reading gds
files into some of the free and open source gds viewers out there,
(layout, magic, electric) I have a great freedom of choosing my own
colors and patterns. When the metal stack becomes high as in modern
technologies, textbooks of the past (at least the ones I have) seems
to fail to give advice how to expand the layermap. I would be happy
for any advice where to look further.

 

Hi Svenn,

I must admit I'm having trouble understanding your post...

You say we are bound to the choices done by our foundries. Hopefully, not ! I guess, any decent
layout software should be customizable at least in this regard. All foundries I have worked with
include a "default" display scheme, but sometimes it's not far from a mockery - undistinguishable
patterns, some layers totally opaque, ugly bright colors, ... - It's a *must* to change them for the
sake of your own mental sanity


Stéphane

 

seems that every foundry has their own preferred colors and patterns

I believe you may be getting slightly confused here... If you go through
a foundry, they will most likely be able to supply you with a "pdk",
process design kit. That will contain DRC rules, LVS rules, a library
technology file, and possibly some sort of display file that contains your
colors.

The thing is, the foundry doesn't care what your colors look like. You
can have metal1 show up as a purple flashing outline with a yellow diamond
pattern if you want to, it doesn't matter. That is ONLY for the visual
benefit of the layout designer. What matters is how the layers are
defined in the technology file. For example, where I work, metal1 is
layer 15. I like using red for my metal1, my supervisor likes using
powder blue. However, when we stream out our data, the gds file simply
calls it layer 15. The colors are used only when the GUI layout tool is
used to display the layout.

That would be a function of the technology file. If you are drawing to a
process using up to metla4, your technology file will define layers up to
metal4. Drawing a 4 metal layer chip, using a technology file that only
has up to metal 3 defined can't be done.

 

As the other posters have eluded to, the display properties at your
facility vs. the foundry are up to you as they have no baring on the
streaming process and are completely arbitrary.

However, you should know where pertinent properties are held in
Cadence. Your tech file tells the software how to stream certain
layers. For instance, if metal1 streams out GDS layer 1, you probably
want to keep that the same so the foundry knows how to interpret your
layouts. Other files, called display resource files (.drf), tell your
system how to interpret those layers called out in your tech file.
This is where you should live to change your settings. These files
can either be modified by hand, or through the Cadence Display
Resource Editor GUI (LSW->Edit->Display Resource Editor).

In a .drf file, layer interpretation properties are defined for each
plotter that your system has (display, printers, etc.). Properties
include colors, stipples, outlines, line styles, as well of
combinations of those called 'packets' that define what you actually
see on your screen. The .drf files are fairly interpretable so
viewing one can be very insightful.

From my experience and research I have found that Cadence uses a
combination of .drf files to accomplish the job of displaying/plotting
your information. These files include (from Cadence Virtuoso 5.41):

The default.drf - $INSTALL_PATH/share/cdssetup/dfII/default.drf
The local display.drf - $INSTALL_PATH/dfII/lovcal/display.drf
and other custom system and user level .drf files.

In summary: feel free to edit your display resources

Hope that helps give you a little background,
Matt

 

Hi Stephane,

I see from the answers I got that I didn't describe my intention clear
enough. My "problem" is not tied to cadence tools only.

Let me try to elaborate:
If reading a book covering custom layout, the authors will use
different color and pattern schemes to illustrate well, diffusion,
poly and different metals. Googling on Lynn Conway (as in Mead and
Conway) give references to the lecture notes where the famous
expression (freely quoted) "where red crosses green, you have a
transistor" which shows up in many other VLSI courses. Now, that would
mean that red is poly and green is diffusion. Is this the general rule
across PDKs? The answer is NO. What are the general rules? The answer
is: There are generally none; each foundry has different color and
pattern scheme for their PDKs. Assigning a color and a pattern to a
particular layer is mostly fully customizable in modern tools. This
can be redefined by the user, but there is a default in the PDK. The
choise of color and pattern may have different reasons. I am looking
for these reasons: Why does poly have that particular color and that
particular pattern? How are the different colors and patterns for
metal and was there a reason for that particular color and that
particular patthern?

Layouters look at layouts most of their working time. Some colors and
patterns are more annoying than other colors and patterns. Just like
the font Times Roman is less suitable for writing code than courier,
blinking yellow is less pleasant than hashed red for poly. (confusion
with default warning in virtuoso schematic capture for example)

If I use the open source tool "layout" I am free to define whatever
color and some patterns for the gds layers. In electric there is a
technology editor function where I can define colors and patterns
freely, just like in cadence. I am looking for something like a least
common denominator for layer color and patterns among layouters. My
hope was that somebody had done some research on what color and
pattern fit best for a particular layer. It doesn't make sense if the
p-well has a filled solid yellow color that draw the attention away
from the lightly dotted pink poly and the hashed light green
diffusion. In typography things like size, font, kerning etc. is being
analyzed to make a text easily readable or to stand out or whatever.
Most VLSI textbooks do not use colors (they may have some pages with
color to show layout examples) so they use different shades of gray
and patterns to indicate which layer is which. Most textbooks do not
cover all layers used in production of semiconductors.

I am looking for a best-practise when it comes to selecting colors and
patterns. Feel free to list your favourite color/pattern stack for a
generic technology (unless it is covered by an NDA :- ). Since I
haven't been doing layout for weeks, I don't know the impact on
readibility when I choose a particular color and pattern.

The core of my search is: Find the best possible color/pattern
assignment for a technology stack independent of tools. (don't forget
to add favourite background color and grid shape/color)

 

The core of my search is: Find the best possible color/pattern

Now, it's much clearer.

The more I think about it, the more I find it an interesting topic. Essentially, the problem here is
that we are dealing with a 3-D structure on a 2-D medium. We need to make the 2-D representation as
intuitive and insightful as possible. In addition to showing the 3-D nature of the structure, we
also want to highlight "features", such as the combination of a specific set of layers.

I believe that the color allows to clearly separate layers (two layers with same pattern but
different color are easily separable, while the opposite is not so true), while patterns have an
effect on the visual prominency (dense pattern vs spare pattern), and on the way layers visually
interact with each other :
- complementary patterns, such as // and \\, result in a dense XX pattern when overlaid
- identical patterns, when overlaid, result in one (the topmost) hiding the other.
- spare patterns will be more transparent than dense patterns.

Also, different colors colors will have different interactions. A pure red pattern interlaced with a
pure green pattern will produce a very different color - yellow - while purple mixed with blue will
give a slightly different one - a brighter purple.

Finally, patterns may interfere. That is, produce a new feature when overlaid. In the example below,
the overlay of two similar patterns make a new pattern with horizontal lines - something that pops
to your eye.

* * * * * * * * *
* * + * * * = *****
* * * * * * * * *

Based on this, we can choose the display of layers to obtain the behavior that want. More elaborated
features could be useful, like variable transparency for example. Or, the ability to define layer
interactions - ie, happens when two specific layers overlap or abut.

Finding a coherent and insightful set of display parameters, especially with the large number of
layers in today's techologies, is however another story...


Stéphane

 

I noticed, when using layout (from layout.sourceforge.net) on a gds
that I streamed from virtuoso, that, unless the programmer takes
special care, edges of one layer may obscure edges of other layers
giving a less pleasant view. In my case this happened when a contact
was placed such that the edge of the metal lane on top of it
coincided. The contact was then showed as a square where one edge was
missing as the metal layer was one level higher in the z-stack of the
displaying widget. (Actually with >layout< this will happen if any
edge of layers with higher gds layer number is covering it) Also,

corner to corner inside a rectangular shape like I know it from
virtuoso. Naturally this is because >layout< does not really care what
the nature of a particular layer is.

Many new drawing widgets of modern toolkits (Swing, Qt) support
transparency. What I learned from the electric manual is that
postscript is not supporting transparency and hence electric does some
intermediate processing of the data in order to work around this. PDF
manage transparency, so this limitation in postscript is probably not
a really big problem for tools able to export directly to pdf for
documentation and printing purposes.