you just use a via and short track in the component footprint design 
and then run update free primitives (yes i know they are not 'free')
it works
no drc probs

am i on the same page as this discussion or maybe i have missed


JaMi Smith wrote:
> Julian,
> Please see below.
> JaMi
> ----- Original Message -----
> From: "Julian Higginson" <[EMAIL PROTECTED]>
> To: "'Protel EDA Forum'" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 03, 2003 1:28 AM
> Subject: Re: [PEDA] eight-layer stackup
> >
> > > From: JaMi Smith [mailto:[EMAIL PROTECTED]
> >
> > > While there may be some way somewhere to make Protel ignore
> > > those dogbones
> > > and vias, DRC wise, I don't think that there is a way to do
> > > it easily short
> > > of putting them on the schematic, possibly as test points, so
> > > that each of
> > > them actually becomes a real "net" it the netlist. You could
> > > turn off some
> > > of your Design Rules, but that would really just be asking
> > > for more trouble.
> > >
> > yeah there is a way:
> >
> > Don't use synchronisation in the ddb, use NETLIST GENERATION and NETLIST
> >
> > In the netlist generation in schematic, you can tell it to include unnamed
> > single pin nets. You will then get nets assigned to all your unused pins
> on
> > your BGA.
> >
> You have kind of lost me here on this one. It appears that no matter what
> you do you have to go back and screw around with the schematic somehow so
> that you can actually get a real live net in the netlist that will represent
> the little "dogbone" trace and the via. It also sounds like I have to have
> make a rule to allow a single pin net, and then actually put that connection
> into the schematic that would become a single pin net. Kinda sounds just
> about like I said but without the testpoint.
> Why on earth would I not want to keep synchronization intact? All in all, it
> sounds like I am doing more work and asking for more problems then
> necessary, and then opening the door for some real errors to sneak in
> undetected.
> Once again, I would rather have the little DRC "error" starring me in the
> face. At least this way I would not miss any other "errors" due to the fact
> that I was tricking Protel.
> I would still like to see a Protel 99 SE "server" to "handle" DRC "errors"
> like I discussed in my post to you regarding your "split plane" problem
> earlier this week, and I would like to see Protel DXP incorporate the
> "solution" to the issue that I discussed.
> > > I would also suggest that you definitely look into using separate
> > > complete layers for power and ground under your BGA as opposed
> > > to trying to juggle split planes.
> >
> > Jeez. How many layers does he have spare for power planes?? my BGA needed
> 3
> > of the buggers. Split planes are the only way to go. Just be really
> careful
> > not to bridge them with a through hole pin like I did...
> >
> > Julian
> > (who got his BGA board not reporting errors, and the BGA part of it is
> fine)
> >
> I'd first like to thank John Haddy and Tom Reineking for the very important
> points that they both brought up along this line in there related responses
> to your post.
> I have spent too many hours out on an FCC OATS (Open Area Test Site) or in
> an Screen Room or Anacoic Chamber trying to track down EMC / Signal
> Integrity problems in equipment that I was trying to get certified for FCC
> or CISPR (or even CTIC) compliance requirements to let this one slide by.
> It has been my experience that a majority of the emissions problems I have
> ever seen can be tracked down to a high speed  signal or clock line that has
> crossed a split in a plane. In addition to the reflection issue that was
> brought up by Tom, there is an even worse problem that has not been
> discussed.
> Simply stated, any signal that is traveling along a conductor over a plane
> will generate currents in the plane that are a mirror of those in the
> conductor. When you cross a gap in between two different planes, you will
> generate seperate currents in both of those planes. Those two different
> currents in each of the two planes will then travel throughout those two
> planes until they get to a common point and where they can cancel each other
> out. This may mean that they will travel to a common point on the board to
> cancel, or it may mean that they will travel all the way back to the power
> supply to cancel. Whatever the case, these currents will have to travel
> throughout the planes, affecting everything that is connected to the planes,
> until they can cancel. While decoupling caps will help the problem somewhat,
> they will not eliminate it. This is referred to as "infecting" the planes
> and supplies with "noise". Once you get this noise into a plane or power
> supply, it gets into everything, and there is no way to get rid of it. The
> only way to get this kind of noise out of a plane or supply is to keep it
> out of the plane or supply in the first place. Period.
> That is why rule number one in PCB Design is to never ever under any
> circumstance cross a split in a plane with a signal. Period. Rule number two
> is to never ever forget about or ignore or violate rule number one. I don't
> care what any of the "so called" experts have to say on this issue, you
> simply should not do it.
> This is such a fundamental rule in the industry that even Protel has this
> one down right, and will flag this as a DRC "error".
> Respecting your comment that you are the person  (who got his BGA board not
> reporting errors, and the BGA part of it is fine), I would say that there is
> a very vast and monumental difference between getting a board to pass Protel
> DRC, and correctly function at high speed from a real world electrical
> perspective (which not only means correctly operating, but also includes EMC
> and Signal Integrity issues).
> Two additional points that I would bring up here respecting having separate
> planes as opposed to split planes, are these:
> 1) Planes are relatively cheap in terms of stack up height. By that I mean
> you can add another plane (or pair) into a stack up for the thickness of the
> copper and a few mils of prepreg, as opposed to the additional spacing that
> may be required between planes if you are going to add another signal layer
> that may need certain spacings due to impedance or other requirements such
> as crosstalk.
> 2.) In an area such as under a BGA, having a separate solid plane that
> extends entirely under the BGA will allow you to add a tremendous amount of
> "decoupling" caps (both ceramics for high frequency and tantalums for good
> ESR and low inductance) around the periphery of the BGA, which will insure
> much better electrical performance of the BGA. This is especially helpful
> (if not absolutely necessary) when you have to mount BGAs back to back on
> both sides of the board and it is impossible to get any decoupling caps into
> the center of the BGA pattern.
> To somewhat complete the topic, I would once again bring up the issue of
> "thermal reliefs" when connecting power and ground pins on a BGA to the
> planes underneath the BGA, and once again state that one should NOT use any
> "thermal relief", which will decimate the planes, but rather make all of
> those connections to the planes DIRECT, since the "dogbone trace", properly
> sized, will provide all of the thermal isolation that is necessary to
> properly solder on the BGA. Rather than cover that subject again here, I
> would simply refer anyone who missed the discussion to my post in response
> to your problem earlier this week.
> One final note, If I understand your statement above correctly, your board
> has only 3 plane layers in the stackup. This is another "no no" in that it
> is what is called "unbalanced construction", but I will not digress here
> about it since it has been adaquately covered here in the forum.
> JaMi

Dennis Saputelli

  ========= send only plain text please! - no HTML ==========
Integrated Controls, Inc.   
2851 21st Street                    tel: 415-647-0480
San Francisco, CA 94110             fax: 415-647-3003

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to