[Top][All Lists]
[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.
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, address@hidden, 2012/05/05
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing,
al davis <=
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, John Griessen, 2012/05/06
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, address@hidden, 2012/05/15
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, al davis, 2012/05/16
- [Gnucap-devel] collapsing nodes. was: Re: Summer of code: Gschem analysis for parsing, Felix Salfelder, 2012/05/17
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, address@hidden, 2012/05/23
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, al davis, 2012/05/23
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, address@hidden, 2012/05/25
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, al davis, 2012/05/23
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, address@hidden, 2012/05/25
- Re: [Gnucap-devel] Summer of code: Gschem analysis for parsing, al davis, 2012/05/25