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
For all your basic questions you can read the book on "ASIC" by Micheal John Sebastin Smith. According to me this is the ASIC bible for beginners. regards, CS "newbie" <nospam@nospam.org> wrote in message news:<W7wrb.13571$Mn.339275@news.xtra.co.nz>... > Hi all > > Can someone help in understanding the main difference between ASIC and FPGA. > I keep hearing both these terms and am not fully clear. > Is there a website explaning this? > > ThanksArticle: 62851
Eric Crabill wrote: > > Hi, > <snip> > > Can you think of an instance where a customer would need > > both at once, on the same pin ? > > For a general purpose FPGA, with general purpose programmable > I/O, you need this on every pin... While the end user makes > a selection via the bitstream, the actual hardware has to be > capable of handling all possible configurations. Not true. Some of the more esoteric IOs are already 'blocked' Users could live with not having 5V IO on every single IO, jus like they live with not having 840MHz SerDes on every IO. > On recent devices, 5V I/O is gone... I would not be surprised > if it's the same issue all over again with 3.3V in a few years. Depends on where you look, and why. On embedded controllers, 5V is actually making a comeback. Lattices' very newest CPLDs, added 5V tolerant IOs. On chip regulators are also appearing, as other vendors look at ways to expand the use-ability of the shrink silicon. > As I had mentioned, it is possible to build a device to support > 5V I/O. That device will cost more for everyone, even if they > are not using 5V I/O. Those I/O will also be slower. I believe > few people would buy these parts, due to the higher cost and > lower performance. Give the customers some hard numbers, and let them decide for themselves :) I see Hynix have just released a high voltage 0.18u process, that targets LCD display drivers (so high voltage here means 40-50V region ) > > There are other approaches -- things like dedicated banks of I/O > just for a specific purpose. Xilinx uses this for the gigabit > serial transceivers in V2pro. One could do something similar > but for a bank of 5V I/O. For 5V I/O, it would still make the > devices more expensive. Some numbers ? XX cents per pin ? > > The point is, if FPGA wish to broaden their market with > > processor cores, and so play in the larger controller > > sandpit, they are going to have to address issues that > > normally go into the 'too hard / not enough market' > > reflex-box. > > If there's "not enough market" I doubt anyone trying to make > money is going to address it. If there were a significant > market, but there were technical hurdles, I am sure people > here, and at other FPGA vendors, would be researching a way > to cash in on it. They are already. Wider Vcc range devices are appearing, you just have to look for them (they are not appearing in FPGA markets first). Narrow/lowered/restricted Vcc devices have been replaced by better engineered, wider Vcc ones. There was an interesting earlier thread that touched on leakage failure modes in higher IO on the finest processes. -jgArticle: 62852
Hi all, xapp660 states that the maximum frequency for the ICAP (internal version of the SelectMAP-interface) is 35MHz. Yet the maximum frequency for SelectMAP is supposed to be 50MHz. How come there's a difference there if the whole point of ICAP is to give you access to the regular SelectMAP-port with all its capabilities from within the FPGA? Isn't ICAP supposed to be just a way to access the exact same logic that is connected to the outside via a set of pins? So the why does it make a difference if I access the same configuration logic via pins from outside the FPGA or via nets from within? -- Sean Durkin Fraunhofer Institute for Integrated Circuits (IIS) Am Wolfsmantel 33, 91058 Erlangen, Germany mailto:23@iis.42.de ([23 , 42] <=> [durkinsn , fraunhofer])Article: 62853
Dear Sir or Madame, I have a data packet which has a 13 bit field for an USB application(7bit + 4bit + 1bit + 1bit). Because of lack of memory I do create a RAM which has a data input width of only 10 bit. The write address of the RAM is [4..0], i.e. 32 words á 10 bit. The words which are written into the RAM are searched for later (CAM-like function). The problem: I have to reduce 13 bit to 10 bit without losing the significance of the 13 bit. But it is not possible to leave out for example two bits of the 7bit (usb address) because the enumeration by the host is not predictable. How could I solve this problem? Thank you very much. Best regards Andres Vazquez G&D System DevelopmentArticle: 62854
Hi, In my experience, when I have to move from a release to another of the ISE, I prefer to create a new project and reuse only the vhdl file and the ucf file. Sometimes there are a strange incompatibility from the release that can generate strange behaviour. By Giuseppe "colin hankins" <colinhankins@cox.net> ha scritto nel messaggio news:kzCrb.14571$Zb7.8816@fed1read01... > I installed ISE 6.1 with the service pack and my Spartan IIe design that > worked fine under 5.2 no longer works in the timing simulation in 6.1. Also, > the number of Slices used increased by 10% as well as the TBUFS. I have > fiddled with almost every combination of options in the synth, map, and par > to try and recreate the better results I had in ISE 5.2. I talked to Xilinx > and they just told me to fiddle with the parameters some more. Has anyone > else had similar problems migrating a project from 5.2 to 6.1? > > Regards, > Colin > >Article: 62855
I'm trying to get rid of all unconstrained nets and wonder how I can specify max delay for nets that is (partly) used to reset DLL's. There are keywords for FFS, LATCHES and RAMS, but none for DLLs?Article: 62856
Yes, there has been discussion on this group regarding this "phenomenon." I have a design that lost about 10% in timing going to 6.1 and that was with heavy use of timing constraints and area constraints. I ended up having to hand place individual LUTs (which also means I lost many of the benefits of synthesis). I wasn't very happy. I've gone back to 5.2 on some of my projects. 6.1 on a few, but with this kind of track record, I don't have much faith in 6.1. If it ain't broke... Jake "colin hankins" <colinhankins@cox.net> wrote in message news:<kzCrb.14571$Zb7.8816@fed1read01>... > I installed ISE 6.1 with the service pack and my Spartan IIe design that > worked fine under 5.2 no longer works in the timing simulation in 6.1. Also, > the number of Slices used increased by 10% as well as the TBUFS. I have > fiddled with almost every combination of options in the synth, map, and par > to try and recreate the better results I had in ISE 5.2. I talked to Xilinx > and they just told me to fiddle with the parameters some more. Has anyone > else had similar problems migrating a project from 5.2 to 6.1? > > Regards, > ColinArticle: 62857
Hi, I have a question concerning the enumeration by USB 2.0 host controllers: How does the host controller enumerate the devices, in a sequential or in a random order? Are there differences between controllers or is it left to the designer's own controller programming ressources? Thanks a lot. Kind regardsArticle: 62858
Sean, It has to do with what we are able to test, and thus what we are able to specify. The ICAP should be just as fast, but not being able to verify that easily makes it something that gets specified in a safe region where 100% of the parts are guaranteed to operate. Austin Sean Durkin wrote: > Hi all, > > xapp660 states that the maximum frequency for the ICAP (internal version > of the SelectMAP-interface) is 35MHz. Yet the maximum frequency for > SelectMAP is supposed to be 50MHz. How come there's a difference there > if the whole point of ICAP is to give you access to the regular > SelectMAP-port with all its capabilities from within the FPGA? Isn't > ICAP supposed to be just a way to access the exact same logic that is > connected to the outside via a set of pins? So the why does it make a > difference if I access the same configuration logic via pins from > outside the FPGA or via nets from within? > > -- > Sean Durkin > Fraunhofer Institute for Integrated Circuits (IIS) > Am Wolfsmantel 33, 91058 Erlangen, Germany > > mailto:23@iis.42.de > ([23 , 42] <=> [durkinsn , fraunhofer])Article: 62859
If this project is realized, pls. let me know too: ser@hil.kiev.ua Sergej HilgurtArticle: 62860
> If by some chance I ever used my home grown, ISA compatible, core in a > commercialized product, would there be legal issues? Chances are I > would never use my own and would probably use a Nios or Microblaze > instead, but if I just needed a simple little core, it could prove > useful. AFAIK (and IANAL) the only effective legal way against a processor clone are patents. This means that very old designs like the 8051, 6502, PIC, etc. should be no problem. The patents only affect ways to design or implement the processor, not the ISA. So if you knew the patents you could design the CPU in a way that does not violate the patent. Unfortuanatle as an amateur you can never be sure what kind of wierd patents suddenly surface out of nowhere. The ISA can not be protected effectively. This does not mean that a pissed processor vendor will not send a hord of lawyers after you to scare you or to cover you in loads of expensive paperwork. Therefore you should stay away from CPUs from companies that live from processor licensing fees. (Like ARM or MIPS) If you really want to play it safe you should implement a SPARC ISA. That's an open standard. Or do a reimplementation of picoblaze or microblaze or xr16. I believe that Xilinx won't mind another Microblaze implementation that helps selling there Chips. (Göran, can you comment on that?) And Jan Gray explicitely stated that he does not object to reimplementations of his xr16 design. Kolja SulimmaArticle: 62861
Hi, I can't see why Xilinx would be against a clean room implementation of MicroBlaze. It would actually be quite interesting. We actually want to promote the use of MicroBlaze. We are not getting our money from MicroBlaze sells but rather on the FPGAs that MicroBlaze uses. If someone did a clean room, open source implementation of MicroBlaze it would probably letting us sell more FPGAs. As Kolja said, you can't really effectively patent an ISA, only an implementation. BUT an implementation can have certain features which you can patent and thus make it hard to design around that patent. ARM has the shadow registers at interrupts and MIPS has the unaligned word access handling,... Even if you did a clean room implementation of ARM and avoid all patents, ARM will sue you to the end. So unless you have big financial backing that will pay your lawyers, you will not win. Göran Kolja Sulimma wrote: >>If by some chance I ever used my home grown, ISA compatible, core in a >>commercialized product, would there be legal issues? Chances are I >>would never use my own and would probably use a Nios or Microblaze >>instead, but if I just needed a simple little core, it could prove >>useful. >> >> > >AFAIK (and IANAL) the only effective legal way against a processor >clone are patents. This means that very old designs like the 8051, >6502, PIC, etc. should be no problem. >The patents only affect ways to design or implement the processor, not >the ISA. So if you knew the patents you could design the CPU in a way >that does not violate the patent. Unfortuanatle as an amateur you can >never be sure what kind of wierd patents suddenly surface out of >nowhere. > >The ISA can not be protected effectively. This does not mean that a >pissed processor vendor will not send a hord of lawyers after you to >scare you or to cover you in loads of expensive paperwork. Therefore >you should stay away from CPUs from companies that live from processor >licensing fees. (Like ARM or MIPS) > >If you really want to play it safe you should implement a SPARC ISA. >That's an open standard. > >Or do a reimplementation of picoblaze or microblaze or xr16. I believe >that Xilinx won't mind another Microblaze implementation that helps >selling there Chips. (Göran, can you comment on that?) > >And Jan Gray explicitely stated that he does not object to >reimplementations of his xr16 design. > >Kolja Sulimma > >Article: 62862
Austin Lesea wrote: > Sean, > > It has to do with what we are able to test, and thus what we are able to > specify. > > The ICAP should be just as fast, but not being able to verify that easily > makes it something that gets specified in a safe region where 100% of the > parts are guaranteed to operate. Thanks for the info, Austin. It seems to me that the 35MHz is indeed all ICAP can handle. At least I've tried 33MHz and 38Mhz, and it works fine with the first but doesn't with the latter, so 35MHz seems reasonable. Whereas the strange thing is that it even works at 50MHz, but only for a while. I posted awhile back that I had trouble performing a readback of the CLB configuration data via ICAP. Now I know it's because I used a CCLK out of spec (I was using 50MHz back then), but the strange thing is that it worked fine for about 370000 bytes, stopping exactly at the same point each and every time I tried, so problems with the clock weren't the first thing I looked into. Seems like there's some error accumulating there that sums up to a S/H-time violation or something after a give time... -- Sean Durkin Fraunhofer Institute for Integrated Circuits (IIS) Am Wolfsmantel 33, 91058 Erlangen, Germany mailto:23@iis.42.de ([23 , 42] <=> [durkinsn , fraunhofer])Article: 62863
In article <b890a7a.0311100755.72deef43@posting.google.com>, Kolja Sulimma <news@sulimma.de> wrote: >The ISA can not be protected effectively. This does not mean that a >pissed processor vendor will not send a hord of lawyers after you to >scare you or to cover you in loads of expensive paperwork. Therefore >you should stay away from CPUs from companies that live from processor >licensing fees. (Like ARM or MIPS) I'm not so sure about this, look at some of the unique ISA features (eg, the initial conditional execution in ARM, the IA64 deferred exceptions (good idea) and rotating register file (bad idea)). I think these items can and are patented. >If you really want to play it safe you should implement a SPARC ISA. >That's an open standard. Just don't call it SPARC. You have to say "Sparc Compatabile IEEE whatever" until you pay sparc money. But that's no big deal. >Or do a reimplementation of picoblaze or microblaze or xr16. I believe >that Xilinx won't mind another Microblaze implementation that helps >selling there Chips. (Göran, can you comment on that?) Microblaze is probably a nice one, since it should map well to large families of FPGAs. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 62864
Hi Goran,
So, playing devli's advocate, Xilinx wouldn't mind if the clean room
Microblaze was targeted at their competitors' devices? Or do you think that
no one would do this because Microblaze only efficiently fits the Xilinx
devices? Or the competitors have their own solutions for their parts?
I wonder....
cheers, Syms.
"Goran Bilski" <goran@xilinx.com> wrote in message
news:boodq5$bgr2@cliff.xsj.xilinx.com...
Hi,
I can't see why Xilinx would be against a clean room implementation of
MicroBlaze.
It would actually be quite interesting.
We actually want to promote the use of MicroBlaze.
We are not getting our money from MicroBlaze sells but rather on the FPGAs
that MicroBlaze uses.
If someone did a clean room, open source implementation of MicroBlaze it
would probably letting us sell more FPGAs.
Article: 62865Thanks all for the good pointers. As mentioned, the simultaneous switching will definitely be an issue. I never heard about this technique of switching different DRAM chips on different phases of the clock. Is it commonly used? There was also a brief mention of "serial DIMMs". Has anyone seen anything like that, or would I need to start from scratch? The problem I'm looking operates on data sets ~16GB. Computation takes about 0.5 sec, compared with ~2 sec required to download (@100MHz). BRAM is used as cache for bandwidth. The main memory bandwidth range I'm interested in would be ~50GB/s, so the computation and memory-access times are comparable. That's why I'm asking the experts, is this currently attainable with FPGAs? Thanks again, FernandoArticle: 62866
In article <2658f0d3.0311100853.4468d276@posting.google.com>, Fernando <fortiz80@tutopia.com> wrote: >As mentioned, the simultaneous switching will definitely be an issue. >I never heard about this technique of switching different DRAM chips >on different phases of the clock. Is it commonly used? I don't see why not, its a simple and elegant solution. >The main memory bandwidth range I'm interested in would be ~50GB/s, so >the computation and memory-access times are comparable. That's why I'm >asking the experts, is this currently attainable with FPGAs? Its pin bandwidth which is going to be needed, and lots of pins. So lets take a 200 MHz DDR signaling, thats 400 Mbps/pin peak. Thus 50 GBs would take, at MINIMUM, 1000 pins! 1000 signaling pins, at 400 MHz, is not very happy. Probably barely doable on the largest part, but not happy. Then there are all the control pins. Quesion: do you REALLY need all that memory bandwidth? Do you really need all that speed? Or could you just make things take 10x longer, only require 2 banks of DDR, and use a smaller piece of FPGA logic? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 62867
"colin hankins" <colinhankins@cox.net> wrote in message news:kzCrb.14571$Zb7.8816@fed1read01... > I installed ISE 6.1 with the service pack and my Spartan IIe design that > worked fine under 5.2 no longer works in the timing simulation in 6.1. Also, > the number of Slices used increased by 10% as well as the TBUFS. I have > fiddled with almost every combination of options in the synth, map, and par > to try and recreate the better results I had in ISE 5.2. I talked to Xilinx > and they just told me to fiddle with the parameters some more. Has anyone > else had similar problems migrating a project from 5.2 to 6.1? > Even worse, I have fatal errors in synthesis of pipelined LUT multipliers which worked fine in 5.2 Talked to Xilinx and got the same useless answer... Hopefully, someone will stumble on a solution, or Xilinx will fix it in a service pack. If not, we'll be stuck on 5.2 ;(Article: 62868
Hi Symon, I don't think Xilinx would be happy but I don't think we would do anything against it. I also think that MicroBlaze will be better implemented in our FPGA than in our competitors. If someone did a clean, pure RTL implementation of MicroBlaze, I think that someone will very quickly try it on our competitors FPGA. I have a pure RTL version of MicroBlaze and it doesn't look good when targeting other devices than Xilinx's devices. But someone started from scratch, the design would probably not be so biased against Xilinx. Göran Symon wrote: >Hi Goran, > So, playing devli's advocate, Xilinx wouldn't mind if the clean room >Microblaze was targeted at their competitors' devices? Or do you think that >no one would do this because Microblaze only efficiently fits the Xilinx >devices? Or the competitors have their own solutions for their parts? > I wonder.... > cheers, Syms. > > >"Goran Bilski" <goran@xilinx.com> wrote in message >news:boodq5$bgr2@cliff.xsj.xilinx.com... >Hi, > >I can't see why Xilinx would be against a clean room implementation of >MicroBlaze. >It would actually be quite interesting. >We actually want to promote the use of MicroBlaze. >We are not getting our money from MicroBlaze sells but rather on the FPGAs >that MicroBlaze uses. >If someone did a clean room, open source implementation of MicroBlaze it >would probably letting us sell more FPGAs. > > > > > >Article: 62869
Hal Murray wrote: > > > Don't get me wrong. As a standard bus interface IP developer > > (PCI, PCI-X, and now PCI Express...) I like 5V I/O even more > > than the next guy. I'd love to be able to directly support > > 5V PCI on newer Xilinx parts without external components. > > What's the newest/best/cheapest part that's reasonable to > connect to old 5V PCI? > > Is there a legal recipe using external parts? I'd expect > that approach would have troubles meeting the loading rules. > > -- > 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. The newest 5 volt tolerant parts that Xilinx has are the Virtex / Spartan II lines. But they both have high startup current requirements. They have recently refined these requirements, but they are still very high relative to the normal currents and require special attention to power supply design, especially if you are using industrial temp parts. On the 5 volt IO parts without the high startup current requirement, Xilinx has no parts that are fully supported with current software. They still recommend the old Spartan XL parts for new designs, but they are only supported with old software which is poorly supported by the hotline. Because of that and the poor price/function ratio, we chose a different vendor. Altera has the ACEX line of parts which are still fully supported by the current software. They are also newer parts (~2 years old) which should be available for a long time to come. BTW, on the price issue, I have found that both vendors will substantially cut their prices to get a design win. If you talk directly to the FPGA vendor's rep you can get 50% or larger reduction in price for moderate volumes. -- 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: 62870
Synthesis : 1.XST 2.Mentor Leo Spec 3.mentor Precision RTL 4. Synplicity Synplify /Pro 5. Synopsys FPGA Compiler II 6. Synopsys Design Compiler Physical Optimization /Synthesis: 1. Mentor Precision Physical 2. Synplicity Amplify 3. Magma (acquired from Aplus) Design PALACE 4. HDI PlanAhead Simulation (HDL) 1. ModelSim 2. Cadence Verilog XL, NC-Sim 3. Synopsys VCS Formal Verification: 1. Synopsys Formality 2. Verplex (now Cadence) Conformal-FPGA Co-design: 1. Mentor Seamless Schematic: 1. Mentor Design architect 2. Innoveda 3. Cadence concept Board level timing 1. Mentor Tau Board level Signal integrity 1. Mentor HyperLYNX 2. Mentor ICX 3. Cadence Specctraquest "Nagaraj" <nagaraj_c_s@yahoo.com> wrote in message news:91710219.0311050420.679a7a14@posting.google.com... > I meant much more. For a detailed design flow, including code > coverage, DFT, physical synthesis, etc. > > regards, > nagaraj > > Mike Treseler <tres@tc.fluke.com> wrote in message news:<3FA83665.9030100@tc.fluke.com>... > > 1. Design entry > > Tool1: emacs vhdl-mode, verilog mode > > Tool2: Quartus block diagram > > 2. Simulation > > Tool1: Modelsim > > Tool2: Aldec > > 3. Synthesis > > Tool1: Leo Spec > > Tool2: Synplify Pro > > Tool3: Quartus > > Tool4: XST > > 4. Place and Route > > Tool1: Xilinx Place & Route + static timing > > Tool2: Quartus Place & Route + static timing > > > > -- Mike TreselerArticle: 62871
Hi all, Is there a VHDL simulation model of the Spartan II/III boot process? I have some boot logic that runs in a CPLD and I'd like my testbench to have something that behaves like a booting FPGA. -- Brad EckertArticle: 62872
> If you really want to play it safe you should implement a SPARC ISA. > That's an open standard. > > Or do a reimplementation of picoblaze or microblaze or xr16. I believe > that Xilinx won't mind another Microblaze implementation that helps > selling there Chips. (Göran, can you comment on that?) > Thanks, the Picoblaze looks like a simple one to look at first. Plenty of documentation and free tools as well. BPArticle: 62873
I asked a DRAM vendor about the possibility of serial DRAM. The comment was that they weren't considering that direction because of poorer latency. I'm not certain the arguement was valid, though, because the DDR design I was trying to put together had to register in the IOBs and in the logic fabric; if the buffering was reduced in the FPGA internals using the serial links, the overall latency might be the same (or better) at a huge reduction in pins. The bandwidth is, however, still an issue. 64 bits wide, 400M/s -> 25.6 Gb/s. Oops! "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:UKFrb.6522$2e2.2752@newssvr25.news.prodigy.com... > It would seem to me that the idea of using custom "serial dimms" combined > with Virtex II Pro high speed serial I/O capabilities might be the best way > to get a boost in data moving capabilities. This would avoid having to > drive hundreds of pins (and related issues) and would definetly simplify > board layout. > > I haven't done the numbers. I'm just thinking out loud. > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu" > > > > "Robert Sefton" <rsefton@abc.net> wrote in message > news:bomt69$1equ1q$1@ID-212988.news.uni-berlin.de... > > Fernando - > > > > Your instincts are right on with respect to the difficulty of fitting > > that many DIMMs on a board and interfacing to them from a single FPGA. > > Forget about it. The bottom line is that there's a trade-off between > > memory size and speed, and memory is almost always the limiting factor > > in system throughput. If you need lots of memory then DRAM is probably > > your best/only option, and the max reasonable throughput is about what > > you calculated, but even the 5-DIMM 320-bit-wide data bus in your > > example would be a very tough PCB layout. > > > > If you can partition your memory into smaller fast-path memory and > > slower bulk memory, then on-chip memory is the fastest you'll find and > > you can use SDRAM for the bulk. Another option, if you can tolerate > > latency, is to spread the memory out to multiple PCBs/daughtercards, > > each with a dedicated memory controller, and use multiple lanes of > > extremely fast serial I/O between the master and slave memory > > controllers. > > > > A hierarchy of smaller/faster and larger/slower memories is a common > > approach, e.g., on-chip core-rate L1 cache, off-chip fast L2 cache, and > > slower bulk SDRAM in the case of microprocessors. If you tossed out some > > specific system requirements here you'd probably get some good feedback > > because this is a common dilemma. > > > > Robert > > > > "Fernando" <fortiz80@tutopia.com> wrote in message > > news:2658f0d3.0311090256.21ce5a9a@posting.google.com... > > > Sharing the control pins is a good idea; the only thing that concerns > > > me is the PCB layout. This is not my area of expertise, but seems to > > > me that it would be pretty challenging to put (let's say) 10 DRAM > > > DIMMs and a big FPGA on a single board. > > > > > > It can get even uglier if symmetric traces are required to each memory > > > sharing the control lines...(not sure if this is required) > > > > > > Anyway, I'll start looking into it > > > > > > Thanks > > > > > > Phil Hays <SpamPostmaster@attbi.com> wrote in message > > news:<3FAD39F6.5572E42C@attbi.com>... > > > > Fernando wrote: > > > > > > > > > How fast can you really get data in and out of an FPGA? > > > > > With current pin layouts it is possible to hook four (or maybe > > even > > > > > five) DDR memory DIMM modules to a single chip. > > > > > > > > > > Let's say you can create memory controllers that run at 200MHz (as > > > > > claimed in an Xcell article), for a total bandwidth of > > > > > 5(modules/FPGA) * 64(bits/word) * 200e6(cycles/sec) * > > (2words/cycle) * > > > > > (1byte/8bits)= > > > > > 5*3.2GB/s=16GB/s > > > > > > > > > > Assuming an application that needs more BW than this, does anyone > > know > > > > > a way around this bottleneck? Is this a physical limit with > > current > > > > > memory technology? > > > > > > > > Probably can get a little better. With a 2V8000 in a FF1517 > > package, > > > > there are 1,108 IOs. (!) If we shared address and control lines > > between > > > > banks (timing is easier on these lines), it looks to me like 11 > > DIMMs > > > > could be supported. > > > > > > > > Data pins 64 > > > > DQS pins 8 > > > > CS,CAS, > > > > RAS,addr 12 (with sharing) > > > > ==== > > > > 92 > > > > > > > > 1108/92 = 11 with 100 pins left over for VTH, VRP, VRN, clock, > > reset, ... > > > > > > > > Of course, the communication to the outside world would also need go > > > > somewhere... > > > > > >Article: 62874
Hi, You can use Virtex or Spartan-II to interface with 5V PCI bus and retain full compliance per the specification. You can use any of our devices, even Spartan3 and Virtex2Pro, with the 5V PCI bus, but you need some level translators. This is certainly a functional solution (I've tested it personally) but it is not compliant with the letter of the specifications. The specifications are pretty clear that you are allowed only one component, and that is your "PCI component" and all bus signals must attach directly to that one component. Eric Hal Murray wrote: > > Don't get me wrong. As a standard bus interface IP developer > > (PCI, PCI-X, and now PCI Express...) I like 5V I/O even more > > than the next guy. I'd love to be able to directly support > > 5V PCI on newer Xilinx parts without external components. > > What's the newest/best/cheapest part that's reasonable to > connect to old 5V PCI? > > Is there a legal recipe using external parts? I'd expect > that approach would have troubles meeting the loading rules.
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