X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Sat, 2 Jan 2016 12:53:17 -0500 Message-Id: <201601021753.u02HrHCw020242@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: <56880595.8000505@ecosensory.com> (message from John Griessen on Sat, 2 Jan 2016 11:15:01 -0600) Subject: Re: [geda-user] ideas on slotting and mechanisms for grouping/associating heterogenous symbols. References: <8444F816-17CE-4A56-A982-4A60DEDA72B8 AT noqsi DOT com> <87FC7D4C-157A-499E-8B93-97653D6A7C68 AT noqsi DOT com>

<624E6A69-62CE-4FCB-9D44-9FDF036254A3 AT sbcglobal DOT net> <56880595 DOT 8000505 AT ecosensory DOT com> Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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.