Kai-Martin Knaak
kn...@iqo.uni-hannover.de writes:
Do attributes have to be unique within a symbol? Currently,
gschem/gnetlist is a bit indifferent.
This has been discussed before:
http://thread.gmane.org/gmane.comp.cad.geda.user/34557/focus=34677
Upshot: current behaviour is inconsistent.
Do attributes have to be unique within a symbol? Currently, gschem/gnetlist
is a bit indifferent.
On the one hand:
* gnetlist issues a warning if the same attribute is set to different values
in many symbol components.
* gnetlist seems to pick only the last value if an attribute is set more
al davis ad...@freeelectron.net writes:
How about prefixing simulation attributes with a dot.
No, please, use a proper namespace prefix, like
spice- verilog- sim-
spice: verilog: sim:
Backend namespaces, use namespaces, with fallbacks into legacy and
global namespaces.
spice-value=
On Jan 17, 2011, at 5:10 PM, Stephan Boettcher wrote:
al davis ad...@freeelectron.net writes:
How about prefixing simulation attributes with a dot.
No, please, use a proper namespace prefix, like
spice- verilog- sim-
spice: verilog: sim:
Backend namespaces, use namespaces,
On Monday 17 January 2011, John Doty wrote:
I'm unhappy with tuning gschem/gnetlist to be especially
friendly to any specific downstream flow. Al's favorite
downstream tool is apparently Verilog, so that seems to be
what he wants to target, with every other flow having to
adapt.
I'm unhappy
On Monday 17 January 2011, Stephan Boettcher wrote:
al davis ad...@freeelectron.net writes:
How about prefixing simulation attributes with a dot.
No, please, use a proper namespace prefix, like
spice- verilog- sim-
spice: verilog: sim:
Backend namespaces, use namespaces, with
On Monday 17 Jan 2011 08:10:24 Stephan Boettcher wrote:
al davis ad...@freeelectron.net writes:
How about prefixing simulation attributes with a dot.
No, please, use a proper namespace prefix, like
spice- verilog- sim-
spice: verilog: sim:
Backend namespaces, use namespaces, with
On Jan 17, 2011, at 11:22 PM, al davis wrote:
On Monday 17 January 2011, John Doty wrote:
I'm unhappy with tuning gschem/gnetlist to be especially
friendly to any specific downstream flow. Al's favorite
downstream tool is apparently Verilog, so that seems to be
what he wants to target, with
It's well past time to realize that there is more to simulation
than Spice. A schematic should be able to be used with a
variety of simulators, and the netlister should take care of
the differences.
Symbols should not have anything specific to any output format.
This is difficult
Matthew Wilkins wrote:
Hm, Peter C is right that this complicates things a lot.
Well, you asked for potential use cases. Not all conceivable uses
may warrant the effort to code. In addition, there may be better
ways to achieve the same goal. Symbols in gschem are a bit overloaded.
The data
Matthew Wilkins matthew_m_wilk...@yahoo.ca writes:
There _is_ a meaning to the order if a netlister expects only one
attribute, but the symbol has several of the same name. In that case,
the netlister could find either the first attribute of that name or
the last, depending on how the
On Jan 5, 2011, at 8:49 AM, Stephan Boettcher wrote:
Matthew Wilkins matthew_m_wilk...@yahoo.ca writes:
There _is_ a meaning to the order if a netlister expects only one
attribute, but the symbol has several of the same name. In that case,
the netlister could find either the first
I'd prefer a spice-prototype attribute, which would allow us to avoid many of
the difficulties without a confusing proliferation of attributes. For the
symbol nmos-3.sym, a suitable prototype might be:
M? #D #G #S #S $model-name L= W= AS= AD= PS= PD= M=
Yes, if we're willing to reinvent
John Doty j...@noqsi.com writes:
I'd prefer a spice-prototype attribute, which would allow us to avoid many of
the difficulties without a confusing proliferation of attributes. For the
symbol nmos-3.sym, a suitable prototype might be:
M? #D #G #S #S $model-name L= W= AS= AD= PS= PD= M=
On Jan 5, 2011, at 9:56 AM, Stephan Boettcher wrote:
John Doty j...@noqsi.com writes:
I'd prefer a spice-prototype attribute, which would allow us to avoid many
of the difficulties without a confusing proliferation of attributes. For the
symbol nmos-3.sym, a suitable prototype might be:
On Jan 5, 2011, at 10:56 AM, Stephan Boettcher wrote:
John Doty j...@noqsi.com writes:
On Jan 5, 2011, at 9:56 AM, Stephan Boettcher wrote:
Is this too verbose?
M? #{pinlabel=D} #{pinlabel=G} #{pinlabel=S} #{pinlabel=S} ${model-name}
L={length} W={width} AS= AD= PS= PD= M=
Yes,
And that is the way forward for the problematic overloading we have
right now, e.g., the pinseq attribute:
The spice netlist shall learn to use a (spice-)port-order
attribute, or however that shall be named, and fall back to pinseq,
with an obsolescence warning.
On Wednesday 05 January 2011 00:42:07 John Doty wrote:
On Jan 4, 2011, at 5:22 PM, Matthew Wilkins wrote:
What are typical use cases for having multiple same-named attributes in a
symbol?
A slotted symbol generally needs multiple slotdef attributes.
A hierarchical symbol will have
On Jan 4, 2011, at 6:04 PM, Peter TB Brett wrote:
On Wednesday 05 January 2011 00:42:07 John Doty wrote:
On Jan 4, 2011, at 5:22 PM, Matthew Wilkins wrote:
What are typical use cases for having multiple same-named attributes in a
symbol?
A slotted symbol generally needs multiple slotdef
What are typical use cases for having multiple same-named attributes in a
symbol?
Same-named attributes in my symbols:
* slotdef -- this is pretty generic
* comment -- sometimes, more than one note needs to be delivered
* documentation -- sometimes, more than one datasheet is available
20 matches
Mail list logo
