On Aug 18, 2010, at 8:44 PM, al davis wrote:

> On Wednesday 18 August 2010, John Doty wrote:
>> Exactly what is the problem you experience?

You left out the quote from your earlier post:

>> 
>> What 
>> gets me most is that the translation is incomplete.  It seems I 
>> always need to hack the netlist.
> 

So, I repeat: what problems force you to hack the netlist?

> 
> 1. There are many components that do not netlist properly.  
> Every symbol must netlist correctly, no exceptions.  There is 
> more to simulation than simple spice circuits.
> 

That requires simulator expertise. Many contributors of components have no 
knowledge of simulation, and are intending the components for other purposes. 
Your demand would prevent many, perhaps most, contributions. But the correct 
fix is to fix the symbol, not hack the netlist.

> 2. There are others that netlist properly to spice only  because 
> of hacks specific to the symbol.  It is not acceptable for the 
> netlister to have any knowledge of any specific symbol or any 
> specific parameter, ever.

If I had written the SPICE netlisting back ends I would have avoided this. But 
the writers had other ideas, and I'm grateful for their hard work. This has 
never been a problem for me. How does this force you to hack the netlist?

> 
> 3. There is no reverse translation.

And that somehow forces you to hack the netlist?

Reverse translation from a non-graphical to a graphical format is an AI 
problem, beyond the present state of the art.

> 
> 4. In most cases, the user enters a value string, in whatever 
> syntax the simulator wants, which means it could be different 
> for different simulators.

Easy and transparent. If it's not right, the easy fix is to the symbol or 
schematic. One parameterization does not fit all simulation tasks. And you 
shouldn't need to hack the netlist. 

> 
> 5. It seems to be necessary to have a different schematic for 
> layout and simulation.

Yep. The commercial tools I've used suffer from the same problem. Requirements 
are different in the different domains. But how does this force you to hack the 
netlist?

> 
> 6. Probes are not supported.

"netname=foo" in schem, then "plot foo" or equivalent in the simulator. 
Trivial. And how does this force you to hack the netlist?

> 
> 7. Nets are collapsed out, even if the simulator doesn't want it 
> that way.

Not sure what you mean. Example?

> 
> 8. I'm tired of hearing about how perfect it is, when I know it 
> isn't.

It isn't perfect, but the alternatives have serious limitations. And how does 
this force you to hack the netlist?

> 
> 9. We need to support modern simulators, not just 30 year old 
> antiques like Spice, and we need to support them fully, not just 
> the compatibility subset.

The most important thing you could do here for your simulator is improve your 
documentation. And how does this force you to hack the netlist?

> 
> 10. geda seems to insist that everyone who wants to play here 
> must adopt its way of doing things, which is in many ways like a 
> proprietary system.  We don't outreach to formats that the 
> leaders consider to be standard.

Huh? We have people doing hydraulic design with gEDA. I do *symbolic* circuit 
analysis by feeding data from gschem to Mathematica. gEDA is an insanely 
flexible toolkit. And how does this force you to hack the netlist?

> 
> 11. That "two stage amplifier" example should be simple enough 
> to explain in a single breath, but it's ..  how long????????

Then go ahead and explain it in a single breath. And how does this force you to 
hack the netlist?

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




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

Reply via email to