| ID: | 3445 |
| From: | Mychaela Falconia <my...@gmail.com> |
| Date: | Sun, 13 Oct 2019 01:28:48 -0800 |
| Subject: | [pcb-rnd] COT data model (was: non-graphical schematics, layout) |
| replies: | 3448 from Bob Paddock <bo...@gmail.com> |
Hi Erich, > What in your view does the PADS model have that cannot be done with any of > the FOSS layout tools currently? The data model which I like and which is missing in geda-pcb and its descendants is what I call copper ownership tracking (COT) - I don't know if there a better industry standard term for it, but if there is one, I am ignorant of it. In the COT data model every electrically conducting object in a PCB design (every component pad, trace, via, polygon, whatever else the tool supports) has an associated owner netname, i.e., it officially belongs to a certain named net per the data model. Both PADS and Altium follow the COT model, KiCAD does too AFAIK, but geda-pcb and its descendants do not. Why do I insist on COT? Besides personal taste preference, I don't see any way to cleanly implement full-featured polygon pours without COT. If you look at any cellphone or cellular modem PCB design from the 2000s decade, you will see that they have a GND copper pour on every layer, covering the entirety of every layer with no exceptions. Absolutely all non-GND circuits on these boards are embedded within these all-layer-filling GND polygon pours. Look at these gerbers for an example of what I am talking about: ftp://ftp.freecalypso.org/pub/GSM/GTA02/GTA02-MB-A6.zip It's an 8-layer PCB with 2+4+2 bbvia structure (there are no vias going all the way through except for a few mounting holes), and all 8 layers have GND polygon pours on them, each pour covering the entirety of the layer. Everything that isn't GND is embedded in these pours with tool-generated clearances around these non-GND objects; the tool that made this board was PADS, and it has a COT data model indicating the owner netname for each copper object; comparing the owner netname of a given object against the owner netname of the polygon pour tells the tool whether to cut clearances or to "drown" the object in the pour. For example, the circuit has plenty of bypass caps to GND, and for each of these caps the GND pad is "drowned" in the GND pour, whereas the signal (non-GND) pad has a clearance around it. Another effect that happens on cellular boards with this GND copper pour arrangement is these polygon pours become very fragmented as a result of non-GND objects cutting into them with clearances, forming many disconnected islands. Removing all islands but the largest is NOT an acceptable option, instead PADS and Altium have a configurable setting for minimum island area, and any islands whose area is above this threshold are kept. But the tool understands that they are now disconnected, and it is the layout engineer's responsibility to interconnect these islands with vias. The COT data model once again comes into play: each island resulting from the polygon pour dicing process is an object associated with netname GND, and the DRC code checks that all objects in a given netname are all connected. If there are two objects with the same netname, but there is no electrically conducting path between them, then it's a big error. It is likewise an error if two objects with different owner netnames touch - that is how shorts are detected in the COT data model. As I understand it, the "full polygon" mode in geda-pcb and its derivatives including pcb-rnd does not quite measure up - when islands form, the tool thinks they are still electrically connected even when they are not. Not acceptable for cellular boards which rely so heavily on all-layer-filling GND pours and auto-generated clearances around everything that isn't GND. My FreeCalypso project is largely about producing derived-work board designs based on Openmoko GTA02 - the historical done-in-PADS board design from 2008 linked above. I have a .asc (PADS ASCII format) export made from PADS for this board, it faithfully captures the entire PADS data model, *and* this format is very well-documented. Thus I have the complete original data model for this board in a well- documented ASCII format. My current FCDEV3B PCB design was created by certain people who worked with me on a barter basis; unfortunately these people liked Altium better than PADS, so they migrated the design from PADS to Altium and did all subsequent layout work in Altium; I loudly protested, but because it was a barter arrangement as opposed to a work for hire with me paying for it, I couldn't do anything about it. I then ended up having to hire another Altium contractor with my own money to fix the utter mess the original people left me with, and I have deep scars from this experience - from now on until the day I die, Altium is my most-hated piece of software on Earth. But I am now looking at producing some new FreeCalypso board designs, and these new boards don't really need anything from FCDEV3B that does not originally come from Openmoko GTA02, thus I can set the done-in- Altium FCDEV3B design aside, go back to the original PADS version, and do the new board right, which means doing it *without Altium*, using only PADS and FOSS. But while PADS is nowhere near as bad as Altium (more precisely, I personally have not had a soul-scarring experience with PADS as I had with Altium), it is still proprietary software that can't work without a proprietary OS underneath, thus it is still something which I need to move away from. Hence my desire to produce my own fork starting from either geda-pcb or pcb-rnd, change the data model to COT, and then translate my beloved Calypso modem layout from PADS to my new FOSS tool - call it CellPCB. Contrary to the way Igor2 misinterpreted me back on the geda-user mailing list many years ago, I am NOT seeking any kind of generic import/export "to and from" PADS - instead my goal is to do a one-time, one-way conversion from PADS to my desired CellPCB FOSS tool, using a highly ad hoc converter program written specifically for the singular job of converting my desired subset of OM GTA02. But such a converter cannot be written until the destination FOSS tool for it comes into existence, and right now there is no such tool - neither geda-pcb nor pcb-rnd offers a COT data model, which is an absolute requirement for this PADS-to-FOSS translation I seek. But because of other things happening in my life which need to be taken care of first, it will probably be another year or two before I start working in the earnest on this project. M~
Reply subtree:
3445 [pcb-rnd] COT data model (was: non-graphical schematics, layout) from Mychaela Falconia <my...@gmail.com>
3448 Re: [pcb-rnd] COT data model (was: non-graphical schematics, layout) from Bob Paddock <bo...@gmail.com>
3450 Re: [pcb-rnd] COT data model (was: non-graphical schematics, layout) from Mychaela Falconia <my...@gmail.com>
3451 Re: [pcb-rnd] COT data model (was: non-graphical schematics, layout) from Bob Paddock <bo...@gmail.com>