Re: gEDA-user: multi-part symbol support

[John Doty <jpd@xxxxxxxxx>]

On Jul 28, 2009, at 1:52 PM, Kai-Martin Knaak wrote:

> On Mon, 27 Jul 2009 11:36:53 -0600, John P. Doty wrote:
>
>> Anything that goes into a BOM, for example. That's an open ended  
>> list,
>
> ack.
>
>
>> A one-shot solution for each attribute won't work.
>
> ack.
>
>
>> Nor, I think, is it right to do
>> this for all attributes, as "source" is potentially properly  
>> multiple,
>> and we shouldn't preclude other such attributes.
>
> Almost all attributes should be made unique with regard to the refdes.
> Therefore it is better to define a set exceptions. The information  
> which
> attributes are exceptions must reside somewhere. Hard coded into the
> source is clearly no good option.

Flexibly coded into the back ends is a good option. A typical PC  
layout netlister needs exactly one footprint per device at the end of  
the day. A typical BOM generator needs at most one value per column,  
and it knows what the columns are. Other flows, other back ends,  
other requirements.

> Somewhere in the config files is an
> invitation for inconsistency problems.

It don't think it's a config file thing.

> It  would make a *.sch file even
> less selfcontained.

Well, I don't think of .sch files as self contained anyway. I treat  
them like source code: what they "compile" to depends on the  
environment in which they are "compiled" (netlisted). That makes it  
fairly easy to reuse them in projects with different parts stocks,  
for example.

> You'd have to always ship a gnetrc along with
> schematic file.
>
> So the information should be included in the schematic.

That's a potential barrier to reuse.

> It would be
> possible to read gnetlist options from global attributes of the  
> schematic
> or from attributes of the title page. However, I'd be wary to  
> introduce
> yet another way to pass options to gaf applications.
>
> But how about this:
>
> Require, that every attribute is unique within the set of symbols with
> the same refdes.

Breaks the current usage of source=. Might break custom flows, too.

> But add the notion of lists as values of an attribute.
> Instead of multiple attributes there would be multiple values of an
> attribute. As an aside, this would resolve possible ambiguity about  
> the
> priority of attributes. A list is ordered in an intuitive way. An
> additional benefit is, that the multiple values cannot be scattered  
> over
> multiple symbols. This reduces the chance of confusion.
>
> Value lists would come handy with my other most wanted gschem feature,
> too: Present a selection of reasonable footprints in the attribute  
> editor
> of gschem. The list of reasonable footprints should be a property  
> of the
> symbol and it should be adapted to the preferences of the site or
> project.

Well, that whole approach is incompatible with schematic reuse, at  
least the way I do it. In most cases it's more sensible to put the  
footprint in the project symbol, not attach it in the schematic.

>
> What would be a sensible syntax for lists of values?

Scheme syntax. Then you can represent arbitrary data structures, and  
need not write another parser. The front end need not even understand  
this: the back end can trivially parse this with (read) without  
evaluation from a string port.

> The attribute name should contain the information, that the  
> attribute can
> contain a list. Else, simple string values might be misinterpreted  
> to be
> lists. An intuitive way to mark an attribute as a list would be to
> require "list_of_" at the start of the name. List items might be
> separated by semicolons.
>
> Bottom line: I propose to make every attribute in a set of multi part
> symbols unique during gnetlist runs. If more than one value of a
> attribute is required for some purpose, this can be achieved with a  
> list
> of values.
>
> Do you see a flaw in this approach?

I generally worry about rigidification. But if the back end has  
access to all of the attributes, and can therefore choose to use  
these rules or bypass them, I see little harm here. But perhaps  
others have comments.

There might be several ways to compose a particular device, and  
attributes with duplicate names might be useful in that case, but I  
can't think of an example.

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




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