Mail Archives: geda-user/2016/01/02/12:53:36
> I am not sure where that database would be in your plan, but to me, external
> to gschem or pcb would be best, and it could be a gnetlist backend.
In my plan, it's the third big "thing" in the flow - schematic
capture, heavifying, layout. I have a bluesky that goes into more
details, but basically it's an API to "something else" which can be
used by gschem, gnetlist, pcb, or whatever. Most of the heavy lifting
would be added to gnetlist but other tools need access to the data
also.
> The "as built" of your post is to me, just the "standard" symbol
> version, which is the default assignment in a datasheet of a part.
> I would not want to reuse schematics by adding some external delta
> patch to it, but rather by adding more attribs to the "standard"
> symbol.
Right, you'd supply enough attributes in your schematic to identify
what you want downstream, and the componentdb fills in the details.
So if you want a 100R 0.5W resistor, the simulation database knows
what model to supply and the layout database knows which vendor you
prefer. You can be as specific or as general as you like in the
schematics.
> A change to a pinswap version would mean changing added pinswap
> attribs not just adding them.
There's two parts to pin/gate swapping:
1. What permutations are *permitted*
2. What permutations are *chosen*
The first can be an attribute, so the database fills it in based on
which part you chose. For example, if you have a NAND gate in your
schematic, the pin/gate swap attribute varies depending on whether you
pick a 14-pin DIP, a 15-pad CSP, or a 6-pin SOT. *If* you decide on a
package at schematic capture time, you can import the swapping info at
capture time. If you defer package selection until layout (or change
the package at layout), the schematic is not an as-built.
> I'd rather that essential info of version be in the schematic
> project dir than perhaps in the layout project dir.
My thought is that pin/gate swapping is easier to do in layout, where
you can see the physics affecting the choice. It makes sense to give
the user the choice there, but it means that the data doesn't
originate in the schematic.
> Heavifying symbols could use a database. SQLite comes to mind as a
> match to these projects.
The type of database is irrelevent - define the API, let people put
whatever database they want behind it. I think a form of HTTP makes
sense, you can put anything behind it from text files to monkeys.
> Swapifying could easily be dealt with as attribs in schematics,
> pinswap files, and netlists with no database engine needed.
The database is there to provide a swapping attribute once the package
is selected, so it's more of a side-effect of the database rather than
something that requires a database. Example: I often use single- and
dual-gate chips in my designs, but the stock NAND gate has pin info
for a quad-gate 7400 14-pin DIP. The process of heavifying the symbol
would include adding a simple swapping attribute.
- Raw text -