gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing


From: al davis
Subject: Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing
Date: Sat, 5 May 2012 18:06:22 -0400
User-agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )

Good start .. but it is time to put spice behind.

Gnucap's preferred netlist format is Verilog, as read by 
lang_verilog.cc. ..

resistor #(.r(10k)) r12 (.p(3), .n(2));

The spice format is too irregular.  Different devices have 
different syntax, it cannot be extended cleanly, it doesn't 
handle different views such as where a "net" or pcb trace is a 
first class object.

The verilog format is consistent, and that makes your job a lot 
easier.

On Friday 04 May 2012, address@hidden wrote:
> As far as my understanding goes in order to get netlist from
> schematic files of gschem, it is required to
> get a list of all components in the circuit and their
> attributes. The required attributes include
> 1. 'refdes' (which can be generated automatically if missing)

I suppose, but don't they all have a refdes?

> 2. 'value' in case of passive components like resistors,
> capacitors etc.

The 'value' concept is not meaningful in general.  geda/spice 
uses 'value' as a string containing all of the parameters or 
whatever, just passed on as a string.  That doesn't work for 
other formats like Verilog, VHDL, Spectre, Qucs ..  

Instead there are parameters, name=value pairs.  Even a resistor 
can have more than just resistance.  There is temperature 
coefficient, tolerance, power rating, capacitance, inductance, 
and more.  I can't, you can't, list them all in general.  
Rather, support the syntax and pass it on.

> 3. 'model-name' for a active components like
> transistors, diodes and other models.
> In some cases, value attribute can also contain the model
> name of active components
> (Eg: value=2N3904 for a transistor)

'model-name' is really a type, like 'resistor'.  Every device 
would have something like that.  

> After getting the model name, in order to use in the
> analysis, the parameters of models are needed.
> Does this mean that the models should be stored?  (loaded as
> plugins?)

The same device has different views depending on what you are 
doing.  It has symbols for schematic, footprints for layout, 
models (subckt, model, module, whatever) for simulation.  You 
might want different models depending on what you are doing 
today.  Preliminary pre-layout simulation ignoring parasitics?  
How about post-layout simulation with IBIS models, where the 
nets are first class objects?

> Also, what can be done in case of missing
> component values? Use some default values?

For what you are doing, nothing, just pass it on.  Some devices 
have default values, but you can't know that  in general.  You 
can't code for it.

> After getting all the components, nets in schematics can be
> analysed to connect the components
> accordingly .i.e, creating nodes in the circuit.

That part is done.

I have some notes on translation here:

http://gnucap.org/dokuwiki/doku.php?id=gnucap:user:netlist_import_and_export

You should begin here.  Study it and understand it.  See if you 
can manually make an augmented netlist in Verilog format that 
includes schematic position data.  Ask about whatever parts are 
not clear.

After you understand that, then look at the gschem format and 
figure out how to map back and forth between them.  Don't worry 
if it seems to take a lot of effort to study it.  I think the 
most difficult part will be establishing connnectivity.   Once 
you understand the mapping, coding should be easy.

To see how to code it, look at lang_verilog.cc.

When I say "coding should be easy" .. that is normal in software 
development.  It is tempting to move quickly to the coding 
phase, but it is not a good idea.  Analysis and truly 
understanding the problem takes MUCH more time than writing the 
code.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]