ic_layout_tool.html
Lots of people have talked about designing a VLSI tool set
(and later extending it to MEMs).
Here are some related snippets.
This file is of interest to people who want to write software
to help other people design VLSI and MEMs.
Check out
vlsi.html
which has information on designing VLSI and MEMs.
to_program.html
has other interesting unfinished software projects.
gEDA: IC/ASIC layout tool
Most of this discussion was on the gEDA mailing list,
which should be archived around
http://www.geda.seul.org/mailinglist/geda-dev.html
.
Magnus Danielson ,
on the gEDA mailing list, around 1999-10, said
* However, a layout editor a la MAGIC for gate arrays would be *
* coolness incarnate, useful, easier to maintain then an automatic *
* router, and would make the perfect starting point for such a *
* project.
From: "James Swonger" <jwsrh@hotmail.com>
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
Date: Tue, 19 Oct 1999 16:47:33 PDT
I've been wondering whether PCB (gPCB) could be extended to
make it serve both PCB and IC layout worlds. Really, any
polygon editor can be used for IC layout, if you're willing
to endure enough hassle (there are guys who use Autocad,
for instance).
What do you need for IC layout?
- many layers (minimum of about 16, typically >=64 support)
- polygon, path, {optional shapes}, cell, text, pin datatypes
- lots of hierarchy & data space capability (cells, arrays)
- libraries, search paths, library/instance/rep/revision instance
mastering, unique instance names
- standard format I/O (GDS-II)
I'd love to see somebody write a g{Tool} that used a clean,
open, readable data format and used UNIX filesystem type
library and instance naming.
I think that the basic polygon tool could be quite simple
and elegant.
LASI still fits on a single floppy; Electric (source
distribution) is under 6MB. If you haven't tried Electric
yet, you should, if only to see what you do and don't
like about what's probably the best integrated free IC
tool out there. I have some beefs with certain things,
but I'd rather you review it for yourself with an open
mind.
I think Electric could be extended/enhanced to be a quite
serviceable tool set, rather than having the community
try again from scratch, but I don't know how much rip-up
would be needed to implement some of the things I take
for granted in the tools I use.
>From: Derek Strembicke <strem@HiWAAY.net>
>Reply-To: geda-dev@geda.seul.org
>To: geda-dev@geda.seul.org
>Subject: gEDA: IC/ASIC layout tool
>Date: Tue, 19 Oct 1999 16:40:16 -0500 (CDT)
>
>Hi,
>
>I've been paying some attention to your gEDA project lately (and listening
>to the chatter). I am specifically interested in an IC/ASIC Layout
>utility...and yes i know the FAQ says you aren't going to develop
>it....unless someone steps up. First let me say that my particular skills
>lie in the area of IC/MEMS design...not programming. I have done some
>programming for imbedded systems so I know where the end of the very long
>rope starts. I have checked out the tools (Chipmunk, Magic) available for
>these purposes and have yet to be impressed (I will look at them closer).
>Anyways (enough blubbering), i am willing to at least attempt the task of
>writing a IC/ASIC layout tool...it won't go fast as i will need to learn
>alot. I like the stuff you have put out so far and would like it to be
>fully compatible with the gEDA project. Thus, what i need is some guidance
>on the database, parsing, file handling, and anything else anyone can
>offer to make this start happening.
>
>The goal (as i see it) is to produce a tool which will be capable of:
>
>1. Layout
>2. DRC
>3. Extract Netlist for simulation in spice tool ng_spice, spice3f5 (or
>like), or other circuit simulator
>4. Export to various formats for fabrication (GDSII and CIF)
>5. Layout vs. Schematic
>6. Cell place and route for gschem files and technology libraries
>7. Provide technology files from as many vendors as possible
>8. MEMS related simulations:
> a. Thermanalysis
> b. Electrostatic
> c. Magnetic
> d. Export structure for FEA analysis
> e. Etch simulation
>
>
>That's about it...alot of work i know but this is the tool i want and i
>don't see anyone developing it for me (or engineers like me) in the near
>future or for free.
>
>Is this something the gEDA project would be willing to help me with (ie.
>support....criticism....testing....criticism....)
>
>Derek Strembicke
>strem@ieee.org
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Date: Tue, 19 Oct 1999 20:20:59 -0400 (EDT)
From: Stephen Tell <tell@cs.unc.edu>
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
MIME-Version: 1.0
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
On Tue, 19 Oct 1999, Derek Strembicke wrote:
> Hi,
> I've been paying some attention to your gEDA project lately (and listening
> to the chatter). I am specifically interested in an IC/ASIC Layout
I'd like to suggest that you take a closer look at magic - it can handle
all of the important items you list except standard-cell place and
route, and the MEMs simulations.
To be fair, layout vs. schematic netlist comparison is handled externaly
too - we use gemini from the University of Washington for that.
Among the things magic does that none of the commercial VLSI tools do:
- all DRC is interactive, not batch-mode. Great for both learning and
serious layout.
- can easily light up connected nets; this is essential when you've got a
lot of layers
One thing that is missing from even our enhanced magic circuit extractor
<http://www.cs.unc.edu/~tell/dist.html> is accurate handling of sidewall
capacitance where there is close metal above or below.
Magic's abstract contacts and automatic well generation are a huge
time-saver for most applications. And before anyone tries to tell you
that portable, scalable layout is dead, we've found that a single
technology file can target most of the 0.25u and 0.18u processes of
interest today. There is a bit of a density penalty, but often its worth
it.
A good standard-cell place and route tool that read magic layout of
library cells, and produced magic files for the assembled array and
wiring, would be a very worthwhile project. I'd like to help out on if
time permits.
> The goal (as i see it) is to produce a tool which will be capable of:
>
> 1. Layout
> 2. DRC
> 3. Extract Netlist for simulation in spice tool ng_spice, spice3f5 (or
> like), or other circuit simulator
> 4. Export to various formats for fabrication (GDSII and CIF)
> 5. Layout vs. Schematic
> 6. Cell place and route for gschem files and technology libraries
> 7. Provide technology files from as many vendors as possible
> 8. MEMS related simulations:
> a. Thermanalysis
> b. Electrostatic
> c. Magnetic
> d. Export structure for FEA analysis
> e. Etch simulation
#7 is a problem - the information needed for creating usable techfiles is
usually proprietary to the fab houses, and available only under NDA.
Steve
--
Steve Tell | tell@cs.unc.edu | http://www.cs.unc.edu/~tell | KF4ZPF
Research Associate, Microelectronic Systems Laboratory
Computer Science Department, UNC@Chapel Hill. W:919-962-1845
From: Paul Bunyk <paul@pbunyk.physics.sunysb.edu>
Subject: Re: gEDA: IC/ASIC layout tool
To: geda-dev@geda.seul.org
Date: Wed, 20 Oct 1999 00:44:57 -0400 (EDT)
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
Operating System: Linux 2.2.12-20smp #1 SMP Mon Sep 27 10:34:45 EDT 1999
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello!
I was trying to accomplish the same... It seems the guys on the list
are too much focused on a formal VHDL->PCB route and do not care about ISIC
layout at all. I do, on the other hand, working with a weird technology
(superconductive IC in my case, MEMS in yours :) ). Let's get together and
do something (better than Magic :) ) at last!
Paul Bunyk
>
> Hi,
>
> I've been paying some attention to your gEDA project lately (and listening
> to the chatter). I am specifically interested in an IC/ASIC Layout
> utility...and yes i know the FAQ says you aren't going to develop
> it....unless someone steps up. First let me say that my particular skills
> lie in the area of IC/MEMS design...not programming. I have done some
> programming for imbedded systems so I know where the end of the very long
> rope starts. I have checked out the tools (Chipmunk, Magic) available for
> these purposes and have yet to be impressed (I will look at them closer).
> Anyways (enough blubbering), i am willing to at least attempt the task of
> writing a IC/ASIC layout tool...it won't go fast as i will need to learn
> alot. I like the stuff you have put out so far and would like it to be
> fully compatible with the gEDA project. Thus, what i need is some guidance
> on the database, parsing, file handling, and anything else anyone can
> offer to make this start happening.
>
> The goal (as i see it) is to produce a tool which will be capable of:
>
> 1. Layout
> 2. DRC
> 3. Extract Netlist for simulation in spice tool ng_spice, spice3f5 (or
> like), or other circuit simulator
> 4. Export to various formats for fabrication (GDSII and CIF)
> 5. Layout vs. Schematic
> 6. Cell place and route for gschem files and technology libraries
> 7. Provide technology files from as many vendors as possible
> 8. MEMS related simulations:
> a. Thermanalysis
> b. Electrostatic
> c. Magnetic
> d. Export structure for FEA analysis
> e. Etch simulation
>
>
> That's about it...alot of work i know but this is the tool i want and i
> don't see anyone developing it for me (or engineers like me) in the near
> future or for free.
>
> Is this something the gEDA project would be willing to help me with (ie.
> support....criticism....testing....criticism....)
>
> Derek Strembicke
> strem@ieee.org
>
>
Date: Wed, 20 Oct 1999 10:28:13 -0400
From: Thepthai Tabtieng <tabtieng@lsil.com>
Organization: LSI Corporation
X-Accept-Language: en
MIME-Version: 1.0
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
James Swonger wrote:
> What do you need for IC layout?
Here's from a point of view of standard cell designers (digital/mixed
signal IOs).
- A shape based editor.
- A runtime data structure that supports; device generation, flexible
drc constraint specication/encapsulation for device.
- Symbolic placement and routing of devices.
- Detailed shape based auto router.
- Layout compactors for compacting symbolic and post compacted layout.
- Integrated and batch DRC and LVS (good visual aid for errors, back
annotation and visual corespondence between layout and schematic would
be nice).
- Extraction for simulation.
- A convenient way (editor?) to specify fixed frame or background
architecture of the cell you are laying out.
LPM (Library of Parameterized Modules) is an EIA
standard like, and complimentary to, EDIF.
--
Steve Williams
X-Sender: strem@mail.hiwaay.net
Date: Wed, 20 Oct 1999 10:51:25 -0500
To: geda-dev@geda.seul.org
From: Derek Strembicke
Subject: Re: gEDA: IC/ASIC layout tool
Mime-Version: 1.0
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
I'm answering everyone at once....if i didn't answer your question directly
then it is probably because i think someone else also answered it.
Ok, first a little about me. Electrical Engineer with a MS in
Micromachining. This field is known as MicroElectroMechanical Systems
(MEMS) in North America, Microsystems in Europe I believe.
>1) What is MEMS?
Basically you take the same tools and processes used for creating IC's and
apply them to the fabrication of miniture mechanical structures. We are
talking about gears, motors, accelerometers, gyros, mirrors, beams, etc on
the scale of microns to 100's of microns. Some methods involve quite
'unique' process steps (LIGA) while other can be done in standard CMOS
process facilities (that's the type i do).
>2) Have you seen Electric? Alliance?
> It just could be a tool which is there but in bad need of a facelift.
I have looked or am looking at all the tools i can to get an idea of the
capabilities. Alliance yes but it does need a real facelift.
Electric...that one i haven't looked at yet....but i will now that a few
people have pointed it out.
>3) Have you gathered propper spec's for external formats?
External formats (GDSII and CIF i am assuming you are talking about). I
don't have the specs in front of me but they are a common exchange format
and i assume will be available. I wanted to check out how much interest
there would be first before taking anymore steps. As i mentioned i am not a
programmer and so this will take a significant effort for me to do...if no
one is interested than I can struggle on with the Windows tools i have
(TANNER) until my company can afford to buy a full-up UNIX system with
CADENCE (I dislike Mentor for historical reasons...once burned, never
yearned).
>4) Have you experience in IC/ASIC design, and with what. This is a control
> question just so that I know where I got you and what kind of experience
> that you got.
IC/ASIC is limited to that necessary to support MEMS structures. I am
currently working on both an analog interface and a digital interface for
small systems. No I don't have lots of experience in Very Large System
Design as you seem to...I did however teach the lab section on that course
in University.....My contribution will be best given in the area of MEMS
(obviously).
>I forsee several difficulties with the project:
>
>1) How do you get access to companies design rules. They are usually well
> protected.
I think the tanner and cadence models are best....that is, talk with the
vendors, point out the wisdom of allowing us to access their design rules
and create tech files for the processes. The NDA's still have to be signed
by the users and are NOT available just freely like the software (yup that
sounds ugly but they won't give that stuff away without NDA's). The point
is that most vendors are willing to make their tech files available freely
for anyone willing to buy silicon so long as the information doesn't become
public. They won't develop the stuff themselves but will allow others
(TANNER DOES this through thier CES department) to do so and give them
capability to provide users on the basis of an NDA. Note that TANNER
charges a hefty sum (in my eyes) for tech files and that just burns
me...like i said my company is small...we aren't going to buy a 50k cadence
software licence and a 5k tech file doesn't make the budget guy smile either.
>2) How do you get the tool accepted for sign-offs.
sign-offs by whom...software developers? Design Engineers? Fabs? I missed
the context of this question.
>3) How do you get the tool supplied with algorithms that "cut it".
With help. I really don't know. Maybe through the university system. As
mentioned by others, we need to get software programmers interested and
trained in the technical aspects...or more reasonably (I think)
appropriately skilled hardware designers interested in software EDA
support. I think if the word gets out we will find lots of interested
'expertise' capable of providing the mathmatical models. It could become
someones MSc of MENG projects....i think it could be a whole
course..probably already exists somewhere and we just need to find the
professor and convince him that developing the proper algorithms for
g would make an excellent course project. Second, the proper way to
design this system is to provide a series of algorithm types. The designer
choses the proper one, assigns the coeffient weights according to some
knowledge of the process, budget, etc).
>4) How do you avoid getting the tool to become yeat another tool which is
> close to useless outside some university framework.
That is what i am afraid of. I don't know the answer....it needs to be be
part of a suite of tools that can be used...hence why I want full
compatibility with gEDA. I don't see any other way. If you just want cheap
IC design go to MAGIC, LASI, or ELECTRIC....but they all are somewhat
limited (as far as i can see). I really want a full up tool with powerful
extensions (FEA, SPICE, LVS, THERM)...the industry needs this badly because
design iterations are too costly and too long....A tool which can
incorporate it all in one design pass (ok maybe two) will not just fade
into the background...and if its free and open, and source available, then
I, you, and anyone can tweak things for a particular
I'm glad there is interest. I will try to get together the preliminaries
and look closer at the other packages. Note: It's hard to go home after a
day of doing layout and DRC and run tests on packages you don't understand
but i think i can do it.
******************other responses**************
MAGIC: Yup i have seen magic and have even tried to fiddle with it a
little. My experience is that is will be a good starting point and a good
model...but, as was mentioned, it only goes so far before you have to use
other programs and doesn't have some of the nicer features such as
Place&Route. I think some of the ASIC people can tell you that on large
systems (not usually designed in university environments) this is not only
a niceity but a must have. I can't imagine laying out some of todays larger
die by hand. I work on small die (2mmx2mm up to 10mmx10mm) and find manual
layout to be an absolute waste of time....not to mention a huge money sink
if you are paying an experienced hardware design engineer a decent wage to
do that....AND it is prone to errors. Extract and LVS is a must as well for
obvious reasons. I want (and i KNOW others do to) this in one package of
tools instead of a pile of tools with questionable interoperability. gEDA
seems a good place to put it. If it's a matter of making
gMagic+gExtract+gLVS+gMEMS+gTHERM+gFEA+gPR+g<lotsa others> then i think
there is a huge market for it. Lotsa small/mid size companies who can't and
won't dole out the big bucks for Cadence or Mentor Graphics systems riding
on a 50k SUN box.
gPCB base: If the tools look and feel alike then that is all the better. I
hated Mentor for buying all those shitty little companies and packaging it
together in suite of tools which was completely unsimilar and unstable. I
don't know about anyone else but it is a huge effort to use tools for
designing a system when those tools don't feel the same....i want to be
able to concentrate on the design issues not on where the damn export or
runsim button is in a particular tool.
As for the techical requirement....I don't know yet. I was just fishing to
see if anyone else was interesting...it seems the answer is a YES! so i
will start gathering information. I haven't been involved in a development
like this before so if someone wants to email me personally and step me
throught the DO's/DON'TS and process i would be real happy to talk with them
By the way: It seems that gEDA is mostly a European effort....there may
therefore be few hour lag in response from me (actually at least 7hrs). I
am a Canadian working in Huntville, Alabama....U.S. Central Time Zone. I
work for a really really really small company doing mostly CMOS MEMS
projects for military applications.
Cheers
Derek
X-Originating-IP: [132.158.107.6]
From: "James Swonger"
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
Date: Wed, 20 Oct 1999 16:21:36 PDT
Mime-Version: 1.0
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
I think that the layout editor itself is much simpler
than this. The P&R, extractors (to SPICE, logic, or
other netlist forma) and netlist comparison tools are
things which act upon the layout database, but are
distinct from the layout editor in operation.
The overall job is probably unmanageable as a single
task, but the point tools are not - they would seem to
be individually doable.
I would suggest getting the layout editor and database
format working as the first priority, since all of the
other tools depend on this. The editor need not do it
all - only provide the polygon editing, hooks and
extensibility. This last item is the key to Cadence's
success; the editor and interface tools are puny
compared to the mountain of SKILL code that does
the manipulations and special functions, menus and
conversions, etc. Much of this SKILL code came back from
the user base, and users can customize their environment
extensively. If the layout editor can accept and emit
command line and menu button scripting then a lot of power
can be built up.
Since MAGIC has (per other posters) many of the point
tools already, it might be a viable platform. I know
it has several fundamental limitations (like rectangle-
only geometry constraints[?]); perhaps some extensions
to its data type handling and its user interface would
make it a more popular tool with less effort than a
scratch development.
Electric has some autorouting and logic simulation
capability. Its DRC facility is extremely limited,
and its connectivity extraction is dependent on using
a geometry (arc) which it does not re-create from
external data files properly. Its GDS I/O also neglects
the GDS datatype field, but this should be fixable
without much fuss (by somebody who can program, that is).
>From: Thepthai Tabtieng
>Reply-To: geda-dev@geda.seul.org
>To: geda-dev@geda.seul.org
>Subject: Re: gEDA: IC/ASIC layout tool
>Date: Wed, 20 Oct 1999 10:28:13 -0400
>
>James Swonger wrote:
>
> > What do you need for IC layout?
>
>Here's from a point of view of standard cell designers (digital/mixed
>signal IOs).
> - A shape based editor.
> - A runtime data structure that supports; device generation, flexible
>drc constraint specication/encapsulation for device.
> - Symbolic placement and routing of devices.
> - Detailed shape based auto router.
> - Layout compactors for compacting symbolic and post compacted layout.
> - Integrated and batch DRC and LVS (good visual aid for errors, back
>annotation and visual corespondence between layout and schematic would
>be nice).
> - Extraction for simulation.
> - A convenient way (editor?) to specify fixed frame or background
>architecture of the cell you are laying out.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Date: Thu, 21 Oct 1999 00:15:11 -0400 (EDT)
From: Stephen Tell
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
MIME-Version: 1.0
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
On Wed, 20 Oct 1999, James Swonger wrote:
> Since MAGIC has (per other posters) many of the point
> tools already, it might be a viable platform. I know
> it has several fundamental limitations (like rectangle-
> only geometry constraints[?]); perhaps some extensions
> to its data type handling and its user interface would
> make it a more popular tool with less effort than a
> scratch development.
The original paper on magic's "corner stitched tile" representation
speculates that it may be extensible from rectangles to trapezoids.
After rethinking and rewriting the database routines, I suspect that this
would involve rewriting the extractor and DRC subsystems too. How often
are non-manhattan geometries used these days anyways? (for normal CMOS; I
suspect MEMs may be different) Would extension to 45 degrees be
sufficient? The few times we've needed 45s, usualy in the corner of a
chip and once for some funky octagonal, we've just done one-lambda
stairsteps. As long as there aren't too many, it doesn't slow things down
too much. Aren't the mask-writing machines grid-based machines anyway?
Anyway, that reference is:
Corner Stitching: A Data-Structuring Technique for VLSI Layout Tools, J.
K. Osterhout, IEEE Transactions on Computer aided Design of Integrated
Circuits and Systems, volume Cad-3, number 1, January, 1984.
On the user interface front, I've been interested for a while in adding an
extension language to magic. After learning the keystrokes and interface
I'm mostly interested in adding advanced features that can access the
internal data structures. Most all of the scripting languages have gui
toolkit interfaces that could also be used to add a more modern user
interface to make it more attractive to new users. (Just don't break the
current one - it is very fast once you get used to it).
My impression is that simple mediocre place & route tools aren't too hard,
but that good ones take a lot of work. I saw a visiting professor write a
channel router in a weekend here once.
The place were hand-layout still shines is where you've got a lot of
repetition throught tiling of identical cells. There's a reason why a lot
of the chips we've done over the years at UNC are some sort of
logic-enhanced memory... The random control logic has been the weak part
of our design flows.
Has anyone used the standard-cell place & route parts of Alliance for
anything serious? When I looked at it about a year ago, the placement
faciltity especialy appeared rather lame, but I may have been missing
somthing important while setting it up.
--
Steve Tell | tell@cs.unc.edu | http://www.cs.unc.edu/~tell | KF4ZPF
Research Associate, Microelectronic Systems Laboratory
Computer Science Department, UNC@Chapel Hill. W:919-962-1845
Date: Thu, 21 Oct 1999 11:55:40 +0200 (MET DST)
From: Marcus Hagn
X-Sender: hag@cw057
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
MIME-Version: 1.0
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
...
> would involve rewriting the extractor and DRC subsystems too. How often
> are non-manhattan geometries used these days anyways? (for normal CMOS; I
> suspect MEMs may be different) Would extension to 45 degrees be
> sufficient? The few times we've needed 45s, usualy in the corner of a
> chip and once for some funky octagonal, we've just done one-lambda
> stairsteps. As long as there aren't too many, it doesn't slow things down
> too much. Aren't the mask-writing machines grid-based machines anyway?
I m doing "normal" CMOS analog cicuit design. I don t need arbitrary
shapes, but the 45 degrees is a must. i have them on nearly every
resistor and capacitor (especially if they have to match). having
only rectangles is definitly a show stopper.
just my 0.02 euro
--
Marcus Hagn Fraunhofer-Institute for
Phone: +49-9131-776-458 Integrated Circuits IIS-A
Fax: +49-9131-776-499 Am Weichselgarten 3
Mobile:+49-172-8722841 91058 Erlangen
Email: hagn@iis.fhg.de Germany
Date: Thu, 21 Oct 1999 10:00:57 -0400
From: Thepthai Tabtieng <tabtieng@lsil.com>
Organization: LSI Corporation
X-Accept-Language: en
MIME-Version: 1.0
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
Extensibility is the key. Also the choice of database structure is very
important. There are obviously many diverging interests in a project
like this and trying to be all things for all the people might be
impossible to accomplish. It is not hard to write a shape editor, but
to have the right infrastructure for doing LVS, DRC, extraction,
compaction, P&R, etc.. would not be easy. Maybe some of these tools
can be developed on the side and communicate through GDS, but for me,
integrated LVS, DRC and compaction is really desirable.
Here are some more thoughts about database:
- Could we use shape or polygon packages already available?
- Must have a nice boolean engine to do various shape processing.
- Must do complex polygon of various angles for MEMs application.
- Should we have connectivity information tied into the shape database?
(my answer to this one is Yes.)
James Swonger wrote:
>
> I think that the layout editor itself is much simpler
> than this. The P&R, extractors (to SPICE, logic, or
> other netlist forma) and netlist comparison tools are
> things which act upon the layout database, but are
> distinct from the layout editor in operation.
>
> The overall job is probably unmanageable as a single
> task, but the point tools are not - they would seem to
> be individually doable.
>
> I would suggest getting the layout editor and database
> format working as the first priority, since all of the
> other tools depend on this. The editor need not do it
> all - only provide the polygon editing, hooks and
> extensibility.
[snips...]
From: Paul Bunyk
MIME-Version: 1.0
Date: Thu, 21 Oct 1999 11:37:45 -0400 (EDT)
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
Hello, everybody!
I am interested in getting a g-Layout editor and was even thinking of
starting writing it. Thus, some thoughts...
James Swonger writes:
>
> I would suggest getting the layout editor and database
> format working as the first priority, since all of the
> other tools depend on this. The editor need not do it
> all - only provide the polygon editing, hooks and
> extensibility.
Agreed completely! And if we agree to live in Linux/modern UNIX world
we will have so many options to make the tools communicate efficiently
with the database and each other that we'll have hard time chosing
between them. For example, we probably can dynamically load a
procedure and start it as a pthread. ;-)
> This last item is the key to Cadence's
> success; the editor and interface tools are puny
> compared to the mountain of SKILL code that does
> the manipulations and special functions, menus and
> conversions, etc. Much of this SKILL code came back from
> the user base, and users can customize their environment
> extensively. If the layout editor can accept and emit
> command line and menu button scripting then a lot of power
> can be built up.
Yes, but have you tried porting SKILL code from 95A to 4.4.3
release of Cadence? I'm doing just that now and cursing Cadence, SKILL
and everyone around in the process... We are lucky we have Guile and
the license for GNU tools do not expire every year!
>
> Since MAGIC has (per other posters) many of the point
> tools already, it might be a viable platform. I know
> it has several fundamental limitations (like rectangle-
> only geometry constraints[?]);
Probably yes, and this immediately stops people working on the fringe
of VLSI technology from really using it. The guy who started this
thread is doing MEMS, try telling him he will not get arbitary-angle
lines... ;-)
> perhaps some extensions
> to its data type handling and its user interface would
> make it a more popular tool with less effort than a
> scratch development.
Speaking of a good foundation (or at least a source of ripping-off the
code and tools). I wonder why noone mentions Octtools suite from
Berkeley. Getting it was (when I played with it in early 90s) a bit
complex --- you had to sign a form that you are not going to export it
to "hostile" countries and pay $250 for a tape copy + manuals, but
many of the tools were also avalable separately (SIS, Espresso, etc.)
and at least their database 'Oct' and the layout/schematic editor
'vem' (which has one of the most convenient drawing interfaces IMHO
among all the tools I've seen) are avalable as part of Ptolemy package
which is definitely Open Source (either Public Domain or GPL).
On the other hand, I honestly believe that we should write the
database from scratch and then writing a GTK editor on top of that
would not be too much of a problem.
> Electric has some autorouting and logic simulation
> capability. Its DRC facility is extremely limited,
> and its connectivity extraction is dependent on using
> a geometry (arc) which it does not re-create from
> external data files properly. Its GDS I/O also neglects
> the GDS datatype field, but this should be fixable
> without much fuss (by somebody who can program, that is).
The main problem of Electric from my perspective is that it is too
much oriented towards "conventional" Si technology. You can not really
draw _shapes_ in layout editing mode, you can place elements
(transistors, vias, etc.) and connect them with arcs. Electric will
move those arcs for you (they are equivalent to lines on your
schematic) and for some technologies you just can not have enough
freedom to do that.
Later,
Paul
--
("`-''-/").___..--''"`-._ UNIX *is* user-friendly, he is just very
`6_ 6 ) `-. ( ).`-.__.`) picky about who his friends are...
(_Y_.)' ._ ) `._ `. ``-..-' Paul Bunyk, Research Scientist
_..`--'_..-_/ /--'_.' ,'art by (and part-time UN*X sysadm)
(il),-'' (li),' ((!.-' F. Lee http://pbunyk.physics.sunysb.edu/~paul
X-Originating-IP: [132.158.107.6]
From: "James Swonger"
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
Date: Thu, 21 Oct 1999 09:04:32 PDT
Mime-Version: 1.0
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
>From: Stephen Tell
>Reply-To: geda-dev@geda.seul.org
>To: geda-dev@geda.seul.org
>Subject: Re: gEDA: IC/ASIC layout tool
>Date: Thu, 21 Oct 1999 00:15:11 -0400 (EDT)
>
>The original paper on magic's "corner stitched tile" representation
>speculates that it may be extensible from rectangles to trapezoids.
>After rethinking and rewriting the database routines, I suspect that this
>would involve rewriting the extractor and DRC subsystems too. How often
>are non-manhattan geometries used these days anyways? (for normal CMOS; I
>suspect MEMs may be different) Would extension to 45 degrees be
>sufficient? The few times we've needed 45s, usualy in the corner of a
>chip and once for some funky octagonal, we've just done one-lambda
>stairsteps. As long as there aren't too many, it doesn't slow things down
>too much. Aren't the mask-writing machines grid-based machines anyway?
I use 45s extensively, and rounded geometries for things like
high voltage junctions (>150V), zener diodes, etc. In practice,
the Cadence tool converts the circles to 20-sided polygons
(N is specifiable).
The advantage of a native datatype, rather than a collection
of stepped rectangles, is that you can manipulate it better
(i.e. you can change its radius with one action, instead of
restretching and adding a bunch of rectangles).
Mask machines do quantize the data to your specified grid
(typical requirement is 1/2 the minimum grid used, and
litho processes tend to smooth anything small). If I'm
making a 20um oval, with a 0.25um spot size (1/2um grid),
that's 80 rectangles. Or one polygon with about maybe
half as many points... there's probably not that much
advantage in data volume, it's all about ease of data
manipulation.
I would have no objection to having, perhaps, a meta-
object layer that supported arbitrary shapes, but built
them out of a bunch of rectangles. I just don't want to
have to herd 40 rectangles by hand to make the shapes I
need.
Maybe a scripting language could handle the circles,
ellipses and polygon(N) features for objects. You could
have drawEllipse(), drawPolygon(), have the stretch commands
look at the object and invoke special stretch scripts when
they encounter the meta-shapes, etc. This would obviate the
rip-up of the existing data format, anyway.
Routing, though, really wants to be done with paths and
paths need to support (at least) octagonal routing for
maximum density of the final layout. I guess you could
make quasi-path routing with yet another feature, a 45-
degree line staircase generator. But this would really
pile on the data, all those little steps, where paths
don't care from angle, just connect the inflection points.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
From: "Kenneth Stephens"
To:
Subject: RE: gEDA: IC/ASIC layout tool
Date: Thu, 21 Oct 1999 10:28:03 -0700
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600
Importance: Normal
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
Databases are always a problem. Suggest that we choose an already defined
database format. Either EDIF or GenCAM. One that is well defined already
and extensible. I have seen many formats come and go. But, what is usually
left is a database that is in ASCII and is sort of human readable. These
last the longest. You programmers choose.
Just my $.02 US
Ken Stephens, President
CAD 2 CAM, Inc.
http://www.cad2cam.com
503-246-4692
Date: Thu, 21 Oct 1999 15:32:54 -0500
From: "Brad Martin P.E."
X-Accept-Language: en
MIME-Version: 1.0
To: geda-dev@geda.seul.org
Subject: Re: gEDA: IC/ASIC layout tool
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
All,
Paul Bunyk wrote:
>
> Hello, everybody!
>
> I am interested in getting a g-Layout editor and was even thinking of
> starting writing it. Thus, some thoughts...
> I wonder why noone mentions Octtools suite from Berkeley.
We worked with them a lot back in '91/'92. About a year's work for us.
1) We found the code to be very cryptic. They made a diligent attempt at
OOP in "C". Your mileage may vary, we kept getting lost in the code.
2) Abandoned by everybody. No community remaining. Dated technology.
We finally decided that it would be easier to start from scratch, but then
gave up the whole project. Not as hard core as the gEDA crew!
That's what happened in one shop (ours).
By the way, agreed on the 45s issue. Gotta have 'em. We heard a rumor a
few years ago that that DEC had internally extended the tool to do 45s.
It was definitely never released, if it ever existed. I'd love to know if
that was just a rumor. We just loved MAGIC, except for that Manhattan thing.
- Brad Martin
Content-Type: text/x-vcard; charset=us-ascii;
name="brad.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brad Martin P.E.
Content-Disposition: attachment;
filename="brad.vcf"
Attachment converted: root:brad.vcf (TEXT/ttxt) (0001B521)
X-Sender: strem@mail.hiwaay.net
Date: Thu, 21 Oct 1999 16:59:03 -0500
To: geda-dev@geda.seul.org
From: Derek Strembicke
Subject: RE: gEDA: IC/ASIC layout tool
Mime-Version: 1.0
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
I guess the same issues that are coming up with the XML discussion start
coming up here.
1. ASCII is nice (human readable), but for a large design (and we should
assume that this will be used in large design sometime in the future) then
the question becomes one of speed...parsing an ascii file? How fast is fast
enough? What is too slow?
The result is, I think, we should be able to export the files to EDIF or
GenCAM or CIF or GDSII....but we should make sure that we are optimized for
our tool performance rather than for a human reader (when is the last time
you printed out sheets of your 10k+ cell ASIC and checked the connections).
Are we going to be able to parse a large ascii database fast enough for a
large design?
(I really don't know I am asking the question)
2. I agree with going to a predefined database format. Specifically one
that can have all the hooks we may possibly need. It would be nice to have
a database that can store a wide number of attributes for a design tech
file (layer thickness, youngs modulus, capacitance, resistance, thermal
expansion coefficient) AND that allows the tools to pick out only the
attributes relavent to that tool (ie. a layout tool doesn't want the youngs
modulus so it has to be able to ignore that). The experienced programmers
should be able to tell us what to do here....the EE's just need to ensure
they know what we are looking for.
It may be better to have separate tech databases for layout and simulation
tools(?)
What are our choices on databases?
3. We (i use this term loosely) want a tool that can do ALL-ANGLE, ARC,
CIRCLE, and Curves (that's the jist of the letters). Someone will want to
use it..even if they are on the fringe. I particularly like the reference
to 'herding rectangles', that is one of the reasons why I stayed away from
MAGIC. Obviously mask tools are varied and can change. A stepped square
spot by mask maker X may turn into a oval spot with with a vector by mask
make Y or someone else making use of interference effects....technology
will move, I think we best keep as much capability at the foundation of
this as we can.
4. Modularization. It makes sense to divide the tool set into individual
modules capable of reading and working from a standard database. MAGICS
ability to do interactive DRC is wonderful (I recall Cadence had this as
well). What modules do we want? I know my list but we should start small
and add later.
First things first. Layout Editor....everyone says its easy to make a
polygon editor so....lets move towards deciding on a database that can
handle what we are looking for.
What are the requirements?
***************************************
Derek Strembicke
LSI/MEMS Design Engineer
strem@ieee.org
I don't suffer from stress....
.... I'm a carrier!
****************************************
To: geda-dev@geda.seul.org, strem@hiwaay.net
Subject: RE: gEDA: IC/ASIC layout tool
Mime-Version: 1.0
Date: Fri, 22 Oct 1999 01:22:46 +0200
From: Magnus Danielson
X-Dispatcher: imput version 991007(IM132)
Lines: 51
Sender: owner-geda-dev@geda.seul.org
Reply-To: geda-dev@geda.seul.org
X-To-Get-Off-This-List: mail majordomo@geda.seul.org, body unsubscribe geda-dev
Status: U
From: Derek Strembicke
Subject: RE: gEDA: IC/ASIC layout tool
Date: Thu, 21 Oct 1999 16:59:03 -0500
> I guess the same issues that are coming up with the XML discussion start
> coming up here.
>
> 1. ASCII is nice (human readable), but for a large design (and we should
> assume that this will be used in large design sometime in the future) then
> the question becomes one of speed...parsing an ascii file? How fast is fast
> enough? What is too slow?
>
> The result is, I think, we should be able to export the files to EDIF or
> GenCAM or CIF or GDSII....but we should make sure that we are optimized for
> our tool performance rather than for a human reader (when is the last time
> you printed out sheets of your 10k+ cell ASIC and checked the connections).
>
> Are we going to be able to parse a large ascii database fast enough for a
> large design?
> (I really don't know I am asking the question)
There are several things that can make ASCII files pretty parseable:
1) Simple gramar and lexical rules.
If the file has simple gramar and lexical rules, then may fairly simple
parsing be done. If one can avoid look aheads by provide forward information
(just as we do in digital formats) speed can be very quick and the state
held at parsing pretty low. Both lexical and gramar complexity exports into
CPU time and memory consumption.
2) Avoid expensive conversions.
This really means conversion of data should not be in formats like IEEE 754
floating point, large integers are better for bulk data. However, one can
create a semi-binary format (like base-64) in order to store floats in a
quick format.
3) Grease up the surrounding libs.
Just parsing an file isn't enought. Allocating and building the internal
structure can blow up in the face. The internal representation and the
routines to handle it needs to be pretty slim.
Personally I think that ASCII format should not need to be much worse than
binary since the internal structure stuff will eat time to. Both XML, EDIF
and others are unecessary complex to parse. I would say that this goes for
geda in general, not just the ASIC tools.
Cheers,
Magnus
To: geda-dev@geda.seul.org
Subject: Re: gEDA: XML Stuff
Date: Fri, 22 Oct 1999 20:56:54 -0400
From: Braddock Gaskill
...
For size, XML files can always be compressed with gzip.
For speed AND size, it would be easy to create a "compiled" XML format,
where common ASCII tags are replaced with byte-codes; floats and
integers are represented binary; and maybe throw a reference lookup table
at the end (like PDF does). The STRUCTURE of XML would be preserved, and
it would be trivial to convert back and forth.
So for starters, develop with normal XML. If speed or size becomes a
problem, we can easily fix it with the above solutions.
-Braddock
ic_layout_tool.html