[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: |
Wed, 23 May 2012 13:56:22 -0400 |
User-agent: |
KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; ) |
On Tuesday 22 May 2012, address@hidden wrote:
> > In gschem, it has been considered normal to use a different
> > schematic for layout or simulation, and maybe even
> > different for different simulators. There really should
> > be types for attributes, some attributes are for
> > simulation, some for layout, etc. Mark them some way,
> > perhaps with a prefix character like "." or "_". Or ..
> > just pass them on and make the target ignore any
> > parameters it doesn't like?
>
> OK. So, parameters not required for simulation need to be
> marked and ignored when parsing.
Ultimately you really need to pass them on so they can be passed
back. That means that the models need a way to deal with
parameters that are merely being passed through.
But for now, don't worry about it. One thing at a time.
> > One nuisance point I just realized ...... A gschem sch
> > file has no notion of connectivity. It comes from the
> > extraction. To do it correctly, you need the actual
> > symbols. That's bad, but we need to deal with it.
>
> Yes, one suggestion is to parse the standard library of
> symbols initially at the time of compilation and save
> required information in an easily (fast) accessible format
> (array?). The required information may the position of pins
> and some attributes like graphical etc.
That doesn't work because the symbols can be changed at any
time. The compiled code can know nothing about specific
symbols.