Re: gEDA-user: multiple attributes with the same value
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 unique (apart from where they do), but there's a strong argument that they should be. Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre pgpV9vOl3C0Tb.pgp Description: PGP signature ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: multiple attributes with the same value
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 than once within a symbol * the gschem attribute editor shows only the last instance of an attributein a symbol. On the other hand: * The gschem attribute editor does not prevent adding a duplicate attribute to a symbol. * gnetlist does not warn if it hits the same attribute twice in a symbol. The master attribute list does not address this issue at all. http://geda.seul.org/wiki/geda:master_attributes_list The use case that had me stumble on this is the comment attribute. From a usability point of view, it looks intuitive to have more than one comment. Of course, this might also be achieved by comment1, comment2, etc. IMHO, there should be a clearly stated policy in the master attribute list. Then the applications can deal with it accordingly. ---<)kaiamrtin(>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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 every other flow having to >> adapt. > > I'm unhappy with tuning gschem/gnetlist to be especially > friendly to any specific downstream flow. John's favorite > downstream tool is apparently SPICE, so that seems to be what he > wants to target, with every other flow having to adapt. Not true. SPICE is one I use, but in the past year I've also used Mathematica, Osmond, Calay, and PADS. A great strength of gEDA is that it supports all of these, and many more. 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
Re: gEDA-user: multiple attributes
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 legacy and > global namespaces. > > spice-value= > sim-value= > value= This looks good to me, although I would suggest using a '.' as the separator, since I think it makes sense to keep '-' available as a character usable in "normal" attribute names. Also because being able to have a toplevel attribute: spice-sdb.fix-my-netlist-please=yes is a required feature. :-P Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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 > legacy and global namespaces. > > spice-value= > sim-value= > value= If it was just the file, I would agree. That was my first thought. In this case, that means the schematic itself would be visually cluttered with repetitions of the namespace prefix, unless there are changes to gschem. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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 with tuning gschem/gnetlist to be especially friendly to any specific downstream flow. John's favorite downstream tool is apparently SPICE, so that seems to be what he wants to target, with every other flow having to adapt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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 fallbacks into legacy and > global namespaces. > > spice-value= > sim-value= > value= Agreed. In most cases, the user is going to want attributes like value= to be common to all flows. It would be good, though, to create a common convention for units in this case. 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. While it is good to have completely generic symbols as a goal, in practice users will need escape hatches to allow more control. So, for example, it is important to have the possibility of SPICE-specific attributes for cases where the SPICE netlister's assumptions turn out to be wrong. Given SPICE's irregularity and multiple incompatible dialects, this is inevitable. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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= -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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 considering how irregular the Spice format is, but hacking the symbols to compensate for shortcomings in one output format is short sighted, especially a format where the inventer of the format wishes it would be replaced by something cleaner. In a schematic, attributes really need to have a type. There are simulation attributes, layout attributes, etc. To minimize the changes to code, for now let's identify the type of an attribute by a non-alnum first character. How about prefixing simulation attributes with a dot. A Verilog netlister would just emit the attributes marked as simulation attributes in the appropriate format, regardless of the meaning of a symbol. A Spice netlister could do this in some cases, but needs extra code to handle special cases. So, for a mosfet, you have attributes like "l" and "w". These must not be hard coded, because it cannot be known in general what attributes will be used. A resistor would have an attribute "r", a capacitor would have an attribute "c". Again, not hard coded but rather just by convention. A Verilog netlister might output: nmos1#(.l(1u), .w(1u)) m12 (.d(3),.s(4),.g(9),.b(0)); resistor #(.r(10k)) r33 (.n(3), .p(8)); boxoid #(.hat(10),.foot(.01)) xbox1 (.top(3), .bot(7)); A Spice netlister might output: m12 (3 9 4 0) nmos1 l=1u w=1u r33 (8 3)10k xbox1 (3 7) boxoid hat=100 foot=.01 For the Verilog netlister, no funny business is needed. All instances have the same syntax. All attributes and connections are mapped by name. It's easy. For the Spice netlister, there are some issues. In general, the attributes can be passed by just stripping the dot and copying, but that doesn't work for the resistor. Different types have different syntax. This must be determined from the type by the netlister. In this case, the mosfet and subckt call can use the same syntax. They are not special. This behavior can be thought of as the default behavior. The resistor is a special case. One particular attribute "r" needs to be emitted without its name. This is a netlister task, not part of a symbol. This is where some kind of mapping is needed. The resistor isn't the only special case. Spice is seriously burdened with those special cases, which is why a spice netlister is so complicated. Still, it is a netlister problem, not a symbol problem. Let the symbols be consistent, and the spice netlister support the bugs in spice. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
> > 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. > > > > spice-port-order > > port-order > > pin-seq (obsolete) Use the pinseq, and pinnumber for physical representations, this prevents the annoying "magic" that slotted component instances give when pinnumbers/slots change. > I'd prefer a spice-prototype attribute, which would allow us to avoid > many of the difficulties without a confusing proliferation of > attributes. I have these procedures in my private git repository that could make netlisting independent of the physical representation. My coding format is different from the other gnetlist code so the coding needs some review. g_get_all_netnames_using_pinlabel(SCM scm_uref) Returns a list of pairs: ( (pinlabelname netname) (pinlabelname netname) (pinlabelname netname) ... ) And g_get_netname_using_pinlabel(SCM scm_uref, SCM scm_pinlabel) which returns one attibute value. This one is probably less useful. For the idea using a spice prototype find a PSpice manual which describes such a format. See the PSPICETEMPLATE in the User Guide. There is no need to reinvent the format, maybe extend it a bit. Are there commercial netlisters that could provide some other possibilities? A piece of documentation and an example copied from the PSpice user manual: % @Value of . Error if no attribute or if no value assigned. &Value of if is defined. ?s...s Text between s...s separators if is defined. ?s...ss...s Text between the first s...s separators if is defined, else the second s...s clause. ~s...s Text between s...s separators if is undefined. ~ s...ss...s Text between the first s...s separators if is undefined, else the second s...s clause. #s...s Text between s...s separators if is defined, but delete rest of template if is undefined. ^ This is the complete hierarchical path to the device being netlisted. s is a separator character i.e.: , . / | Examples: r...@refdes %1 %2 @VALUE v...@refdes %+ %- ?DC|d...@dc| ?AC|a...@ac| x...@refdes %IN+ %IN- %OUT+ %OUT- @MODEL I don't have guile code for such a netlister. In 2007 someone wrote something similar with guile. On sourceforge there is this: "Allow the definition of spice syntax in symbols. - ID: 1758382" http://sourceforge.net/tracker/?func=detail&aid=1758382&group_id=161080&atid=818428 Being able to fetch netnames using pinseq and pinnumber could prevent one of those bloody email wars without an implementation in sight. > 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 yell at each other about syntax, but I think the basic idea is > sound. Right now, spice-sdb is essentially reduced to guessing what > the symbol represents. It can't always tell reliably (it's been know > to decide my flip-flops are diodes!). There isn't generally one right > answer: with a different kind of model (subcircuit), the prototype > for nmos-3.sym might be: > > X? #D #G #S $model-name > > Suggested syntax: > > First characters up to the "?" are the device prefix. > > #x means the net attached to pinnumber x. > %x means the net attached to pinseq x. > `x means the net attached to pinlabel x. > $x means the value of attribute x. > x= means an optional x=value string to be emitted only if the x > attribute is present. > > An improved SPICE netlister could incorporate heuristics similar to > spice-sdb to pick a prototype from a collection of defaults, or fall > back purely on pinseq and model-name, if no spice-prototype attribute > is present, for backward compatibility. Bas -- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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=
>>
>> Yes, I think it is. Also note that we've for many years had l=, w=,
>> m=, etc. as special attributes in both SPICE back ends. Unfortunately,
>> it isn't documented, and the case sensitivity always trips me up (as
>> it did above).
>
> Well, the {} syntax may be optional
>
> W= defaults to W={W}
> #D defaults to #{pinlabel=D}
At the very least, we also want to be able to use pin numbers. Pin labels are
potentially ambiguous, especially for slotted components. But if we could use
pin numbers, we could make SPICE netlists with slotted components. I recently
asserted this was impossible, but I have been known to be wrong ;-)
---
John Doty Noqsi Aerospace, Ltd.
This message contains technical discussion involving difficult issues. No
personal disrespect or malice is intended. If you perceive such, your
perception is simply wrong. I'm a busy person, and in my business "go along to
get along" causes mission failures and sometimes kills people, so I tend to be
a bit blunt.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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=,
> m=, etc. as special attributes in both SPICE back ends. Unfortunately,
> it isn't documented, and the case sensitivity always trips me up (as
> it did above).
Well, the {} syntax may be optional
W= defaults to W={W}
#D defaults to #{pinlabel=D}
You may want to write W={w} W={W}, to cover both cases :-)
And please drop %x `x ...
--
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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:
>>
>> M? #D #G #S #S $model-name L= W= AS= AD= PS= PD= M=
>>
>> We can yell at each other about syntax, but I think the basic idea is sound.
>> Right now, spice-sdb is essentially reduced to guessing what the symbol
>> represents. It can't always tell reliably (it's been know to decide my
>> flip-flops are diodes!). There isn't generally one right answer: with a
>> different kind of model (subcircuit), the prototype for nmos-3.sym might be:
>>
>> X? #D #G #S $model-name
>>
>> Suggested syntax:
>>
>> First characters up to the "?" are the device prefix.
>>
>> #x means the net attached to pinnumber x.
>> %x means the net attached to pinseq x.
>> `x means the net attached to pinlabel x.
>> $x means the value of attribute x.
>> x= means an optional x=value string to be emitted only if the x attribute is
>> present.
>
> Same overloading, just sperad out, I don't like that.
Well, it's not quite the same, because the semantics are in the user's control
here. The alternative is a confusing proliferation of extra attributes. I don't
know that there's a perfect answer.
>
> 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=, m=, etc. as
special attributes in both SPICE back ends. Unfortunately, it isn't documented,
and the case sensitivity always trips me up (as it did above).
---
John Doty Noqsi Aerospace, Ltd.
This message contains technical discussion involving difficult issues. No
personal disrespect or malice is intended. If you perceive such, your
perception is simply wrong. I'm a busy person, and in my business "go along to
get along" causes mission failures and sometimes kills people, so I tend to be
a bit blunt.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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 yell at each other about syntax, but I think the basic idea is sound.
> Right now, spice-sdb is essentially reduced to guessing what the symbol
> represents. It can't always tell reliably (it's been know to decide my
> flip-flops are diodes!). There isn't generally one right answer: with a
> different kind of model (subcircuit), the prototype for nmos-3.sym might be:
>
> X? #D #G #S $model-name
>
> Suggested syntax:
>
> First characters up to the "?" are the device prefix.
>
> #x means the net attached to pinnumber x.
> %x means the net attached to pinseq x.
> `x means the net attached to pinlabel x.
> $x means the value of attribute x.
> x= means an optional x=value string to be emitted only if the x attribute is
> present.
Same overloading, just sperad out, I don't like that.
Is this too verbose?
M? #{pinlabel=D} #{pinlabel=G} #{pinlabel=S} #{pinlabel=S} ${model-name}
L={length} W={width} AS= AD= PS= PD= M=
--
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
> 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 how a spice simulation is set up, this seems like a much better approach. The 'pinseq' attribute is obsoleted, as the prototype defines the order of pins in the spice card. I suspect that a simple gnetlist backend (without hierarchy) could be written in about 30 lines of scheme, because the netlister hardly needs to know anything about SPICE syntax. It's all contained in the prototype, with a bit of variable substitution done by the netlister. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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 name or >> the last, depending on how the netlister was written. > > This should either case an error or a prominent warning. > >> About overloading: >> >> Sometimes it's desirable to overload attributes; for example I might >> want to simulate a circuit through a spice netlister, then generate a >> BOM of the parts in the simulation. Having the BOM netlister use the >> same "value" attributes as the simulation helps prevent errors in >> keeping the two flows in sync. >> >> To give the user the choice of overloading the symbols or not, each >> netlister could first look for a netlister-specific attribute, and if >> that doesn't exist then use a generic attribute. i.e first look for >> "spice-sdb-value", and if that doesn't exist then use the generic >> "value". > > 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. > > spice-port-order > port-order > pin-seq (obsolete) 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 yell at each other about syntax, but I think the basic idea is sound. Right now, spice-sdb is essentially reduced to guessing what the symbol represents. It can't always tell reliably (it's been know to decide my flip-flops are diodes!). There isn't generally one right answer: with a different kind of model (subcircuit), the prototype for nmos-3.sym might be: X? #D #G #S $model-name Suggested syntax: First characters up to the "?" are the device prefix. #x means the net attached to pinnumber x. %x means the net attached to pinseq x. `x means the net attached to pinlabel x. $x means the value of attribute x. x= means an optional x=value string to be emitted only if the x attribute is present. An improved SPICE netlister could incorporate heuristics similar to spice-sdb to pick a prototype from a collection of defaults, or fall back purely on pinseq and model-name, if no spice-prototype attribute is present, for backward compatibility. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
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. This should either case an error or a prominent warning. > About overloading: > > Sometimes it's desirable to overload attributes; for example I might > want to simulate a circuit through a spice netlister, then generate a > BOM of the parts in the simulation. Having the BOM netlister use the > same "value" attributes as the simulation helps prevent errors in > keeping the two flows in sync. > > To give the user the choice of overloading the symbols or not, each > netlister could first look for a netlister-specific attribute, and if > that doesn't exist then use a generic attribute. i.e first look for > "spice-sdb-value", and if that doesn't exist then use the generic > "value". 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. spice-port-order port-order pin-seq (obsolete) I like your idea. What is the spice term for pins? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes (was: [Patches] GTK Recent-file-manager)
>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 is by the order that they appear in the symbol's attribute list. This is defined by the order in which they were attached to the symbol originally, or the order that they appear in the symbol file. As far as I know, none of the use cases that people have mentioned assign any meaning to the order in which the symbols appear in the list. It's possible for someone to write a script or netlister that does assign some meaning, but it doesn't seem like a good idea. Better to give different names to the attributes, like slotdef-A slotdef-B, etc. and have the code search for any attribute names beginning with "slotdef-". 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. About overloading: Sometimes it's desirable to overload attributes; for example I might want to simulate a circuit through a spice netlister, then generate a BOM of the parts in the simulation. Having the BOM netlister use the same "value" attributes as the simulation helps prevent errors in keeping the two flows in sync. To give the user the choice of overloading the symbols or not, each netlister could first look for a netlister-specific attribute, and if that doesn't exist then use a generic attribute. i.e first look for "spice-sdb-value", and if that doesn't exist then use the generic "value". ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes (was: [Patches] GTK Recent-file-manager)
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 base that has been floating on and off the mailing list is meant to better serve the purpose. An alternative would be the notion of "packages" like in other EDA suites. A package would be a container for whatever the designer of a library likes to bundle -- symbols, footprints, documents, notes, simulation models, and whatnot. > I *think* the list of attributes shown in the dialog can be > generated in a way where repeated attributes will appear as: > > documentation Vis N V > documentation (2) Vis N V > documentation (3) Vis N V 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. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes (was: [Patches] GTK Recent-file-manager)
>> 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 >More use cases I can think of: >* author -- in case there is more than one. >* vendor -- where to buy Hm, Peter C is right that this complicates things a lot. I *think* the list of attributes shown in the dialog can be generated in a way where repeated attributes will appear as: documentation Vis N V documentation (2) Vis N V documentation (3) Vis N V Then when it comes time to apply a change, gschem will search the object's list of attributes to find the one that appears in the right sequence in the attribute list. >> While I was at it, I added a help button to the dialog, which brings up the >> 'Master Attributes List' of the wiki with definitions of all the typical >> attribute names. >Great. Is the list downloaded on the fly, or is it from a local copy? it uses the same mechanism as other help viewing actions, which read from the local copy. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes (was: [Patches] GTK Recent-file-manager)
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 attributes. >> >> A hierarchical symbol will have multiple source attributes if its >> underlying schematic has multiple pages. >> >> And nobody knows what other use cases there are, or may be in the future. >> You should make as few assumptions about how people will use attributes as >> practical. > > One of the problems we have at the moment is that sometimes attributes in the > schematic override attributes in the symbol, and sometimes they don't. > > Example 1. Suppose I have a "refdes=A?" attribute in a symbol. I instantiate > the symbol in a schematic, and attach a "refdes=A1" attribute to the > instantiated symbol. gnetlist (etc) will use "refdes=A1". This is > overriding > behaviour. > > Example 2. Suppose I have a "net=Vcc:1" attribute in a symbol. I instantiate > the symbol in a schematic, and attach a "net=Vdd:1" attribute to the > instantiated symbol. gnetlist will short Vcc to Vdd and connect pin 1 to the > shorted net. This is aggregation behaviour. > > The problem with this is inconsistency. IMHO it would be better to have > overriding behaviour *only*, because in the longer term being able to > reliably > override attributes would particularly be helpful in doing things like > hierarchical back-annotation and parameterised subcircuits (the latter would > be awesome for ASIC design applications, for instance). As far as I can > tell, > everything that can be achieved with aggregation behaviour can be achieved > with overriding behaviour, but not the other way around. This sort of inconsistent behavior is a serious barrier to extension of capability. I agree with this diagnosis. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes (was: [Patches] GTK Recent-file-manager)
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 multiple source attributes if its > underlying schematic has multiple pages. > > And nobody knows what other use cases there are, or may be in the future. > You should make as few assumptions about how people will use attributes as > practical. One of the problems we have at the moment is that sometimes attributes in the schematic override attributes in the symbol, and sometimes they don't. Example 1. Suppose I have a "refdes=A?" attribute in a symbol. I instantiate the symbol in a schematic, and attach a "refdes=A1" attribute to the instantiated symbol. gnetlist (etc) will use "refdes=A1". This is overriding behaviour. Example 2. Suppose I have a "net=Vcc:1" attribute in a symbol. I instantiate the symbol in a schematic, and attach a "net=Vdd:1" attribute to the instantiated symbol. gnetlist will short Vcc to Vdd and connect pin 1 to the shorted net. This is aggregation behaviour. The problem with this is inconsistency. IMHO it would be better to have overriding behaviour *only*, because in the longer term being able to reliably override attributes would particularly be helpful in doing things like hierarchical back-annotation and parameterised subcircuits (the latter would be awesome for ASIC design applications, for instance). As far as I can tell, everything that can be achieved with aggregation behaviour can be achieved with overriding behaviour, but not the other way around. Regards, Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
