|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Mon Feb 24 2003 - 12:09:52 EST
Dear Charles,
> 1. Can you point to some location for study about the recently added
> inductance extraction I read about on Tims web page. Perhaps a couple of
> commands or an example to allow further study.
This is still under development, so I haven't written up anything formal
about it. In brief: You need to get a copy of the "FastHenry" source code.
Magic doesn't actually do inductance extraction, which is extremely labor
intensive. What it does do is geometry extraction, which is dumped to a
file and which can be shoved into a field equation solver like FastHenry
to get an equivalent transmission-line circuit with inductors, capacitors,
and resistors.
Because field-equation solvers are slow, it is best only to extract the
geometry of interest (such as when you specifically design a spiral
inductor). The method undoubtedly requires a bit of playing around with,
but the steps are as follows:
1) Put the inductor layout in a separate subcell.
2) Surround the entire subcell with (internally-defined) layer "subcircuit".
3) Define the "ports" (input/output) of the inductor with labels, one
side of which should be coincident with the subcircuit layer boundary.
4) Extract ("extract all")
5) Write a .sim file netlist ("exttosim") (that's the Tcl-version variant
of "ext2sim")
6) Do "extresis geometry"
7) Do "extresis all"
8) Do "exttospice" (likewise, the Tcl-version variant of ext2spice)
What you get is very similar to the standard use of "extresis" (see the
extresis tutorial), except that where the "subcircuit" layer is defined,
you will get a file <cellname>.fh, which is a (hopefully valid) input
file for FastHenry. Using FastHenry (see the FastHenry manual; I can't
go into that much detail here), you can convert the .fh file to a SPICE
equivalent circuit.
The last "exttospice" step will produce the standard SPICE deck *except*
that the subcell with the "subcircuit" layer will become a subcircuit
call ("X..." record in the SPICE deck). At this point you should be
able to append the SPICE deck produced by FastHenry to the SPICE deck
produced by magic and simulate.
Note that this method (i.e., using the "subcircuit" layer) is generally
applicable to any situation in which magic is not expected to extract
a subcircuit, but for which a subcircuit exists. This would include
standard-cell designs (esp. analog standard cells) where a set of
device or circuit layouts has been manufactured, characterized
empirically, and a SPICE model produced to match the empirical data.
> 2. Is there any way to display the cursor's X,Y location as I work with a
> layout. I find knowing where I am, geometrically speaking is always very
> useful with any drawing package.
Yes. If you use "magic -w" (the GUI wrapper), the cursor's position is
always printed in the upper right-hand corner of the title bar. This
uses the magic command "box values" to grab the box coordinates.
It occurs to me though, that you probably want a real-time display of
the X11 cursor's position relative to the magic layout, not the
position of the magic cursor (i.e., the box). There is no way to get
the cursor (as opposed to the box) value in magic coordinates (as opposed
to window pixel coordinates). There is such a function (grx11GetCursorPos()
and friends), but no command-line command that calls it. It is trivial to
add one, so I will (check 7.2.26, to be posted shortly).
> 3. I see that with Magic 7.2 and its Tcl command window that the macro "g"
> for grid doesnt work anymore. It keeps wanting four arguments. I did find
> in ../command/CmdFl.c the CmdGrid function wanting a MagWindow first
> argument, but quite frankly I dont know what to tell it. An example would
> be appreciated.
My mistake. To avoid conflicts with internal Tcl/Tk commands, I renamed
a few of magic's commands. Because "grid" is the command for Tk's grid-
placement widget, I extended the command to "gridspace" in magic to avoid
conflict. However, I didn't change the command in the macro file. You
can fix it by changing ${CAD_HOME}/lib/magic/sys/.magic:
# G key
macro g "grid"
macro G "grid 2"
to:
# G key
macro g "gridspace"
macro G "gridspace 2"
Changes need to be made to magic/proto.magic in the source directory if
you don't want them overwritten on the next "make install-tcl". A fix
to this will also be in the version 7.2.26 posting.
About your comments on the Icarus Verilog-to-layout design flow:
> I did take a side trip with Electric a month or so ago, and although I
> can compile its automotive speed controller IC sample from source with
> its library and its silicon compiler and it even does load in cells from
> its version of the mosis library, place them in rows and connect them up,
> it is designed for VHDL and I am working in Verilog. So, that and the fact
> that Magic appears to be more prevalent then Electric has caused me to come
> back to Magic again. I have trouble believing that Electric can do something
> that Magic cannot do, rather, I suspect that my understanding of Magic is
> not complete enough yet.
Sadly, there are things which tools like Electric do which magic does not,
and good netlist place & route is one of them. I would suggest that this
is primarily due to the fact that development on magic slowed to a trickle
about the same time that most of the digital custom design world moved
on to VHDL/Verilog compiling. I think it's particularly unfortunate
that academia is where good research gets done on complex tasks like
place & route, and traditionally academia meshes well with open-source
development. According to the standard open-source software manifesto,
this is how the best solutions to the hardest problems get to the end-
user in the fastest possible way. I'm trying to put magic back on this
sort of development track.
Regards,
Tim
|
|
|
|