Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy

[Bill Gatliff <bgat@xxxxxxxxxxxxxxx>]

Dave N6NZ wrote:
> Bill Gatliff wrote:
>   
>> Dave N6NZ wrote:
>>
>>     
>>> I believe this style leads to the most readable schematics, and scales 
>>> up well to larger designs.
>>>   
>>>       
>> Agreed.  At least until you do like me, and forget to put down the power
>> symbol once (or twice).  :)
>>     
>
> Well, the netlist checker or some other DRC should whine about missing 
> power.  I always verify netlist connectivity manually anyway -- these 
> days I do few designs that are so large I can't do it manually (although 
> I recognize they exist.)
>   

Yea, I need to explore that part of gaf more.  I'm still kind of a newbie.


> Most of my opinions about schematic editing were formed as a logic 
> designer on very large projects -- 30 to 60 logic designers (not 
> counting circuit designers, techs, and CAD support).  As a logic 
> designer on large CPU projects, I never once thought about how to hook 
> up power (except to keep under my budget of (say) 200A of -4.5V), and as 
> far as clocks go, only the functionality, not distribution. (Although 
> once I was assigned to the clock distribution team for a few weeks, and 
> *all* I thought about was clocks.)
>   

If you powered up all of my designs that I've done over my entire
career, the total probably wouldn't even approach 200A.  You might not
even get close if you got all the production units, too!  :)

> Adding an extra layer of pin mapping to gEDA, though, would be pretty 
> difficult to do in an upward compatible way.  While that's the "right" 
> way, I'm not convinced enough of the ROI to make everyone redo their 
> libraries.
>   

I don't think the "investment" part is a large as it seems, because
you'd be getting rid of redundancy in the existing symbol set.  So you
wouldn't have to rework EVERY symbol--- just one of each type.  That's
still a lot, I know...

There's one minor point I hadn't accounted for, however, which is that a
"NAND" symbol will go by lots of names like "7400", "4000", 
"sn74ahc1g00", and so on, so the symbol library browser would need a
little more smarts to place a symbol in multiple locations.  I can
imagine some wildcard-containing queries that would deal with that
problem, but a basic directory structure won't deal with the problem I
don't think.  Hellooooo, SQLlite.  :)

Are there cases where a device is so out-of-whack in its mapping between
a "NAND"-type symbol that would properly represent it and the associated
footprint pinout that we wouldn't be able to accomodate it without
expressing it with its _own_ symbol and _own_ footprint?  I don't think
I've encountered such a part, but I don't have 200A of experience behind
me.  :)

As far as being upwardly-compatible, could we leave the existing system
in place for a few (forever) revisions?  It's just a degenerate case
where there's a 1-1 mapping between symbol pin name and footprint pin
name.  Seems like that could coexist peacefully with a few new
attributes and logic.

Finally, if there was better connection between a symbol repository
like, say, gedasymbols.org and the gaf symbol/footprint browsers, then
uptake of the new symbols would be greatly facilitated...  :)  :)


b.g.

-- 
Bill Gatliff
bgat@xxxxxxxxxxxxxxx




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