Mail Archives: geda-user/2015/07/09/19:07:12
On 07/09/2015 11:27 PM, DJ Delorie wrote:
>> #3 is certainly growing on me. I find myself dealing with multiple
>> layout contractors, and one of them wants footprint names like
>> "BGA484C100P22X22_2300X2300X260". I don't think those belong in the
>> schematics, and the others are happy with "BGA484". So, it's a
>> flow-dependent mapping.
>
> That idea was a side-effect of my "component database" blue-sky. We really
> want *three* main tools:
>
> * schematic capture (gschem)
> * mapping to a backend (netlister + component_db + project_ruleset)
> * backend (pcb/sim/etc)
>
> The mapping would map symbolic information (pins A,B,Y, value, etc) to
> physical information (package-specific pinouts, simulation models,
> etc) based on whatever relevent local rules apply. Most of this info
> is what's back-annotated anyway, but the backend can provide its
> as-built data to the netlister on the fly, to merge with new schematic
> info.
A couple of years ago I wrote a parser for the pin mapping syntax you
propose (http://www.delorie.com/pcb/pin-mapping.html) for my component
database layer (handled in pcb). I used a gschem-compatible file format
and one file each for a family of components, e.g.
file omron-g6k.com:
"""
name=g6k
manufacturer=Omron
comment=DPDT relay series
C G6K-2P { # THT
# The PCB footprint file (.fp) used
footprint=g6k-tht
# A mapping from gschem generic relay symbol pins to the footprint's pins
pinmap=P:1,N:8,11:3,12:2,14:4,21:6,22:7,24:5
}
...
C G6K-2G { # SMT
footprint=g6k-smt-il
pinmap=P:1,N:8,11:3,12:2,14:4,21:6,22:7,24:5
}
...
"""
file panasonic-tq2-l2.com:
"""
name=TQ2-L2
manufacturer=Panasonic
comment=2PDT, 2 coil latching
C TQ2-L2 { # THT
footprint=panasonic-tq2-tht
pinmap=P:1,N:5,PR:10,NR:6,11:3,12:2,14:4,21:8,22:9,24:7
}
...
"""
This was used in combination with generic relay symbols which have symbolic
names instead of pin numbers. In gschem, each symbol had either a footprint
attribute or a component attribute attached, the latter caused pcb to search
for the correct component and map the symbolic name to pin numbers.
The parser could possibly serve as a starting point from a source code
perspective for a freestanding "third tool".
How do you think this mapping tool should get the data from the schematic -
via a special scheme netlist script or by reading the schematic file itself?
Best regards,
Robert
- Raw text -