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 Mar 24, 8:57=A0pm, Symon <symon_bre...@hotmail.com> wrote: > 2) Only nutters have power planes. They use up valuable space in which > you could more profitably use a ground plane. Surely you mean "Only nutters have separately filtered power planes for individual general purpose digital IC supplies." Otherwise, suggesting that planes (partial or full) are not needed for power distribution to digital circuitry is ludicrous. > If anyone wants to disagree with this advice, I want a specific, first > person example where what I suggest is wrong. I don't want to hear what > some 'guru' told you on a course you paid for. :-) Why should we supply any more evidence than you have? AndyArticle: 146651
Paul: Actually the exe is a part of another software. I cant control how it calls the tcl script. I can only modify the tcl script. Alan: If i open a tclsh shell and ran 'source $env(XILINX)/bin/xilinx-init.tcl', i'll get the same 2 error that you got. I did raise this question in the Xilinx forum. A Xilinx employee gave me the following solution: [1] Create a second tcl script (second.tcl) that contains all the xilinx tcl commands that i want to use. [2] Include the following command in the first tcl script (first.tcl) exec xtclsh second.tcl So when the exe calls first.tcl, it'll in turn pass second.tcl to a xtclsh shell to be evaluated. It seems to be a bit of a workaround but it works. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146652
Thomas, Some thoughts: > 1. Filtering of IC-supply-voltage > While it is quite standard to filter e.g. the PLL-supply voltages of a > FPGA, there are some suggestions to filter the supply-voltage of every > IC (CPU, FPGA, memory, ...) on the PCB with a ferrite-bead + C. > (Consequently, this also means that every IC has it's own Vdd-island > in the power-plane.) Does this work? You must be using a non-Xilinx device: our requirements are clearly spelled out in our user's guides. And, we do not require filtering the supply to our clock tile PLL in V5, V6, nor S6. The MGT's do require filtering, and again this is covered in our user's guides. If you chose not to follow our guides, then it is up to you to prove the system meets your requirements. > 2. Return-path on Vdd-plane > It is pretty clear that a solid ground-plane is required for return- > path of I/O-signals. Most people also agree, that a power-plane will > also do this job. But is this only because of the bypass-caps? Or is > the "native" return-current flowing on ground when the output-driver > is sinking and on Vdd when the output-driver is sourcing (assuming a > high-impedance destination), i.e. it would be perfect to have both > planes close to the signal-line? Again, our plane and signal layer, and its stack-up, is clearly documented. Our patented "SparseChevron" technique for IO signal integrity is superb at reducing ground bounce from SSO (simultaneous switching outputs). > 3. Shields of connectors, chassis ground > Most PCBs have one or more connectors with shields (e.g. USB, RJ45, > VGA, RS-232,...) Do you connect these directly to circuit-ground? Or > with C and R in parallel? Or do you have some kind of "frame-ground"? > Have you the mounting holes grounded to the chassis? All or just one? Ah, now it gets interesting: you won't find this in any guide! Commonly the entire enclosure is a Faraday shield, and is considered the safety ground, or earth ground, and gets connected to the third wire ground of the power distribution system (cold water pipe ground/ earth ground/ safety ground). Now, what you do with that safety ground inside the box, with respect to your common signal ground is up to you. A good choice is a hard connection (no RC) at ONE POINT, as close as possible to where the safety ground enters the enclosure. Now, if each interface has its own safety ground/ shield ground, each of these is terminated on the Faraday enclosure ground, on the OUTSIDE. Once the connector leads enter the enclosure, you DO NOT connect the shield to the circuitry (it is ONLY connected at that one point described earlier). Signal grounds inside cables terminate on your pcb ground. If you have very long cables between boxes, and there may be a safety ground voltage difference between enclosures, then the signal grounds may be only connected at one end, or capacitive coupled at both ends, or some other solution. If there is as much as 3 volts AC of safety ground imbalance (not an unusual requirement), signals may have to be large swing (like RS232), or differential (RS422) which detail how to be wired to avoid problems with safety ground voltage differences between boxes. Imagine a ESD strike of 10 kv: it travels from your finger, to the enclosure, and then remains on the outside, wrapping around until it gets to the safety ground. Any opening, a joint without a screw more than 3" (75mm), will allow the sheet of charge from the ESD to enter the enclosure, race along the inside surface, and cause your pcb to go stupid. Be careful about ESD zaps to display indicators, push buttons, and switches! Often these displays and controls have to carefully engineered to prevent ESD zaps from entering the enclosure! Similarly, an ESD zap to a cable should travel to the enclosure, and hence back to safety ground, never having a reason to enter the enclosure. Once you think you did everything right, then testing with a zapper is the only way to prove you have met your requirement. If you are building something that has no ESD requirements, it may still have RFI/EMI requirements. All the same rules apply (if the enclosure is properly designed for ESD, it is very likely also the best RFI/EMI design as well). If you have no RFI/EMI requirements, then you are building a toy, and you probably just don't want them to be returned to the store, so it is still a good idea to do a good job with ESD and RFI/EMI, but perhaps cutting corners to reduce costs... AustinArticle: 146653
On 3/25/2010 4:03 PM, austin wrote: > Thomas, > > Some thoughts: > >> 1. Filtering of IC-supply-voltage >> While it is quite standard to filter e.g. the PLL-supply voltages of a >> FPGA, there are some suggestions to filter the supply-voltage of every >> IC (CPU, FPGA, memory, ...) on the PCB with a ferrite-bead + C. >> (Consequently, this also means that every IC has it's own Vdd-island >> in the power-plane.) Does this work? > > You must be using a non-Xilinx device: our requirements are clearly > spelled out in our user's guides. And, we do not require filtering > the supply to our clock tile PLL in V5, V6, nor S6. > It's hard to imagine a board without some non-Xilinx devices on it somewhere. Some of these devices may need isolation from the noise generated by the FPGA. Power islands are a good way to deal with this. Syms.Article: 146654
On 03/25/2010 01:20 AM, -jg wrote: > On Mar 25, 1:41 pm, Jason Thibodeau<jason.p.thibod...@gmail.com> > wrote: >> >> When I run this on my spartan 3e, I get different values for each and >> every run. I would assume these values would stay the same. What >> explanation is there for their differences? Power fluctuations? > > ?? Err ? > 'stay the same' - did you really mean what you wrote ? > Of course they will change. > Even an Atomic clock varies... > > > Smarter would be to post numbers on how much they changed, as > 'different values' has no useful information. > > A ring oscillator, is a Thermometer, and a Voltmeter, > and a process-quantifier - all coming out in one number. > > -jg > > > Thinking about it further, I suppose I didn't mean stay exactly the same. I did expect differences, and I guess I confirm with you all that what I am seeing is normal. I have typically less than 5% fluctuations between runs. Thanks for all your input. It gives me a bit to think about. -- Jason ThibodeauArticle: 146655
On 3/25/2010 2:55 PM, Andy wrote: > On Mar 24, 8:57 pm, Symon<symon_bre...@hotmail.com> wrote: >> 2) Only nutters have power planes. They use up valuable space in which >> you could more profitably use a ground plane. > > Surely you mean "Only nutters have separately filtered power planes > for individual general purpose digital IC supplies." I meant what I said. And don't call me Shirley. > > Otherwise, suggesting that planes (partial or full) are not needed for > power distribution to digital circuitry is ludicrous. In general, and especially in the context of the OP's points about using power planes as signal return paths, I contend that power planes on digital boards are expensive and a waste of time. Indeed, they can be counter productive. There are many power supplies on the board. For example, an FPGA may typically have different supplies on different I/O banks, plus a core supply, plus an DCM/PLL supply. Would you have a plane for every supply? If you use a single PCB layer for two supplies, what happens when a signal on an adjacent layer crosses the gap? What happens when you want to isolate a device from a noisy supply? Far simpler to use the power islands mentioned in the OP, and use multiple ground planes for return paths. > >> If anyone wants to disagree with this advice, I want a specific, first >> person example where what I suggest is wrong. I don't want to hear what >> some 'guru' told you on a course you paid for. :-) > > Why should we supply any more evidence than you have? > Is that the royal 'we'? :-) > Andy > >Article: 146656
Hi everyone, I'm just about to start an implementation of a USB 3.0 interface in VHDL for data transfer from FPGA to a PC and vice versa. The core should acts as a USB device for the PC. The core is intended for an FPGA projects where an "easy" interface to a PC is needed. Higher data rates as defined by the 3.0 standard should be possible with the implementation. Questions are: Does anyone have experience in implementing a USB interface? What are the external chipsets and components respectively required? What about standard compliance? Which standard? Which version? What is the defference between USB Server + USB Client in this respect and which one should I implement to get the desired functionality? Thank You Friends For All Your Kind Support!Article: 146657
"Maurice Branson" <traubenuss@arcor.de> wrote in message news:4bab9732$0$6875$9b4e6d93@newsspool2.arcor-online.net... > Hi everyone, > > > I'm just about to start an implementation of a USB 3.0 interface in VHDL > for data transfer from FPGA to a PC and vice versa. The core should acts > as a USB device for the PC. The core is intended for an FPGA projects > where an "easy" interface to a PC is needed. Higher data rates as defined > by the 3.0 standard should be possible with the implementation. > > > > Questions are: > > Does anyone have experience in implementing a USB interface? > > What are the external chipsets and components respectively required? > > What about standard compliance? Which standard? Which version? > > What is the defference between USB Server + USB Client in this respect and > which one should I implement to get the desired functionality? > > > > Thank You Friends For All Your Kind Support! > > > You will find a lot of information on www.usb.org While I don't mean to be unhelpful the questions you are asking make me feel that you are unlikely to get far with this. USB3 is not easy. If you don't absolutely have to have the USB3 super speed then USB2 high speed (480 Mbit/s) is a lot easier - the 'least brain' approach is to use an FTDI chip for the interface. www.ftdichip.com Michael KellettArticle: 146658
Thanks, Michael! I will have a look at the URL you postet. Anyway I want this project to be one from which I learn a lot. So I am not interested in the 'least brain' approach but to do as much as I can in VHDL and just use a chipset for the physical link.Article: 146659
Patrick Maupin <pmaupin@gmail.com> wrote: >On Mar 24, 6:57=A0pm, n...@puntnl.niks (Nico Coesel) wrote: >> My experience is that people don't like change and like to stay stuck >> in old unproductive methods. Sometimes you need to push people >> forward. > >My experience is that learning a new tool is only worthwhile if you >are going to use it a LOT and gain a LOT from it. My experience is >also that a cursory examination of a tool can usually give you a >reasonable feel for whether this is going to happen or not. Which is why Eclipse is such a fine tool: it supports a lot of languages and platforms so you'll need to learn one tool and get going with many languages and platforms. >> Thats rubbish. Perhaps true for the simple IDEs intended to give >> people a quick start. I don't like those either. > >See, those are the ONLY ones I like. > >> Eclipse is a whole other story though. It is designed to aid working >> on complex projects. I have several projects that share a common code >> base and some of those projects result in 10 to 20 slightly different >> binaries. Eclipse helps me to organize such projects. A makefile >> keeping all the defines and projects definitions apart would be a >> nightmare. And that is besides the many aids Eclipse provides like >> having a list of types, variables, defines and functions from a file, >> showing call hierarchies, shading parts that are not getting compiled, >> refactoring (renaming symbols), comparing versions from a version >> control repository, etc, etc. > >No, the nightmare is finding the configuration button to set the >project exactly right. IMHO, if you delegate the complex stuff to an >engine like this, you lose control over it rather than gain control. >And once again, I will refer you to Linux -- is your project really >more complicated, with more options, than the kernel? Do you really >think all the kernel hackers are Luddites? Yes, they are. My job includes kernel hacking and I'm finding the total lack of proper documentation, comments and the obfusticated C++ objects simulation in C a big hurdle. IMHO the audio handling in the Linux kernel is a complete mess. Kernel hackers may like the Linux kernel the way it is now but in reality it is a cow's turd you want to stir in as little as possible. >> Ofcourse you can do all this with a command line tools but it is way >> less productive and more prone to errors than having everything >> presented to you in a GUI. I never liked developing while peeking >> through a key-hole. When I need to work on an software project I >> always load the source into Eclipse because it allows me to examine >> the structure of a piece of software very quickly. Where is this >> function called from? Just open the call hierarchy. What is this >> define? Just move over it with the mouse pointer. Where is the define >> or symbol declared? Shift-click and you'll have the answer. Open a .h >> file for examination by shift-clicking on it. > >You haven't described anything in this paragraph that can't be done >with a decent modern editor. In that case Eclipse contains a decent modern editor. >> Not to mention debugging. Its all there. And I forgot the best thing: >> Eclipse works the same way for different languages. Writing and >> debugging a C/C++ program works the same way as debugging a PHP >> script. Eclipse is about learning one workflow and apply it to any >> language. > >Ahh, THERE is a difference between editors and IDEs. Yes, debugging. >Well, I write most of my software in Python and spend very little time >debugging. Most of my Verilog tests are self-checking, and I >sometimes look at waveforms, but very little else. I don't think I >have personally set a breakpoint in about 15 years, since I used to >have to write C/C++, so this is not very high on my priority list (and I wonder how much time you spend on finding a typo. A debugger is most helpfull in those cases. I use the debugger mostly for verification so I'm absolutely sure my software does what it is supposed to do and not that the answer seems right. >Of course, one probable reason for that is that somebody started to >document how impact works in batch mode, and gave up because the >software sucks so badly that you can't accurately describe its >behavior without calling attention to just how bad it really is. LOL! -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146660
I agree that power islands, where required, are OK, but it was not clear what your original statement was recommending. Under what circumstances power islands are required is up for debate. Whether they are used as signal shield layers (for HF return currents) is dependent up on the application, whether traces can be routed without crossing between different islands, and whether or not adding additional layers for additional ground planes is a good trade. No sir, I'm just part of the common 'we' (the same group you adressed as 'anyone'). Are you the Royal Symon? AndyArticle: 146661
On Mar 25, 10:55=A0am, Andy <jonesa...@comcast.net> wrote: > > Otherwise, suggesting that planes (partial or full) are not needed for > power distribution to digital circuitry is ludicrous. Consider: Why do we need power planes? Are we trying to keep the "reference rails" common between chips to a very high degree like we do with our ground planes? Here's an argument: distributed capacitance between the power and ground planes are effective at the very high frequency end where decoupling caps start to loose their effectiveness. Oops! Decoupling at those very high frequencies off-chip doesn't appear to have much effect [guru suggestion] and the larger the plane, the lower the self- resonant frequency of that plane. If you have an 11" board, your quarter wavelength is about 250MHz. Smaller planes are more effective at pushing this high end of resonance out of the picture. Smaller planes means smaller distributed capacitance. I can understand the need for power planes in analog or balanced circuits where the decoupling effects are still prevalent at the discrete level. But for chip level? Maybe not after all. After my most recent board involvement I'm convinced that power distribution would become less problematic with power distributed to small, chip-local islands. The small islands do help distribute the decoupling caps over an area, affecting inter-cap resonance issues. We've come a long way since the wire-wrap days of star configured power and ground distribution. But little attention has been paid to the science behind power distribution. There are tools that have become available in recent years to help plan the power distribution and avoid the troubles with plane resonance or interference between capacitors. The tiny islands might be one of the better ways to go.Article: 146662
On 25 Mrz., 02:10, Thomas Entner <thomas.ent...@entner- electronics.com> wrote: > 3. Shields of connectors, chassis ground > Most PCBs have one or more connectors with shields (e.g. USB, RJ45, > VGA, RS-232,...) Do you connect these directly to circuit-ground? Or > with C and R in parallel? Or do you have some kind of "frame-ground"? > Have you the mounting holes grounded to the chassis? All or just one? The problem with this is, that for high frequencies and lower frequencies different setups work well. That is why you find conflicting design guids for whether ground and shield should be connected and where they should be connected. KoljaArticle: 146663
On 25 Mrz., 02:57, Symon <symon_bre...@hotmail.com> wrote: > Hi Thomas, > 2) Only nutters have power planes. They use up valuable space in which > you could more profitably use a ground plane. Well, how do you create a low inductance path to the next capacitor? You do not necessarily need a full plane, but making sure there is a low inductance path quickly gets very cumbersome. A power plane is as good a reference for a signal as a ground plane and the PCB stack needs to be symmetric anyway. So what is the disadvantage of having a power plane as layer 2 when there is a gnd in layer N-2? Putting a GND plane there instead will waste more space with no gain (as you still need to route the power signals somewhere) and putting no plane in that layer will result in a bent board. Also, adjacent power planes provide multi GHz decoupling that is next to impossible to achieve with soldered capacitors. KoljaArticle: 146664
John_H <newsgroup@johnhandwork.com> wrote: > On Mar 25, 10:55?am, Andy <jonesa...@comcast.net> wrote: >> Otherwise, suggesting that planes (partial or full) are not needed for >> power distribution to digital circuitry is ludicrous. > Consider: > Why do we need power planes? Are we trying to keep the "reference > rails" common between chips to a very high degree like we do with our > ground planes? Some drivers can pull up almost as much as down. > Here's an argument: distributed capacitance between the power and > ground planes are effective at the very high frequency end where > decoupling caps start to loose their effectiveness. Oops! Decoupling > at those very high frequencies off-chip doesn't appear to have much > effect [guru suggestion] and the larger the plane, the lower the self- > resonant frequency of that plane. If you have an 11" board, your > quarter wavelength is about 250MHz. You need to consider the power and ground planes as a radial transmission line. If you send a pulse in, the capactance per unit (radial) distance increases as r, and the inductance decreases as r. The series inductance is mostly determined near the via, as is the deficit in parallel capacitance. > Smaller planes are more effective > at pushing this high end of resonance out of the picture. Smaller > planes means smaller distributed capacitance. > I can understand the need for power planes in analog or balanced > circuits where the decoupling effects are still prevalent at the > discrete level. But for chip level? Maybe not after all. With the large currents required by some chips, it isn't so obvious. There are processors with Idd over 100 amps. > After my most recent board involvement I'm convinced that power > distribution would become less problematic with power distributed to > small, chip-local islands. The small islands do help distribute the > decoupling caps over an area, affecting inter-cap resonance issues. -- glenArticle: 146665
Thomas Entner wrote: > As I think, many FPGA-designers have also to deal with EMC, I hope > someone can help me here. We have currently some discussions (and > doubts) regarding EMC-topics. As many people have different opinions > on this subject, and it is quite hard to objectively verify, I would > like to ask for some comments about following: > > 1. Filtering of IC-supply-voltage > While it is quite standard to filter e.g. the PLL-supply voltages of a > FPGA, there are some suggestions to filter the supply-voltage of every > IC (CPU, FPGA, memory, ...) on the PCB with a ferrite-bead + C. > (Consequently, this also means that every IC has it's own Vdd-island > in the power-plane.) Does this work? Please dont! you will just add to the number of caps you need. You only need to do this with sensitive analogue parts and PLLs of FPGAs > > 2. Return-path on Vdd-plane > It is pretty clear that a solid ground-plane is required for return- > path of I/O-signals. Most people also agree, that a power-plane will > also do this job. But is this only because of the bypass-caps? Or is > the "native" return-current flowing on ground when the output-driver > is sinking and on Vdd when the output-driver is sourcing (assuming a > high-impedance destination), i.e. it would be perfect to have both > planes close to the signal-line? Yes, the initial pulse of power at high edge rates first comes from on chip capacitance then from the power plane. > > 3. Shields of connectors, chassis ground > Most PCBs have one or more connectors with shields (e.g. USB, RJ45, > VGA, RS-232,...) Do you connect these directly to circuit-ground? Or > with C and R in parallel? Or do you have some kind of "frame-ground"? > Have you the mounting holes grounded to the chassis? All or just one? > Shields, mount the connectors with fingers touching a metallic box encloseing the circuit. Ensure that the ground planes are also bolted inside the box to the ground plane at regular intervals. Ensure that the plateing on the inside of the box is conductive. To check that it is conductive make a brush out of some 16/0.2 mm wire, strip 25mm, and 12.5 mm from the end bend through 90 degrees. Use your meter on continuity and gently use the two brushes as probes. If you do not get a low reading with light pressure, reject the case. Lots of good stuff here http://www.compliance-club.com/ Particularly in the Keith Armstrong section JamesArticle: 146666
On Mar 25, 2:41=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > Some drivers can pull up almost as much as down. =A0 The issue isn't direct return current to the VCC drive transistor because the current needs to head through the package to the VCC pin to the power island in the first place which may be referenced to the wrong plane anyway. With effective decoupling near the source, the return current goes from the driver to the on-chip decoupling, through the package to the off-chip decoupling, to the plane(s) the signal references against. The smaller the overall current loops, the smaller the EMI and crosstalk. Do you want your huge current spikes to force your ground and power planes to both fluctuate at equal amplitudes? Or would you prefer that your ground is more solid and the power plane sloppier? The answers aren't obvious otherwise we wouldn't have guidelines that specify not only a power plane but one 1uF, one 0.1uF, and one 0.01uF capacitor per power and ground pin pair (of which there are 27 on the part). Bogus guidelines.Article: 146667
Is it possible to get a detailed report out of XST, listing the gates it has optimized out of a design? XST is removing some gates that I specifically put into a design, and I want to prevent this. I can use the XST constraints file, but I'd like to see exactly what it is doing. Googling hasn't turned up much, yet. Thanks -- Jason ThibodeauArticle: 146668
John_H <newsgroup@johnhandwork.com> wrote: > On Mar 25, 2:41?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> Some drivers can pull up almost as much as down. ? > The issue isn't direct return current to the VCC drive transistor > because the current needs to head through the package to the VCC pin > to the power island in the first place which may be referenced to the > wrong plane anyway. With effective decoupling near the source, the > return current goes from the driver to the on-chip decoupling, through > the package to the off-chip decoupling, to the plane(s) the signal > references against. The smaller the overall current loops, the > smaller the EMI and crosstalk. Well, in the TTL days everything was ground referenced. With CMOS that is much less true. In any case, it is series inductance (bond wires, package pins, and PC traces) > Do you want your huge current spikes to force your ground and power > planes to both fluctuate at equal amplitudes? Or would you prefer > that your ground is more solid and the power plane sloppier? If I remember the early CMOS right, it was symmetric. The switch point was at (Vss+Vdd)/2. As far as I know, that isn't true anymore. In any case, there isn't much we can do about the inductances inside the package. Once it gets outside, we need low enough inductance until it gets to a large enough capacitance. > The answers aren't obvious otherwise we wouldn't have guidelines that > specify not only a power plane but one 1uF, one 0.1uF, and one 0.01uF > capacitor per power and ground pin pair (of which there are 27 on the > part). Bogus guidelines. -- glenArticle: 146669
On 3/25/2010 6:13 PM, Kolja Sulimma wrote: > On 25 Mrz., 02:57, Symon<symon_bre...@hotmail.com> wrote: >> Hi Thomas, >> 2) Only nutters have power planes. They use up valuable space in which >> you could more profitably use a ground plane. > Well, how do you create a low inductance path to the next capacitor? > You do not necessarily need a full plane, but making sure there is a > low inductance > path quickly gets very cumbersome. You use copper pours and puddles around the IC to link its bypass capacitors. > A power plane is as good a reference for a signal as a ground plane > and the PCB stack > needs to be symmetric anyway. So what is the disadvantage of having a > power plane as > layer 2 when there is a gnd in layer N-2? 1) The stack up does not need to be symmetrical wrt to planes and signal layers. However, you should make the substrates symmetrical. I have made several boards that aren't plane symmetrical. Talk to your PCB vendor. (Some of these boards were about 12x8 inches and didn't warp.) 2) When a signal trace passes from layer 1 to layer N-1, its reference plane has now changed. If this signal has a fast rise time, you have to use a bypass capacitor nearby, with its attendant inductance, and via inductance. With two ground planes, a regular via is enough. 3) You make an interesting point when you say that a power plane is as good as a ground plane as a reference. This is true. The problem comes that you now have two references in your system, and they will have some small noise voltage between them. You can reduce this to a small amount of noise with capacitors, but for each power plane, you have to do this. With multiple ground planes, they are all bonded together with the ground vias in your board. > Putting a GND plane there instead will waste more space with no gain > (as you still need to > route the power signals somewhere) and putting no plane in that layer > will result in a bent board. Indeed, you need to put the powers somewhere. I recommend routing them all on a couple of dedicated layers away from signal traces. On an FPGA with at least 1.2V, 1.8V, 2.5V and 3.3V rails, which of these are you suggesting will be on a plane? All of them? (Again, the bent board thing is a fallacy, I have found.) > > Also, adjacent power planes provide multi GHz decoupling that is next > to impossible to achieve with > soldered capacitors. > We've been here before. It has a small amount of capacitance, which doesn't help you because the multi-GHz can't get up the vias and balls into the dice. Think of it this way, the reason a soldered capacitor doesn't give you multi-GHz is the fact that you have to connect to it. Actually in the ceramic of the cap is multi-GHz. It's the same with connecting your chips to a adjacent-plane-made capacitor. Of course, what this arrangement does also provide is the possibility of multi-GHz resonances in your power planes. Lovely. Using a ground plane where ever a reference plane is needed makes the SI design very simple indeed. > > KoljaArticle: 146670
On 3/25/2010 6:04 PM, Andy wrote: > I agree that power islands, where required, are OK, but it was not > clear what your original statement was recommending. Under what > circumstances power islands are required is up for debate. > > Whether they are used as signal shield layers (for HF return currents) > is dependent up on the application, whether traces can be routed > without crossing between different islands, and whether or not adding > additional layers for additional ground planes is a good trade. > > No sir, I'm just part of the common 'we' (the same group you adressed > as 'anyone'). Are you the Royal Symon? > > Andy Hi Andy, You appear to have overlooked one of my queries. I'm interested in your response. Would you have a plane for every supply? I'm interested, because you posted that "suggesting that planes (partial or full) are not needed for power distribution to digital circuitry is ludicrous". Thanks, HRH Symon. p.s. I thought 'anyone' was singular. :-)Article: 146671
Thank you everyone for the comments, it is an very interesting reading. I already got a lot of input for a new PCB-design, from which we will do some variants to check which EMC-solution works best. Looks like we need more variants than originally planned... ThomasArticle: 146672
On Mar 25, 3:11=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 3/25/2010 6:04 PM, Andy wrote: > > > I agree that power islands, where required, are OK, but it was not > > clear what your original statement was recommending. Under what > > circumstances power islands are required is up for debate. > > > Whether they are used as signal shield layers (for HF return currents) > > is dependent up on the application, whether traces can be routed > > without crossing between different islands, and whether or not adding > > additional layers for additional ground planes is a good trade. > > > No sir, I'm just part of the common 'we' =A0(the same group you adresse= d > > as 'anyone'). Are you the Royal Symon? > > > Andy > > Hi Andy, > > You appear to have overlooked one of my queries. I'm interested in your > response. > > Would you have a plane for every supply? > > I'm interested, because you posted that "suggesting that planes (partial > or full) are not needed for power distribution to digital circuitry is > ludicrous". > > Thanks, HRH Symon. > > p.s. I thought 'anyone' was singular. :-) By 'plane', do you mean an entire PWB layer? In that case, no, an entire layer is not always necessary (unless the circuitry served by the power supply is distributed all over the board anyway.) If by 'plane', you mean a broad area flooded with copper, but not necessarily an entire PWB layer, then my answer is yes, a broad, flooded area is necessary for power distribution to digital circuitry. AndyArticle: 146673
> In North America, that is Avnet (as you have noted). I suggest you > call them on the phone and request quotes and delivery. Why shouldn't Xilinx tell us when parts are available. They are the mfg. They probably have a better idea. Even an approximation would be better than nothing. What's the sales politics in saying you're going to have a package but don't say when? Sorry this post went off in a software debate. I was really only interested right now in the packages. Brad Smallridge AiVisionArticle: 146674
Hi, Thank you for your suggestions. I will take a look at them and get back to you if I have any more questions. Aditi. On Mar 25, 4:55=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > John Larkin <jjlar...@highnotlandthistechnologypart.com> wrote: > > On Wed, 24 Mar 2010 13:59:56 -0700 (PDT), Aditi <aditi...@gmail.com> > > wrote: > > >Hi, > > > >I am planning to use a Spartan 6 FPGA (XC6SLX9) in my new design. > > >Could someone suggest a reprogrammable PROM to configure this device, > > >like the capacity of the Flash PROM needed ? > > We're using a NuMonics serial flash chip, M25P16, SO-8, 16 mbits, to > > program a Spartan6/45. Works fine. We just use a .BIT file in a B&K > > USB programmer. We actually solder the SO-8 to a small adapter board > > so we can plug it into a dip socket. > > You can also load the FPGA with some core and program the SPI Flash via J= TAG > with that core. This works with Impact and (sourceforge) xc3sprog. > > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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