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
rickman <gnuarm@gmail.com> wrote: >On Mar 19, 10:03 am, "sdaau" <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk> >wrote: >> Hi all, >> >> I am speculating about starting an FPGA based project soon, which may need >> to use RAM. So I'd like to leverage the (relative) abundance (and thus, >> hopefully low price) of desktop (or laptop) PC memory modules for this >> purpose - and I was wandering if the community had any comments or >> suggestions. >> >> Primary points of interest are: >> >> * What is, in your opinion, the cheapest type of DIMM (desktop?) and >> SO-DIMM (laptop?) modules currently available (2010-2011)? From a quick >> scan, I can find >> ** SO DIMM 200-PIN, 1x512 MB module (DDR2 SDRAM) 667 MHz >> ** DIMM 240-PIN, 1x1GB module (DDR3 SDRAM) 1066 MHz >> .. for approx the same price ( below 13 Euro per GB). I'm aware this may >> be location dependent - but would the above represent the (currently) >> cheapest/most abundant modules on the market? If not, what would you >> consider cheapest/most abundant - and what would be a good reference >> (website) to consult? >> >> * Do the PCB sockets for the diverse module types differ significantly in >> price (maybe SO-DIMM sockets usually cost twice as much as DIMM?) Also, any >> (negative) experiences in soldering any of these by hand? >> >> * When they say stuff like "DDR2 SO-DIMM memory modules commonly have clock >> speeds from 200 MHz up to 800 MHz" (http://en.wikipedia.org/wiki/SO-DIMM), >> I'd assume they talk of max frequencies - does that still mean, that I can >> clock the modules with _less_ of a frequency (say 50 MHz)? >> >> * Given that, say, "DDR2 is neither forward nor backward compatible with >> either DDR or DDR3" (http://en.wikipedia.org/wiki/DDR2_SDRAM), obviously >> there is a need for dedicated hardware signaling interface for each type of >> RAM. Is there something like a 'base interface' (say, maybe something like >> SPI), which would be relatively easy to use, and that all RAM modules would >> support (at the expense of reaching top speeds)? >> >> * Assuming that there (most likely) isn't such a 'base interface' for all >> RAM types, what (of the currently cheapest and most available types of >> modules) would you feel is easiest to learn to interface with? >> >> I'd also love to hear any other considerations in this type of usage that I >> may have missed - as well as any links to tutorials/previous projects using >> FPGA and these types of RAM for PCs.. >> >> Looking forward to any responses - thanks in advance, >> Cheers! > > >Based on some of the questions you are asking, it appears that you are >a newbie to working with DRAM. Each version of DRAM has its own >characteristics, always optimized for transfer speed. SDRAM transfers >one word on each clock cycle. DDR SDRAM transfers two words on each >clock cycle. DDR2 transfers four words on each clock cycle and I >don't know for sure, but I expect DDR3 transfers eight words on each >clock cycle. There are also electrical differences because typical Wrong. All DDR memories transfer two words for each clock cycle. Higher versions offer more facilities like on-die-termination, on chip PLLs, higher speeds and lower voltages. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 151276
Don't worry about compatibility between different RAM types. Your board will need to be re-designed to change type. First of all there are different core voltages for each type. Then if you use a DIMM or SO-DIMM there are differences in the socket keying. One thing that would normally point to using chips rather than SO-DIMM or DIMM is that the cheapest FPGA families often don't support DIMM memory. This is true of Spartan 6 for example. So saving a few bucks on DIMM memory may cost you big bucks going for a higher end FPGA. My only reason to go away from chip memory would be that I need a very large amount of memory (more than a couple of the densest chips). Finally the price sweet spot for memory is a moving target. I think right now your best price per bit is still DDR2, but DDR3 should take over soon enough. That being said it does you no good to decide on DDR3 until you know your FPGA will support it at a reasonable speed (watch out - all DDR families have relatively high minimum operating frequencies). -- GaborArticle: 151277
> Hi, > > Yet another newbie question: > Is SDRAM fast enough to generate a 720p or 1024p video stream (VGA or > DVI output) using a Spartan-3 or -3E FPGA ? > I am also interested if SDRAM is sufficient for video streaming? E.g. Video-over-IP.Article: 151278
Maybe you are using the "E"-version of Nios? This low performance- version became "freeware" some time ago. Regards, ThomasArticle: 151279
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote: > On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote: (snip) >> It was at FPL1999 that someone presented this as a sidenote in a >> presentation about some >> other topic. They said they were able to damage Altera FPGAs by >> instantiating ring counters. (snip) > What you remember as a ring counter was probably a ring oscillator > that was used to get a high frequency clock to drive the rest of the > FPGA logic with a high toggle rate. Without system level > considerations and monitoring the power requirements could easily push > the device into a thermal region that would damage the device. The > HDL and bitstream itself is perfectly valid, it is the thermal > management that is to blame for the destruction. The failure points > would likely be wide spread through the device. The designs that I am interested in have many signals changing on average every other clock cycle, and clocked as fast as I can get the design to run. I have wondered when that will cause thermal problems, such as requiring a heat sink. > This failure mode isn't the same as a badly constructed bitstream > violating DRC rules and creating device damage that would be difficult > to detect as it may only exist at a few points within the device. Well, a small ring oscillator would cause local heating, which may be enough to damage a small portion of the device. > Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC > in the 7 Series families) have the ability to shutdown the device if > the junction temperature exceeds user defined values. This can be > used to prevent this type of thermal damage, but it would not be able > to prevent localized damage due to bad bitstreams. That should work for heating over the whole array, but maybe not good enough for a localized ring oscillator. Though shouldn't DRC be able to detect ring oscillators? Is it that hard to do? -- glenArticle: 151280
On Mar 19, 6:49=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > On Mar 19, 10:48=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > (snip) > > >> It was at FPL1999 that someone presented this as a sidenote in a > >> presentation about some > >> other topic. They said they were able to damage Altera FPGAs by > >> instantiating ring counters. > > (snip) > > > What you remember as a ring counter was probably a ring oscillator > > that was used to get a high frequency clock to drive the rest of the > > FPGA logic with a high toggle rate. =A0Without system level > > considerations and monitoring the power requirements could easily push > > the device into a thermal region that would damage the device. =A0 The > > HDL and bitstream itself is perfectly valid, it is the thermal > > management that is to blame for the destruction. =A0 The failure points > > would likely be wide spread through the device. > > The designs that I am interested in have many signals changing > on average every other clock cycle, and clocked as fast as I can > get the design to run. =A0I have wondered when that will cause thermal > problems, such as requiring a heat sink. > > > This failure mode isn't the same as a badly constructed bitstream > > violating DRC rules and creating device damage that would be difficult > > to detect as it may only exist at a few points within the device. > > Well, a small ring oscillator would cause local heating, which > may be enough to damage a small portion of the device. > > > Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC > > in the 7 Series families) have the ability to shutdown the device if > > the junction temperature exceeds user defined values. =A0This can be > > used to prevent this type of thermal damage, but it would not be able > > to prevent localized damage due to bad bitstreams. > > That should work for heating over the whole array, but maybe not > good enough for a localized ring oscillator. > > Though shouldn't DRC be able to detect ring oscillators? =A0 > Is it that hard to do? > > -- glen It sounds like you have a pretty aggressive design and if there is a lot of logic in the design than it would be possible to exceed Tj without a heat sink. The Xilinx XPE (estimator) and XPA (analyzer) can help you out with determining the expectated power and thermal requirements. See http://www.xilinx.com/power for more details. I wouldn't be worried about a ring oscillator creating any significant localized heating in an FPGA to the point that it would damage the device. Ring oscillator circuits are used extensively in the device testing and I've never heard of an RMA linked to anything that even remotely resembled damage due to localized Tj extremes. If you do have ring oscillators in your design you will get some warnings in the timing analysis, but otherwise they are permitted as there isn't anything wrong with a ring oscillator. Ed McGettigan -- Xilinx Inc.Article: 151281
On Mar 19, 3:59=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 19, 10:48=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > On 15 Mrz., 02:28, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > You can fry an FPGA with VDHL and vendor synthesis software. > > > > This has been demonstrated at the FPL conference a decade ago. > > > > I am quite surprised about this. Can you provide any additional > > > material on how this was achieved? > > > > There aren't any scenarios, other than internal tri-state contention, > > > that I can come up with to make this happen with a proven tool chain. > > > It was at FPL1999 that someone presented this as a sidenote in a > > presentation about some > > other topic. They said they were able to damage Altera FPGAs by > > instantiating ring counters. > > This resulted in spontaneous applause by the Xilinx crowd in the > > audience but the presenter > > made clear that this attack also applies to Xilinx Fpgas and that it > > is computationally infeasible > > to detect such attacks. > > > I just browsed through the list of papers of that conferencehttp://www.= informatik.uni-trier.de/~ley/db/conf/fpl/fpl1999.html > > but can't remember, which paper it was. > > > There were some prominent people from Xilinx present (Peter Alfke, > > Steve Trimberger, Steve Guccione and some other Steve). Maybe one of > > them remembers. > > > Kolja Sulimma > > cronologic > > What you remember as a ring counter was probably a ring oscillator > that was used to get a high frequency clock to drive the rest of the > FPGA logic with a high toggle rate. =A0Without system level > considerations and monitoring the power requirements could easily push > the device into a thermal region that would damage the device. =A0 The > HDL and bitstream itself is perfectly valid, it is the thermal > management that is to blame for the destruction. =A0 The failure points > would likely be wide spread through the device. > > This failure mode isn't the same as a badly constructed bitstream > violating DRC rules and creating device damage that would be difficult > to detect as it may only exist at a few points within the device. Maybe I am not familiar with the damage you are referring to. If you send a badly constructed bit stream to a part that violates DRC rules, how does it damage a part other than causing overheating? Are you saying that there exists configuration settings that do damage through over voltage application to some feature in the chip? > Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC > in the 7 Series families) have the ability to shutdown the device if > the junction temperature exceeds user defined values. =A0This can be > used to prevent this type of thermal damage, but it would not be able > to prevent localized damage due to bad bitstreams. Has Xilinx been able to cause this damage? RickArticle: 151282
"Abby Brown" <abbybrown@charter.net> writes: > Hi, > > Does someone produce a cheaper and simpler substitute for > Altera's Cyclone III starter board? It needs to connect to a > laptop to download configuration and test cases and upload > results (ICT). A driver that connects to Windows .Net would be > ideal. Terasic makes a cheap Cyclone III board, model DE0. They have academic pricing too if it's for school. Don't know anything about connecting to .net though.Article: 151283
Thomas Entner wrote: > Maybe you are using the "E"-version of Nios? This low performance- > version became "freeware" some time ago. Yes, it is the "E" version. Using the "S" or "F" version, it creates encrypted VHDL. Thanks for the information, I missed it on the web, because it was not on the NIOS II overview page, only a link to "Buy a License", but on the detailed page for the Economy CPU it is written: http://www.altera.com/products/ip/processors/nios2/cores/economy/ni2-economy-core.html -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbussArticle: 151284
Using standard DIMMs or SODIMMs is good for cost but only for a limited period until the next speed garde or type takes over in popularity. The choice of vendors is good as well and these can be big advantages over discrete memory chips. At the moment the memory of choice is DDR3. Price per bit is best and density is also a big winner. However some FPGA families cannot support this memory type and your PCB design needs to be fairly good to run at these speeds. Note that DDR2/3 do have minimum speeds if you are going to use DLL/ PLLs that they use internally. You may be operate them out of this mode but I have never seen anyone do that and there will be very in examples out there to reference. There may be other things to consider. DIMMs and SODIMMs need a lot of I/O to use them. Probably 80-100 depending on a few things. That can impact the size of FPGA packacge you use and that is a cost as well if you go up in package size because of it. Hard memory cores are also another thing to consider. All of our Spartan-6 based development boards have a x16 DDR3 on board and that's because there is hard memory controller in the FPGA. That means we are not using FPGA fabric for a memory controller that is in itself a cost. The hard controller will have a cost that is advertised into the FPGA cost but it will be a small fraction of the equivalent soft core fabric approach. Big upside of the hard memory controller is that it is relatively easy to get going. Note that the Spartan-6 controller will only go to x16 data and won;t support a DIMM/SODIMM. DIMM/SODIMM are different for each memory type. Usually there is a different polarisation notch. Pinout and operating voltages are also different. For simplicity don't ignore conventional SDRAM. Personally if I don't have a high performance, density, issue or even a hard controller available this is my memory type of choice. No minimum frequency on this either. I certainly won't bother with DDR1 and would only use DDR2 things like Cyclone IV boards as we have done in our Raggedstone3 product because the DDR3 isn't really an option. John Adair Enterpoint Ltd. - Home of Merrick1. The cost effective HPC board. On Mar 19, 2:03=A0pm, "sdaau" <sd@n_o_s_p_a_m.n_o_s_p_a_m.imi.aau.dk> wrote: > Hi all, > > I am speculating about starting an FPGA based project soon, which may nee= d > to use RAM. So I'd like to leverage the (relative) abundance (and thus, > hopefully low price) of desktop (or laptop) PC memory modules for this > purpose - and I was wandering if the community had any comments or > suggestions. > > Primary points of interest are: > > * What is, in your opinion, the cheapest type of DIMM (desktop?) and > SO-DIMM (laptop?) modules currently available (2010-2011)? From a quick > scan, I can find > ** SO DIMM 200-PIN, 1x512 MB module (DDR2 SDRAM) 667 MHz > ** DIMM 240-PIN, 1x1GB module (DDR3 SDRAM) 1066 MHz > .. for approx the same price ( below 13 Euro per GB). I'm aware this may > be location dependent - but would the above represent the (currently) > cheapest/most abundant modules on the market? If not, what would you > consider cheapest/most abundant - and what would be a good reference > (website) to consult? > > * Do the PCB sockets for the diverse module types differ significantly in > price (maybe SO-DIMM sockets usually cost twice as much as DIMM?) Also, a= ny > (negative) experiences in soldering any of these by hand? > > * When they say stuff like "DDR2 SO-DIMM memory modules commonly have clo= ck > speeds from 200 MHz up to 800 MHz" (http://en.wikipedia.org/wiki/SO-DIMM)= , > I'd assume they talk of max frequencies - does that still mean, that I ca= n > clock the modules with _less_ of a frequency (say 50 MHz)? > > * Given that, say, "DDR2 is neither forward nor backward compatible with > either DDR or DDR3" (http://en.wikipedia.org/wiki/DDR2_SDRAM), obviously > there is a need for dedicated hardware signaling interface for each type = of > RAM. Is there something like a 'base interface' (say, maybe something lik= e > SPI), which would be relatively easy to use, and that all RAM modules wou= ld > support (at the expense of reaching top speeds)? > > * Assuming that there (most likely) isn't such a 'base interface' for all > RAM types, what (of the currently cheapest and most available types of > modules) would you feel is easiest to learn to interface with? > > I'd also love to hear any other considerations in this type of usage that= I > may have missed - as well as any links to tutorials/previous projects usi= ng > FPGA and these types of RAM for PCs.. > > Looking forward to any responses - thanks in advance, > Cheers! > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 151285
> Hmmm...let me just recap to make sure I understand everything thus > far. Okay, so the general strategy is to sequentially push/pull the > data to/from DDR memory while using some BlockRAM to hold data > between bursts. Also, some logic will be needed to determine when > would be the best time to switch between reading and writing. > Normally, one would create a DDR memory controller using the MIG in > Xilinx's Core Generator. However, my board doesn't have a standard > DDR memory module and instead has a PseudoSRAM (which the MIG doesn't > support). This particular external RAM has a mode that acts like > asynchronous SRAM which is slow but easy to write a controller for. > It also has a burst mode that acts like synchronous DRAM, which is > fast but needs a more complicated controller. All Digilent supplies > you with is a VHDL module that probably doesn't even support burst > mode. I have a textbook that explains how to use the slow > asynchronous mode, but of course that won't cut it. All sounds right! > Since I know nothing about VHDL (I'm a Verilog boy), should I even > attempt learning VHDL to analyze the above sample code or should I > just jump straight into writing it in Verilog from scratch? It's been a few weeks since I looked at the module, but from memory it wouldn't have been too difficult to convert it from VHDL to Verilog. I would probably do this just so that I can attempt to understand what it's doing, by analysing it line by line. The OPB_PSRAM_CONTROLLER code looks quite a lot nicer, though you'd need to implement an OPB bus to use it without modification (http://www.xilinx.com/support/documentation/ipembedprocess_coreconnect_opbbusstruct.htm) > If I were to create a VHDL controller based on the links above, can > I even instantize a VHDL module from my Verilog top module? Yes, there shouldn't be any problem doing that. > Because I know nothing about DDR style memory controllers, is there > anything else you guys can point me to for help in designing a burst > mode controller from scratch (preferably more concepts than code)? > Or am I just stuck with what that datasheet gives me? I've never tried doing it, but the data sheet should hopefully tell you everything you need to do! :) Basically, work out what the sample code is doing and match it up to the data sheet. Then work out what you need to do differently for burst mode. JoelArticle: 151286
On Mar 19, 11:17=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 19, 3:59=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On Mar 19, 10:48=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote: > > > > On 15 Mrz., 02:28, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > You can fry an FPGA with VDHL and vendor synthesis software. > > > > > This has been demonstrated at the FPL conference a decade ago. > > > > > I am quite surprised about this. Can you provide any additional > > > > material on how this was achieved? > > > > > There aren't any scenarios, other than internal tri-state contentio= n, > > > > that I can come up with to make this happen with a proven tool chai= n. > > > > It was at FPL1999 that someone presented this as a sidenote in a > > > presentation about some > > > other topic. They said they were able to damage Altera FPGAs by > > > instantiating ring counters. > > > This resulted in spontaneous applause by the Xilinx crowd in the > > > audience but the presenter > > > made clear that this attack also applies to Xilinx Fpgas and that it > > > is computationally infeasible > > > to detect such attacks. > > > > I just browsed through the list of papers of that conferencehttp://ww= w.informatik.uni-trier.de/~ley/db/conf/fpl/fpl1999.html > > > but can't remember, which paper it was. > > > > There were some prominent people from Xilinx present (Peter Alfke, > > > Steve Trimberger, Steve Guccione and some other Steve). Maybe one of > > > them remembers. > > > > Kolja Sulimma > > > cronologic > > > What you remember as a ring counter was probably a ring oscillator > > that was used to get a high frequency clock to drive the rest of the > > FPGA logic with a high toggle rate. =A0Without system level > > considerations and monitoring the power requirements could easily push > > the device into a thermal region that would damage the device. =A0 The > > HDL and bitstream itself is perfectly valid, it is the thermal > > management that is to blame for the destruction. =A0 The failure points > > would likely be wide spread through the device. > > > This failure mode isn't the same as a badly constructed bitstream > > violating DRC rules and creating device damage that would be difficult > > to detect as it may only exist at a few points within the device. > > Maybe I am not familiar with the damage you are referring to. =A0If you > send a badly constructed bit stream to a part that violates DRC rules, > how does it damage a part other than causing overheating? =A0Are you > saying that there exists configuration settings that do damage through > over voltage application to some feature in the chip? > > > Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC > > in the 7 Series families) have the ability to shutdown the device if > > the junction temperature exceeds user defined values. =A0This can be > > used to prevent this type of thermal damage, but it would not be able > > to prevent localized damage due to bad bitstreams. > > Has Xilinx been able to cause this damage? > > Rick- Hide quoted text - > > - Show quoted text - This is well off the original topic.... If "this damage" refers to localized thermal issues then not to the best of my knowledge. Hot spot (localized) thermal imaging analysis is done on new parts to determine if any issues exist and occasionally something in a hard block (PowerPC, BlockRAM, PCIe, etc) is found and corrected in a mask step before production. If "this damage" refers to exceeding the junction temperature then yes this is a real issue and high temperatures with voltage will damage the part. This is a common technique used for device lifetime reliability testing with both over voltage and over temperature conditions used as acceleration factors to reduce the time required for testing. Ed McGettigan -- Xilinx Inc.Article: 151287
On Mar 20, 6:16=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > This is well off the original topic.... not so far ed, you stated that bit-stream spec published will make bad bit-streams in use and that will damage fpgas so the discuss went on fpgas damages and this is interesting ! so please continu allArticle: 151288
"PovTruffe" <PovTache@gaga.invalid> a écrit : > Hi, > > Yet another newbie question: > Is SDRAM fast enough to generate a 720p or 1024p video stream (VGA or > DVI output) using a Spartan-3 or -3E FPGA ? No response :-(( Maybe my question was not very clear. Let me paraphrase it: What kind of RAM would you use for a video frame buffer (Spartan-3E) ? Or would either type of RAM work ?Article: 151289
>"PovTruffe" <PovTache@gaga.invalid> a �crit : >> Hi, >> >> Yet another newbie question: >> Is SDRAM fast enough to generate a 720p or 1024p video stream (VGA or >> DVI output) using a Spartan-3 or -3E FPGA ? > >No response :-(( >Maybe my question was not very clear. Let me paraphrase it: >What kind of RAM would you use for a video frame buffer (Spartan-3E) ? >Or would either type of RAM work ? > > > For any application you must calculate what size and speed of ram you require. So for your application you must determine the memory bandwidth and the size of memory needed to fit the data into the memory. You know what your application is and the relevan parameters so you just need to match those to the standard ram available. You may find that it is not possible to with the fpga you want to use and you need to choose a higher spec device. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151290
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a écrit : >>No response :-(( >>Maybe my question was not very clear. Let me paraphrase it: >>What kind of RAM would you use for a video frame buffer (Spartan-3E) ? >>Or would either type of RAM work ? > > For any application you must calculate what size and speed of ram you > require. So for your application you must determine the memory bandwidth > and the size of memory needed to fit the data into the memory. You know > what your application is and the relevan parameters so you just need to > match those to the standard ram available. You may find that it is not > possible to with the fpga you want to use and you need to choose a higher > spec device. Thank you for your response. However I was in fact expecting more a rule of thumb response such as for example "SDRAM would probably work for VGA resolution at 30Hz rate no more...". I am still choosing the right components for my first FPGA design that is just a learning project with no other specific purpose. If I can generate a video stream thats fine, if not I will do something else (or lower the frame size, refresh rate, etc). The challenge is also to design a working Spartan-3 FPGA board with the largest non BGA package and with only 2 layers. The risk of course is the board will never work.Article: 151291
"PovTruffe" <PovTache@gaga.invalid> wrote in message news:4d876ea8$0$19933$426a74cc@news.free.fr... > "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a écrit : >>>No response :-(( >>>Maybe my question was not very clear. Let me paraphrase it: >>>What kind of RAM would you use for a video frame buffer (Spartan-3E) ? >>>Or would either type of RAM work ? >> >> For any application you must calculate what size and speed of ram you >> require. So for your application you must determine the memory bandwidth >> and the size of memory needed to fit the data into the memory. You know >> what your application is and the relevan parameters so you just need to >> match those to the standard ram available. You may find that it is not >> possible to with the fpga you want to use and you need to choose a higher >> spec device. > > Thank you for your response. However I was in fact expecting more a rule > of thumb response such as for example "SDRAM would probably work for > VGA resolution at 30Hz rate no more...". > > I am still choosing the right components for my first FPGA design that is > just > a learning project with no other specific purpose. If I can generate a > video > stream thats fine, if not I will do something else (or lower the frame > size, > refresh rate, etc). > > The challenge is also to design a working Spartan-3 FPGA board with the > largest non BGA package and with only 2 layers. The risk of course is the > board will never work. > > For a full HD display running at 60Hz frame rate you need about 125Mpix/s x 24 or 30 bits. Easily within the lowest spec DDR SDRAM as you only need sequential access. You can always up the bitwidth of the memory to increase bandwidth if access time proves inadequate but obviously you'll need to determine that at the outset. PhilArticle: 151292
If I was you I would have a look at some of Xilinx boards. Download the schematics and gerbers to see how they have designed them. From your comments you dont seem to have much knowledge about designing boards. There is no way that you can use two layers for a bga design. The minimum would be 4 and this would have to be a fairly low frequency design. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151293
You could buy directly from devboards GmbH for 133 EUR (excl. VAT). http://devboards.de/shop/artikeldet.php?proid=6852&bez=DB4CGX15&sid=917d6d818f1b75509a705942b8de4f00&PHPSESSID=917d6d818f1b75509a705942b8de4f00Article: 151294
In article <8JKdnaSMPotTFxrQnZ2dnUVZ8qOdnZ2d@brightview.co.uk>, Phil Jessop <phil@noname.org> wrote: > >"PovTruffe" <PovTache@gaga.invalid> wrote in message >news:4d876ea8$0$19933$426a74cc@news.free.fr... >> "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a écrit : >>>>No response :-(( >>>>Maybe my question was not very clear. Let me paraphrase it: >>>>What kind of RAM would you use for a video frame buffer (Spartan-3E) ? >>>>Or would either type of RAM work ? >>> >>> For any application you must calculate what size and speed of ram you >>> require. So for your application you must determine the memory bandwidth >>> and the size of memory needed to fit the data into the memory. You know >>> what your application is and the relevan parameters so you just need to >>> match those to the standard ram available. You may find that it is not >>> possible to with the fpga you want to use and you need to choose a higher >>> spec device. >> >> Thank you for your response. However I was in fact expecting more a rule >> of thumb response such as for example "SDRAM would probably work for >> VGA resolution at 30Hz rate no more...". >> >> I am still choosing the right components for my first FPGA design that is >> just >> a learning project with no other specific purpose. If I can generate a >> video >> stream thats fine, if not I will do something else (or lower the frame >> size, >> refresh rate, etc). >> >> The challenge is also to design a working Spartan-3 FPGA board with the >> largest non BGA package and with only 2 layers. The risk of course is the >> board will never work. >> >> > >For a full HD display running at 60Hz frame rate you need about 125Mpix/s x >24 or 30 bits. Easily within the lowest spec DDR SDRAM as you only need >sequential access. You can always up the bitwidth of the memory to increase >bandwidth if access time proves inadequate but obviously you'll need to >determine that at the outset. The original question is too ill-posed - I wouldn't take any "rule of thumb" type response with respect to video - the numbers add up too fast. One would assume you're not just reading or writing to the DDR - you probably need to do (at least one) of both a frame-buffer read, and a frame-buffer write. So 2X (at least) the BW requirements there. How are you going to pack (20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data onto a (16/32/48/64 bit) memory interface? Pack it, or throw away bandwidth? Reads and Writes at same time? - can you still guarantee "sequential access" enough so you don't lose bandwidth efficiencies to the DRAM? Is there anything else (a CPU?) using the DRAM too that throws this off? To the OP - there's no "rule of thumb". Sit down with a pen and paper, or excel spreadsheet, and calculate you're requirements. --MarkArticle: 151295
Mark Curry <gtwrek@sonic.net> wrote: (snip) > The original question is too ill-posed - I wouldn't take any > "rule of thumb" type response with respect to video - the > numbers add up too fast. > One would assume you're not just reading or writing to the DDR - > you probably need to do (at least one) of both a frame-buffer read, > and a frame-buffer write. So 2X (at least) the BW requirements there. > How are you going to pack (20-bit, 24-bit, 30-bit and/or 32-bit?) > pixel data onto a (16/32/48/64 bit) memory interface? Pack it, > or throw away bandwidth? There is the old trick (IBM CGA days) of doing the writes during refresh times. For the CGA, I believe that there was an interrupt on vertical refresh, such that you do all the writes then. > Reads and Writes at same time? - can you still guarantee "sequential access" > enough so you don't lose bandwidth efficiencies to the DRAM? Is there > anything else (a CPU?) using the DRAM too that throws this off? -- glenArticle: 151296
In article <im8d2q$um6$2@news.eternal-september.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Mark Curry <gtwrek@sonic.net> wrote: >(snip) > >> The original question is too ill-posed - I wouldn't take any >> "rule of thumb" type response with respect to video - the >> numbers add up too fast. > >> One would assume you're not just reading or writing to the DDR - >> you probably need to do (at least one) of both a frame-buffer read, >> and a frame-buffer write. So 2X (at least) the BW requirements there. >> How are you going to pack (20-bit, 24-bit, 30-bit and/or 32-bit?) >> pixel data onto a (16/32/48/64 bit) memory interface? Pack it, >> or throw away bandwidth? > >There is the old trick (IBM CGA days) of doing the writes during >refresh times. For the CGA, I believe that there was an interrupt >on vertical refresh, such that you do all the writes then. That's implied now anyway - the one response gave the number of ~125Mpixels/sec. That implies using the blanking time to do something "useful". The actual pixel clock for 1080P is around 145MHz. --MarkArticle: 151297
"maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> a écrit : > If I was you I would have a look at some of Xilinx boards. Download the > schematics and gerbers to see how they have designed them. I already have several schematics but I am not yet working on the memory and video circuits. I asked a question because I saw people talking about DRAM there... > From your comments you dont seem to have much knowledge about designing > boards. There is no way that you can use two layers for a bga design. > The minimum would be 4 and this would have to be a fairly low frequency design. I wrote: "largest NON-BGA package". That is a PQ208 one. I am mostly worried by the lack of power planes and higher pin capacitance. By the way I have a significant experience about PCB design but never with a FPGA.Article: 151298
> The original question is too ill-posed - I wouldn't take any "rule of thumb" > type response with respect to video - the numbers add up too fast. OK but I have the freedom to choose whatever video size, rate, # of bits I like. If I can generate only a 100 x 100 pixel video at 10Hz, thats is fine. > One would assume you're not just reading or writing to the DDR - you probably > need to do (at least one) of both a frame-buffer read, and a frame-buffer write. > So 2X (at least) the BW requirements there. How are you going to pack > (20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data onto a (16/32/48/64 bit) > memory interface? Pack it, or throw away bandwidth? Yes I am aware of the multiple accesses, read and write, that will be required. Because of the PQ208 package the memory interface will probably be limited to 16 bit. And some address lines may not be used as well. I am mainly worried about the PQ208 high pin capacitance. > Reads and Writes at same time? - can you still guarantee "sequential access" > enough so you don't lose bandwidth efficiencies to the DRAM? Is there > anything else (a CPU?) using the DRAM too that throws this off? I will probably include a CPU later and try to access the RAM as a learning exercise. > To the OP - there's no "rule of thumb". Sit down with a pen and paper, > or excel spreadsheet, and calculate you're requirements. I will do that later. I tryed to make it clear that for this project I do not have the professional / engineering approach that most of you in this group are used to. There are no predefined and rigid features for the board. I will just choose a FPGA, throw a RAM and a few peripherals, then play with the board. However the PCB will be designed as optimally as possible (shortest trace lengths, equal length for buses, etc). Later things will become clearer and I will get a much better feel about the capabilities of a FPGA. Because of the steep learning curve, if I begin working with all the details, the board will never be finished this year and I would probably run out of motivation...Article: 151299
PovTruffe <PovTache@gaga.invalid> wrote: (snip) > OK but I have the freedom to choose whatever video size, rate, # > of bits I like. > If I can generate only a 100 x 100 pixel video at 10Hz, thats is fine. > >> One would assume you're not just reading or writing to the > DDR - you probably >> need to do (at least one) of both a frame-buffer read, and > a frame-buffer write. >> So 2X (at least) the BW requirements there. How are you going to pack >> (20-bit, 24-bit, 30-bit and/or 32-bit?) pixel data > onto a (16/32/48/64 bit) >> memory interface? Pack it, or throw away bandwidth? You might look at some of the Digilent boards. The Spartan3E board has on-board DDR, and a VGA connector, though only one bit per color. (It should be possible to dither, though, otherwise only eight colors.) There are other boards with FPGA, RAM, and VGA connector, too. That will get you practice with the RAM interface. Then you can start your own board design. The FPGA has pretty strong drivers, the RAM might not be so strong, though with only one module it should be fine. Many systems won't run at full speed with all modules in place. -- glen
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