delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/06/25/19:31:24

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Envelope-From: paubert AT iram DOT es
Date: Fri, 26 Jun 2015 01:30:42 +0200
From: "Gabriel Paubert (paubert AT iram DOT es)" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] [RFC][PATCH] PCB: Allow non rounded clearances for
rectangular/square pins and pads
Message-ID: <20150625233042.GA32022@visitor2.iram.es>
References: <20150625163731 DOT GA18117 AT visitor2 DOT iram DOT es>
<1435268559 DOT 24445 DOT 13 DOT camel AT cam DOT ac DOT uk>
MIME-Version: 1.0
In-Reply-To: <1435268559.24445.13.camel@cam.ac.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -0.2 (/)
X-Spamina-Spam-Report: Content analysis details: (-0.2 points)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: iram.es]
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
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

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019