Mail Archives: geda-user/2015/02/18/23:12:44
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-85233039-1424319046=:7324
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Wed, 18 Feb 2015, John Griessen wrote:
> On 02/18/2015 12:05 PM, gedau AT igor2 DOT repo DOT hu wrote:
>> That would result in separate copper pads that find.c thinks are magically
>> connected but are not connected in reality (unless you
>> soldered a component or wire on them that realizes the "internal
>> connection").
>
> I was thinking of a large pad in the center that connects them with copper.
> So that the footprint itself is
> the component.
That's one pad extra. I think it would work without an extra pad, but the
idea is otherwise the same.
>
> On 02/18/2015 03:26 AM, gedau AT igor2 DOT repo DOT hu wrote:>
>> My proposal makes this more explicit because the non-overlapping parts of
> the pads would be sticking out, like bristles of a
>> hedgehog and there is an 1:1, visible connection between a pad and nets.
> Just like with connectors now.
>
> How to do like that? I guess intconn does not do it, I've also been confusing
> it too.
As I said, intconn can not do this. There are two different problems. One
is the star connection, which is not solved by intconn, and the other is
the classic "smd 0 ohm jumper" problem which is solved by intconn. The
confusing part is that the two features are doing similar thing at a
level. I will try to clarify this at the bottom of this mail.
>
> The description of how to create a star connection component could be:
>
> The "Star connection point" has one more pin than the number of nets desired
> to connect
> as one physical net with branches that star outward from the star point.
>
> The pins around the edges pass drc by spacing apart from each other, but
> overlap a central pad
> that connects them all.
>
> DRC rules allow a short to go unreported in a radius from the center of the
> "Star connection point".
>
> One pin has an attribute "highest_name" whose value could be VCC or GND or
> XXX. The others lack that
> attribute, and might have netnames like VCC-A1 VCC-D1 VCC-D2...
>
>
> Netlisting creates a netlist with the "highest_name" value on all of the nets
> attached to all the pins
> of the "Star connection point". PCB would be able to highlight or associate
> netname with paths and pads,
> and optionally associate of highlight or match netlist to "highest_name" and
> all that touch it through
> the star point.
>
I think my proposal #3 was simpler and does not depend on a radius, nor
does it require introducing an extra pad. It also doesn't require any
change in the netlist.
Below I will try to explain the two concepts from all aspects I can think
of. Sorry, it's a wall of text.
Note: it was long ago I did intconn so some details in the following
explanation may be wrong (e.g. whether it goes depth-first or not). Please
ignore such mistakes, the important aspect does not depend on these
details.
What find.c did before the intconn patch was this (described in an
oversimplified way):
0. There is a starting object and the task is to list everything that's
(galvanically (copper) or logically (rat)) connected to
it on the current design. Set the current object to the starting object
and mark it found. Clear the mark from all objects on the design. Make an
empty object list called the "open list".
1. Check all non-marked traces, find the first that touches the current
object. If found, mark it, put it on the open list, go to 1, else go to 2.
2. Check all non-marked polygons, find the first that touches the current
object. If found, mark it, put it on the open list, go to 1, else go to 3.
3. Do the same with vias, pins, pads, arcs, rats, etc., you get the point.
4. If we got here, we finished mapping/marking/listing all objects
that is in direct contact with our current object. Throw away the current
object. If the open list is not empty, take the first object from the open
list and make it the current object and go to 1, else go to 5.
5. If we got here, the open list is empty, we finished mapping all
connected objects.
Run this from a trace for example. You will soon or later hit a pad. If
the pad is not connected to any other objects, it is a dead-end and, the
search ends there. This is the most common case on a finished design.
The intconn patch adds this to the above, to the points where pad and pin
connections are considered:
3a. if it is a pin or a pad, also check whether it has intconn() set. If
it does, imply a _logical_ connection between the current pin/pad and all
the pins/pads that are connected: mark those pins/pads, put them on the
open list. In other words: some pins/pads are connected in reality even if
they are not connected on the PCB, and find.c must be able to follow those
"non-existent" connections as well. NOTE: intconn() must be a property of
the pad as there may be multiple groups of independent internal
connections in an element.
The star patch which we need works on the same spot, but does the
opposite:
3b. if the current object is a pad/pin (let's call it A) and the next
non-marked object is also a pad/pin (call it B), and the two pads are part
of the same element and the element is marked as "pads don't short",
do _not_ mark B. In other words: althoug there is an explicit, visible
physical connection on copper between your pads, just ignore it! NOTE: the
"pads don't short" could be a property of the whole element (easy support
for stars) or a per-pad property.
For the star, we need the second feature.
The first feature (intconn) would leave us with:
- a set of pads not physically connected
- while pcb thinks they are connected (assuming you solder some component
on them that will connect them)
So it is useful in _adding_ "find.c connections" where there is no
physical connection. It is a permission for find.c to jump to a seemingly
unconnected pad.
The second feature ("pads don't short") sets it up so we have:
- a set of pads connected physically by thick copper
- still pcb thinks they are totally separated pads with no connection
- ... unless you connect them by traces elsewhere (this would indicate
shorts other than in the middle of the star component)
- each pad is connected to it's dedicated network
So it is useful in _removing_ a "find.c connection" where there's real
copper connection on the design. It is a logical blocker or barrier for
find.c so it won't jump from one pad to another inside a star element.
I think the confusion comes from the fact that the two features differ
only in "sign" on this level, adding or removing a find.c jump.
Attached are two examples of how I imagine a star footprint. PCB is not
very good in displaying pin numbers, so the upper pad's numbers are not
visible (could be tweaked by mirroring the pads I guess).
Regards,
Igor2
--0-85233039-1424319046=:7324
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=star1.fp
Content-Transfer-Encoding: BASE64
Content-ID: <alpine DOT DEB DOT 2 DOT 00 DOT 1502190510450 DOT 7324 AT igor2priv>
Content-Description:
Content-Disposition: attachment; filename=star1.fp
DQpFbGVtZW50WyIiICIiICIiICIiIDE2MDAwMCAxNDI1MDAgMCAwIDAgMTAw
ICIiXQ0KKA0KCVBhZFswIC0xMjUwMCAwIDAgNTAwMCA1MDAwIDc1MDAgIiIg
IjEiICJzcXVhcmUiXQ0KCVBhZFstMTI1MDAgMCAwIDAgNTAwMCA1MDAwIDc1
MDAgIiIgIjIiICJzcXVhcmUiXQ0KCVBhZFswIDAgMCAxMjUwMCA1MDAwIDUw
MDAgNzUwMCAiIiAiMyIgInNxdWFyZSxlZGdlMiJdDQoJUGFkWzAgMCAxMjUw
MCAwIDUwMDAgNTAwMCA3NTAwICIiICI0IiAic3F1YXJlLGVkZ2UyIl0NCg0K
CSkNCg==
--0-85233039-1424319046=:7324
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=star2.fp
Content-Transfer-Encoding: BASE64
Content-ID: <alpine DOT DEB DOT 2 DOT 00 DOT 1502190510460 DOT 7324 AT igor2priv>
Content-Description:
Content-Disposition: attachment; filename=star2.fp
DQpFbGVtZW50WyIiICIiICIiICIiIDIwMDAwMCAxMjc1MDAgMCAwIDAgMTAw
ICIiXQ0KKA0KCVBhZFswIDAgMCAxMjUwMCA1MDAwIDUwMDAgNzUwMCAiIiAi
MSIgInNxdWFyZSJdDQoJUGFkWzc1MDAgMCA3NTAwIDEyNTAwIDUwMDAgNTAw
MCA3NTAwICIiICIyIiAic3F1YXJlIl0NCglQYWRbMTUwMDAgMCAxNTAwMCAx
MjUwMCA1MDAwIDUwMDAgNzUwMCAiIiAiMyIgInNxdWFyZSJdDQoJUGFkWzIy
NTAwIDAgMjI1MDAgMTI1MDAgNTAwMCA1MDAwIDc1MDAgIiIgIjQiICJzcXVh
cmUiXQ0KCVBhZFswIDIwMDAwIDAgMzI1MDAgNTAwMCA1MDAwIDc1MDAgIiIg
IjUiICJzcXVhcmUsZWRnZTIiXQ0KCVBhZFs3NTAwIDIwMDAwIDc1MDAgMzI1
MDAgNTAwMCA1MDAwIDc1MDAgIiIgIjYiICJzcXVhcmUsZWRnZTIiXQ0KCVBh
ZFsxNTAwMCAyMDAwMCAxNTAwMCAzMjUwMCA1MDAwIDUwMDAgNzUwMCAiIiAi
NyIgInNxdWFyZSxlZGdlMiJdDQoJUGFkWzIyNTAwIDIwMDAwIDIyNTAwIDMy
NTAwIDUwMDAgNTAwMCA3NTAwICIiICI4IiAic3F1YXJlLGVkZ2UyIl0NCglQ
YWRbLTYyNTAgMTYyNTAgMTEyNTAgMTYyNTAgNzUwMCA1MDAwIDEwMDAwICIi
ICI5IiAic3F1YXJlIl0NCglQYWRbMTYyNTAgMTYyNTAgMzEyNTAgMTYyNTAg
NzUwMCA1MDAwIDEwMDAwICIiICIxMCIgInNxdWFyZSxlZGdlMiJdDQoNCgkp
DQo=
--0-85233039-1424319046=:7324--
- Raw text -