From: prashantj@usa.net (Prashant) Newsgroups: comp.arch.fpga Subject: Async RAM on an FPGA board Date: 18 Dec 2002 08:50:37 -0800 Organization: http://groups.google.com/ Lines: 21 Message-ID: NNTP-Posting-Host: 64.207.24.62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1040230238 22274 127.0.0.1 (18 Dec 2002 16:50:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 18 Dec 2002 16:50:38 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24168 Hi, I'm trying to build a synchronous FPGA design on the A15E APEX DSP Development Board (Professional Version) from Altera. The board has 512 Kbytes of "asynchronous" RAM which can be used with the FPGA. Since this on-board RAM is asynchronous, it cannot be used in my synchronous design on the FPGA. Altera always recommends using synchronous RAM for all synchronous designs and I feel that should be the case. No asynchronous cores in a synchronous design. Is there any way the async on-board RAM can be used with a synchronous design on the FPGA, without causing any errors ? I have tried using the async RAM and have found that when I read 64 7-bit values from the async RAM, some of them are erroneous. The errors are unpredictable from one run to another. I guess this would mean that the asynchronicity of the RAM is causing the problem. Let me know if anyone has any suggestions. Thanks, Prashant ###### From: "Jonathan Bromley" Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: Wed, 18 Dec 2002 17:02:23 -0000 Lines: 51 Message-ID: References: Reply-To: "Jonathan Bromley" NNTP-Posting-Host: 62.49.79.188 X-Trace: news.demon.co.uk 1040230950 11984 62.49.79.188 (18 Dec 2002 17:02:30 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 18 Dec 2002 17:02:30 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24153 "Prashant" wrote > Is there any way the async on-board RAM can be used with a synchronous > design on the FPGA, without causing any errors ? You've simply got to find some way to make your synchronous FPGA generate correctly timed read and write cycles for the asynch RAM (see its data sheet). It's usually easy to get read cycles correct (note I didn't say "get read cycles right" - groan). Set up address and read-enable on one clock, then on the next clock (or perhaps two or even three clocks later, depending on RAM speed vs. clock speed) you capture the read data off the data lines and on the same clock edge you can remove read-enable and the address. No problems, because there is sure to be some delay after the clock edge before address and read-enable go away, therefore plenty of hold time for the RAM at the end of the read cycle. Write cycles, on the other hand, are a PITA because you need to ensure that you have enough hold time for address and data AFTER your FPGA removes write-enable. Even if the SRAM has zero hold time (trailing edge of write-enable to address/data invalid), you can't guarantee that the write-enable to address/data skew is in your favour if they are both removed by the same clock edge. So you end up playing horrible games to hold the address and write data valid for a little while after write-enable is removed. Typically you need to resynchronise write-enable to the falling edge of your system clock. If you don't do this, the only other way is to allow one complete clock cycle AFTER the end of write-enable, and then remove the address and data. This makes write cycles one whole clock slower than they need to be, and it explains why everyone prefers synchronous RAMs. Depending on exactly what you are doing with the RAM, it may be possible to finesse your way around these issues by using write-posting or a FIFO on writes. But it's not easy to get these tricks working correctly, and I suggest you start with a simpler approach and just accept that things will be a little slower. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. ###### From: "Rob Finch" Newsgroups: comp.arch.fpga References: Subject: Re: Async RAM on an FPGA board Lines: 75 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <09gM9.5141$pS6.1144042@news20.bellglobal.com> Date: Thu, 19 Dec 2002 04:17:46 -0500 NNTP-Posting-Host: 65.95.21.253 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1040289468 65.95.21.253 (Thu, 19 Dec 2002 04:17:48 EST) NNTP-Posting-Date: Thu, 19 Dec 2002 04:17:48 EST Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24254 > > Is there any way the async on-board RAM can be used with a synchronous > > design on the FPGA, without causing any errors ? Yes. In order to use the async ram reliably you need to use a clock operating at a higher frequency than the desired ram access, and build a state machine that accesses the ram in a fashion that meets all the ram timing requirements. The higher the clock frequency is, the better timing resolution will be possible. Register the address, data and control signals in the FPGA so the async ram inputs are fed directly from the registered outputs (don't put in any intervening mux's or other logic as this affects routing delays between signals). Specify timing constraints for the ram signals so that tools can use these when determining how to build the logic. Don't try and fudge the delays by building in async elements in the FPGA; this won't work reliably and will cause nothing but grief. Do a synchronous design. The FPGA is probably being clocked at a much higher rate than the external async ram can be accessed, so there are probably wait states involved in accessing the ram anyway. I use the simple state machine below. My system runs at half the clock frequency which is why the ready line is held active for two cycles. The ram runs at 1/4 the clock frequency. This machine forces full timing for back-to-back accesses while allowing access to begin on any clock cycle. The write line pulses low for one cycle in the middle of access. If you're using 15ns ram don't expect to be able to access it at 60MHz. 25MHz is more realistic. sram (even async) is great for random access performance. Even at 25MHz it's operating a lot faster than SDRAM. If you don't care about the performance interfacing regular DRAM is a snap as it's an easy extension to the state machine, and DRAM uses fewer pins. reg [2:0] rcd; always @(posedge clkib) begin if (reset) begin rcd <= 3'b0; ram_rdy <= 0; end else begin case(rcd) 0: begin rcd <= ram_cs; oe <= ~(rd|ifetch); we <= 1; end 1: begin ram_rdy <= 1; rcd <= rcd + 1; we <= ~wr; oe <= ~(rd|ifetch); end 2: begin ram_rdy <= 1; rcd <= rcd + 1; we <= 1; oe <= ~(rd|ifetch); end 3: begin ram_rdy <= 0; rcd <= 0; oe <= 1; end endcase end end Rob www.birdcomputer.ca ###### From: prashantj@usa.net (Prashant) Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: 19 Dec 2002 07:54:51 -0800 Organization: http://groups.google.com/ Lines: 8 Message-ID: References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> NNTP-Posting-Host: 64.207.24.62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1040313291 1010 127.0.0.1 (19 Dec 2002 15:54:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 19 Dec 2002 15:54:51 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!headwall.stanford.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24260 Hi, Thanks everyone for the suggestions. My FPGA runs @ 40MHz and the RAM specs say its a 10ns RAM. I thought @ 40MHz the FPGA ran slow enough for the RAM to be accessed comfortably. But I will take your suggestion and give the RAM more time to fetch data. Thanks again, Prashant ###### From: "Jonathan Bromley" Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: Thu, 19 Dec 2002 17:39:43 -0000 Lines: 63 Message-ID: References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> Reply-To: "Jonathan Bromley" NNTP-Posting-Host: 62.49.79.188 X-Trace: news.demon.co.uk 1040319583 24918 62.49.79.188 (19 Dec 2002 17:39:43 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 19 Dec 2002 17:39:43 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24251 > Thanks everyone for the suggestions. My FPGA runs @ 40MHz and the RAM > specs say its a 10ns RAM. I thought @ 40MHz the FPGA ran slow enough > for the RAM to be accessed comfortably. But I will take your > suggestion and give the RAM more time to fetch data. WHOA THERE! You didn't listen! If it's 10ns SRAM with a 40MHz clock then you probably have plenty of time to do the fetch (although you should check the delay through the FPGA's I/O pads, since they can be quite slow). BUT.. THE PROBLEM IS PROBABLY RELATED TO DATA HOLD TIME AT THE END OF WRITE CYCLES. I thought I'd said that clearly, but it's worth saying again. You MUST ensure that write data and address are held valid for some time AFTER the end of your write strobe pulse. It's tedious, but it's important. With a 25ns clock you should be able to play tricks with 2-phase clocking... (view in monospaced font) WRITE CYCLE... __ __ __ __ clk __| |__| |__| |__| : :_____: : data, adrs XXXXXXXXX_____XXXXXXXXX (clocked by rising edge) ___:_____: __:_____:__ nWE |__| Note that nWE is asserted on rising edge and removed on falling edge of clock. Get this by ORing together two signals, one synchronised to clock rise and the other to clock fall... __ __ __ __ clk __| |__| |__| |__| ___:__ : __:_____:__ nWE_early |_____| (clocked by falling edge) ___:_____: :_____:__ nWE_late |_____| (clocked by rising edge) ___:_____: __:_____:__ nWE |__| (nWE_late OR nWE_early) But be ready to go back to slower multi-cycle writes if things don't quite go right. My suggestion may give rise to problems because the address might be changing during the early part of the write cycle. Read your RAM data sheet very carefully. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. ###### From: eric - Mtl User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: fr-CA, fr-FR, en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 133 Message-ID: Date: Thu, 19 Dec 2002 17:37:09 -0500 NNTP-Posting-Host: 65.94.88.215 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1040337400 65.94.88.215 (Thu, 19 Dec 2002 17:36:40 EST) NNTP-Posting-Date: Thu, 19 Dec 2002 17:36:40 EST Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24256 Jonathan Bromley wrote: >>Thanks everyone for the suggestions. My FPGA runs @ 40MHz and the RAM >>specs say its a 10ns RAM. I thought @ 40MHz the FPGA ran slow enough >>for the RAM to be accessed comfortably. But I will take your >>suggestion and give the RAM more time to fetch data. > doable, yes, comfortable no ... > > WHOA THERE! You didn't listen! > > If it's 10ns SRAM with a 40MHz clock then you probably have plenty > of time to do the fetch (although you should check the delay through > the FPGA's I/O pads, since they can be quite slow). BUT.. > > THE PROBLEM IS PROBABLY RELATED TO DATA HOLD TIME AT THE END OF > WRITE CYCLES. I thought I'd said that clearly, but it's worth > saying again. You MUST ensure that write data and address > are held valid for some time AFTER the end of your write strobe > pulse. It's tedious, but it's important. > > With a 25ns clock you should be able to play tricks with > 2-phase clocking... (view in monospaced font) > > WRITE CYCLE... > __ __ __ __ > clk __| |__| |__| |__| > : :_____: : > data, adrs XXXXXXXXX_____XXXXXXXXX (clocked by rising edge) > > ___:_____: __:_____:__ > nWE |__| > I did the same kind of design (Spartan II, 10ns K6R4008V1C SRAM / 48Mhz) but with a minor change. As shown above, I keep the adrs bus on for the whole cycle, but I drive the data bus only during the active period of your nWE. Driving it for the whole cycle is likely to create bus contention if the write is followed by a read. The minor change is that I add "weak keeper" symbols to the data pins so that they keep their logic state even after I stop driving them (thus avoiding data hold time violation). It also works for read cycles where the data is sampled while releasing nOE (this might work simply with capacitive loading, the keepers are for peace of mind) For it to work properly , the SRAM must go hiZ cleanly (not driving transient garbage on the data bus) but I never saw this being a problem. > > Note that nWE is asserted on rising edge and removed on > falling edge of clock. Get this by ORing together two > signals, one synchronised to clock rise and the other to > clock fall... > __ __ __ __ > clk __| |__| |__| |__| > ___:__ : __:_____:__ > nWE_early |_____| (clocked by falling edge) > ___:_____: :_____:__ > nWE_late |_____| (clocked by rising edge) > ___:_____: __:_____:__ > nWE |__| (nWE_late OR nWE_early) > > > But be ready to go back to slower multi-cycle writes if > things don't quite go right. My suggestion may give rise > to problems because the address might be changing during the > early part of the write cycle. Read your RAM data sheet > very carefully. To prevent this problem, I drive the nCS signal using the same clock as addr, nCS is a fast "F16" driver, bidirectional signal. the nWE pin is driven with nCS feedback (delayed) input OR the logical value for nWE. I use a slower "F6" driver for it. Combinatorial delay for the nWE signal is : t(nCS Driver) + t(nCS receiver with built in delay element) + t(LUT [the OR gate]) + t(nWE driver) Combinatorial delay for the nCS signal is : t(nCS Driver) Combinatorial delay for the addr bus is : t(addr(x) Driver) This gives an extra few ns delay between address / nCS change & nWE assertion. If, due to process variation, this delay becomes shorter, so is the address bus switching time and nWE will always lag behind (if routing/placement is properly done) The SRAM I use have a 0ns specification for adress to nWE (this means nWE is internally delayed) and minimum nWE pulse width is a short 7ns. ---------- Another way to go at these frequencies would be to use the 90 deg output (or 2x out) of a DLL to double time resolution and correct clock mark/space ratio (another cause for timing errors and unreliable async SRAM operation). Going that way enables more predictable signal sequencing and avoid the frowned upon use of async delays. If I had to do it again, I'd probably go that way. hope this helps. Eric PS : For unobfuscated email, remove "not" and "me" Samsung K6R4008V1D datasheet : http://www.samsungelectronics.com/semiconductors/SRAM/High_Speed/Asynch_Fast/4M_bit/K6R4008V1D/k6r4008v1d.htm http://www.samsungelectronics.com/semiconductors/SRAM/High_Speed/Asynch_Fast/4M_bit/K6R4008V1D/ds_k6r4008v1d.pdf > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. > > ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: Thu, 19 Dec 2002 15:03:45 -0800 Organization: Xilinx,Inc Lines: 16 Message-ID: <3E025050.C28A30D7@xilinx.com> References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: eric - Mtl Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24198 Just to avoid confusion: The only asynchronous operation in a Xilinx RAM is the reading of the distributed ( 16-bit deep) LUT-RAM. Everything else is synchronous and self-timed, without hold-time requirements. That means the writing of the LUT-RAM and the reading and the writing of the BlockRAM, in all flavors of Virtex and Spartan-II, are all synchronously referenced to the clock edge and have no address or data hold-time requirements. Peter Alfke, Xilinx Applications > > I did the same kind of design (Spartan II, 10ns K6R4008V1C > SRAM / 48Mhz) but with a minor change. > ###### From: prashantj@usa.net (Prashant) Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: 19 Dec 2002 15:18:36 -0800 Organization: http://groups.google.com/ Lines: 34 Message-ID: References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> NNTP-Posting-Host: 64.207.24.62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1040339917 4851 127.0.0.1 (19 Dec 2002 23:18:37 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 19 Dec 2002 23:18:37 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!feedme.news.mediaways.net!newsfeed.sovam.com!newsfeed.media.kyoto-u.ac.jp!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24262 "Jonathan Bromley" wrote in message news:... > > Thanks everyone for the suggestions. My FPGA runs @ 40MHz and the RAM > > specs say its a 10ns RAM. I thought @ 40MHz the FPGA ran slow enough > > for the RAM to be accessed comfortably. But I will take your > > suggestion and give the RAM more time to fetch data. > > WHOA THERE! You didn't listen! > Hi Jonathan, I write data to the RAM through my PC's serial port to the FPGA and then to the RAM. The data is written through the FPGA @ 40MHz, but its only written once (one word) every 8.68us (1/115.2KHz). I checked my code and the write enable signal stays enabled all the time (since I'm only writing). The address also changes only @ the rate of 115.2 KHz and many cycles after the data is written to the RAM. Also, if I read back the external RAM data (one word every 8.68us)through the FPGA to the PC, the data is found to be the same as what was written. Hence I assume that the writing of the data was correct. The problems start when I run a seperate piece of code on the FPGA which requires to read 64 words of data from the RAM in 64 clock cycles. Some of the values are captured incorrectly. Hence, I assumed that it was the read cycles which were incorrectly operating and so I wanted to slow down my read cycles. Am I on the right track ? I highly appreciate the timing diagrams you drew up there. Thanks, Prashant ###### Message-ID: <3E025760.22EA@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 36 Date: Fri, 20 Dec 2002 12:33:52 +1300 NNTP-Posting-Host: 203.79.98.83 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1040340946 203.79.98.83 (Fri, 20 Dec 2002 12:35:46 NZDT) NNTP-Posting-Date: Fri, 20 Dec 2002 12:35:46 NZDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!c03.atl99!news.webusenet.com!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24229 Prashant wrote: > > "Jonathan Bromley" wrote in message news:... > > > Thanks everyone for the suggestions. My FPGA runs @ 40MHz and the RAM > > > specs say its a 10ns RAM. I thought @ 40MHz the FPGA ran slow enough > > > for the RAM to be accessed comfortably. But I will take your > > > suggestion and give the RAM more time to fetch data. > > > > WHOA THERE! You didn't listen! > > > > Hi Jonathan, > I write data to the RAM through my PC's serial port to the FPGA and > then to the RAM. The data is written through the FPGA @ 40MHz, but its > only written once (one word) every 8.68us (1/115.2KHz). I checked my > code and the write enable signal stays enabled all the time (since I'm > only writing). ?! - Do you mean this - the WRN should NOT be active on an address change. Normally, WRN is the 'most-narrow' pulse. > The address also changes only @ the rate of 115.2 KHz > and many cycles after the data is written to the RAM. Also, if I read > back the external RAM data (one word every 8.68us)through the FPGA to > the PC, the data is found to be the same as what was written. Hence I > assume that the writing of the data was correct. If you only read the last-written byte, you can get false-confidance :) A better test is a pattern write, then read. We use 255-(AdrU XOR AdrL) as a simple pattern, that rolls, and avoids matching the address. -jg ###### From: "Jonathan Bromley" Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: Fri, 20 Dec 2002 10:24:42 -0000 Lines: 84 Message-ID: References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> Reply-To: "Jonathan Bromley" NNTP-Posting-Host: 62.49.79.188 X-Trace: news.demon.co.uk 1040379882 18311 62.49.79.188 (20 Dec 2002 10:24:42 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 20 Dec 2002 10:24:42 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!proxad.net!proxad.net!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24247 "Prashant" wrote > I write data to the RAM through my PC's serial port to the FPGA and > then to the RAM. The data is written through the FPGA @ 40MHz, but its > only written once (one word) every 8.68us (1/115.2KHz). I checked my > code and the write enable signal stays enabled all the time (since I'm > only writing). The address also changes only @ the rate of 115.2 KHz > and many cycles after the data is written to the RAM. Also, if I read > back the external RAM data (one word every 8.68us)through the FPGA to > the PC, the data is found to be the same as what was written. Hence I > assume that the writing of the data was correct. I agree with Jim Granville that it's a really bad idea to leave nWR asserted continuously. Are you pulsing nCS? Usually, you expect a SRAM to perform a write to its internal storage on the rising edge of (nWR OR nCS). If both are held asserted (low) then it's not at all clear what will happen. Possibly you get a write taking effect when the address changes, but it's very uncertain and very bad practice. > The problems start when I run a seperate piece of code on the FPGA > which requires to read 64 words of data from the RAM in 64 clock > cycles. Some of the values are captured incorrectly. > Hence, I assumed that it was the read cycles which were incorrectly > operating and so I wanted to slow down my read cycles. Let's assume for the moment that your writes really are correct, and the reads are failing. You need to think about the whole logic path from the FF that registers your RAM address on one clock cycle, through any logic in the FPGA, through the output pads, to the RAM, through the RAM's access time, back into the FPGA through the input pads and finally into a flipflop that captures the read data on the next clock edge: LOGIC PATH: =========== <----- FPGA address path -----> <------ FPGA data path ------> __________ _________ FF inside | ______ ______ ______ ______ _____ |FF inside| FPGA, | | | | FPGA | | SRAM | | FPGA | | | | FPGA,| storing Q|--|logic?|--| OBUF |--|A D|--| IBUF |--|logic|--|D to| address | |______| |______| |______| |______| |_____| | capture| __________| | RAM data| |_________| TIMING: ======= FF prop. + logic + OBUF + SRAM + IBUF + logic + FF setup delay delay delay tAA delay delay time All of this must fit into 25ns, of which the SRAM takes 10ns. So you have a 15ns budget which must be shared between the two completely separate logic paths that I've labelled "FPGA address path" and "FPGA data path". So, the question is, how do you set up your constraints (in the UCF file, or whatever)? In practice the best way is probably to guess as a first attempt - try allowing 9ns for the address path, and 6ns for the data path. Then you will get a timing report from the place-and-route tools and there are 3 possible outcomes: (1) both timing constraints were successfully met - you're done, the design will work OK (2) BOTH constraints were violated - it looks like you have no chance of achieving single-cycle reads (3) ONLY ONE constraint was violated - so you can now go back to the UCF file and change the way your 15ns constraint is shared between the two paths, and then try again. Xilinx gurus will probably tell me how you can include an external logic delay (like the SRAM) in a single, long path - but I don't know the UCF syntax well enough to know how to do that, sorry. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: Fri, 20 Dec 2002 19:23:44 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> X-Complaints-To: abuse@supernews.com Lines: 23 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:24239 >I agree with Jim Granville that it's a really bad idea to leave nWR >asserted continuously. Are you pulsing nCS? Usually, you expect >a SRAM to perform a write to its internal storage on the rising >edge of (nWR OR nCS). If both are held asserted (low) then >it's not at all clear what will happen. Possibly you get a >write taking effect when the address changes, but it's very >uncertain and very bad practice. If you don't meet the setup/hold times on the address during a write, it can write something anywhere. You might be able to argue that it will only write things that look like the data (assuming that meets setup/hold) and that it won't write to addresses specified by the address bits that don't change. I don't think the spec sheet will say anything about that. -- 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. ###### From: prashantj@usa.net (Prashant) Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: 20 Dec 2002 12:07:19 -0800 Organization: http://groups.google.com/ Lines: 31 Message-ID: References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> NNTP-Posting-Host: 64.207.24.62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1040414839 3267 127.0.0.1 (20 Dec 2002 20:07:19 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 20 Dec 2002 20:07:19 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24258 Hi, I'm sorry, I may not have been very clear on the details of my complete process. Here goes: Step 1 : Program FPGA to read data from serial port and write to the external RAM. I described this in details in my previous post. My feeling is that this part is getting done correctly. I do keep the write signal asserted all the time, but the chip select signal deasserts itself when no writing is being done. 64,000 words are written to the external RAM. Step 2: In a similar process as above, I reprogram the FPGA to read data from the external RAM and write to the serial port of the PC. This data is then checked on the PC and found to be exactly the same as what was written to the RAM in step 1. So I write 64,000 words in step 1 and then read all 64000 words in step 2. The reading/writing happens once every 346 cycles (115.2KHz) @ 40MHz in the FPGA. Alternate Step 2 : I program the FPGA to run my 'design code' which reads data from the external RAM and uses it to produce the required outputs. This time 64 values are read in 64 cycles from the external RAM for every run of my 'design code'. Thus the design code will run for 1000 runs before all 64000 values are used from the external RAM. It is during the alternate step 2, when I read 64 words in 64 cycles @ 40MHz, that some of the data read is found to be erroneous. Thanks, Prashant ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: Sat, 21 Dec 2002 05:10:39 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> X-Complaints-To: abuse@supernews.com Lines: 28 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:24318 >Alternate Step 2 : I program the FPGA to run my 'design code' which >reads data from the external RAM and uses it to produce the required >outputs. This time 64 values are read in 64 cycles from the external >RAM for every run of my 'design code'. Thus the design code will run >for 1000 runs before all 64000 values are used from the external RAM. > It is during the alternate step 2, when I read 64 words in 64 cycles @ > 40MHz, that some of the data read is found to be erroneous. Is there a simple timing problem? If you are doing a read, what's the time from clock to address out of FPGA, address to data valid at RAM, setup time at FPGA. Correct for speed of light on traces, clock jitter, many outputs switching... How much do yo have to spare? Is there any pattern to which data bits are getting picked/dropped? Or which address lines are not working? If you run it again do you get the same errors? If you run it several times, do most of the errors happen at the same spot? If you reload your Step 2 code is the data still correct? -- 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. ###### From: "Rob Finch" Newsgroups: comp.arch.fpga References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> Subject: Re: Async RAM on an FPGA board Lines: 16 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Sat, 21 Dec 2002 03:41:55 -0500 NNTP-Posting-Host: 65.95.20.164 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1040460116 65.95.20.164 (Sat, 21 Dec 2002 03:41:56 EST) NNTP-Posting-Date: Sat, 21 Dec 2002 03:41:56 EST Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24320 > It is during the alternate step 2, when I read 64 words in 64 cycles @ > 40MHz, that some of the data read is found to be erroneous. > How do you know the data read in alternate step 2 is erroneous ? If you re-run step 2 again after running alternate step 2, are the data values corrupted ? Are the I/O constraints in the config file the same between the two configurations ? eg. same pin settings, same switching standards ? Rob ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: Sat, 21 Dec 2002 14:03:20 -0500 Organization: Arius, Inc Lines: 29 Message-ID: <3E04BAF8.6CA7FEA6@yahoo.com> References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> <3E03890A.1C5140F@andraka.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZ33BkJj8daYuhjjqoPY6yBoCQIsTqa11YO15+YoC76kRQfx9dEom/j X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 21 Dec 2002 19:03:03 GMT X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!iad-peer.news.verio.net!news.verio.net!newsfeed.cwix.com!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24297 Ray Andraka wrote: > > I've done that on many designs. The weak pullups are enough as long as the > memory is located close to the FPGA. Where I have an influence, I recommend > pullups on the control signals so that reconfiguration won't upset the > contents of the RAM. It is very useful to have the capability to reconfigure > without corrupting RAM contents (see my paper on the radar environment > simulator for examples of this, available at no charge on my website). My understanding is that with FPGAs and other chips that have weak internal pullups on the IO pins, they are only for assuring the state of an unconnected input and are not guaranteed to hold an external trace an pins to a known value when not driven. I am pretty sure I have read this warning in Xilinx literature somewhere. I *always* use external pullups/downs if I need to assure the state of a signal before configuration. -- 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 FAX ###### Message-ID: <3E04C368.BC622696@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> <3E03890A.1C5140F@andraka.com> <3E04BAF8.6CA7FEA6@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 50 Date: Sat, 21 Dec 2002 19:37:34 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1040499454 68.15.41.165 (Sat, 21 Dec 2002 14:37:34 EST) NNTP-Posting-Date: Sat, 21 Dec 2002 14:37:34 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24303 Exactly, that is why I went on to state where I have influence... I've been stuck with 3rd party boards without them though that didn't have the pull-ups. With 4K parts, the pull ups were strong enough to ensure a high level in all but the most severe emi environments if the trace was short and lightly loaded. Newer parts have less margin I think. rickman wrote: > Ray Andraka wrote: > > > > I've done that on many designs. The weak pullups are enough as long as the > > memory is located close to the FPGA. Where I have an influence, I recommend > > pullups on the control signals so that reconfiguration won't upset the > > contents of the RAM. It is very useful to have the capability to reconfigure > > without corrupting RAM contents (see my paper on the radar environment > > simulator for examples of this, available at no charge on my website). > > My understanding is that with FPGAs and other chips that have weak > internal pullups on the IO pins, they are only for assuring the state of > an unconnected input and are not guaranteed to hold an external trace an > pins to a known value when not driven. I am pretty sure I have read > this warning in Xilinx literature somewhere. I *always* use external > pullups/downs if I need to assure the state of a signal before > configuration. > > -- > > 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 FAX -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: prashantj@usa.net (Prashant) Newsgroups: comp.arch.fpga Subject: Re: Async RAM on an FPGA board Date: 23 Dec 2002 09:08:13 -0800 Organization: http://groups.google.com/ Lines: 34 Message-ID: References: <09gM9.5141$pS6.1144042@news20.bellglobal.com> NNTP-Posting-Host: 64.207.24.62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1040663293 15834 127.0.0.1 (23 Dec 2002 17:08:13 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Dec 2002 17:08:13 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24363 "Rob Finch" wrote in message news:... > > It is during the alternate step 2, when I read 64 words in 64 cycles @ > > 40MHz, that some of the data read is found to be erroneous. > > > > How do you know the data read in alternate step 2 is erroneous ? > > If you re-run step 2 again after running alternate step 2, are the data > values corrupted ? > > Are the I/O constraints in the config file the same between the two > configurations ? eg. same pin settings, same switching standards ? > > Rob To answer some of the questions asked. 1. If I run the code again, I do not get the errors in the same spot. They change with a new run. 2. I know the data read in the alternate step 2 is erroneous, as I capture it through the internal logic analyzer and view it in the Quartus software. 3. The IO configs are kept the same between the two files as far reading data from the external RAM is concerned. 4. Recently, I ran the alternate step 2 slower, which means I read the data from the external RAM in two cycles instead of one. This seems to have helped the data coming in be stable in alternate step 2. Wonder if I was reading too fast ? Thanks, Prashant