Re: gEDA-user: moving slotting to pcb?

[John Griessen <john@xxxxxxxxxxxxxx>]

DJ Delorie wrote:
> Would it make
> more sense, from a design flow perspective, to just send the symbolic
> information to pcb and let pcb assign footprints and pinouts?

I think almost everyone is still going to want to get to both the pins
chosen and the fundamental labels such as E B C on a transistor easily
from the schematic.  That could be by having a source schematic and
a mapped one, or have the gschem internal representation be both
with visibility selectable.  One view of a schematic could be the
as-built with pins chosen and another shows just E,B,C for pins.
For reuse purposes, you'd want to be able to generate an output schematic
in unmapped form where some of the info is dropped.
Maybe call that .ckt instead of .sch.

From pin-mapping.html:  " For example, a standard 7400-series quad NAND gate
   might have this for a pin mapping:

     [(A,B),Y]=([(1,2),3],[(4,5),6],[(9,10),8],[(12,13),11])
     GND=7
     VCC=14

   In this example, items in parentheses are swappable and items
   in square brackets are groups. "

Where will the mapping above and the power pins go?  Not in a .ckt
fundamentally labeled schematic of logic gates.

DJ notices a need for a unique identifier for placed symbols
since swapping is beneficial between packages as well as between
slots in one package.  That UUID will go in a gschem schematic, and the
rest of the info can be elsewhere until you finish a mapped schematic.

I would not mind if schematics always needed two files to go beyond
the fundamentally labeled kind.  The first would be the .sch
file like we use now, that has the info to draw symbols (with UUIDs),
connected with wires and  showing pin numbers -- good for debugging.
The second one could be a csv file called .map or .schmap or
.schemap, and contain the info for pins swapping,
and the mapping between fundamental names and pin numbers and unique
symbols, and package data.  There will also be loads of other data
coming from a package, and that could all be kept in the .schemap file.
Back annotations and BOMS could be made from/to such a .schemap file
without looking at the .sch file.

It's possible that some values would be best flowing from the mapping
file to be displayed on the schematic with gschem.  R and C values of
traces could be back annotated without opening/editing/processing
the schematic, just the map file.  Values of components might be
overridden by a map file when looking at the .ckt fundamentally labeled
view.  Taking a design to reuse might involve promoting attributes
from the map file to the .ckt file, then leaving the map file behind.
In other words filtering out some of the contents or a map file to keep
and tossing the rest that is package related.

John Griessen


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