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
In article <41700734.669C9E48@yahoo.com>, rickman <john@bluepal.net> wrote: >"vax, 9000" wrote: >> >> 1. 3.3V or 5V parts (compatible with TTL/HTCmos) >> 7. low cost > >I can tell you that item 1, 5 and 7 are hard to combine. The Xilinx >parts that might do best are the Coolrunner (not Coolrunner II) If I remember right, I think the best combination of 5V tolerant and cheap is XC9500XL. Straight XC9500 has a price premium now, and XV is not 5V tolerant. -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 74651
Rick, I agree. As I said in another post in this thread, point-of-load supplies are useful, but as long as you keep them on the board where they're used, their position relative to the FPGA makes bugger all difference. They're low enough in area/height/power wastage these days to place in the bits of pcb 'tundra' you often get between connectors and the like! Cheers, Syms. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:416F6DB9.9DBF780F@yahoo.com... > Symon wrote: > > I think he was addressing the comments about keeping the PSU near the > chips. I have *never* heard anyone recommend that PSU placement would > affect the need for good PCB design. The range of frequencies that PSU > selection or placement would affect is way below the range of freqencies > that would be affected by PCB layout.Article: 74652
Austin, PCB ground bounce? But this thread is about not having PCB power planes. No-one's suggesting doing without a ground plane. That's the main (only!) weapon against ground bounce. The loop-inductance you're taking about that carries the return current is then between the FPGA and it's decoupling capacitors. The ground plane ensures the power supply doesn't bounce relative to the decoupled supply at the FPGA. If you're talking about ground bounce on the silicon, then all we PCB designers can do is firmly bolt down the ground pins to the PCB ground plane. A power plane, or lack thereof, isn't gonna affect ground bounce after that. Also, when you say in a previous post 'If you do not have both a power and a ground plane for each of these supplies, the SSO numbers must be reduced.', I'd disagree. You probably must have a ground plane, but throwing separate layers at supplies for Vcco, Vccint, Vccaux, Rocket I/O supplies is a little excessive! It's easier to use this methodology, and certainly easier for Xilinx to support, but you can get as good results by using one or two layers to share supplies locally at the FPGA. You can also use this layer for other things away from the FPGA. To do this, your decoupling must be good at the FPGA, and the connection between the supply and the local plane must be able to supply the current needed. You're also, IMHO, better off having multiple ground planes, and routing the power. Finally, I'd be interested in how increasing bypass capacitance can make ground bounce worse in the same system, especially one with a ground plane? More energy stored? di larger? dt faster? What? Cheers, Syms. "Austin Lesea" <austin@xilinx.com> wrote in message news:ckomo5$s21@cliff.xsj.xilinx.com... > Tom, > > There is no "C" in Ldi/dt. > > If you can find out how varying a capacitance in any way changes the > induced bounce (V=-Ldi/dt), let me know. > > Bypass capacitance prevents rail collapse, but it does nothing to > prevent ground bounce (it can actually make it worse, as there is more > energy stored which makes di larger and dt faster). > > Austin >Article: 74653
Eric Smith wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > I am not aware that they *don't* report a max clock speed, but it is > > very unusual to care about clock speed if you don't spec a requirement. > > If you don't use a speed constraint, the tool assumes you don't care > > about the speed and just does a route without any optimization. Isn't > > that obvious? > > No, it's not obvious. You could just as easily say that an automaker > shouldn't include a speedometer in a new car unless you tell the dealer > how fast you plan to drive. > > If I give an explicit constraint, I want the tools to work harder (if > necessary) to try to meet it, but that doesn't mean that if I don't give > a constraint that I don't care about it at all. By that reasoning it > would be fine for the tools to produce a design with a minimum clock > period of a fortnight. I don't understand your point. If you don't tell the tool what an acceptable clock period is, then how is the tool supposed to know the difference between a nanosecond and a fortnight? Tools are not people, they can't reason. Besides, how would *I* know what you find an acceptable clock period if you don't tell me? I still see systems that are clocked well below 10 MHz. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74654
Ben Jackson wrote: > > In article <41700734.669C9E48@yahoo.com>, rickman <john@bluepal.net> wrote: > >"vax, 9000" wrote: > >> > >> 1. 3.3V or 5V parts (compatible with TTL/HTCmos) > >> 7. low cost > > > >I can tell you that item 1, 5 and 7 are hard to combine. The Xilinx > >parts that might do best are the Coolrunner (not Coolrunner II) > > If I remember right, I think the best combination of 5V tolerant and > cheap is XC9500XL. Straight XC9500 has a price premium now, and XV is > not 5V tolerant. I don't have full pricing in front of me, but the newest CPLD part from Xilinx that has 5 volt tolerance is the XCR3xxxXL family, so I would expect these to be the cheapest. They are 3.3 volt supply and are near zero power as well. But like most CPLDs they get very pricey as the size goes up! -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74655
Hello All, I've been designing with Xilinx FPGAs for a while so I'm used to the "Slice" concept. I'm looking at Altera's Max II as a nice possible solution for a design. I took my VHDL code and it synthesized to 40 Slices in a Spartan III. Then I took the same code and sythesized it for a Max II (using Quartus II now) and it was 71 LE's. I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly dependant on how the code is sysnthesized. But is a approximate 1 Slice = 2 LE's a pretty close all around estimate. Thanks EricArticle: 74656
>I don't understand your point. If you don't tell the tool what an >acceptable clock period is, then how is the tool supposed to know the >difference between a nanosecond and a fortnight? Tools are not people, >they can't reason. Besides, how would *I* know what you find an >acceptable clock period if you don't tell me? I still see systems that >are clocked well below 10 MHz. The tools could at least tell me what the worst case clock-clock time is for each clock. That's not rocket science. And maybe even give a warning for not specifying the appropriate constraints. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 74657
hi all What is role of place & route tools in synthesis in vhdl.& HOW THE AREA & time constrain are specifiesd in XIlinx or modelsim software? Can LabVIEW be used for programming of ALTERA or XILINX boards or LabVIEW7 is meant for configuring the FPGA h/w of NATIONAL INSTRUMENTS only -----BANSALdhan rajArticle: 74658
>From the datasheet: The CCLK frequency is set using the ConfigRate option in the bitstream generation software. The maximum CCLK frequency that can be selected is 60 MHz. When selecting a CCLK frequency, ensure that the serial PROM and any daisy-chained FPGAs are fast enough to support the clock rate. On power-up, the CCLK frequency is approximately 2.5 MHz. This frequency is used until the ConfigRate bits have been loaded when the frequency changes to the selected ConfigRate. Unless a different frequency is specified in the design, the default ConfigRate is 4 MHz. It doesn't specify whether the internal oscillator stops running when config is complete, but the CCLK output certainly does. Since Virtex no longer allows user access to the internal CCLK oscillator I don't see why they would leave it running. Stefan Tillich <stefanti@gmx.at> wrote in message news:<416e8f73$0$11614$3b214f66@aconews.univie.ac.at>... > Hi, > > Does anyone know the frequency of the internal oscillator of Xilinx > VirtexE FPGAs which is used to generate the CCLK for Master-Serial > configuration mode? I'm aware that the datasheet specifies 4 MHz as > default CCLK frequency but that isn't necessarily identical to the > frequency of the oscillator. > > What's the behavior of this oscillator after configuration? Is it turned > off or can it be disabled through some option in the bit file? > > Regards > > Stefan TillichArticle: 74659
In article <41701FEE.E5673855@yahoo.com>, rickman <john@bluepal.net> wrote: >Ben Jackson wrote: >> If I remember right, I think the best combination of 5V tolerant and >> cheap is XC9500XL. Straight XC9500 has a price premium now, and XV is >> not 5V tolerant. > >I don't have full pricing in front of me, but the newest CPLD part from >Xilinx that has 5 volt tolerance is the XCR3xxxXL family, I guess the original poster wanted "5V TTL compatible". The XC9500XL family will take Vccio = 5V and drive 5V out. The XCR3xxxXL will accept 5V in but Vccio = Vcc = 3.3V. Thanks for pointing out that family -- I hadn't really considered that distinction before. -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 74660
Hi Sandeep, I guess it would fit into an Spartan-3 XC3S200, right? I'd like to test it with this FPGA. How can we do that? (I see that there are synthesized netlists on Niktech's website). Regards, -- Jaime Andrés Aranguren Cardona jaac@nospam.sanjaac.com SanJaaC Electronics Soluciones en DSP www.sanjaac.com (Remove "nospam" from e-mail address) "Sandeep Dutta" <webmaster@niktech.com> escribió en el mensaje news:p4qdnZwCAqt4nu3cRVn-2Q@comcast.com... > http://www.niktech.com > > Hardware Features > > · Data Path Width 32 bits > · Most instructions are 16 bit. PC Relative jump instructions are 32 bit. > · Four stage pipeline. > · Von Neumann Architecture (Data and Instruction in the same address space). > · Sixteen, 32 bit General Purpose Registers. > · Four USER defined instructions (with Register File Write back capability). > · Parallel execution of independent Load/Store, Multiply/Shift , > User Defined Instructions and ALU instructions (In order issue; Out of > order completion) > · Some Conditional Instructions (Reduces branches & increases code density). > · Built in 32 bit Timer. > · Power Down Mode. > · 32x32 Multiplier (Multi cycle execution). > > Software Development Tools > · GNU Assembler, Linker (binutils) > · GCC (C Compiler) > · GDB (Debugger) and Instruction Set Simulator > · Standalone C-Library (RedHat newlib) > · Modified version of DietLibc > > Size and Performance. > > Netlists for the current implementation is available for XILINX Virtex, > Spartan-II and Spartan-IIE; it > utilizes 1375 LUTs (809 slices); the size includes a 32 bit timer and a > 32x32 bit LUT based multiplier. > > The design has been tested to operate at 60MHZ on a Spartan-II (speed > grade -6). > > Netlists, Documentation and Development tools can be downloaded from > http://www.niktech.com. > >Article: 74661
hi everybody How can the FPGAs (particularly ALTERA) be used for high speed data acquisition of the order of 10 MSPS(mega samples per second ).Which one ADSP 21992 or FPGA is better? What is a CAN(CONTROone ADSP 21992 or FPGA is better? What is a CAN(CONTROL AREA NETWORK)? pls reply soon .thanks in advanceArticle: 74662
Symon, Answers below, Austin Symon wrote: > Austin, > PCB ground bounce? But this thread is about not having PCB power planes. It was about number of layers. A ground plane is a layer. > No-one's suggesting doing without a ground plane. That's the main (only!) > weapon against ground bounce. The loop-inductance you're taking about that > carries the return current is then between the FPGA and it's decoupling > capacitors. The ground plane ensures the power supply doesn't bounce > relative to the decoupled supply at the FPGA. The ground L is the bounce in the ground plane. The Vcc plane L is the bounce in the Vcc. > If you're talking about ground bounce on the silicon, then all we PCB > designers can do is firmly bolt down the ground pins to the PCB ground > plane. A power plane, or lack thereof, isn't gonna affect ground bounce > after that. > Also, when you say in a previous post 'If you do not have both a power and a > ground plane for each of these supplies, the SSO numbers must be reduced.', > I'd disagree. You probably must have a ground plane, but throwing separate > layers at supplies for Vcco, Vccint, Vccaux, Rocket I/O supplies is a little > excessive! I said a pair of planes for each high current switching supply, namely a Vccint/Gnd pair, and a Vcco/Gnd pair. That makes four layers. The dual grounds are required to reduce the ground return inductance to something that is reasonable. And the vcc loop inductance. Both. It's easier to use this methodology, and certainly easier for > Xilinx to support, but you can get as good results by using one or two > layers to share supplies locally at the FPGA. I disagree. Looking at those that succeed, vs. those who have issues, I see those that followed our recommendations a much happier bunch. We take our recommendations very seriously. We are not out to minimize our support, but rather to maximize our customers' successes (and our own in the process). To suggest a marginal power distribution system is just not good business! Why would we suggest that a customer 'play around' when we and our disti's have already run all the simulations, and built numerous verification, characterization, and demo pcbs to prove what works, and what does not work? Anyone who thinks they know better how to use our chip might get lucky, but often is not. Why would anyone think that they know more than we do about something they did not design? Surprisingly, many do think that they know more, and as a consequence are sometimes terribly disappointed. For the introduction of V4, we had a 1Gb/s LVDS networking pcb ready to demo, and a memory interfaces pcb ready to demo. Those are two of the largest applications problems our customers face today - fast IOs and fast memories. If we don't know how to make it work, how would that make a customer feel? I always read how a vendor suggests using their device. The use of the POL supplies is an experiment to validate a concept. I wouldn't go to product until I had proven it works (if it was my job). The same goes for using only four layers, or traces to Vcco, etc. You can also use this layer > for other things away from the FPGA. To do this, your decoupling must be > good at the FPGA, and the connection between the supply and the local plane > must be able to supply the current needed. > You're also, IMHO, better off having multiple ground planes, and routing the > power. Yes, ground is all important (more so than the Vcc's), and Vcc 'planes' may sometimes just be routed. It depends again on the switched currents. > Finally, I'd be interested in how increasing bypass capacitance can make > ground bounce worse in the same system, especially one with a ground plane? > More energy stored? Yes, the rails don't collapse. di larger? Yes, the source impedance is lower. dt faster? Yes, lower source impedance also leads to faster transients. Lastly, we had a case where the vias from the bypass caps where wired such that the L from the cap to the plane was the largest element (not hard to do, one tiny via each end, at the end of a flag of trace to the chip cap). Adding caps directly across the existing cap did absolutely nothing. One might conclude that the bypassing wasn't doing anything. But really, the L to the caps was so bad, that the caps were not doing anything. Little things count. Had to tell the pcb layout person to get the L out of there! (excuse the pun - again)Article: 74663
Hi Eric, > But is a approximate 1 Slice = 2 LE's a pretty close all around > estimate. Give or take ~10% as a design-dependant margin and you should be OK. Best regards, BenArticle: 74664
>> The "max" lines of code have to do with the simulation speed.
I'll have to look into the free ModelSim version again to see if I would slow down too much.
>> how do you probe inside the FPGA with a logic analyzer? Do you recompile
to bring out internal
points to IO pins?
I have 16 pins dedicated to an unused expansion bus on the Xilinx that I currently have hooked up to a logic analyzer. I can select beween 8 different 16-bit signals internal to the FPGA by hitting 1-8 on the serial port. Any time I add some code I hook up the relevant signals to the mux. I rarely have to recompile to get different signals out.
>> Chipscope Pro(tm) sure beats using a logic analyzer
Maybe I'll try this out, it looks like it might be worthwhile.
I'm not anti-simulation, I wish I had a good simulation tool but I also wish I had Matlab and a few other software packages, too. I don't, so I end up doing strange things like "simulating" an RS Encoder using bitwise operations in Microsoft Excel.
Article: 74665Hal Murray wrote: > > >I don't understand your point. If you don't tell the tool what an > >acceptable clock period is, then how is the tool supposed to know the > >difference between a nanosecond and a fortnight? Tools are not people, > >they can't reason. Besides, how would *I* know what you find an > >acceptable clock period if you don't tell me? I still see systems that > >are clocked well below 10 MHz. > > The tools could at least tell me what the worst case clock-clock > time is for each clock. That's not rocket science. And maybe > even give a warning for not specifying the appropriate constraints. Who said the tool does not give you the results? I belive at least one post here said that info *was* available. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74666
Guitarman wrote: > > Hello All, > > I've been designing with Xilinx FPGAs for a while so I'm used to the > "Slice" concept. I'm looking at Altera's Max II as a nice possible > solution for a design. > > I took my VHDL code and it synthesized to 40 Slices in a Spartan III. > Then I took the same code and sythesized it for a Max II (using > Quartus II now) and it was 71 LE's. > > I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly > dependant on how the code is sysnthesized. > > But is a approximate 1 Slice = 2 LE's a pretty close all around > estimate. The problem is not a hardware issue, but a granularity issue. Slices are not a good measure of how much logic your design is using. Slices have two LUTs and two FFs. If one FF is used, the slice is counted as used. You are better off determining how many LUTs and FFs are used in each design. They are much more comparable although there will be family dependant differences in how well the designs can pack into the larger granules. Mostly the newer parts will pack logic and FFs more densely than the older parts. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 74667
Xilinx 9500XL is the best choice for interfacing to 5V logic. Yet it's not capable of driving levels up to 5V, just 5V input tolerance. You can't get a single device for < 10$ in small or medium quantities. 9500XL has a maximum of logic ressources compared to coolrunner or even coolrunner2. Disadvantages of 9500xl: lot's of power consumption, drives only 8mA low, 4mA high. Use a mix of 95144xl and 9572xl for cost optimisation. If you need a quick and flexible solution for about 12-15$, use the smallest spartan3 device with an XCF01S platform flash and level shifters. MIKEArticle: 74668
Hi everybody, I'am searching for 4 digits BCD (=16 bits) to BIN convertor. If possible in VHDL. ThanksArticle: 74669
Since BCD to Bin is the easy direction (a bunch of adders), why is it you don't care to try it yourself? Are you limited by speed? Latency? Resources? CPLD rather than FPGA implementation? How many digits do you need? "JPR" <jpr@nospam.com> wrote in message news:41705b34$0$29012$afc38c87@news.easynet.fr... > Hi everybody, > > I'am searching for 4 digits BCD (=16 bits) to BIN convertor. If possible in > VHDL. > > ThanksArticle: 74670
> 1. Is it possible to put either Linux or Nucleus RTOS into this chip memory, Yes and yes by using the on-board DDR memory. The ML310 board actually ships with a pretty extensive demo for Linux. The web page for ML310 at http://www.xilinx.com/ml310 has a documentation section that describes in much detail on how to build Linux systems for the board. Further, XAPP765 is a document to get you started with EDK and MontaVista Linux (http://direct.xilinx.com/bvdocs/appnotes/xapp765.pdf) A (very) minimal Linux kernel takes around 600KB. So, you might be able to run it out of BRAM on larger chips. However, in most cases it is not the Linux kernel that takes most space but the application that you run on top of it. Nucleus is known to run on Virtex-II Pro. For more information please contact Mentor. > > 2. If yes, when Linux or Nucleus RTOS is loaded, will we get communications > stack and drivers for IEEE 802.11 in ad-hoc mode (this as any EE Engineer > knows is a wireless LAN standard)? While we have not tested the ML310 with a wireless card the Linux kernel supports these cards and we have done tests with PCMCIA cards from Cisco on the ML300 board. So, chances are high that a 802.11 PCI card will work out of the box. > > 3. If yes, then we'll purchase a standard IEEE 802.11 card, can this card be > plugged into your development kit port? Yes, into one of the four PCI slots (2x 3.3V, 2x 5V). - PeterArticle: 74671
On Sat, 16 Oct 2004 00:04:22 GMT, "John_H" <johnhandwork@mail.com> wrote: >Since BCD to Bin is the easy direction (a bunch of adders), why is it you >don't care to try it yourself? >Are you limited by speed? Latency? Resources? CPLD rather than FPGA >implementation? How many digits do you need? (probably just enough to get his homework done) l;-) -- Rich Webb Norfolk, VAArticle: 74672
More comments:- "Austin Lesea" <austin@xilinx.com> wrote in message news:ckpd8h$rn2@cliff.xsj.xilinx.com... > Symon, > > Answers below, > > Austin > > Symon wrote: > > Austin, > > PCB ground bounce? But this thread is about not having PCB power planes. > > It was about number of layers. A ground plane is a layer. > Go back and read the OP. He had a ground plane, he wanted to know if he could get away with routing the power separately. Yes he can! Especially with a PQ208 which has a lead frame made of little inductors on every pin! I hope you Xilinx boys have encapsulated some bypass caps in there somewhere! > > No-one's suggesting doing without a ground plane. That's the main (only!) > > weapon against ground bounce. The loop-inductance you're taking about that > > carries the return current is then between the FPGA and it's decoupling > > capacitors. The ground plane ensures the power supply doesn't bounce > > relative to the decoupled supply at the FPGA. > > The ground L is the bounce in the ground plane. The Vcc plane L is the > bounce in the Vcc. > Assuming the ground balls/pins are connected straight to the ground plane and if the Vcc balls/pins are coupled tightly to the ground plane via sufficient decoupling capacitors and enough low inductance copper track/local plane, you don't need a Vcc plane that traverses the whole board. The current loop is between the ground plane, the FPGA, the bypass cap. One plane can't bounce without the other if the bypass caps nail them together! > > If you're talking about ground bounce on the silicon, then all we PCB > > designers can do is firmly bolt down the ground pins to the PCB ground > > plane. A power plane, or lack thereof, isn't gonna affect ground bounce > > after that. > > Also, when you say in a previous post 'If you do not have both a power and a > > ground plane for each of these supplies, the SSO numbers must be reduced.', > > I'd disagree. You probably must have a ground plane, but throwing separate > > layers at supplies for Vcco, Vccint, Vccaux, Rocket I/O supplies is a little > > excessive! > > I said a pair of planes for each high current switching supply, namely a > Vccint/Gnd pair, and a Vcco/Gnd pair. That makes four layers. The dual > grounds are required to reduce the ground return inductance to something > that is reasonable. And the vcc loop inductance. Both. > Not necessary. The ground layer is important, as I said later more ground planes are good. But big planes for Vcco and Vccint are NOT necessary. Just low inductance from the bypass caps to the FPGA power pins/balls. > It's easier to use this methodology, and certainly easier for > > Xilinx to support, but you can get as good results by using one or two > > layers to share supplies locally at the FPGA. > > I disagree. Looking at those that succeed, vs. those who have issues, I > see those that followed our recommendations a much happier bunch. > Maybe you could come up with better recommendations, then your happy bunch might get happier and richer from the money they save on PCBs! > We take our recommendations very seriously. We are not out to minimize > our support, but rather to maximize our customers' successes (and our > own in the process). To suggest a marginal power distribution system is > just not good business! Why would we suggest that a customer 'play > around' when we and our disti's have already run all the simulations, > and built numerous verification, characterization, and demo pcbs to > prove what works, and what does not work? Fair enough. I'm sure this is true. > > Anyone who thinks they know better how to use our chip might get lucky, > but often is not. Why would anyone think that they know more than we do > about something they did not design? Surprisingly, many do think that > they know more, and as a consequence are sometimes terribly disappointed. > Deep breath! I can see why you sometimes rile up Rickman! ;-) Anyway, I count myself as someone who does know better how to use the chip in this case, at least better than XAPP623, and I have plenty of boards to back it up. When you get lucky every time, there's another word for it. I'm not saying it's easy, but it's possible, and I save my company a lot of money on PCBs by using fewer layers, fewer bypass caps, and squeezing extra functionality onto the board. What I'm trying to do with my posts here is help other folks understand that what Xilinx says is only one way to do it; other ways work, and work very well. Don't get me wrong, I think Xilinx does an excellent job, especially at support. Your recommendations enable someone with little PCB design expertise to get it right first time. Sometimes though, we non-Xilinx 'gentiles' can do good stuff too! > For the introduction of V4, we had a 1Gb/s LVDS networking pcb ready to > demo, and a memory interfaces pcb ready to demo. Those are two of the > largest applications problems our customers face today - fast IOs and > fast memories. If we don't know how to make it work, how would that > make a customer feel? > > I always read how a vendor suggests using their device. > We agree on this! > The use of the POL supplies is an experiment to validate a concept. I > wouldn't go to product until I had proven it works (if it was my job). > > The same goes for using only four layers, or traces to Vcco, etc. > > You can also use this layer > > for other things away from the FPGA. To do this, your decoupling must be > > good at the FPGA, and the connection between the supply and the local plane > > must be able to supply the current needed. > > You're also, IMHO, better off having multiple ground planes, and routing the > > power. > > Yes, ground is all important (more so than the Vcc's), and Vcc 'planes' > may sometimes just be routed. It depends again on the switched currents. > OK, so now we agree that a routed/local planed Vcc works? You seem to flip-flop more than a Democrat nominee! ;-) Again we agree, local plane/ routed can Vcc work fine. > > Finally, I'd be interested in how increasing bypass capacitance can make > > ground bounce worse in the same system, especially one with a ground plane? > > More energy stored? > > Yes, the rails don't collapse. But if the rails collapse, ground bounce is the least of your worries. Your design is already dead. > > di larger? > > Yes, the source impedance is lower. > > dt faster? > > Yes, lower source impedance also leads to faster transients. > At these high frequencies, the capacitor package size (= inductance) is the thing that dominates the source impedance. Not the capacitance. Look at the manufacturers data sheets. Download this and look for yourself http://www.murata.com/designlib/mcsil.html . Above 50MHz an X5R 0402 cap has the same impedance whether it's 56nF or 470nF. The ground bounce problem is solely a result of poor coupling between the ground plane and the FPGA. > Lastly, we had a case where the vias from the bypass caps where wired > such that the L from the cap to the plane was the largest element (not > hard to do, one tiny via each end, at the end of a flag of trace to the > chip cap). Adding caps directly across the existing cap did absolutely > nothing. One might conclude that the bypassing wasn't doing anything. > But really, the L to the caps was so bad, that the caps were not doing > anything. Little things count. > > Had to tell the pcb layout person to get the L out of there! (excuse the > pun - again) Of course, very good point. It's a constant fight against the PCB routing tool to prevent it stripping out extra vias I add to decrease impedance. Ah, Austin, I enjoy these chats. Even when I C your terrible puns! Write back soon mate, Syms. ;-)Article: 74673
Followup to: <90282e35.0410151112.77a87654@posting.google.com> By author: ericjohnholland@hotmail.com (Guitarman) In newsgroup: comp.arch.fpga > > Hello All, > > I've been designing with Xilinx FPGAs for a while so I'm used to the > "Slice" concept. I'm looking at Altera's Max II as a nice possible > solution for a design. > > I took my VHDL code and it synthesized to 40 Slices in a Spartan III. > Then I took the same code and sythesized it for a Max II (using > Quartus II now) and it was 71 LE's. > > I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly > dependant on how the code is sysnthesized. > > But is a approximate 1 Slice = 2 LE's a pretty close all around > estimate. > Well, given that 1 slice = 2 LUTs + 2 FFs + some more logic, and 1 LE = 1 LUT + 1 FF + some more logic, it would be expected. -hpaArticle: 74674
Marc, My colleague just came clean; he'd fitted an early V2P7 that didn't have the LVDS_DT functionality. No wonder he had problems that external resistors fitted. Cheers, Syms. "Marc Randolph" <mrand@my-deja.com> wrote in message news:4JOdna9_pM_87ffcRVn-tg@comcast.com... > Symon wrote: > >>Just be aware that the internal termination can be > >>less than ideal. > > > > Care to relate your experiences of the internal termination? I've had no > > trouble at 600Mbit/s data and a 600MHz clock. Some of my colleagues have > > mentioned that they've run into problems, and they've reverted to fitting > > external 100R resistors. > > Howdy Symon, > > We are using the internal _DT resistors on a V2P7 for receiving a > LVDS clock that is slightly over 600 MHz, as well as the source > synchronous data that goes along with it. It technically works (we > never have bit errors over all operating conditions), but using a > differential probe at the vias immediately below the inputs pins show > that there isn't much margin - the signal quality looks pretty poor. > > A more serious problem that we had was with a 600+ MHz GCLK input. What > we believe we discovered was that a nearby GCLK input with a single > ended 3.3V 66 MHz clock was affecting its signal quality enough that > we'd sometimes miss clocks. The 66 MHz clock looked good (no excessive > overshoot or other noise on it). Lowering the frequency to 311 MHz, > with no change to routing, fixed the problem. > > Have fun, > > Marc
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