[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-dev: Re: gEDA trackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Apr 19, 2007 at 01:52:03PM -0400, DJ Delorie wrote:
> > 1. Database driven part/symbol/footprint system
>
> In six hours?
Yes! ;-) The use case I see that makes people want this is:
Cast: Howard, the hardware designer.
"1. Howard is designing a data acquisition board and knows that it will
be just full of op amps. Right now he needs to buffer a signal from a
transducer (high output impedance, low impedance ADC input), so he
places a generic op amp symbol on the schematic, and connects it as a
follower. He hasn't yet decided which specific op amp to use, since he
has several options at this stage in the design, so he decides to do
this later.
"2. Later, Howard has finished the schematic and checks his power
budget. He finds that the only op amp that will work here is the 324.
He places a few (N/4) "324" container symbols on the schematic and then
selects the generic op amp follower and assigns it to a free "324"
container.
"3. The next day Howard begins the board layout, and he finds that if he
uses the default DIP14 footprint for his 324's, the board won't fit into
its box. He fixes that by changing the 324's footprint attributes to
SO14.
"When the board layout is complete, Howard looks for orderable parts, so
he runs:
$ bomgen dataacq.sch
bomgen: dataacq.sch: No orderable parts found matching R14!
$ echo oh drat && rm -rf /"
Ok. So. There are a few objects here that gEDA currently doesn't know
about:
* a generic symbol
* a container symbol to hold generic symbols
gEDA doesn't need anything special to support generic symbols - it's
more of a library issue: generic symbols must be purged of footprint=
etc. attributes. Container symbols are a little more tricky. I tried
hacking this up the last two weekends but didn't manage to get gnetlist
to produce a correct netlist. What I did was to define a new libgeda
object: OBJ_SLOT. In the file format it looks like this:
T 200 900 8 10 1 1 0 0 1
footprint=DIP14
S
{
T 200 1300 8 10 1 0 0 0 1
slotdef=2:5,6,7
T 200 1500 8 10 1 0 0 0 1
device=OP_AMP
}
'slotdef' is special: my hacked libgeda uses it to marry generic symbols
named U1:2 to a slot with slotdef starting with 2:, then edits the
pinnumber attributes in the generic symbol according to the 5,6,7 in the
container's slotdef. I got as far as gschem displaying the pin numbers
on the generic symbol correctly, and getting this far is definitely
doable within 6 hours.
Now I definitely can't do this tomorrow during the sprint, and I don't
REALLY expect anyone to do it properly for me; I'd just like to get this
on the archives in case some eager beaver wants something to do.
Part 1 of the use case needs no coding; just a bit of symbol editing.
Part 2 is kinda mostly there once you add OBJ_SLOT to libgeda. I'm sure
if you avoid the REFDES:slotnum hackery I did and instead using
something like "slot=2" (but not that, because slot= is magic), it would
be easier to get proper netlists. One nice thing to do would be to
validate the slot into which you assign a generic symbol: all the
generic symbol's toplevel attributes must match the corresponding
attributes in the target OBJ_SLOT.
Part 3 I haven't really thought very hard about, but the use case seems
to suggest another level of object hierarchy: perhaps OBJ_PACKAGE?
Minus the 'T' lines, a 7400 might look like this:
refdes=U1
footprint=DIP14
P
{
footprint=DIP14
S
{
slotdef=1:1,2,3
device=NAND_GATE
}
...
}
P
{
footprint=SO14
S
{
slotdef=1:1,2,3
device=NAND_GATE
}
...
}
Or, one could just go for fatter container symbols, one for each
footprint / other "heavy" attribute combination. But having the generic
"function-end" symbols split out of the "part-end" symbols should
mitigate much of the disadvantage of heavy symbols.
The last part would be bomgen, which would grep an orderable parts
database for entries whose attributes exactly match those attached to
the "part-end" symbol in the schematic.
My holy grail here is to be able to deal with microcontrollers in a sane
way, where you might have any number of functions multiplexed onto the
pins. That, and I want to avoid having a 208-pin symbol that's just a
huge mostly empty box whose pin names are A17/ADC0/DTR1. I'd far rather
have all the distinct functions in their own little symbols, each
individually draggable to the vicinity of its circuitry.
> > 2. n*45 placement of components
>
> I.e. arbitrary rotations? (why stop at 45's? ;)
As a data point, the Open Graphics Project seems to be building a board
that has this huge FPGA sitting in the middle of the board at a 45
degree angle to everything else. Would be nice if they were, in
principle, able to design their board with free tools!
- --
Hard work has a future payoff. Laziness pays off NOW.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGKJeDwyMv24BBd/gRAg7mAJ0RiONfBYku0Lg14ffEYOf++uc9fACgh4eB
fvc5Oqu82h05ARLYkP3d5Ag=
=8LtA
-----END PGP SIGNATURE-----
_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev