( ESNUG 427 Item 12 ) ------------------------------------------- [04/14/04]
Subject: ( ESNUG 422 #6 ) Silicon Canvas Rebutts The User Review Of Laker
> In general, it was difficult to import a Virtuoso netlist to Laker. One
> netlist in particular needed extensive hand-editing prior to exporting
> to Laker.
>
> - Art Gonzalez
> Advanced Micro Devices Austin, TX
From: Mark Strauss <mark=user domain=sicanvas spot calm>
Laker will import a circuit file, which is the CDL, or SPICE-like,
representation of the circuit. This file contains the circuit topology
from the top level circuit, down to the transistor level subcircuits.
Laker can handle up to 50 levels of hierarchy. This file can be generated
by hand, or from various schematic generator tools (ex. Cadence Composer,
ViewLogic ViewDraw, Cohesion AMS Designer, etc.).
This user seemed to have a lot of trouble with importing a "Virtuoso
netlist". I'm not sure what type of file that was, or if it was one listed
in the above description for the circuit files that Laker does recognize.
> 1. Create Map File
>
> A map file is a prerequisite prior to exporting a netlist from
> Virtuoso to Laker. This file is vital since it contains the
> mapping elements necessary for Laker to "recreate" the Virtuoso
> schematic and to be able to create a layout cellview. Depending
> on the number of different devices that need mapping, it can take
> a while to create the map file (from scratch) and to create it
> correctly. A generic map file could cover many devices in many
> different schematics.
The map file is used to convert the data found in the circuit file over to
(1) Laker Magic Cells for the layout representation of the circuit,
and
(2) Laker Symbols for the schematic representation of the circuit.
For each type of device defined in the circuit file (ex. x (instance),
m (transistor), r (resistor), c (capacitor), l (inductor), d (diode), and
q (bipolar)) there are two lines required in the map file, one to map the
device over to a Magic Cell, the other to map the device over to a symbol.
Given there are only a handful of device types in any given technology,
this file should be relatively easy to create. The user needs (1) the
circuit file to know which devices are used and (2) the Laker technology
file to know the name of the Magic Cell to map to. I'd like to find out
why he had such difficulty with this. And yes, a generic map file can be
made to cover many devices in many different schematics.
> 2. Unreadable Binary Netlist
>
> When Laker imports a Virtuoso netlist, it automatically creates a
> "binary" netlist which is non-readable. The user must export
> this binary netlist to create a readable CDL(Circuit Design
> Language)/SPICE netlist file.
I'm unsure of what the Virtuoso netlist was that he tried to import into
Laker. On the fly, Laker creates a schematic from the CDL netlist, the map
file, and the Laker technology file. The "readable" CDL/SPICE netlist
file that Laker exports is really just the netlist that was imported. The
imported netlist is considered the "golden" netlist.
> 3. Parameter Inheritance
>
> Laker cannot handle parameter inheritance!
>
> In Virtuoso, Parameter Inheritance is the hierarchical
> relationship between the parameters of a device at the current
> and lower levels. Basically, the parameters of a device are
> passed down or "inherited" to the lower level devices. Think of
> an inverter symbol that has length and width parameters. These
> parameters are inherited down to the pmos and nmos devices.
Laker handles parameter passing, where the parameters are listed/passed in
the CDL netlist. I'm not sure of the problem he was having here, but think
it may be due to the "Virtuoso" netlist he was trying to import.
> One schematic in particular used an inverter w/ parameter
> inheritance. In the netlist, this inverter was listed in the
> sub-circuit of another device. I had to manually add the
> parameter inheritance expressions to the inverter in the
> sub-circuit for Laker to recognize it!
>
> Graphically, in the schematic under this situation, the inverter
> symbol would be repesented by a "box" instead of the familiar
> inverter symbol.
Laker provides the user with the ability to generate symbols from a simple
.lib file (similar to a pared down version of a Synopsys .lib file).
The .lib file contains the names of the subcircuits, their functions (i.e.,
BOOLEAN Operation), Inputs, and Output pins. The reason this file is
needed is that the names of Inverters, NANDs, NORs, etc, are user defined,
and Laker would have no way of knowing which symbol to apply to
which subcircuit.
> 1. Device Hierarchy Problem
>
> The stick diagram will not generate devices with hierarchy. One
> must actually descend into the device symbol and select the
> "primitives" for stick diagram representation.
The stick diagram was targeted for transistor level design, not block level
floorplanning. Block level floorplanning can be accomplished just by
dragging/dropping the hierarchical instances from the design browser window
into the layout window. Flights lines, between the instances, are shown
in the layout window, so the user can move the instances around for
best placement.
> 2. 90-Degree Device Labels
>
> Reading 90 degree device labels on the gates was no fun. Perhaps
> Laker can have a pop-up window appear when the cursor is placed
> on a device. This pop-up window could list the device name
> horizontally.
Submitted to R&D as an enhancement request.
> 3. Unrealistic Device Abstracts
>
> The devices in the stick diagram are of the same width and length.
> Realistic abstracts with true width and length parameters would
> have been more helpful for floorplanning.
The idea behind the stick diagram is to allow the user to find the most
optimum floorplan for the transistors. The stick diagram is a higher level
abstract, thus, the widths/lengths are not the actual. The stick diagram
has a "preview" feature, which allows the users to see the actual layout
before realizing it.
If one wants to floorplan with the actual widths/lengths, then he/she can
go directly from the design browser to the actuals in the layout window,
without using the stick diagram. It's just a matter of changing a default
setting in the options table. And in both cases, Laker can set the most
optimum floorplan by turning on the "Automatic Transistor Chaining
and Placement function".
> 4. Device Flip Feature Requested
>
> It was frustrating not being able to flip (not "swap") a device
> from left-to-right and vice-versa since this feature is not
> available.
I'm not quite sure what you mean by "flip (not "swap"). Laker's "move"
will move an individual transistor to another place in the layout (i.e.,
to the left or the right of another transistor). Laker's "swap"
command will switch the Source/Drain nodes of an individual transistor.
> 5. Find Function Requested
>
> A device "find" function would also be very appreciated. I had
> to zoom in and scour the 90 degree labels on the devices to find
> my device of interest.
Submitted to R&D as an enhancement request.
> 6. Print Feature Requested
>
> There is no "print" feature. There were several times that I
> wanted to print my stick diagram floorplan but couldn't. I wound
> up using the "snapshot" feature of my Unix environment for
> printing.
Submitted to R&D as an enhancement request.
> 7. Cannot Delete Highlighted Net
>
> Highlighted nets won't delete when depressing F8.
Highlighted nets are cleared when F8 is depressed. I'm wondering if he
meant that flightlines aren't cleared when F8 is depressed. Clearing
flightlines can be accomplished by clicking in an open area of the layout.
> 8. Merge Gates Feature Requested
>
> There is a merge feature for devices but not for gates.
Although there is a merge feature for S/D in the stick diagram mode, there
isn't a "merge gate" feature. The reason is that actual widths are not
displayed in the stick diagram. There are merge features for both S/D and
gates in the layout window.
> 9. Unrealistic Wiring
>
> I know that the wiring connections in the stick diagram show
> connectivity to devices only and do not represent any particular
> metal layers; however, for floorplanning, being able to assign
> specific metal layers to the wires would be more realistic. When
> drawing stick diagrams with colored pencils, a layout designer
> will more than likely use different colors to represent different
> metal wires. Why not with the Stick Diagram Tool?
The stick diagram does not have the true dimensions in it, only relative
device placement. The "number of tracks" is a guide to show congestion.
As transistors are moved around in the stick diagram, the congestion
changes. The wiring, or tracks, shown in the stick diagram are not meant
to be editable by the user.
> After having worked with Cadence's Virtuosos XL software for a few weeks,
> I wonder if the Laker Stick Diagram tool is really necessary. The XL
> software will realize devices directly from the schematic to the layout
> cellview with the "Gen from Source" and "Pick from Schematic" features.
As mentioned above, the user can go directly from the schematic to the
layout cellview. It's just a matter of changing an option.
> C. Cell Template
>
> Cell Height
>
> I was trying to create a standard cell with a specific cell height.
> In the Cell Template form, Cell Height is not a user-defined field
> but rather the resultant of the summation of several parameters. It
> was really difficult to manipulate these parameters and to try to
> attain a specific cell height for my standard cell.
>
> A user-defined cell height would have allowed me to try and "tune"
> the parameters to meet my standard cell height.
As he mentioned, the cell height is not a user editable field. It is
equation based (i.e., summation of 7 individual parameters). As parameters
are tuned, clicking the "Apply" button recalculates the sum (which is
listed in the "Cell Height" field).
> D. Layout
>
> User-defined Fold Pattern
>
> Traditional device folding has the output in the middle and the
> inputs (i.e. vdd) on the outside. For example, a device folded once
> to create two stripes would have the output on the middle node and
> the inputs would be on the outside nodes.
>
> The Laker software has folded devices with the output node on the
> outside and the input node on the inside. User control over the
> fold pattern would be useful.
Laker's folding policy is based on left/right placement of transistor
source/drain regions, as these regions are interchangeable until actual
connections are made. When Laker folds a transistor, it puts the left
side S/D region of the full transistor into the center of the two
half-sized transistors. And of course, the right-side S/D of the full
transistor becomes the outer left/right S/D's of the two half-sized
transistors. With this in mind, the output nodes of folded transistors
can be set to become the center S/D region of the folded devices.
> E. Wire Routers
>
> Point-to-Point (PTP) Router
>
> This feature is really neat and a very strong feature for Laker!
> One defines source and target connections and the router will
> connect both points. Dependencies include user-defined criteria
> such as metal layer direction costs (horz or vert), design rules,
> etc. The user may use the fully automatic PTP mode or the semi-
> automatic mode for more control.
>
> This feature was especially appreciated at the big block level.
>
> For small cells, it was not very productive, especially when trying
> to connect multiple gates in poly. More often than not, there was
> no orderly placement of poly to connect the multiple gates which
> shot the frustration factor up quickly.
The PTP router is just that. It connects a first point to a second
point with user defined design rules, available layers, and cost
functions, in hand. It is not meant for connecting from one point to
multiple points at one time. Users should use the "Create Path"
feature to make multiple connections.
- Mark Strauss
Silicon Canvas, Inc. San Jose, CA
|
