Re: gEDA-dev: SoC: Gerber, DRC, gsch2pcb and D-BUS

[al davis <ad136-at-NOSPAMfreeelectron_dot_net>]

On Friday 23 March 2007 14:51, Stuart Brorson wrote:
> OK, thanks.  I took a look at it.  It's a single op-amp
> powered by two batteries.  It's an inverting amp, gain=1.
>  You have an AC source driving the input through a pot.

Oops ... forgot to specify the gain ...

> As you know very well, this is an analog schematic.
>  Therefore, the VHDL and the Verilog netlister won't produce
> any useful output 'cause they're not designed for this kind
> of work.

Check.

But VHDL and Verilog do support analog, and are becoming 
increasingly popular for it.  The netlister needs to pass on 
all information.

> As for the SPICE netlisters, "spice" won't do anything with
> this since gEDA's original SPICE netlisters are rather
> primitive.  "spice-sdb" could handle this circuit, but you
> (purposely) did things to make it fail:

Of course it is on purpose.

> *  SPICE has no concept of a pot, as you know, so that
> component won't appear in the netlist.

Point here is that all components need a translation, even if it 
is only to a "X" device.

Another more subtle point is that a symbol can represent an 
encapsulation of something else.  It would be nice to have a 
system supported way to say that a pot is two resistors, and 
have that travel with the graphic representation of it.

> *  SPICE has no concept of a battery, so it won't netlist
> either. 

It's a DC source.  More importantly, a box is a box.  It has 
name, attributes, connections, etc.  I want the information 
passed on.  The Spice format itself is part of the problem.

> *  You didn't include any .subckt card for the op 
> amp, so ngspice can't do anything with it.

That's fine.  I don't expect information that is not in the 
schematic.  It is resonable to expect that to come from 
somewhere else.  Just list it, and pass on the attributes.

> *  There is no analysis defined via a SPICE directive card,
> so again no analysis command will show up in the netlist.

Of course not.  Analysis is not part of a schematic.  I just 
want a netlist that the simulator can use.  I will tell the 
simulator what to do with it separately.  It might not even be 
for a simulator.

> * Your resistors include an attribute r=10K (or some value)
> which won't netlist in spice-sdb since spice-sdb cues off of
> the "value" attribute to get the resistance.

I know that.  There is a need to pass on arbitrary attributes.

> I assert that this circuit is simulatable using gEDA in its
> current  form if you just follow the rules.  Therefore it's 
inaccurate to say:
> >>  The existing netlister does not work very well.
> since your circuit deliberately does things which are
> designed to preclude proper netlisting.  But of course you
> know all this.
>
> If I am not mistaken, your point is that you can't enter any
> old schematic and expect to generate a correct netlist using
> gnetlist. But that's also true of any commerical tool out
> there, so the point is kind of moot.

My point is that there is a need for generalized sharing through 
a common format, that you or I or anyone else cannot prejudge 
any particular tool's needs, or user's needs.

> Or maybe your point is that gEDA isn't a universal simulation
> environment.  That's true, but creating such an environment
> has never been gEDA's main focus.  Qucs may be a better tool
> for that task....

Gasp.. You really thing Qucs is universal????

I guess in this context, my point is that certain parts of our 
system are so good, we don't realize how good they are.  
Something else gets in the way.

I proposed a solution, and made a case demonstrating the need 
for it.  I think it is a good "summer of code" project.

> Another point you may be making is that a VHDL like netlist
> format could do a better job than gnetlist dealing with this
> schematic?  But if you don't include a simulation model for
> the op-amp and ignore the syntax required by the tool, then
> it doesn't matter what your file format is -- nothing will
> work properly.

All I want is data exchange, without translator-enforced 
filtering.

No schematic is truly complete, in the sense of having all 
models.  I could have an all CMOS analog circuit, with 
everything the way you expect.  Still, I need to get the model 
parameters from the foundry to do a proper simulation.  That's 
not the problem.

In the Spice sense, we are living with a mid-80's notion of 
Spice.  We need to update it.

> From my standpoint, it works quite well within the
> boundaries for
> which is was designed.  If we want a better netlister
> (i.e. gnetman++), then that's another matter.

Yes it does work the way it was designed.  We need something 
better.  I made a proposal for how to do it, suggested it as a 
SOC project, and demonstrated the need for it.

One big difference between gnucap and spice derivatives like 
ng-spice is that I have no problem throwing away my own code 
from a year ago because I found a better way.  The old way 
seemed good at the time.  Recommending replacing something is 
not intended to degrade the original in any way.  Often the 
highest use of a work is to learn from it.  Then based on that 
knowledge do it again better.  The new one would not have been 
possble without the old one.

We have the opportunity to take the lead here. Let's do it.



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev