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
Hi Paul, First of all try to use Indirect flash programming using jtag interface. If it will work fine your EPCS is connected correctly and your fpga should start automatically. If not , check epcs connection to fpga and msel pins configuration. Second step is to write and read back epcs config using your rs connection. Then you have to prepare flash image using sof2flash" --epcs --input="example.sof" --output="example.flash" Adam > Hi,all > > I'm Paul Ham in Korea and have some difficulties in using ASMI_PARALLEL > altera ip core. > Anyone who knows well this problem could advice to me. > > I'm using Cyclone FPGA with EPCS4 and Quartus V9.1 without service pack. > My design is very simple like below : > 1) receive the data from PC via RS232. > The data is .rpd file made by Conver Programming Files of Quartus menu. > Due to the EPCS spec, its size is 512KByte. > 2) write the data to internal dpram. (double buffering) > 3) read the data from dpram to asmi_parallel every 256 bytes.(page write) > > When I simulated it with signaltap, it wrote other .rpd file into EPCS4 > well. > And it configured well after power-up. > > But it didn't work when I programmed itself directly to EPCS4. > It always generate the illegal_erase and illegal_write. > > I found some ways to solve the problem like below but anything didn't work > well. > 1) make 4 pins related to configuration, nCS/ASDO/DCLK/DATA0, "USE AS > REGULAR IO" at .qsf file. > -> set_global_assignment -name RESERVE_ASDO_AFTER_CONFIGURATION "USE AS > REGULAR IO" > set_global_assignment -name RESERVE_DATA0_AFTER_CONFIGURATION "USE AS > REGULAR IO" > set_global_assignment -name RESERVE_DCLK_AFTER_CONFIGURATION "USE AS > REGULAR IO" > set_global_assignment -name RESERVE_FLASH_NCE_AFTER_CONFIGURATION > "USE AS REGULAR IO" > 2) modify the value of "ncs_reg" in asmi_parallel.v as below. > -> always @ ( negedge clkin_wire or posedge end_ophdly) > if (end_ophdly == 1'b1) ncs_reg<= 1'b1; > else if (wire_ncs_reg_ena == 1'b1) ncs_reg<= 1'b0; > 3) install the service pack 1 : I didn't try it > > I guess that the problem is related to the setting of 4 configuration > pins. > But I'm not sure what could I do. > If you have any advice or solution, please let me know. > > Thanks advance > Regards > Paul > > > > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 149076
"mitho" <adnan.siddiq@n_o_s_p_a_m.live.com> writes: > Hi. > We are working on a image processing based on FPGA. But we are confused > about which FPGA to select. We looked for ML 410 virtex-4. But its too > costly around $3000. Can anybody suggest a relative cheap and efficient > FPGA. Thanks As others have said, the Spartan range is much cheaper if you want to stick to Xilinx. And a lot depends on what signal processing you want to do... If no-one minds a small commercial: I've built the low-level image processing for an automotive lane-departure-warning system in a Spartan 3E 250 in this system: http://www.conekt.co.uk/images/stories/Products_FILES/t%20cam_web.pdf Or a bigger job - the image processing part of a Visual SLAM system - (corner detector, Haar feature extraction, and DVI output) needed quite a lot of the Spartan 3ADSP 3400 on this board: http://www.conekt.co.uk/images/stories/Products_FILES/t%20cam%20stereo_web.pdf Or if you want to do full-HD 60Hz stereo matching, you might find the board you initially mentioned a bit on the small side :) Give us more idea as to what algorithms you want to run and we can give you more idea as to an appropriate way of implementing them. And don't fixate on FPGAs until you're sure they're the right answer - why can't you do it on a PC? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.co.uk/capabilities/39-electronic-hardwareArticle: 149077
I hope this is the correct group, I suspect there is more people here really understanding how an SDRAM works than in the embedded group. We are working on a design proposal with FPGA and DRAM to replace an obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ SRAM-style reads, with a maximum read cycle timing of 80 ns. (The loading to SRAM would be from a serial flash, handled by FPGA, but this is a one-time-per-power-on, non-critical operation). I first figured this should be doable with a 100 MHz standard SDRAM, since it has about 60 ns worst-case random read timing, but, it then struck me that it needs refreshing as well. Q1: Am I assuming correctly that this will _not_ be doable with a 100 MHz SDRAM, since there is no time for refreshing in between two reads? There is no way to do two fully random reads within 80 ns? What if I stick within the same bank (yes, leaving 75% of the DRAM unused, but still)? Q2: Further; am I assuming correctly that it wont help me to step up to DDR or DDR2, since the only thing improved is the burst rates, fully random byte reads are still as slow (active-to-active command period, Trc)? Nothing else is guaranteed from the host system, there are no guaranteed pauses we could use for refresh, and it is not guaranteed that the host system reads the entire memory sequentially, which also would have solved the refresh issue. It is simply a host processor without cache executing it's code from this emulated EEPROM. A million thanks in advance for anything bringing me forward in this process. Best Regards, /JohannesArticle: 149078
On Sep 29, 8:07=A0am, Johannes <johan...@excito.com> wrote: > I hope this is the correct group, I suspect there is more people here > really understanding how an SDRAM works than in the embedded group. > > We are working on a design proposal with FPGA and DRAM to replace an > obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The > loading to SRAM would be from a serial flash, handled by FPGA, but > this is a one-time-per-power-on, non-critical operation). > > I first figured this should be doable with a 100 MHz standard SDRAM, > since it has about 60 ns worst-case random read timing, but, it then > struck me that it needs refreshing as well. > > Q1: Am I assuming correctly that this will _not_ be doable with a 100 > MHz SDRAM, since there is no time for refreshing in between two reads? > There is no way to do two fully random reads within 80 ns? What if I > stick within the same bank (yes, leaving 75% of the DRAM unused, but > still)? > > Q2: Further; am I assuming correctly that it wont help me to step up > to DDR or DDR2, since the only thing improved is the burst rates, > fully random byte reads are still as slow (active-to-active command > period, Trc)? > > Nothing else is guaranteed from the host system, there are no > guaranteed pauses we could use for refresh, and it is not guaranteed > that the host system reads the entire memory sequentially, which also > would have solved the refresh issue. It is simply a host processor > without cache executing it's code from this emulated EEPROM. > > A million thanks in advance for anything bringing me forward in this > process. > > Best Regards, > /Johannes Completely random access in any SDRAM will not be very fast. Unless you can keep everything in one row per bank (you can keep all banks open at once) you have to take a hit for a new random row access. How big was the original memory device you're trying to emulate? Would it make sense to use something else like SRAM to emulate it?Article: 149079
On 29 Sep, 14:33, Gabor <ga...@alacron.com> wrote: > On Sep 29, 8:07=A0am, Johannes <johan...@excito.com> wrote: > > > > > > > I hope this is the correct group, I suspect there is more people here > > really understanding how an SDRAM works than in the embedded group. > > > We are working on a design proposal with FPGA and DRAM to replace an > > obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ > > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The > > loading to SRAM would be from a serial flash, handled by FPGA, but > > this is a one-time-per-power-on, non-critical operation). > > > I first figured this should be doable with a 100 MHz standard SDRAM, > > since it has about 60 ns worst-case random read timing, but, it then > > struck me that it needs refreshing as well. > > > Q1: Am I assuming correctly that this will _not_ be doable with a 100 > > MHz SDRAM, since there is no time for refreshing in between two reads? > > There is no way to do two fully random reads within 80 ns? What if I > > stick within the same bank (yes, leaving 75% of the DRAM unused, but > > still)? > > > Q2: Further; am I assuming correctly that it wont help me to step up > > to DDR or DDR2, since the only thing improved is the burst rates, > > fully random byte reads are still as slow (active-to-active command > > period, Trc)? > > > Nothing else is guaranteed from the host system, there are no > > guaranteed pauses we could use for refresh, and it is not guaranteed > > that the host system reads the entire memory sequentially, which also > > would have solved the refresh issue. It is simply a host processor > > without cache executing it's code from this emulated EEPROM. > > > A million thanks in advance for anything bringing me forward in this > > process. > > > Best Regards, > > /Johannes > > Completely random access in any SDRAM will not be very fast. =A0Unless > you can > keep everything in one row per bank (you can keep all banks open at > once) you > have to take a hit for a new random row access. =A0How big was the > original > memory device you're trying to emulate? =A0Would it make sense to use > something else like SRAM to emulate it? Thanks for your reply. Yes, SRAM is an option but not wanted due to it's high price (it's for a high volume product), hence the preference of DRAM. The original memory size is 4 MByte so it's not a lot of data, but DRAM is still a lot cheaper.Article: 149080
"Johannes" <johannes@excito.com> wrote in message news:0aad6682-bdc6-40cf-86c6-ece9be74dd94@l20g2000yqm.googlegroups.com... >I hope this is the correct group, I suspect there is more people here > really understanding how an SDRAM works than in the embedded group. > > We are working on a design proposal with FPGA and DRAM to replace an > obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The > loading to SRAM would be from a serial flash, handled by FPGA, but > this is a one-time-per-power-on, non-critical operation). Is there really no Flash chip that could do this job? I guess EEPROM has its erase/write issues similar to the the flash. Maybe that could be emulated..Article: 149081
On 29 Sep, 14:48, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote: > "Johannes" <johan...@excito.com> wrote in message > > news:0aad6682-bdc6-40cf-86c6-ece9be74dd94@l20g2000yqm.googlegroups.com... > > >I hope this is the correct group, I suspect there is more people here > > really understanding how an SDRAM works than in the embedded group. > > > We are working on a design proposal with FPGA and DRAM to replace an > > obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ > > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The > > loading to SRAM would be from a serial flash, handled by FPGA, but > > this is a one-time-per-power-on, non-critical operation). > > Is there really no Flash chip that could do this job? > I guess EEPROM has its erase/write issues similar to the the flash. Maybe > that could be emulated.. Yes, we have actually done a solution already with Flash, but the customer whishes to move on to another memory solution for two reasons: - standard nor flash is getting obsolete in a few years - since the cycle time required is 80 ns, a standard 70 ns NOR flash isn't enough when adding some FPGA timing, we need 55 ns NOR flash, which is virtually impossible to buy these days Regarding the writes this is not an issue since this is not done in standard operating modes. (Writes are only done in a machine firmware upgrade, and is another story). Thanks for your replies so far. I really need a DRAM wizard to show me if there are any tricks to fit a refresh cycle in between two random reads, all in 80 ns. Moving up to DDRx is no problem, if required. Best Regards, /JohannesArticle: 149082
I think you have grasped the problem correctly in that latency is the biggest issue. We have done similar things on our Craignell1 http://www.enterpoint.co.uk/component_replacements/craignell.html and Craignell2 http://www.enterpoint.co.uk/component_replacements/craignell2.html modules that are aimed at obsolete component replacement. Refresh can be an issue but you can design a controller to do refresh after a EEprom access cycle that may solve that issue. Success of that depends on how often the virtual EEprom is accesssed and how fast the host microprocessor is. One technique to consider is to use the FPGA RAM for this. It is much faster and works well for small EEprom. The RAM can be preloaded at configuration or loaded after from SPI Flash. If you know how the memory space is used you can also use a page swapping technique and preload the FPGA RAM before an access cycle occurs for a guven memory location. To make any of these work you may need a higher clock frequency. Remember your incoming signals are probably asynchronous to your module clock and you may lose half a clock or more just synchronising. To do anything different may cause problems. In the extreme think about using an external SRAM as an alternative to SDRAM. John Adair Enterpoint Ltd. On 29 Sep, 13:07, Johannes <johan...@excito.com> wrote: > I hope this is the correct group, I suspect there is more people here > really understanding how an SDRAM works than in the embedded group. > > We are working on a design proposal with FPGA and DRAM to replace an > obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The > loading to SRAM would be from a serial flash, handled by FPGA, but > this is a one-time-per-power-on, non-critical operation). > > I first figured this should be doable with a 100 MHz standard SDRAM, > since it has about 60 ns worst-case random read timing, but, it then > struck me that it needs refreshing as well. > > Q1: Am I assuming correctly that this will _not_ be doable with a 100 > MHz SDRAM, since there is no time for refreshing in between two reads? > There is no way to do two fully random reads within 80 ns? What if I > stick within the same bank (yes, leaving 75% of the DRAM unused, but > still)? > > Q2: Further; am I assuming correctly that it wont help me to step up > to DDR or DDR2, since the only thing improved is the burst rates, > fully random byte reads are still as slow (active-to-active command > period, Trc)? > > Nothing else is guaranteed from the host system, there are no > guaranteed pauses we could use for refresh, and it is not guaranteed > that the host system reads the entire memory sequentially, which also > would have solved the refresh issue. It is simply a host processor > without cache executing it's code from this emulated EEPROM. > > A million thanks in advance for anything bringing me forward in this > process. > > Best Regards, > /JohannesArticle: 149083
Johannes <johannesmannen@gmail.com> wrote: (snip) >> > We are working on a design proposal with FPGA and DRAM to replace an >> > obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ >> > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The >> > loading to SRAM would be from a serial flash, handled by FPGA, but >> > this is a one-time-per-power-on, non-critical operation). >> Is there really no Flash chip that could do this job? >> I guess EEPROM has its erase/write issues similar to the the flash. Maybe >> that could be emulated.. A suggestion which could work for DRAM or Flash, though may or may not help, is to use two devices with the same data, and access them alternately. That gets the average access rate up, though you have to pipeline the data. (snip) > - since the cycle time required is 80 ns, a standard 70 ns NOR flash > isn't enough when adding some FPGA timing, we need 55 ns NOR flash, > which is virtually impossible to buy these days -- glenArticle: 149084
On Sep 29, 9:28=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Johannes <johannesman...@gmail.com> wrote: > > (snip) > > >> > We are working on a design proposal with FPGA and DRAM to replace an > >> > obsolete EEPROM memory. Consequently, we need to emulate standard RO= M/ > >> > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The > >> > loading to SRAM would be from a serial flash, handled by FPGA, but > >> > this is a one-time-per-power-on, non-critical operation). > >> Is there really no Flash chip that could do this job? > >> I guess EEPROM has its erase/write issues similar to the the flash. Ma= ybe > >> that could be emulated.. > > A suggestion which could work for DRAM or Flash, though may > or may not help, is to use two devices with the same data, and > access them alternately. =A0That gets the average access rate up, > though you have to pipeline the data. > > (snip) > > > - since the cycle time required is 80 ns, a standard 70 ns NOR flash > > isn't enough when adding some FPGA timing, we need 55 ns NOR flash, > > which is virtually impossible to buy these days > > -- glen In this case, having multiple copies in the same device may do the trick since an SDRAM has multiple banks. Single data rate SDRAM and DDR 1 generally has four banks and larger DDR 2 parts have 8 banks. Sticking with the single data rate parts you can do refresh just by activating a row, but remember this requires an activate to every row in every bank within the refresh period, while the auto-refresh command refreshes a row in all four banks at once. In this way if you had to do an access while one bank / row is doing a "refresh" you can get the data from another bank. -- GaborArticle: 149085
Johannes <johannesmannen@gmail.com> wrote: >On 29 Sep, 14:48, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote: >> "Johannes" <johan...@excito.com> wrote in message >> >> news:0aad6682-bdc6-40cf-86c6-ece9be74dd94@l20g2000yqm.googlegroups.com... >> >> >I hope this is the correct group, I suspect there is more people here >> > really understanding how an SDRAM works than in the embedded group. >> >> > We are working on a design proposal with FPGA and DRAM to replace an >> > obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ >> > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The >> > loading to SRAM would be from a serial flash, handled by FPGA, but >> > this is a one-time-per-power-on, non-critical operation). >> >> Is there really no Flash chip that could do this job? >> I guess EEPROM has its erase/write issues similar to the the flash. Maybe >> that could be emulated.. > > >Yes, we have actually done a solution already with Flash, but the >customer whishes to move on to another memory solution for two >reasons: >- standard nor flash is getting obsolete in a few years I don't think so. NOR flash has many advantages over NAND flash. Staying available for a long time is one of them. >- since the cycle time required is 80 ns, a standard 70 ns NOR flash >isn't enough when adding some FPGA timing, we need 55 ns NOR flash, >which is virtually impossible to buy these days Sure about that? Did you talk to ISSI? They sell devices targeted for industrial applications. Not high tech but they claim to keep devices active for many years. >Regarding the writes this is not an issue since this is not done in >standard operating modes. (Writes are only done in a machine firmware >upgrade, and is another story). > >Thanks for your replies so far. I really need a DRAM wizard to show me >if there are any tricks to fit a refresh cycle in between two random >reads, all in 80 ns. Moving up to DDRx is no problem, if required. The problem is CAS latency. DDR memory is just wider memory in parallel banks. This increases the burst transfer bandwidth but the latency is still very long. Did you look into SRAM? -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 149086
Gabor <gabor@alacron.com> wrote: >On Sep 29, 9:28=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> Johannes <johannesman...@gmail.com> wrote: >> >> (snip) >> >> >> > We are working on a design proposal with FPGA and DRAM to replace an >> >> > obsolete EEPROM memory. Consequently, we need to emulate standard RO= >M/ >> >> > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The >> >> > loading to SRAM would be from a serial flash, handled by FPGA, but >> >> > this is a one-time-per-power-on, non-critical operation). >> >> Is there really no Flash chip that could do this job? >> >> I guess EEPROM has its erase/write issues similar to the the flash. Ma= >ybe >> >> that could be emulated.. >> >> A suggestion which could work for DRAM or Flash, though may >> or may not help, is to use two devices with the same data, and >> access them alternately. =A0That gets the average access rate up, >> though you have to pipeline the data. >> >> (snip) >> >> > - since the cycle time required is 80 ns, a standard 70 ns NOR flash >> > isn't enough when adding some FPGA timing, we need 55 ns NOR flash, >> > which is virtually impossible to buy these days >> >> -- glen > >In this case, having multiple copies in the same device may do the >trick since an SDRAM has multiple banks. Single data rate SDRAM >and DDR 1 generally has four banks and larger DDR 2 parts have 8 >banks. Sticking with the single data rate parts you can do refresh >just by activating a row, but remember this requires an activate to >every >row in every bank within the refresh period, while the auto-refresh >command refreshes a row in all four banks at once. In this way >if you had to do an access while one bank / row is doing a "refresh" >you can get the data from another bank. This gets you into trouble when writing. If you allow random writes, you'll need some fancy caching algorithm to allow for any random write sequences. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 149087
Nico Coesel <nico@puntnl.niks> wrote: (snip) > This gets you into trouble when writing. If you allow random writes, > you'll need some fancy caching algorithm to allow for any random write > sequences. This is supposed to be an EPROM replacement. As I understand it, the DRAM is loaded at powerup with the appropriate bits, and read, randomly. Most likely the load is sequential and not speed sensitive. It does seem to me that the multiple bank with the same data solution should work, but the OP will have to decide. -- glenArticle: 149088
Johannes skrev 2010-09-29 14:07: > I hope this is the correct group, I suspect there is more people here > really understanding how an SDRAM works than in the embedded group. > > We are working on a design proposal with FPGA and DRAM to replace an > obsolete EEPROM memory. Consequently, we need to emulate standard ROM/ > SRAM-style reads, with a maximum read cycle timing of 80 ns. (The > loading to SRAM would be from a serial flash, handled by FPGA, but > this is a one-time-per-power-on, non-critical operation). Hi Johannes, If you only need to emulate "read", then a parallel flash should do the job... You could also check out PSRAMs. > > I first figured this should be doable with a 100 MHz standard SDRAM, > since it has about 60 ns worst-case random read timing, but, it then > struck me that it needs refreshing as well. > > Q1: Am I assuming correctly that this will _not_ be doable with a 100 > MHz SDRAM, since there is no time for refreshing in between two reads? > There is no way to do two fully random reads within 80 ns? What if I > stick within the same bank (yes, leaving 75% of the DRAM unused, but > still)? > > Q2: Further; am I assuming correctly that it wont help me to step up > to DDR or DDR2, since the only thing improved is the burst rates, > fully random byte reads are still as slow (active-to-active command > period, Trc)? > > > Nothing else is guaranteed from the host system, there are no > guaranteed pauses we could use for refresh, and it is not guaranteed > that the host system reads the entire memory sequentially, which also > would have solved the refresh issue. It is simply a host processor > without cache executing it's code from this emulated EEPROM. > > A million thanks in advance for anything bringing me forward in this > process. > > Best Regards, > /Johannes > > > -- Best Regards Ulf Samuelsson These are my own personal opinions, which may or may not be shared by my employer Atmel Nordic ABArticle: 149089
On Mon, 27 Sep 2010 05:53:16 -0500, "mokhoo" <amn257@n_o_s_p_a_m.yahoo.com> wrote: >Dear All, >I am working on project using Xilinx Spartan3 XC3S2000. I have used one DCM >and it worked well. However, when I tried to instantiate another It lone for >other purpose, errors appeared in the building phase as follows: > >ERROR:NgdBuild:604 - logical block 'CLK_1/DCM_inst' with type 'DCM_2' >could > not be resolved. A pin name misspelling can cause this, a missing edif >or ngc > file, or the misspelling of a type name. Symbol 'DCM_2' is not supported >in > target 'spartan3'. > >ERROR:NgdBuild:604 - logical block 'CLK_2/DCM_IFCLK' with type 'DCM_1' > could not be resolved. A pin name misspelling can cause this, a missing >edif > or ngc file, or the misspelling of a type name. Symbol 'DCM_1' is not > supported in target 'spartan3'. > >Concerning the above problem I have two questions: >1. Why adding another DCM fails? >2. Why adding another DCM affects the first one although they are not >related to each other in the design? > >Thanks and best regards, > > > > >--------------------------------------- >Posted through http://www.FPGARelated.com Hi, It looks like you have been using the Xilinx Core Generator in order to instantiate the DCM? If this is the case, a black-box .ngc file for the DCM will be generated by the tool, and you will have to add a macro search path pointing to this .ngc file. You can do this from the translate-options, if you are using ISE. If not, you can use the "-bd <search-path>" option. Regards, KimArticle: 149090
Hi Paul, Any progress ? Adam > Hi Paul, > > First of all try to use Indirect flash programming using jtag interface. > If it will work fine your EPCS is connected correctly and your fpga > should start automatically. > If not , check epcs connection to fpga and msel pins configuration. > > Second step is to write and read back epcs config using your rs connection. > > Then you have to prepare flash image using > sof2flash" --epcs --input="example.sof" --output="example.flash" > > Adam > >> Hi,all >> >> I'm Paul Ham in Korea and have some difficulties in using ASMI_PARALLEL >> altera ip core. >> Anyone who knows well this problem could advice to me. >> >> I'm using Cyclone FPGA with EPCS4 and Quartus V9.1 without service pack. >> My design is very simple like below : >> 1) receive the data from PC via RS232. >> The data is .rpd file made by Conver Programming Files of Quartus menu. >> Due to the EPCS spec, its size is 512KByte. >> 2) write the data to internal dpram. (double buffering) >> 3) read the data from dpram to asmi_parallel every 256 bytes.(page write) >> >> When I simulated it with signaltap, it wrote other .rpd file into EPCS4 >> well. >> And it configured well after power-up. >> >> But it didn't work when I programmed itself directly to EPCS4. >> It always generate the illegal_erase and illegal_write. >> >> I found some ways to solve the problem like below but anything didn't >> work >> well. >> 1) make 4 pins related to configuration, nCS/ASDO/DCLK/DATA0, "USE AS >> REGULAR IO" at .qsf file. >> -> set_global_assignment -name RESERVE_ASDO_AFTER_CONFIGURATION "USE AS >> REGULAR IO" >> set_global_assignment -name RESERVE_DATA0_AFTER_CONFIGURATION "USE AS >> REGULAR IO" >> set_global_assignment -name RESERVE_DCLK_AFTER_CONFIGURATION "USE AS >> REGULAR IO" >> set_global_assignment -name RESERVE_FLASH_NCE_AFTER_CONFIGURATION >> "USE AS REGULAR IO" >> 2) modify the value of "ncs_reg" in asmi_parallel.v as below. >> -> always @ ( negedge clkin_wire or posedge end_ophdly) >> if (end_ophdly == 1'b1) ncs_reg<= 1'b1; >> else if (wire_ncs_reg_ena == 1'b1) ncs_reg<= 1'b0; >> 3) install the service pack 1 : I didn't try it >> >> I guess that the problem is related to the setting of 4 configuration >> pins. >> But I'm not sure what could I do. >> If you have any advice or solution, please let me know. >> >> Thanks advance >> Regards >> Paul >> >> >> >> >> --------------------------------------- >> Posted through http://www.FPGARelated.com >Article: 149091
Sorry for the late reply, stuck in meetings all day. Thanks a lot for your replies! @John: Thanks, I'm right now checking if there might be time for the refresh after the reads, would be the simplest solution. Most likely not possible though, but I'm checking anyways, just in case. Thanks! @glen Two identical devices is also a great idea, will of course work! Pricing may be an issue, am looking into it. @gabor Also a great idea, but I'm not following you all the way. Is it possible to: 1) Initiate a read 2) initiate a refresh in another bank, all in 80 ns? Because as I said, there are no guaranteed pauses whatsoever to do anything else than responding to reads every 80 ns. @Nico -Yes, believe me we have checked thoroughly all flash vendors. I know ISSI is good with keeping parts in production, but they don't do FLASH at all as far as I know. -SRAM is also out of the question because of the price. High volume product + 4 MByte SRAM is not a good combination. -And as glen pointed out correctly, writes is not an issue, write is performed only on power-on and is not timing critical @Ulf Yes, thanks. Have looked into both FLASH and PSRAM, and would prefer not to use any of those for the above mentioned reasons, price and availability is not sufficient. Nice seing you here btw, long time... :) So this leaves me with the following options: - using two SDRAM's with separate interfaces to the FPGA. One in refresh while reading the other. - using a 4 time as large SDRAM and keep identical data in at least two banks (assuming this works, see comment to gabor above) - dismiss the idea of using DRAM and re-evaluate the other options (parallel flash etc.) Thanks a lot for your time so far, great help. If you get any more ideas, I'm eternally grateful. /JohannesArticle: 149092
On Sep 30, 9:12=A0am, Johannes <johannesman...@gmail.com> wrote: > Sorry for the late reply, stuck in meetings all day. Thanks a lot for > your replies! > > @John: Thanks, I'm right now checking if there might be time for the > refresh after the reads, would be the simplest solution. Most likely > not possible though, but I'm checking anyways, just in case. Thanks! > > @glen > Two identical devices is also a great idea, will of course work! > Pricing may be an issue, am looking into it. > > @gabor > Also a great idea, but I'm not following you all the way. Is it > possible to: 1) Initiate a read 2) initiate a refresh in another bank, > all in 80 ns? Because as I said, there are no guaranteed pauses > whatsoever to do anything else than responding to reads every 80 ns. > > @Nico > -Yes, believe me we have checked thoroughly all flash vendors. I know > ISSI is good with keeping parts in production, but they don't do FLASH > at all as far as I know. > -SRAM is also out of the question because of the price. High volume > product + 4 MByte SRAM is not a good combination. > -And as glen pointed out correctly, writes is not an issue, write is > performed only on power-on and is not timing critical > > @Ulf > Yes, thanks. Have looked into both FLASH and PSRAM, and would prefer > not to use any of those for the above mentioned reasons, price and > availability is not sufficient. Nice seing you here btw, long > time... :) > > So this leaves me with the following options: > - using two SDRAM's with separate interfaces to the FPGA. One in > refresh while reading the other. > - using a 4 time as large SDRAM and keep identical data in at least > two banks (assuming this works, see comment to gabor above) > - dismiss the idea of using DRAM and re-evaluate the other options > (parallel flash etc.) > > Thanks a lot for your time so far, great help. If you get any more > ideas, I'm eternally grateful. > > /Johannes I think there is one other solution that has not been mentioned. Why are you limited to 100 MHz SDRAM? Can't you go with a 133 MHz SDRAM? Then you would have more clock cycles to do your read and still initiate a refresh on a separate bank. I guess it has been a long time since I've worked with SDRAM, so I'm not sure a faster interface actually would give you more time for a refresh. I would need to look at a data sheet again. RickArticle: 149093
> I think there is one other solution that has not been mentioned. =A0Why > are you limited to 100 MHz SDRAM? =A0Can't you go with a 133 MHz SDRAM? > Then you would have more clock cycles to do your read and still > initiate a refresh on a separate bank. =A0I guess it has been a long > time since I've worked with SDRAM, so I'm not sure a faster interface > actually would give you more time for a refresh. =A0I would need to look > at a data sheet again. > Yes, but this doesn't help. 100, 133 or even 1100 MHz DDR-III has the same random access times (about 50-60 ns for a full random read cycle). It's only burst that has improved.Article: 149094
On Sep 30, 11:13=A0am, Johannes <johannesman...@gmail.com> wrote: > > I think there is one other solution that has not been mentioned. =A0Why > > are you limited to 100 MHz SDRAM? =A0Can't you go with a 133 MHz SDRAM? > > Then you would have more clock cycles to do your read and still > > initiate a refresh on a separate bank. =A0I guess it has been a long > > time since I've worked with SDRAM, so I'm not sure a faster interface > > actually would give you more time for a refresh. =A0I would need to loo= k > > at a data sheet again. > > Yes, but this doesn't help. 100, 133 or even 1100 MHz DDR-III has the > same random access times (about 50-60 ns for a full random read > cycle). It's only burst that has improved. I think the point is how many accesses you can make during the 80 ns you have. If you need to read one bank while activating another, the cycle timing doesn't change, but the number of commands you can send to the device does. By the way you don't really need to do a "refresh" to a bank, only activate the row followed by a precharge. That takes two commands on the address / command interface anyway you look at it. This represents a smaller portion of the 80 ns when you are running a faster clock rate. When I have designed SDRAM controllers, I generally start with a chart to show on each clock cycle what I am doing on the address / command interface, and what is happening on the DQ interface. When using multiple banks, this is highly pipelined and interleaved, so charting it out helps to visualize what I need to do. For example, when doing high data-rate access, I have a favorite controller that always moves to the next bank after a single burst access. It also always uses the autoprecharge commands for read or write. This means that I can activate a row, read (or write), and precharge it in two commands. Interleaving the banks allows an access to any random row in the next bank with no dead cycles as long as I have a burst of at least 2 words, and don't change direction (read v. write). If I look at a single burst to the same row of each of the four banks as my minimum access or "word size", then I have essentially a really random access memory that runs at the device clock rate. Note that since I am usually doing video and image processing, I'm less concerned about latency and more concerned with throughput. In your case however, you can map the cycle of reading a bank while "refreshing" another and look at the worst case latency if the external request comes at any point in the current cycle. By the way, you realize that some of the latency necessarily comes in the path from registering the data in the FPGA to placing it on the outputs of the pseudo-EEPROM bus. This should also be helped with a hight clock rate. One more point about refresh. Like the early DRAM devices, single-data-rate SDRAM only requires a refresh to each row (of each bank) within the stated refresh period, usually 32 or 64 ms. Any row/bank that you have read or written in that time does not need additional refresh. In the early days there were DRAM refresh controllers that kept a log (1 bit per row) of row accesses and only refreshed the untouched rows as required, usually in one big burst. Assigning your address such that row address is in the lower bits usually causes the additional refresh requirement to be very small because the access is typically sequential. All of the above bit is not true of DDR SDRAM. There are additional reasons to use the auto-refresh command in these devices, namely giving the chip a window to re- calibrate its DLL without creating jitter in the DQ interface. These devices typically require a distributed refresh with a maximum time between refreshes of 15.6 us. I don't think this helps in your case. Regards, GaborArticle: 149095
On Sep 30, 11:13=A0am, Johannes <johannesman...@gmail.com> wrote: > > I think there is one other solution that has not been mentioned. =A0Why > > are you limited to 100 MHz SDRAM? =A0Can't you go with a 133 MHz SDRAM? > > Then you would have more clock cycles to do your read and still > > initiate a refresh on a separate bank. =A0I guess it has been a long > > time since I've worked with SDRAM, so I'm not sure a faster interface > > actually would give you more time for a refresh. =A0I would need to loo= k > > at a data sheet again. > > Yes, but this doesn't help. 100, 133 or even 1100 MHz DDR-III has the > same random access times (about 50-60 ns for a full random read > cycle). It's only burst that has improved. But if the read takes 60 ns and you have 80, can't you get a refresh in between the reads? Or does the full read cycle require the full 80 ns? Looking at the data sheet, I see that you can interleave banks which appears to add nothing to the time of a random read. You would need to use more then two banks with duplicate data, but you could start a read on bank 0, then do a refresh on bank 1. Next read bank 1 and refresh bank 2. Finally read bank 2 and refresh bank 0. By the time this is complete, you can go back to reading bank 0. I'm not sure if you you can do this with two banks. It depends on the time required between the refresh to starting the next read. RickArticle: 149096
Gabor <gabor@alacron.com> wrote: (snip) > One more point about refresh. Like the early DRAM devices, > single-data-rate SDRAM only requires a refresh to each > row (of each bank) within the stated refresh period, usually > 32 or 64 ms. Any row/bank that you have read or written > in that time does not need additional refresh. In the early days > there were DRAM refresh controllers that kept a log (1 bit > per row) of row accesses and only refreshed the untouched > rows as required, usually in one big burst. Assigning your > address such that row address is in the lower bits usually > causes the additional refresh requirement to be very small > because the access is typically sequential. This reminds me, some years ago I was working on a design with a very large finite state machine, with the possibility of storing it in SDRAM. I had thought about the possibility of positioning the states in memory such that the row access pattern would be sufficient for refresh. Normally, it might stay in a small number of states, so I had thought about duplicating some of the states to supply enough that it would reliably satisfy the refresh requirement. Still, with random input, one might be able to statistically get the probability of missing a row refresh within the refresh time very small, but maybe not zero. -- glenArticle: 149097
On Thu, 30 Sep 2010 08:13:30 -0700 (PDT), Johannes <johannesmannen@gmail.com> wrote: > >> I think there is one other solution that has not been mentioned. Why >> are you limited to 100 MHz SDRAM? Can't you go with a 133 MHz SDRAM? >> Then you would have more clock cycles to do your read and still >> initiate a refresh on a separate bank. I guess it has been a long >> time since I've worked with SDRAM, so I'm not sure a faster interface >> actually would give you more time for a refresh. I would need to look >> at a data sheet again. >> > >Yes, but this doesn't help. 100, 133 or even 1100 MHz DDR-III has the >same random access times (about 50-60 ns for a full random read >cycle). It's only burst that has improved. But a typical device has (say) RAS-CAS) latency of 2. Therefore if in Cycle 1 you open Bank 1 and present the read row address, it will be in Cycle 3 that you present the column address. (Then there are a couple more cycles before you get the data back) That leaves Cycle 2 spare. Use it to start a Refresh in the alternate bank; Refresh will take a few cycles in its own right... If the Refresh is not complete by the end of the current 80ns period, you cannot read from the Bank 2 in the second 80ns period, so you need to cycle through 4 banks. (That will give 240ns for a refresh; ample time including any precharge requirements. Gabor is right - you need something like a spreadsheet to map out what happens in each cycle, in each bank. The importance of 133MHz or higher is not to achieve faster random reads, but to increase degrees of freedom for aligning other activities (refresh, precharge) in the gaps during the reads - 133MHz memory (clocked at 125) would give 10 cycles rather than 8. - BrianArticle: 149098
Hi all, I have a quite sparse evaluation board: you can find on it a Virtex 5, a SPI-ROM, SRAM as well as a JTAG interface. I am trying to do some experiments with partial reconfiguration, so I need to put somewhere into memory the partial bitstreams. Has anyone tried to put them on a SPI-ROM? Of course it is possible to put one on it, but can I put several of those there? Further, this is a very simple interface, is there a possibiltiy to address the content of the ROM somehow? Obviously, I would need different offsets from where I read when I access the different bitstreams. Many thanks for your help, PatrickArticle: 149099
Hi, I am just wondering how difficult it is to add a flash card reader to an FPGA. In other words, I have 64 free I/O pins on my board and I wanna connect there a reader so that I can read data from a flash card. Anyone experience with that and can point me to a good source where this is described in detail how to do that. Any helpful comments are very much appreciated. Phil
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