Mail Archives: geda-user/2015/07/09/22:53:56
On Fri, 10 Jul 2015, Robert Drehmel wrote:
> 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.
I have something similar too, brought one step further. I have a pinmap
attribute with a sligtly different syntax doing the same, and a devmap
attribute. Devmap contains a file name; the file contains random
attributes specific to an actual device (by convention always including a
pinmap attribute and a footprint attribute).
I have a an alternative gsch2pcb (called gsch2pcb_devmap) that first
appliies the extra attributes, then resolves pinmaps and then run the
original gsch2pcb on the result.
(Unfortunately it operates on the schematics too, while it should be a
gnetlist backend. It's because of scheme: the current setup is hackish,
but works and I use it in production; if I started to write a proper
backend in scheme, I wouldn't have anything working until 2030.)
Anyway, in this setup devmap is sort of a high level description, using
a database (not in the sql sense). I place a generic n-chan fet symbol and
instead of fooling around with pins and footprints I just attach a
devmap=2n7002_sot23 then there's a text file called 2n7002_sot23.
From my user perspective it's simple, easy to follow, easy to maintain,
easy to set up. My devmap files are in svn, so I don't have to reinvent
library sync methods. I need to play with footpritns and pin mappings only
the first time I use a device, then I can trust the devmap file.
My devmap files also contain attributes for ordering numbers at my
favorite parts shops. It's much easier to maintain them than having them
scattered in billions of schematics and I still don't need to use heavy
symbols.
Regards,
Igor2
- Raw text -