Inconsistencies with Electric v6.07??? ....

[Todd Hochwitz]

Steve:

First, I'd like to thank you for providing an excellent software package
for teaching IC design.  I used Electric v6.04 as the layout package for an
analog VLSI class I taught nearly two years ago, and the students were able
to successfully create op amps, mixers, and noise sources for fabrication
through MOSIS.  We did encounter a few "features" we had to work around,
but they were minor.

I was asked to teach an introductory digital VLSI course again this spring,
and decided to drop Magic for Electric v6.07.  I've been spending the past
couple of weeks using the latest version of Electric, and have noticed some
(potentially) inconsistent behavior.

A disclaimer -- so far I've been working from my past experience with
v6.04.  I notice you've expanded the manual with more information, but I
haven't taken the time to fully RTFM.  Perhaps some of my observations will
be discussed in the manual -- if so, just say so and I can look for the
answer myself.  But my gut tells me that some of the observations aren't
going to be found in the user's manual.

Some background info about the build and operating environment:  I obtained
both source files from your web site, compiled the ElectricSFS project with
Microsoft Visual Studio 6.0 Service Pack 6 on a machine running Windows
2000 Service Pack 3.  The code was compiled with support for LISP and
IRSIM, but no support for TCL nor Java.  I've been running Electric v6.07
on three separate systems between the university and the home office, all
running Windows 2000 SP3.

In order to simplify my life, I will be providing the students with a
library file containing all relevant DRC, SPICE, IRSIM, pad and padframe
info/facets.  So my first step was to load up Electric and make sure the
following options were configured to save important options with the
library file:

FILE: Library Options
FILE: CIF Options
FILE: GDS Options
FILE: DEF Options
WINDOWS: Text Options
TECHNOLOGY: Technology Options
TECHNOLOGY: Technology Units
TOOLS: DRC Options
TOOLS: DRC Rules
TOOLS: Simulation Options
TOOLS: Spice Options

By having all of the option settings saved with the libraries, I am
somewhat confident that the students at least start out with a common pad
frame library (which some of them will invariably mess up -- that is what
students do, I guess).

The target process for the digital class is the same as that for the analog
class -- the AMI SCNA/SCNE process through MOSIS (two metal layers, two
poly layers, NPN, poly cap, lambda=0.8 microns).  I modified the CIF/GDS
I/O parameters to match the latest list from MOSIS, I extracted some of the
DRC rules I'd added to the BiCMOS library in v6.04, created one library for
BiCMOS and one for the MOCMOS process, and then started to try and "design"
with each library (BiCMOS and MOCMOS).

Based upon the setup just described, I have observed:


Loading a modified MOCMOS Library
=================================

That led to my first discovery.  After makng sure that the MOCMOS
technology options were set correctly (2 metal layers, second poly, no
stacked vias, updated the DRC rules, imported GDS of the padframe) I saved
the library to disk.  Then I quit Electric, started back up, and loaded in
the modified MOCMOS library.  The top padframe facet displayed on the
screen, but the palette of MOCMOS components on the left pane did not
reflect the second poly layer nor the limit of two metal layers -- the
palette had four metal layers and single poly.  I checked the Technology
options, and it listed two metal layers and two poly layers.  I then
selected Change Current Technology, MOCMOS was indeed highlighted, and
clicked OK -- lo and behold, when the dialog disappeared the Component
Palette was now updated.

OK ... then I quit Electric, started Electric, and loaded in my BiCMOS
library.  When the library was loaded in, the top level padframe was
displayed and the Component palette was switched to BiCMOS.

Ah ha!  I then quit Electric, started again, changed the technology to
something else (I tried BiCMOS, CMOS, NMOS, Generic, Schematic Analog),
loaded in my MOCMOS library -- the Component palette didn't change.  So it
would appear that when a library is stored with the MOCMOS technology
selected, Electric doesn't automatically update the settings.  Is there a
way around this behavior?

Related to this -- I can NOT get Electric to accept changes to the DRC
rules for MOCMOS process.  I've tried twice to modify some of the settings,
double check them before saving the library, but whenever I load the MOCMOS
library the "old" values are in use.  I've had no problems with the BiCMOS
library nor a MOCMOSSUB test library -- both of those save and update the
modified DRC rules correctly.  Again -- is this a feature of Electric that
can be modified from an option setting somewhere?


Digital Simulator
=================

Next, I decided to "ignore" the problems with MOCMOS, and try to
create/test a simple CMOS inverter with the BiCMOS technology.  So I
created a new layout facet with the BiCMOS technology, placed an NMOS and
PMOS transistor, connected as inverter, created a POWER export called Vdd
for the source of the PMOS, created a GROUND export called GND for the
source of the NMOS, created an INPUT export for the shared gates called IN,
and created an OUTPUT export for the shared drains called OUT.  I started
up the digital simulator, selected the IN signal, toggled H and L, got the
output to work properly -- nice.  But I noticed that the rise/fall times
were uniform -- shouldn't have been, since the NMOS and PMOS devices were
sized identically (3/2).

So I looked at the built in simulator options, saw it was set to ALS -- ah
ha!  I changed to IRSIM, closed the simulator window, and tried to
re-simulate.  The ALS simulator window was brought up again.  I checked the
simulator settings, still said IRSIM.  So I saved the library, quit,
started Electric again, loaded the library, checked the simulate settings
-- IRSIM was selected, tried to simulate, and the ALS window opened.

I then looked at the facet list, noticed the various ALS related facets. 
Deleted them, opened up the simulator, and NOW the simulator window opened
with IRSIM as the simulation environment.

Does Electric use the ALS/IRSIM setting only if there aren't ALS facets in
the library?  I have a concern that when one of my students accidently
switches to ALS, (s)he won't be able to get back to IRSIM until they track
me down and ask why (and yes, it will happen this semester *grin*).


Incomplete SPICE parasitics Part 1
==================================

OK, figured out that little feature.  So I next turned my attention to the
SPICE output.  Still using the BiCMOS technology.  I configured the SPICE
tool options to use parasitics, made sure the various cap/resistor values
for the layer matched nominal settings from MOSIS, used the SPICE3 engine
with Level 3 transistors, and told Electric to get the SPICE models from an
external file.  I wrote out the SPICE file, loaded with a text editor, and
examined.  I saw a problem I had noticed with v6.04 -- Electric extracted
the area and perimeter information for the NMOS transistor, but nothing for
the PMOS transistor.  And no capacitance information for the M1 layer was
extracted.  [Not to get ahead of myself, but since the area/perimeter
information is generated for both NMOS and PMOS devices with the MOCMOS
technology and the M1 capacitance is computed, seems like an error in the
BiCMOS code]

Since the bulk of the student work will be done with IRSIM, I wasn't too
disappointed with lack of area/perimeter information.

I then created a new facet inv2{lay}, placed two instances of the inv{lay},
connected the Vdd exports together with M1, connected the Gnd exports
together with M1, connected the OUT export of one inverter to the IN export
of the other, and made two new M1 traces for an input to the first inv{lay}
instance and an output from the second inv{lay} instance.  Then created the
appropriate POWER/GROUND/INPUT/OUTPUT exports for the new inv2{lay} facet,
wrote out the SPICE deck, examined with a text editor.  Good news -- the
inv{lay} was placed as a sub circuit in the file, with the NMOS transistor
area/perimeter written out and same values as my previous test, and two
instances were called out in the SPICE code.  Perfect.

So I next decided to create a test facet for the pair of inverters.


Magically Mutating Lambda
=========================

I like to split my designs into the "real" facets and a higher level "test"
facet.  I'll place some standard SPICE parts, and then connect the parts to
different instances of the layout, write SPICE deck, and simulate.

So I made a new facet, schematic, called test_inv2{sch}, and changed the
technology to schematic, analog.  I placed an instance of the inv2{lay}
facet on the page, and then went to select a SPICE DC source.  Placed it,
connected between the IN and GND exports of the inv2{lay} instance -- no
problems.  Then added another DC voltage supply between the Vdd and GND
exports -- no problems.  Added a transistor load for the output of
inv2{lay}, and then wrote out the SPICE deck.

All looked good.  Until I took a closer look at the transistor
widths/lengths.  When I wrote out the SPICE decks from inv{lay} and
inv2{lay}, the 3/2 lambda widths/lengths were written as 2.4u and 1.6u --
correct for the lambda of 0.8.  But now Electric had written the
widths/lengths as 6u by 4u.  Huh?  I looked at the technology units, and
all of the values had changed on me.

So I started over.  Quit Electric, started again, loaded my library,
checked the units -- lambda was indeed 0.8.  This time, I noticed that as
soon as I selected the SPICE component a window with a progress bar
appeared for a moment on the screen.  Hmmmm ... checked the technology
units settings, and they had all changed on me!

I looked in the lib folder, and saw readable dumps for the SPICE parts.  On
a hunch, I opened the files.  And I saw several lines with techname: xxx
lambda: yyy.  And the lambda values corresponded to the post-SPICE part
selection values.  Ah ha!  So I removed those lines from the SPICE parts
files, tried again.  This time, it worked correctly.  And the transistor
sizes/area/perimeter settings were consistent with inv{lay} (at least for
the NMOS transistor -- PMOS transistor only had W and L, no area/perimeter).

So, it would be nice to warn the user that loading a SPICE part will
override the technology units.  Or distribute versions of the SPICE parts
libraries that don't contain techname: xxx lambda: yyy settings (I also
found those lines in other txt files, and removed them for my installation).


Incomplete SPICE parasitics Part 2
==================================

I next decided to try the inverter test with the MOCMOS technology.  So I
loaded my MOCMOS library, created a test CMOS inverter with the same
exports as I had done with the BiCMOS technology.  And this time I was
pleasantly surprised to discover that Electric wrote out the area and
perimeter information for both the NMOS and PMOS devices.  Plus the M1
capacitance information.

Wow.

So I created the inv2{lay} facet, placed two inv{lay} instances, connected
inv{lay} exports as mentioned above, created new exports for the inv2{lay}
facet, and wrote out a new SPICE deck.  Again, all of the NMOS/PMOS
dimensions and parasitics were written as part of a sub-circuit, and the
new M1 capacitances for the inv2{lay} were added.

Sweet.

Then I created the test_inv2{sch} facet, placed the instance of the
inv2{lay} facet, hooked up the SPICE parts as I had done with the BiCMOS
technology, checked to make sure that the lambda setting wasn't changed,
and wrote out the SPICE deck.

Huh?

All of the area/perimeter information was missing from the transistors
(although the width and length information was still present), and the
parasitic capacitances of the M1 layers were gone.

OK ... maybe Electric doesn't like mixing MOCMOS with other technologies. 
I can live with that.

But just for the heck of it, I descended into the inv2{lay} facet and tried
writing the SPICE deck again.  This time, Electric did not write out the
area/perimeter information, nor the M1 capacitances.  What?  So I descended
into inv{lay}, and same thing -- the SPICE deck was no longer the same as
the one I wrote before adding the SPICE parts.  I removed the
test_inv2{sch} facet, and tried again.  Still no area/perimeter/capacitance
information.

So I decided to try the process again.

After creating inv{lay}, the SPICE listing includes
area/perimeter/capacitance information.  After creating inv2{lay}, the
SPICE listing still includes area/perimeter/capacitance information.  But
as soon as I place a SPICE part, the area/perimeter/capacitance information
disappears from the SPICE output.  And for good measure, I did the test a
third time.  Same "failure."  Even though the "use parasitics" setting was
checked, and values were provided for layer capacitance/resistance.

Is there another setting that is being re-set by the SPICE parts?


Well ... I think that concludes my present set of observations.  Yes, I
know -- lengthy.  But I figured that if I had discovered some
inconsistency, the information might help you.

Thanks again for the software, and any information/pointers you can provide.


Todd Hochwitz

www.technical-mandala.com
address@hidden
Phone: (307) 755-1032
Fax: (509) 753-6337

Technical Mandala
1402 Ord St.
Laramie, WY 82070-4762