Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Feb 5, 1:53=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Feb 5, 3:59=A0am, Sean Durkin <news_MO...@tuxroot.de> wrote: > > > > > This just had me stuck for 2 days, measuring ripple on my supply, > > checking my clocks, checking the layout and so on. I probably would've > > sent the board out for x-rays to check for soldering issues next, hadn'= t > > I by chance run across a colleague in the corridor who had the same > > problem 5 years ago. > > So did you solve your problem then? =A0The title suggests the problem > was found. > > A system which stops generating a clock once the done pin goes high > still needs a couple more clocks with the default Done=3D4 time > position. =A0Changing to Done=3D6 got rid of the head scratching many, > many years ago. Just remember that there was a reason for the default setting, namely to allow an orderly startup of multiple devices. If you're only starting up one device on this configuration chain there's no need to delay startup until after DONE goes high.Article: 145326
(comp.dsp added, as there are people there who consider these problems.) rickman <gnuarm@gmail.com> wrote: > On Feb 5, 6:42 am, Symon <symon_bre...@hotmail.com> wrote: (snip) >> In my designs, and perhaps yours too, the power plane, such as it is, is >> useless as a reference plane for the simple reason that it's chopped up >> into many different pours for all the different voltages. I don't think >> you are suggesting a separate layer for each separate voltage? So, there >> will be slots in the plane, and every time a fast signal passes across >> this slot, you'll get the thing radiating as a good slot antenna does! >> You could add a bunch of bypass caps to bridge between the planes, but >> there's rarely space for this with a dense BGA design. For sure, if your >> planes are close together in the middle of your stack, this problem is >> small, but then you need wider surface traces to get the impedance you >> require. It is not at all easy to figure out the impedance of ground (or power) planes. There have been long discussions, either here or in other groups, about signals crossing slots between planes. I believe that it isn't as simple as you say, but one should still be careful about it. >> So, I recommend multiple ground planes close to all your signals. A >> thick core in the centre of the board to make up the correct thickness. >> Then you can simply forget about any slot issues. Like you say, this >> lets you keep the traces thin and with a lower characteristic impedance, >> which is normally what you want when routing BGA FPGAs. The two ground >> planes should be well bonded with vias, so there isn't a problem when a >> signal goes through a via and passes from being referred to one ground >> plane to the other. > Below, you talk about the connecting of the power and ground plane by > spacing to be of little value and yet propose that vias are adequate > to couple multiple ground planes. I find that interesting. For a > signal passing between layers the return current would have a long > path to reach a via and back. I believe, for the most part, it doesn't do that. The capacitance of even a single plane is high enough at the higher frequencies that for the most part the return current doesn't have to take the long way around. >> I reject the notion of placing a power plane and a ground plane close >> together in the middle of the board to get the benefit of the >> inter-plane capacitance for bypassing reasons. Don't get me wrong, it >> won't hurt, but IMO the amount of capacitance gained is tiny, and even >> though it is a very high Q capacitor, getting the power to the die is >> stymied by the inductance of the vias and BGA balls that are part of the >> PDS. I think I agree with this. The way to actually see this is to calculate the radial propagation of the signal into the plane from the via. The impedance (both inductance and capacitance) will change with radial distance and frequency. >> If your power plane is in the middle of the board, the signal path >> of these vias are longer. You don't care about the supply stiffness on >> your plane, it's on the die that counts. Well, I think it is both. For a single supply via, yes. But if you add them all up, then the ground plane has to supply (or sink) the total of all the vias, and some of that comes from the interplane capacitance. The via inductance will be most important at the highest frequencies. The ground plane at slightly lower, but still significant frequencies. At some point there is a tradeoff between the two, and you have to figure out what that means in terms of plane positioning. >> If you graunch off the metal >> cover of an FPGA you'll see that the manufacturer has already had to add >> bypass caps on the BGA substrate for this very reason. Furthermore, if >> you have a PCB ground plane close to the surface and hence close to the >> FPGA, the cavity between the PCB ground plane and the ground plane in >> the FPGA is smaller, reducing the inductance of the vias and BGA balls >> and so reducing stuff like ground bounce. >> So, IMO, the disadvantages of having the planes further from your >> signals and components more than outweigh the tiny gain in bypass >> capacitance you gain. > I'm a bit unclear on what you are saying. You are suggesting that the > impedance of the vias is enough that you should put the planes as > close as possible to the component surface, but then you recommend > putting the decoupling caps on the back side much further away from > the component with longer vias. To see this, you have to think of it in frequency (Fourier) space. The switching currents have frequency components over a wide range, with a peak somewhere near 1/(transition time) but significant over a range of lower frequencies. The highest ones are supplied by the internal capacitors. The next lower ones by the ground plane itself, near the via. Lower still by the ground plane farther away, where interplane capacitance is important. Then there are the onboard bypass capacitors, the power supply bypass capacitors, the power supply filter capacitors, etc. >> I say better is to put your bypass caps as close as possible to the >> FPGA, and maybe use puddles of copper close to the ground planes to >> maximise the via and capacitor utilization. Here's an article showing >> what I mean. Fig. 2. >> http://www.x2y.com/bypass/mount/backside_cap.pdf >> Whatever, YMMV, and I'm sure your designs work just fine. It's hard to >> cock it up, but I contend that the dual ground plane design I suggest >> above is nigh on impossible to go wrong with from an SI point of view, >> even if you have absolutely no clue what you're doing. That's why I use it! > Yes, one common element is that most designs apply overkill in the > supply decoupling area. When an engineer uses a method and it works, > it is like the elephant protection charm... you don't see any > elephants do you, so it must be working! > I would likely not use the offset coupled planes you describe mainly > because it only works well for boards with active components on only > one side. > In Lee Ritchey's class I asked about adding caps to the package to > overcome lead inductance causing ground bounce. He showed me that the > bounce is caused by the switching currents of driving an external > signal travel in a loop and independent of any capacitance on the > package, still have to travel through the leads of the part (even if > they are only bonding leads). In fact, there is *nothing* you can do > about the series inductance of pins in a package other than fix the > package. That is why I seriously doubt that the small added > inductance of 30 mil of a via is significant in any but the highest > speed designs. But as you say, YMMV. Yes. The problem comes with switching a large number of lines at very close to the same time. Since they won't be at exactly the same time (propagation delay to the pads) the highest frequency components aren't as important as you might think. The peak frequency of the ground current, then, will depend on how close the transitions are to each other more than the transition rate. Now, consider writing zero to a 64 bit data bus. All drivers going low on the same clock cycle! -- glenArticle: 145327
Mike Harrison <mike@whitewing.co.uk> wrote: (snip) > up to date, James Larson created "Motherboard Operation" - players > take it in turns to snip components from a working, running PC > motherboard until it stops working... > This was accompanied by "PC PSU Buckaroo" - players choose and add > more and more loads to an old PC power supply until it fails.... I haven't tried it recently, but it used to be that PC power supplies would fail at zero load. I did it once (I don't remember why) and smoked one. (Yes, real smoke.) The original PC/AT had an optional hard disk drive. If you didn't buy one there was a load resistor on the power supply to meet the minimum load requirement. You would think that the AT motherboard would take enough current, but it seems not. -- glenArticle: 145328
rickman <gnuarm@gmail.com> wrote: > On Feb 5, 8:45 am, Symon <symon_bre...@hotmail.com> wrote: (really big snip) >> with a thick centre core and routed powers. This way the internal signal >> layers are shielded. I tend to agree. The ssggss stack I suggested >> because I almost always use laser drilled micro-vias on my boards, so I >> need two signal layers on the outside. Also, my enclosures do the EMC >> shielding. With standard vias, sgssgs is probably better. (snip) > As to the return current having to "jump" between layers being a > problem, if you use the ssgpss stackup and have the power and ground > very close rather than widely spaced, the capacitive coupling allows > the signal to switch between them without issue. In fact, when > splitting a plane for multiple power sections, the return current will > switch from one power plane, to the ground plane and back to the next > power plane as if they were all one plane. This is because of the > capacitive coupling between layers. Of course this only works for the > highest frequency components of the signals, but that's all we really > care about, no? > -------+ +-------> Return Current > =======| |======== Power Planes > | | > +--+ > =================== Ground Plane Yes. Actually, I believe that for the really highest frequency components, that they are supplied by the plane itself. (Especially as signals won't be switching at exactly the same time.) The slightly lower ones, but only slightly, will take the path you mention. Frequencies with wavelength shorter than the long path around won't be able to take that path. The lower frequencies are still there, though, but at low enough levels that ordinary bypass capacitors and interplane capacitance will take care of them. -- glenArticle: 145329
In comp.arch.fpga Eric Chomko <pne.chomko@comcast.net> wrote: > Has anyone created a copy machine of an old system using an FPGA? I > was wondering if it would be possible to take an entire SWTPC 6800 and > compile the schematics and have it run on an FPGA board.? Wouldn't > even have to be the latest Xylinx product, I suspect. I haven't done it yet, but I am interested. I have a Digilent Spartan3E board for that purpose. I think it is big enough for the whole system for many of those machines. -- glenArticle: 145330
John_H wrote: > So did you solve your problem then? The title suggests the problem > was found. Yes, it just took me awhile to get there. > A system which stops generating a clock once the done pin goes high > still needs a couple more clocks with the default Done=4 time > position. As I said, I've never seen this before when using iMPACT. I'd expect it would know how many clock cycles are needed. When uploading the bitstream with a microcontroller or something, I always keep clocking for awhile after the bitfile is transferred, but with iMPACT (which I use in the lab for quick first tests before the rest of the infrastructure is up and running) this has never been necessary. Nor have I ever had to fiddle with the startup sequence before. > Changing to Done=6 got rid of the head scratching many, > many years ago. Well, I've never needed that setting until now. I guess I've done about ten boards myself and used a dozen others, and never changed that setting. The question is: why does this happen on this particular board and not on any others I've ever encountered? Just trying to understand where this comes from. cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).Article: 145331
Gabor wrote: > I have seen this exact problem with embedded programming. The > processor > would stop CCLK (slave serial in this case, but the same idea) as soon > as it saw DONE, but it would only check for DONE starting after the > last bit of the configuration bitstream. The problem only showed up > for some iterations of the design, because apparently the bitstream > doesn't always end on a byte boundary and the number of extra bits > might or might not be enough to clock the FPGA into the end of the > startup sequence. I've had this happen when using .bit-files, since they include stuff like date and project name, which I usually auto-generate in a script wenn running the flow, hence the size varies. But these days I usually only program bin-files, since then that problem went away at least. But anyway, shouldn't iMPACT be smart enough to know how many clock cycles are needed? And why doesn't it complete the rest of the startup sequence only on this one particular board? Maybe it's just a bug in IMPACT... :) cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).Article: 145332
rickman <gnuarm@gmail.com> wrote:
...
> I guess I was hoping for a little more detail than just "it's from the
> data sheet". Like I said, to get a clock to output timing requires
> you to add several numbers depending on the IO types you are using.
> Exactly what part are you using and what IO types and configuation?
> The post layout timing will only be as accurate as the information it
> is provided with. I'm not trying to be a pain, but I noticed that
> this number exactly matches the base number for clock to output
> timing, XC3S200A, DCM not in use -4 speed grade. This value is only
> valid if you are using LVCMOS25 on both the clock port and the output
> with 12 mA drive. Of course, it is possible that this same value came
> from some other combination of chip and configuration.
LVCMOS25 is default, if nothing else is constrained. And the timing report
for the LVCMOS/fast/8 mA case said something like
COMP "adbus<0>" OFFSET = OUT 11 ns BEFORE | MAXDELAY | 0.064ns|
11.064ns| 0| 0
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 145333
Eric Chomko wrote:
> Has anyone created a copy machine of an old system using an FPGA? I
> was wondering if it would be possible to take an entire SWTPC 6800 and
> compile the schematics and have it run on an FPGA board.? Wouldn't
> even have to be the latest Xylinx product, I suspect.
No fpga, but same idea:
http://www.grc.com/pdp-8/pdp-8.htm
-- Mike Treseler
Article: 145334"Eric Chomko" <pne.chomko@comcast.net> wrote in message news:badc12c3-cb2b-4ce9-9543-237d60fc22d5@o8g2000vbm.googlegroups.com... > Has anyone created a copy machine of an old system using an FPGA? There have recently been some discussions along these lines in the comp.lang.modula2 newsgroup regarding different ways of re-implementing a Lilith. Also MiniMig is an Amiga 500 re-implemented using an FPGA. http://en.wikipedia.org/wiki/Minimig -- Chris Burrows CFB Software http://www.cfbsoftware.com/modula2Article: 145335
On Feb 5, 12:49=A0pm, Gabor <ga...@alacron.com> wrote: > On Feb 5, 1:13=A0pm, austin <aus...@xilinx.com> wrote: > > > > > Pat, > > > We have encrypted hspice models as shown, mostly only for Virtex > > family parts, for "heavy lifting" customers who require them. > > > Since the devices models belong to Toshiba, IBM, UMC (etc.), these > > must be protected (they do not belong to us), so the hspice encrypted > > models are what we support. =A0Period. > > > IBIS models exist for all families, and parts. =A0These are per the IBI= S > > standard, so any tool that works with the IBIS standard should support > > these models. =A0If it doesn't then we need to know (file a webcase so > > we can see why it didn't work). > > > The latest IBIS extension is for the high speed serial IO on newer > > parts, also supported per the standard. > > > xSpice (n, p, x, etc. take your pick) are not supported. =A0Period. > > > Austin > > A quick Google of "convert IBIS models to spice" brings up quite > a few conversion tools. =A0Perhaps you could try to run the Spartan > 3A IBIS model through a converter? On my computer, googling "convert IBIS models to spice" brought up a lot of pointers to a SINGLE tool from 1998, and a lot of tools which go from spice to IBIS. But, you might be more adept at googling than me, so if you find more than the tool at intusoft, please share. Thanks, PatArticle: 145336
Eric Chomko wrote: > Has anyone created a copy machine of an old system using an FPGA? I > was wondering if it would be possible to take an entire SWTPC 6800 and > compile the schematics and have it run on an FPGA board.? Wouldn't > even have to be the latest Xylinx product, I suspect. I did. Some 8 years ago. http://alexfreed.com/FPGApple/ And then a few other vintage computers. -Alex. --- news://freenews.netfront.net/ - complaints: news@netfront.net ---Article: 145337
On Feb 5, 12:13=A0pm, austin <aus...@xilinx.com> wrote: > xSpice (n, p, x, etc. take your pick) are not supported. =A0Period. Thanks for the clarification. A simple perusal of the web page when I was tired didn't make that fact clear. And I understand that you can't share third-party IP. But, it seems like you're in a perfect position to build a simplified model, check it against the third party IP models, and distribute it with no warranties and the caveat that it is simplified, and matches reasonably well, but not perfectly. I don't know if you tally these things or not, but if you do, please put me down in the category of "would like to see pin spice models available." Thanks, PatArticle: 145338
On Feb 5, 7:03=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > And I understand that you can't share third-party IP. =A0But, it seems > like you're in a perfect position to build a simplified model, check > it against the third party IP models, and distribute it with no > warranties and the caveat that it is simplified, and matches > reasonably well, but not perfectly. To add to this, intusoft apparently has a more up-to-date ibis->spice converter for paying customers (and other EDA vendors may as well). If the fabs don't object to Xilinx shipping the data in an IBIS file, they certainly shouldn't be able to object to you converting that data back to a spice model using such a third-party tool. Again, Xilinx is in the best position to do this, because (1) then the conversion is only done one place and hopefully only has to be paid for once; and (2) somebody who can legally use the original spice model can eyeball the results of a few sims to make sure the converter didn't go completely wacky. I may not represent most of your customers, in that I'm completely paranoid about how things work, but the more I think about it, the more I think that, personally, even if I wanted to use your IBIS models, I can't trust them, because it sounds like you haven't round- tripped them back to spice and checked that they match the original models reasonably well. Best regards, PatArticle: 145339
On 2/5/2010 9:53 PM, glen herrmannsfeldt wrote: > > Yes. Actually, I believe that for the really highest frequency > components, that they are supplied by the plane itself. (Especially > as signals won't be switching at exactly the same time.) > Hi Glen, If these highest frequencies are supplied by the planes, why do Xilinx and Altera put capacitors on the BGA substrate? That must cost money. Are they wrong? Thanks, Symon.Article: 145340
On 2/5/2010 2:44 AM, Patrick Maupin wrote: > Xilinx Spartan 3A pin > > > Any thoughts? > > Thanks, > Pat Pat, the pins are a 10pf capacitor. HTH, Syms. p.s. More or less!Article: 145341
Symon <symon_brewer@hotmail.com> wrote: > On 2/5/2010 9:53 PM, glen herrmannsfeldt wrote: >> Yes. Actually, I believe that for the really highest frequency >> components, that they are supplied by the plane itself. (Especially >> as signals won't be switching at exactly the same time.) > If these highest frequencies are supplied by the planes, why do Xilinx > and Altera put capacitors on the BGA substrate? That must cost money. > Are they wrong? OK, not quite the highest frequencies, but almost. The highest that get through the inductance of the package and past the internal capacitors. I think it isn't so hard to calculate the impedance of an infinite plane with a hole (via) as a function of frequency. That should partly answer the question. -- glenArticle: 145342
On Feb 5, 8:05=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 2/5/2010 2:44 AM, Patrick Maupin wrote: > > > Xilinx Spartan 3A pin > > > Any thoughts? > > > Thanks, > > Pat > > Pat, the pins are a 10pf capacitor. > > HTH, Syms. > > p.s. More or less! Thanks, Symon, that is indeed very useful. My current needs are in regard to the differential receiver (probably in LVDS mode). I have a (slow, around 1 MHz) Manchester-encoded differential signal that might be at a really low level (or a really high level!), and that requires level shifting as well. I want to bring it in to the LVDS pins, probably through a small external preamplifier with some AC coupling. Naturally, I want to simplify the preamp as much as possible, so it would be great to be able to simulate it in conjunction with the receiver. Obviously, simulating the receiver as a couple of caps to ground and looking at the voltages at the pins to make sure they are within LVDS spec is a good start, but it would be really excellent to be able to see the recovered signal out the back of the receiver in the simulation. Basically, I'm just trying to save an external comparator. Slow comparators are available in smallish quantities for under 30 cents, but the prices for faster ones just seem unreasonable, and since I'm doing all the clock and data recovery digitally, I prefer to have a fair degree of accuracy on the location of the signal edges. Thanks, PatArticle: 145343
> Basically, I'm just trying to save an external comparator. =A0Slow > comparators are available in smallish quantities for under 30 cents, > but the prices for faster ones just seem unreasonable, and since I'm > doing all the clock and data recovery digitally, I prefer to have a > fair degree of accuracy on the location of the signal edges. Forgot to mention. In this design, I have a lot of pins available. The smallest FPGA is a sunk cost, with a lot of resources which I am trying to use cleverly (but not so cleverly I get burned in production). Since the signal is so slow, I am considering providing hysteresis to the comparator by outputting the decoded signal back out an LVDS transmit pair. At 1 MHz, even a 15 ns prop delay in providing a tiny hysteresis should not be a problem, I don't think, but I'd love to have a reasonably accurate model to test this against. Thanks, PatArticle: 145344
Patrick wrote: > > But, you might be more adept at googling than me, so if you >find more than the tool at intusoft, please share. > I poked a stick at the free Intusoft tool some years back, it didn't help me much as the IBIS models I needed to translate were a later version than it supported. I have manually extracted info from the IBIS tables and package models to set up LTspice runs; this works well when verified against lab measurements. ----------- FWIW, I posted an simple, unverified LVDS LTSPICE sim here a few years ago showing problems that arise when driving a typical FPGA input from a fast LVDS A/D with sub-ns high impedance current source outputs : http://groups.google.com/group/comp.arch.fpga/msg/ab999f47d42e50f8 http://fpgastuff.googlepages.com/lvds_current.pdf http://fpgastuff.googlepages.com/lvds_current.zip ----------- Free tools that might help: Edality's IBIS tool has a free viewer-only mode that I find useful: http://www.edality.com/ibisds/v1/ Eispice looks interesting ( haven't used this one yet ), includes some sort of IBIS model support: http://www.thedigitalmachine.net/eispice.html BrianArticle: 145345
On Feb 5, 9:23=A0pm, Brian Davis <brimda...@aol.com> wrote: > Patrick wrote: > > > But, you might be more adept at googling than me, so if you > >find more than the tool at intusoft, please share. > > =A0I poked a stick at the free Intusoft tool some years > back, it didn't help me much as the IBIS models I needed > to translate were a later version than it supported. > > =A0I have manually extracted info from the IBIS tables > and package models to set up LTspice runs; this works > well when verified against lab measurements. > > ----------- > > =A0FWIW, I posted an simple, unverified LVDS LTSPICE sim > here a few years ago showing problems that arise when > driving a typical FPGA input from a fast LVDS A/D with > sub-ns high impedance current source outputs : > =A0http://groups.google.com/group/comp.arch.fpga/msg/ab999f47d42e50f8 > =A0http://fpgastuff.googlepages.com/lvds_current.pdf > =A0http://fpgastuff.googlepages.com/lvds_current.zip > > ----------- > Free tools that might help: > > Edality's IBIS tool has a free viewer-only mode that I find useful: > =A0http://www.edality.com/ibisds/v1/ > > Eispice looks interesting ( haven't used this one yet ), > includes some sort of IBIS model support: > =A0http://www.thedigitalmachine.net/eispice.html > > Brian Very good links! Thanks! I don't know how, but I missed them when I did some research before I posted my question. PatArticle: 145346
On Feb 5, 6:55=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > rickman <gnu...@gmail.com> wrote: > > ... > > > I guess I was hoping for a little more detail than just "it's from the > > data sheet". =A0Like I said, to get a clock to output timing requires > > you to add several numbers depending on the IO types you are using. > > Exactly what part are you using and what IO types and configuation? > > The post layout timing will only be as accurate as the information it > > is provided with. =A0I'm not trying to be a pain, but I noticed that > > this number exactly matches the base number for clock to output > > timing, XC3S200A, DCM not in use -4 speed grade. =A0This value is only > > valid if you are using LVCMOS25 on both the clock port and the output > > with 12 mA drive. =A0Of course, it is possible that this same value cam= e > > from some other combination of chip and configuration. > > LVCMOS25 is default, if nothing else is constrained. And the timing repor= t > for the LVCMOS/fast/8 mA case said something like > =A0 COMP "adbus<0>" OFFSET =3D OUT 11 ns BEFORE | MAXDELAY =A0 =A0| =A0 = =A0 0.064ns| > =A0 =A0 11.064ns| =A0 =A0 =A0 0| =A0 =A0 =A0 =A0 =A0 0 Maybe I am missing something, but your original post said "XC200A and LVCMOS25/12mA/Fast slew drive TICKOF is 5.24 ns and timing can be met (16.666 -5.24 =3D 11.42 > 11)" The 5.24 ns value matches the data sheet value for LVCMOS25 on both the clock input and the driver output with 12 mA fast slew and not using the DCM. Using the 8 mA drive you list above adds 0.38 ns giving 5.62 ns. Subtracting from 16.666 gives 11.046 which is close to the result above, but not a perfect match. I don't know if there is still a mismatch between your constraints and the data I am using or maybe the timing file is more up to date than the data sheet. Either way, I guess I am asking if the description of your I/Os is as above, both the clock input and the driver output at LVCMOS25 and the output at 8 mA FAST and the DCM is not being used. If you want to get a little more margin in your timing, which is where I think you are taking this, you can utilize the DCM and improve your margin by almost 2 ns! RickArticle: 145347
On Feb 5, 4:38 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > (comp.dsp added, as there are people there who consider these problems.) > > rickman <gnu...@gmail.com> wrote: > > On Feb 5, 6:42 am, Symon <symon_bre...@hotmail.com> wrote: > > (snip) > > >> So, I recommend multiple ground planes close to all your signals. A > >> thick core in the centre of the board to make up the correct thickness. > >> Then you can simply forget about any slot issues. Like you say, this > >> lets you keep the traces thin and with a lower characteristic impedance, > >> which is normally what you want when routing BGA FPGAs. The two ground > >> planes should be well bonded with vias, so there isn't a problem when a > >> signal goes through a via and passes from being referred to one ground > >> plane to the other. > > Below, you talk about the connecting of the power and ground plane by > > spacing to be of little value and yet propose that vias are adequate > > to couple multiple ground planes. I find that interesting. For a > > signal passing between layers the return current would have a long > > path to reach a via and back. > > I believe, for the most part, it doesn't do that. The capacitance > of even a single plane is high enough at the higher frequencies > that for the most part the return current doesn't have to take > the long way around. What do you base this on? And what do you mean by the "capacitance of even a single plane"??? What is the sound of one hand clapping? Isn't capacitance measured between two conductors? Above you said, "The two ground planes should be well bonded with vias, so there isn't a problem when a signal goes through a via and passes from being referred to one ground plane to the other." How is bonding the planes with vias useful if the current has to go all the way to a via and back in order to follow the trace??? > >> I reject the notion of placing a power plane and a ground plane close > >> together in the middle of the board to get the benefit of the > >> inter-plane capacitance for bypassing reasons. Don't get me wrong, it > >> won't hurt, but IMO the amount of capacitance gained is tiny, and even > >> though it is a very high Q capacitor, getting the power to the die is > >> stymied by the inductance of the vias and BGA balls that are part of the > >> PDS. > > I think I agree with this. The way to actually see this is to > calculate the radial propagation of the signal into the plane > from the via. The impedance (both inductance and capacitance) > will change with radial distance and frequency. That is why Lee Ritchey's course was such an eye opener for me. There are any number of ways you can "calculate" and theorize what happens in power planes. But unless you verify it by testing in hardware, you are just whistling in the dark. Lee has done that. One test he made that really impressed me was to show that a decoupling cap does not need to be close to a pin to work well. If the power and ground plane are closely spaced, the impedance is very low. If you understand transmission lines, you will know that the current into (or out of) a driver into the transmission line is constant until the signal reaches the other end and depending on what load it finds, either continues until the reflection returns to the driver (as in a series terminated line with high impedance load) or keeps flowing as when it reaches the decoupling cap. So if the cap is further away, the transmission line supplies the current for decoupling until the wave front reaches the cap. The point is that the planes have to be closely coupled for there to be a high enough capacitance (also known as a low enough impedance) to provide the current until the pulse reaches the cap. Lee actually built a board and has measurement data to show this. So analyze away if you want, but how can you dispute measurements? > >> If your power plane is in the middle of the board, the signal path > >> of these vias are longer. You don't care about the supply stiffness on > >> your plane, it's on the die that counts. > > Well, I think it is both. For a single supply via, yes. But if you > add them all up, then the ground plane has to supply (or sink) the > total of all the vias, and some of that comes from the interplane > capacitance. The via inductance will be most important at the > highest frequencies. The ground plane at slightly lower, but > still significant frequencies. At some point there is a tradeoff > between the two, and you have to figure out what that means in terms > of plane positioning. What exactly is any of this based on? > >> If you graunch off the metal > >> cover of an FPGA you'll see that the manufacturer has already had to add > >> bypass caps on the BGA substrate for this very reason. Furthermore, if > >> you have a PCB ground plane close to the surface and hence close to the > >> FPGA, the cavity between the PCB ground plane and the ground plane in > >> the FPGA is smaller, reducing the inductance of the vias and BGA balls > >> and so reducing stuff like ground bounce. > >> So, IMO, the disadvantages of having the planes further from your > >> signals and components more than outweigh the tiny gain in bypass > >> capacitance you gain. > > I'm a bit unclear on what you are saying. You are suggesting that the > > impedance of the vias is enough that you should put the planes as > > close as possible to the component surface, but then you recommend > > putting the decoupling caps on the back side much further away from > > the component with longer vias. > > To see this, you have to think of it in frequency (Fourier) space. > The switching currents have frequency components over a wide > range, with a peak somewhere near 1/(transition time) but > significant over a range of lower frequencies. The highest ones > are supplied by the internal capacitors. The next lower ones > by the ground plane itself, near the via. Lower still by the > ground plane farther away, where interplane capacitance is important. > Then there are the onboard bypass capacitors, the power supply > bypass capacitors, the power supply filter capacitors, etc. > > > > >> I say better is to put your bypass caps as close as possible to the > >> FPGA, and maybe use puddles of copper close to the ground planes to > >> maximise the via and capacitor utilization. Here's an article showing > >> what I mean. Fig. 2. > >>http://www.x2y.com/bypass/mount/backside_cap.pdf > >> Whatever, YMMV, and I'm sure your designs work just fine. It's hard to > >> cock it up, but I contend that the dual ground plane design I suggest > >> above is nigh on impossible to go wrong with from an SI point of view, > >> even if you have absolutely no clue what you're doing. That's why I use it! > > Yes, one common element is that most designs apply overkill in the > > supply decoupling area. When an engineer uses a method and it works, > > it is like the elephant protection charm... you don't see any > > elephants do you, so it must be working! > > I would likely not use the offset coupled planes you describe mainly > > because it only works well for boards with active components on only > > one side. > > In Lee Ritchey's class I asked about adding caps to the package to > > overcome lead inductance causing ground bounce. He showed me that the > > bounce is caused by the switching currents of driving an external > > signal travel in a loop and independent of any capacitance on the > > package, still have to travel through the leads of the part (even if > > they are only bonding leads). In fact, there is *nothing* you can do > > about the series inductance of pins in a package other than fix the > > package. That is why I seriously doubt that the small added > > inductance of 30 mil of a via is significant in any but the highest > > speed designs. But as you say, YMMV. > > Yes. The problem comes with switching a large number of lines > at very close to the same time. Since they won't be at exactly > the same time (propagation delay to the pads) the highest frequency > components aren't as important as you might think. The peak > frequency of the ground current, then, will depend on how close > the transitions are to each other more than the transition rate. The high frequency components are the only ones I care about for ground bounce. The problem is caused by series inductance. The lower the frequency, the lower the impact. But still, ground bounce is largely a package problem which you can do nothing about on the board other than make it worse. Another really amazing thing I got from Lee's course is that there are any number of engineers who get it wrong. I'm not talking about typical board designers, I am talking about engineers designing chips and packages. He has any number of examples where he was called in to fix a problem and he told them to throw it out and start over doing it right. In one case, they wanted to use some chip that Lee found had too much lead impedance and would ground bounce all the noise margin out of the logic levels. So they had to scrap the idea of using the chip. RickArticle: 145348
On Feb 5, 9:24=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Symon <symon_bre...@hotmail.com> wrote: > > On 2/5/2010 9:53 PM, glen herrmannsfeldt wrote: > >> Yes. =A0Actually, I believe that for the really highest frequency > >> components, that they are supplied by the plane itself. =A0(Especially > >> as signals won't be switching at exactly the same time.) > > If these highest frequencies are supplied by the planes, why do Xilinx > > and Altera put capacitors on the BGA substrate? That must cost money. > > Are they wrong? > > OK, not quite the highest frequencies, but almost. > > The highest that get through the inductance of the package and > past the internal capacitors. > > I think it isn't so hard to calculate the impedance of an > infinite plane with a hole (via) as a function of frequency. > That should partly answer the question. Two different problems. The capacitance of the power and ground planes closely spaced is effective at frequencies well above that where capacitors become highly inductive and the impedance rises to a point of being useless. So any caps used inside the package are not there to handle "the highest frequencies". To be honest, I don't know why they would put caps inside the package unless their packages are poorly designed, unless it is to account for poor designers... In a discussion some time back between an engineer and a Xilinx rep about the "recommended" decoupling caps, it was admitted that their recommendation was overkill for most designs since there is such a wide range of designs implemented in their parts. Reading between the lines I would say this means they were recommending overkill for the designers who can't figure it out for themselves. When was the last time a design review said you had too many decoupling caps? I firmly believe what Lee Ritchey showed me (that only a fraction of the number of caps normally used are really needed) but I still try to use one per power pin! Call it superstition or just lack of confidence in myself. But no one's design failed because he used too many caps on the power plane. BTW, Lee Ritchey's book, "Right the First Time..." is available on CD for $25. I recommend it. Everything I have said here is from what I learned in his course using that book. RickArticle: 145349
Hi Rick ! rickman wrote: > Lee Ritchey showed me (that only a fraction of the number > of caps normally used are really needed) but I still try to use one > per power pin! Call it superstition or just lack of confidence in > myself. But no one's design failed because he used too many caps on > the power plane. Excellent point, I feel concerned by this remark :-) > Rick yg -- http://ygdes.com / http://yasep.org
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z