Re: Inconsistencies with Electric v6.07??? ....

[Steven Rubin]

> 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).
>
> 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?

The problem is caused by your use of the "saving options with 
libraries".  Some of it is Electric's fault, and I will try to clean that 
up, but some of it is "correct behavior" on Electric's part.

You probably understand this, but I will explain a bit of it as background...

"Options" are bits of state in Electric.  The process of saving a library 
takes all state with it.  Thus, in the absense of any "cleverness" on the 
part of Electric, each library that gets written would contain the entire 
state of the system at that time, and each library that gets read-in would 
overwrite all options and set them to the state that they were in when the 
library was written.

To make options work as people would expect, Electric "removes" all options 
from memory before a write, and restores them after the write.  This makes 
the libraries pure so that it does not affect options when read back 
in.  To actually save options, Electric writes a dummy library (with no 
facets) when you quit, and reads it back when you start-up.  This library, 
called ".electricoptions.elib" or something like that (varies with each 
platform) has all of your options.

To make things more complicated, Electric offers the ability to "save 
options with libraries".  It tells the system that certain options should 
NOT be removed before writing a library.  Thus, the state of these options 
at the time that you do a "save" will be reinstated when you read that library.

Now to your problem.  Since you requested that the design rules be saved 
with the libraries, the state of these rules is overwritten when you read 
the library.  Even if you made a change to the rules and can see that they 
are valid when you restart Electric, those rules get reset when you read 
that library with state in it.  The fix is easy: make the change to the 
rules and then save the library again.

The problem with the dual-poly technology options is a bit more complex...

Since most options do not get saved with the libraries, it is possible that 
a user may create a design with certain technology options, and another 
user will read that library with different technology options.  This would 
be a much more serious problem than a simple option-clash because having 
different technology options may cause the entire circuit to be 
incorrect.  To get around this, Electric saves the technology options with 
every library, regardless of requests by the user.  When a library is read 
that has different technology options, the user is informed and asked if 
the new options should be used.  The bug in Electric here is that you have 
already saved these options with the library, so the system doesn't notice 
that you have made a change.  The workaround is to stop saving the 
"technology options" with your students' libraries.  Then the right effect 
will be achieved.

> 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*).

There is no connection between the facets in the library and the simulation 
engine that is used.  I have no explanation for the phenomena that you are 
reporting.  If you want to send an example of this, I will look into it 
further.  You should send a SMALL library and instructions for repeating 
the problem.

> 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]

Again, you can send a simple example of this and I will look at it.  The 
SPICE netlister is actively being worked-on right now (not by me) and 
problems such as this can be handled.  I suspect that it is a bug in the 
definition of the BiCMOS transistors.  This technology is rarely used.

> 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).

It isn't the SPICE parts that is changing the value of lambda, it is your 
use of a load transistor.  You picked a "schematics" transistor.  You 
should have placed a "bicmos" transistor.

Electric has different technologies, and each has a value of 
"lambda".  Lambda is that famous "scalability" factor used to make IC 
layouts process-independent.  Unfortunately, even nonlayout technologies 
(such as "schematics") have values of lambda, and this causes 
problems.  When a SPICE deck is written, the current value of lambda is 
used to determine the actual size of all components in the deck.  The size 
of lambda is taken from the technology that is current, and since you have 
components from the schematic technology, that becomes the current 
technology, and its lambda value is used.  One workaround is, as I said, to 
place components from the desired technology in this top-level 
facet.  Another workaround is to change the value of lambda in the 
schematics technology so that it matches that of your layout technology.

> 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?

Once again, the "current technology" is important here.  When you created 
the test-jig, you made it of type "{sch}" and that is not necessary or even 
correct (you can place the SPICE components in a layout).  In any case, if 
there are schematics components in the menu on the left (and the current 
technology is "schematics"), then the SPICE netlister is not going to 
bother examining the areas of each wire because it presumes that they are 
"sticks" with no area.  Make sure that the right technology is in effect 
before writing the SPICE deck.

Good luck with your course.

   -Steven Rubin