Re: gEDA-user: blue sky ideas - written down finally

[Dave N6NZ <n6nz@xxxxxxxx>]

On Dec 27, 2009, at 2:08 PM, DJ Delorie wrote:

> 
>> User now needs to somehow specify that U01 GND is connected to
>> analog ground, U01 V+ and V- to analog power rails.  U01 GND, U02
>> GND, U03 GND and U04 GND are connected to digital ground. U02 VCC is
>> connected to 5V, U03 VCC3v3 is connected to 3v3 power, and U04
>> VCC1v8 s connected to 1v8 power.  So is this in some attribute table
>> or something?
> 
> I'm not exactly sure what's best here, but I know it doesn't belong in
> the *gate*.  
<Minnesota accent>Yuppers</Minnesota accent>

My current methodology would have an infrastructure bubble on some back sheet that connects up the power and ground pins for each package.  But now since package selection can be deferred, that doesn't work so hot, unless we extend the idea of back-annotation to include creation of schematic sheets.  Which I'm OK with.

> My idea is to have a table object that shows up in the
> schematic, like in a corner or something, that lists all the power
> pins and what nets they connect to.  I've seen other schematics with
> this, it seemed much cleaner than what we do.

Yes, that makes sense.  But again, the table can get populated at layout time. So I'm thinking the table is just a graphical place-holder to contain back-annotation information.  The user can place the table(s) on some sheet, and it gets updated by down-stream tools for back-annotation.  Actually.... this is starting to sound like embedding a gattrib grid on a sheet some place.  Which might be a reasonable generalization of the functionality. 

> 
> How we populate the table, who is responsible for it, how the user
> edits it - if it's even in the schematic at all - is TBD.  Heck, you
> don't even know what the power pins *are* until you've selected a
> package, and that's way down the line flow-wise.

Also, consider that there are some things that will no doubt have to be set by the user, and some things that can't be set by the user but only by back-annotation, and somethings where the user will want the option to specify a locked override that a back-end tool can't scribble onto.  But I think you want to see all the settings in one place.

In the case of something like TTL, I could see there being two tables, one where each row is a symbol instance, and a second table where the rows are package instances, for stuff that goes with the package.  I'm not sure how that maps to modern FPGA or gate-array design, my GA design experience is too stale.

Now that I think about it.... once upon a time I worked with a system that did common signal matching.  In that case, the infrastructure signals showed up on *every* bubble, and the tool that mapped to packages would match on shared signals (which clock, which clock-enable, mainly, but it could be any arbitrary signal).  So there is a counter-example to the assertion that infrastructure does not belong on the bubble.  I'm not convinced it's a killer methodology, though.


> 
> As an aside, support for a table of pin mappings opens itself up to
> FPGA mappings, too - just supply a CSV instead of trying to map it to
> a schematic.

Instead of a table in the schematic, there could be a "see file foo.csv" symbol that all the tools could be wise too.  But I'd rather see the contents of the file sensibly displayed in the schematics.

-dave



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