Mail Archives: geda-user/2015/06/25/19:31:24
On Thu, Jun 25, 2015 at 10:42:39PM +0100, Peter Clifton wrote:
> On Thu, 2015-06-25 at 18:37 +0200, Gabriel Paubert (paubert AT iram DOT es)
> wrote:
>
> > Actually, I'm chasing the annoying bug that sometimes happens of a small
> > sliver of copper that creates shorts under very specific conditions and
>
> Did you try the patches I posted a while back... (15/02/2015). Email
> subject was "PCB users - Call for testing of polygon fixes"
No, I think I have found a pattern for my case, but still need a few
more tests.
>
> Unfortunately, I never quite finished cleaning up the remaining issues
> (mostly sanity checking the logic of a few things, and cleaning up some
> error-cases).
>
> The patches contain descriptions of the problems they fix, including
> some test-cases. From your description, it might be relevant to the bugs
> you mentioned.
>
> Perhaps you could see if they help in any of the files you have problems
> with).
Indeed, although I'm starting to have a proliferation of PCB trees on my
machines.
>
> > I've been diving in the polygon code for 2 days and a half, because it
> > caused systematic problems when generating Gerber files for a moderately
> > complex board: 80x200mm, ~680 components, but "only" 2000 pads since it's
> > relativly high frequency (up to 1GHz) and roughly half the components are
> > capacitors of various sizes (60 of them 0201, the rest mostly 0603 with
> > quite a few 1206 and some 0402 thrown in, three EIA7343 tantalum).
>
> One interesting Gerber file issue, is that board houses sometimes use
> only "flashed" pads for generating automatic test programs for flying
> probe testers.
>
> PCB doesn't (IIRC) generate flashed pads, at least not for all shapes. -
> I've had at least one case (I think) where boards have "passed"
> automatic testing, with manufacturing defects still present, and I think
> the underlying cause may have been the fab house's inability to
> auto-extract the pad locations.
AFAIR, PCB only uses flashes for vias and round pins and pads. Since
vias are tented in most of my designs, this leaves only the round pads.
I have less than 20.
>
> Ultimately, the gerber output HID should create macros for any shapes it
> needs, and always flash pads. (Sadly I've no time to dive in myself).
> This would also significantly reduce file-size, keeping the existing
> clearance shapes.
I agree that the Gerber driver should be modified. However, my feeling
is that a new driver (gerber2x or gerberx2?) should be written from
scratch, keeping the existing one as "legacy". The new one should try
to comply with the latest specifications where they are reasonable, one
of them being flashing all pads, pins and, vias since it clearly helps
electrical testing.
>
> > Anyway, the patch is appended, it boils down to:
> > - adding a new flag called "squareclearance" that changes the behaviour
> > of the clearance for non-circular pads and pins.
> > - enable this feature by essentially copying the code fragments for the
> > "square" flag and renaming square to squarecleareance with appropriate
> > UPPER/lower/CamelCase.
> > - map the corresponding Toggle action to Alt-Q
>
>
> What was the use-case for this? (Stylistic, electrical design
> requirement, or workaround for the large / buggy gerber output?)
All of them (except file size) plus an educational one: hacking the code
helps me a lot in understanding it.
>
> I'm not against the possibility of this, but I do find the proliferation
> of flags somewhat distasteful. I guess we never did get around to that
> all encompassing file-format update.
>
> > - change some of the internal ABI of the polygon code that really
> > annoyed me, as well as reordering some structures for better packing.
>
> I'd be interested to see some/all of these change (clean or not), so I
> can inform myself before protesting against them ;). Ugly as the polygon
> code is, I've several WIP development branches that might be broken by
> major API changes.
I've not changed any internal API at all yet. For now the patches in
this area boil down to these modifications in the structure definitions:
diff --git a/src/polyarea.h b/src/polyarea.h
index 43fd93d..f63e83d 100644
--- a/src/polyarea.h
+++ b/src/polyarea.h
@@ -82,8 +82,8 @@ struct VNODE
{
VNODE *next, *prev, *shared;
struct {
- unsigned int status:3;
- unsigned int mark:1;
+ unsigned char status;
+ unsigned char mark;
} Flags;
CVCList *cvc_prev;
CVCList *cvc_next;
@@ -96,15 +96,15 @@ struct PLINE
Coord xmin, ymin, xmax, ymax;
PLINE *next;
VNODE head;
- unsigned int Count;
double area;
rtree_t *tree;
- bool is_round;
Coord cx, cy;
Coord radius;
+ unsigned int Count;
+ bool is_round;
struct {
- unsigned int status:3;
- unsigned int orient:1;
+ unsigned char status;
+ unsigned char orient;
} Flags;
};
The reasons are:
- when the structure size is at least a multiple of 4 bytes (32 bit),
and more likely 8 (64 bit machines and some 32 bit because there is
a double in there), it is stupid to use 2 bit fields when two
unsigned char fields will do (extracting from bit fields and
especially assigning to is more expensive). I'm aware that the first
Alpha machines could not store a byte and any access to a variable
shorter than 32 bit was painful (especially writes), but I don't
think there are many left around. On the other hand, using bit fields
hurts everybody.
- the is_round field in the middle of PLINE is very wasteful for
alignment. The same can be said for the Count field , which is the
only 4 byte value on 64 bit architectures: putting Count, is_round and
the Flags at the end takes 7 bytes. This saves 16 bytes per PLINE
struct on 64 bit machines.
- this may be non optimal on MacOSX, where sizeof(bool)==4 if what
I've read on the net is correct, but I don't have any Mac to test
(actually I have a decade old PPC base Mac, but I've eradicated
Nanny's^WMacOS from it). The solution is simple, use an unsigned char
instead, and prohibit the use of bool in any structure, especially
if it may be allocated in large numbers. For now is_round is not
used very much so the change should be trivial.
I'm not sure for the area field , IIRC the alignment of doubles depends
on the ABI for 32 bit architectures and anyway 64 bit is what really matters
these days.
- Raw text -