[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: one schmatic ==> two netlist



> Thank's for the quick answer.

You're welcome.  Unfortunately, my answer wasn't particularly 
helpful or useful . . . . . 

> I need the Spice netlist not only for simulation, I need it also for LVS=20
> (Layout Versus Schmatic).=20
> I can create a Spice netlist from the IC Layout (even from the digital pa=
> rt).=20
> The usual way is to compare this with a netlist, created from the schmati=
> c=20
> editor.

I assume this is also known as "extracting the parasitics", i.e. after
you lay out the IC you can run a tool which creates a netlist with the
device connectivity, along with estimates of the parasitic
capacitances obtained by calculating the distance of the structures
from each other and from the substrate.  Right? 

And what you want to do is use gschem to capture the schematic & then
create a spice netlist from it to do the comparison with the netlist
extracted from the layout, right?

> I know, this sounds very complicated when you know the CAD flow for PCB=20
> design. I personaly moved one year ago from PCB to ASIC design and was=20
> shocked about this uncomfortable methode.

It may be a PITA, but OTOH, at least you do have tools available in
the ASIC world to handle parasitic capacitances.  In the world of
analog board design, you do your design as best you can & maybe add
some model stray caps at sensitive nodes in your circuit for
modeling.  But then when you fab your board, the best you can do is
pray that you got it right. . . .

> Never the less, if we find a solution to this problem with the device=20
> property, I can use gschem for my development.

Well, I am not the one to decide.  Nonetheless, I will make an
observation or three: 

*  Hierarchy is kind of primitive in gEDA right now, although we have
a developer who is making several advanced proposals about how to fix
it & has contributed some heavy-duty code.  Things may be in motion,
which bodes well for you.

*  Hierarchy is important, because it seems to me that if Verilog
modules are to be incorporated into gschem, then the best way to
name/designate the modules is related with the question of how to
handle hierarchy.  That is, Verilog designs are typically very
hierarchical & the way that the different modules are named, cataloged
and handled will be determined by how hierarchy in general is handled
in gschem.  

*  Currently, the only attribute which identifies to the netlister
what type of part each component is, is the "DEVICE" attribute.  IN
the future, a more sophistocated hierarchy handler will have one
attributes (or equivalent handles) available to deal with
distinguishing parts like resistors and transistors from abstract
blobs of logic.  However, this means that the current netlister will
need to be totally re-worked in order to handle the more generalized
set of attributes (or handles, or whatever) being introduced.

This all requires a certain amount of re-architecting in the area of
hierarchy, which might take some time.  Stay tuned, or get involved!

> Gruesse in die neue Welt
> Peter

Tschuess,

Stuart