Kai-Martin Knaak
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. They don't have to be un
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 targ
On Monday 17 Jan 2011 08:10:24 Stephan Boettcher wrote:
> al davis 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
On Monday 17 January 2011, Stephan Boettcher wrote:
> al davis 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
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 unha
On Jan 17, 2011, at 5:10 PM, Stephan Boettcher wrote:
>
> al davis 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 fallback
al davis 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=
sim-value=
value=
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 considerin
> > 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 Jan 5, 2011, at 10:56 AM, Stephan Boettcher wrote:
> John Doty 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=
>
John Doty 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, I think it is. Also note that we've for many years had l=, w
On Jan 5, 2011, at 9:56 AM, Stephan Boettcher wrote:
> John Doty 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:
>>
>>
John Doty 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=
>
> We can ye
> 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 rei
On Jan 5, 2011, at 8:49 AM, Stephan Boettcher wrote:
>
> Matthew Wilkins 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 n
Matthew Wilkins 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 netlister was written.
Th
>How would the dialog establish the order? Would the order be significant
>to some action? If so, there should be a way to manipulate order from
>the GUI.
>
As far as I can see, the only way for a program to distinguish between two
attributes with the same name, attached to the same symbol i
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 bas
>> 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 availab
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 multip
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 ha
21 matches
Mail list logo
