From: Steven Derrien Newsgroups: comp.arch.fpga Subject: Spartan II and asynchronous memory interface Date: Thu, 02 Aug 2001 18:25:29 +0200 Organization: INRIA - RENNES Lines: 32 Message-ID: <3B697EF9.E5BDF155@irisa.fr> NNTP-Posting-Host: spyder.irisa.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.irisa.fr 996769528 26188 131.254.51.10 (2 Aug 2001 16:25:28 GMT) X-Complaints-To: usenet@irisa.fr NNTP-Posting-Date: 2 Aug 2001 16:25:28 GMT X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!teaser.fr!enst!univ-angers.fr!univ-rennes1.fr!irisa.fr!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8841 Hi, We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) to a VHDL targeted to the BurchEd Spartan II board (http://www.burched.com) We plan to make our work freely available, but are currently stuck on a problem. The design is a 16 CPU-SOC which interfaced to a parallel port. We have somes on-chip blockrams which serves as ROM, and off-chip asynchronous SRAM whiwh serves as main memory. Our problem is that we get frequent errors when accessing the off-chip SRAM banks. Generally a single bit wrong in a 16 bit data word every 200-300 access. All simulation (RTL,gate-level,post place and route) went fine. Right now, our system is clocked at 1Mhz far below its maximum frequency. Besides, the SRAM Write Enable command output signal is registered (although not in a IOB register) to avoid glitches which could cause wrong write operations. All IOB are configured with SLOW slew-rate and drive 12mA (default IOB config) We have been beating our heads on this problem for almost a week now, are there any experts around there to offer some tips/ideas/advices ? Thanks, Steven ###### Reply-To: "david garnett" From: "david garnett" Newsgroups: comp.arch.fpga References: <3B697EF9.E5BDF155@irisa.fr> Subject: Re: Spartan II and asynchronous memory interface Date: Thu, 2 Aug 2001 17:59:27 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Lines: 54 Message-ID: <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> NNTP-Posting-Host: userds77.uk.uudial.com X-Trace: 996772457 news.dial.pipex.com 3763 62.188.6.183 X-Complaints-To: abuse@uk.uu.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!news-han1.dfn.de!news-koe1.dfn.de!do.de.uu.net!lnewspeer01.lnd.ops.eu.uu.net!lnewspost00.lnd.ops.eu.uu.net!emea.uu.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8806 The BurchED Spartan board is only two layer, and has what seems to me is a fairly poor power/ground layout - I would be much happier to see a real ground 'plane' at least under the chip. Perhaps your problems are related - things happen really fast inside something like a Spartan II and if your decoupling is not perfect ... Dave [ In other respects I think that the board is useful and very good value for money - but if I were laying it out I'd have a solid ground under the chip proper, with all chip grounds connected directly to it, and then place decoupling caps round the edge of the chip on the underside, preferably connecting to a VCC power 'plane' directly under the ground 'plane', giving very short decoupling track lengths.] Dave "Steven Derrien" wrote in message news:3B697EF9.E5BDF155@irisa.fr... > Hi, > > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) > to a VHDL targeted to the BurchEd Spartan II board > (http://www.burched.com) > > We plan to make our work freely available, but are currently stuck on > a problem. The design is a 16 CPU-SOC which interfaced to a parallel > port. > > We have somes on-chip blockrams which serves as ROM, and off-chip > asynchronous > SRAM whiwh serves as main memory. Our problem is that we get frequent > errors when accessing the off-chip SRAM banks. Generally a single bit > wrong in a 16 bit data word every 200-300 access. > > All simulation (RTL,gate-level,post place and route) went fine. > Right now, our system is clocked at 1Mhz far below its maximum > frequency. > Besides, the SRAM Write Enable command output signal is registered > (although not in a IOB register) to avoid glitches which could cause > wrong write operations. > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > config) > > We have been beating our heads on this problem for almost a week now, > are there any experts around there to offer some tips/ideas/advices ? > > Thanks, > > Steven ###### From: Steven Derrien Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Thu, 02 Aug 2001 19:35:55 +0200 Organization: INRIA - RENNES Lines: 62 Message-ID: <3B698F7B.73A2211A@irisa.fr> References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> NNTP-Posting-Host: spyder.irisa.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.irisa.fr 996773754 30739 131.254.51.10 (2 Aug 2001 17:35:54 GMT) X-Complaints-To: usenet@irisa.fr NNTP-Posting-Date: 2 Aug 2001 17:35:54 GMT X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!fr.usenet-edu.net!usenet-edu.net!enst!univ-angers.fr!univ-rennes1.fr!irisa.fr!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8833 david garnett wrote: > > The BurchED Spartan board is only two layer, and has what seems to me is a > fairly poor power/ground layout - I would be much happier to see a real > ground 'plane' at least under the chip. Perhaps your problems are related - > things happen really fast inside something like a Spartan II and if your > decoupling is not perfect ... Is this also a strong issue when the system is clocked below 1MHz ? (sorry I have very little knowledge of PCB layout issues) Thank you, Steven > Dave > > [ In other respects I think that the board is useful and very good value for > money - but if I were laying it out I'd have a solid ground under the chip > proper, with all chip grounds connected directly to it, and then place > decoupling caps round the edge of the chip on the underside, preferably > connecting to a VCC power 'plane' directly under the ground 'plane', giving > very short decoupling track lengths.] > > Dave > > "Steven Derrien" wrote in message > news:3B697EF9.E5BDF155@irisa.fr... > > Hi, > > > > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) > > to a VHDL targeted to the BurchEd Spartan II board > > (http://www.burched.com) > > > > We plan to make our work freely available, but are currently stuck on > > a problem. The design is a 16 CPU-SOC which interfaced to a parallel > > port. > > > > We have somes on-chip blockrams which serves as ROM, and off-chip > > asynchronous > > SRAM whiwh serves as main memory. Our problem is that we get frequent > > errors when accessing the off-chip SRAM banks. Generally a single bit > > wrong in a 16 bit data word every 200-300 access. > > > > All simulation (RTL,gate-level,post place and route) went fine. > > Right now, our system is clocked at 1Mhz far below its maximum > > frequency. > > Besides, the SRAM Write Enable command output signal is registered > > (although not in a IOB register) to avoid glitches which could cause > > wrong write operations. > > > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > > config) > > > > We have been beating our heads on this problem for almost a week now, > > are there any experts around there to offer some tips/ideas/advices ? > > > > Thanks, > > > > Steven ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Thu, 02 Aug 2001 10:47:21 -0700 Organization: Xilinx Lines: 65 Message-ID: <3B699229.9B3577CD@xilinx.com> References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.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.7 (Macintosh; U; PPC) X-Accept-Language: en To: david garnett Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!news-lei1.dfn.de!newsfeed00.sul.t-online.de!t-online.de!colt.net!dispose.news.demon.net!demon!newsfeed.mathworks.com!cyclone.swbell.net!bos-service1.ext.raytheon.com!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8755 One suggestion ( for cases of blind desperation ) is to cool the FPGA ( and perhaps also the RAM) down , well below freezing. This makes the chips much faster, and might make the error occur more often, and thus more easy to analyze. Higher Vcc has the same effect. A very fast 'scope ( and scope probe ) might also show potential clock ringing, reflections, Vcc dips etc. "A 1 MHz clock does not a slow chip make" :-( Peter Alfke, Xilinx Applications ====================================== david garnett wrote: > The BurchED Spartan board is only two layer, and has what seems to me is a > fairly poor power/ground layout - I would be much happier to see a real > ground 'plane' at least under the chip. Perhaps your problems are related - > things happen really fast inside something like a Spartan II and if your > decoupling is not perfect ... > Dave > > [ In other respects I think that the board is useful and very good value for > money - but if I were laying it out I'd have a solid ground under the chip > proper, with all chip grounds connected directly to it, and then place > decoupling caps round the edge of the chip on the underside, preferably > connecting to a VCC power 'plane' directly under the ground 'plane', giving > very short decoupling track lengths.] > > Dave > > "Steven Derrien" wrote in message > news:3B697EF9.E5BDF155@irisa.fr... > > Hi, > > > > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) > > to a VHDL targeted to the BurchEd Spartan II board > > (http://www.burched.com) > > > > We plan to make our work freely available, but are currently stuck on > > a problem. The design is a 16 CPU-SOC which interfaced to a parallel > > port. > > > > We have somes on-chip blockrams which serves as ROM, and off-chip > > asynchronous > > SRAM whiwh serves as main memory. Our problem is that we get frequent > > errors when accessing the off-chip SRAM banks. Generally a single bit > > wrong in a 16 bit data word every 200-300 access. > > > > All simulation (RTL,gate-level,post place and route) went fine. > > Right now, our system is clocked at 1Mhz far below its maximum > > frequency. > > Besides, the SRAM Write Enable command output signal is registered > > (although not in a IOB register) to avoid glitches which could cause > > wrong write operations. > > > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > > config) > > > > We have been beating our heads on this problem for almost a week now, > > are there any experts around there to offer some tips/ideas/advices ? > > > > Thanks, > > > > Steven ###### From: "Andy Peters com"> X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 10 Message-ID: <7tga7.1193$B.110132@newsread1.prod.itd.earthlink.net> Date: Thu, 02 Aug 2001 17:54:11 GMT NNTP-Posting-Host: 24.221.131.16 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 996774851 24.221.131.16 (Thu, 02 Aug 2001 10:54:11 PDT) NNTP-Posting-Date: Thu, 02 Aug 2001 10:54:11 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Thu, 02 Aug 2001 10:51:42 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8775 david garnett wrote: > > The BurchED Spartan board is only two layer, That's good to know. If it were me, I'd do at least four layers - top and bottom for signal, middle two for VCC and GND. -andy ###### From: "Andy Peters com"> X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface References: <3B697EF9.E5BDF155@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 46 Message-ID: Date: Thu, 02 Aug 2001 18:05:30 GMT NNTP-Posting-Host: 24.221.131.16 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 996775530 24.221.131.16 (Thu, 02 Aug 2001 11:05:30 PDT) NNTP-Posting-Date: Thu, 02 Aug 2001 11:05:30 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Thu, 02 Aug 2001 11:03:00 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8772 Steven Derrien wrote: > We have somes on-chip blockrams which serves as ROM, and off-chip > asynchronous > SRAM whiwh serves as main memory. Our problem is that we get frequent > errors when accessing the off-chip SRAM banks. Generally a single bit > wrong in a 16 bit data word every 200-300 access. > > All simulation (RTL,gate-level,post place and route) went fine. > Right now, our system is clocked at 1Mhz far below its maximum > frequency. > Besides, the SRAM Write Enable command output signal is registered > (although not in a IOB register) to avoid glitches which could cause > wrong write operations. > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > config) > > We have been beating our heads on this problem for almost a week now, > are there any experts around there to offer some tips/ideas/advices ? In addition to registering the write enable, I'd register the SRAM data and address busses, too. Many years ago, as a "green" engineer, I was bitten by an extremely weird problem similar to yours: I was writing to a Xicor NovRAM from an 8051 via an Altera EPLD. The EPLD (among other things) had a mux that drove the RAM address lines (one source was the 8051, the other was "something else"). Initially, I did not register the address outputs, and the thing would not work -- corrupted data. Looking at it on a logic analyzer, and a fast digitizing 'scope, showed me that I was meeting setup requirements by a WEEK (well, you know what I mean). After about a week of flattening my forehead against various hard structural objects, I asked another engineer what I was doing wrong. The first question he asked: "Are your outputs synchronous?" The answer, of course, was no. He said, "Register the address outputs." I did so, and everything was hunky AND dory. I would also use the IOB registers. You'll get "highly-similar" clock-to-out times for all of your signals. Why aren't you putting the write enable register in an IOB? They're free, ya know. The other obvious thing is to make sure that you're meeting setup and hold requirements around the SRAM write enable. Check your simulation model. -andy ###### From: Steven Derrien Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Thu, 02 Aug 2001 20:22:09 +0200 Organization: INRIA - RENNES Lines: 65 Message-ID: <3B699A51.FA525484@irisa.fr> References: <3B697EF9.E5BDF155@irisa.fr> NNTP-Posting-Host: spyder.irisa.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.irisa.fr 996776528 1129 131.254.51.10 (2 Aug 2001 18:22:08 GMT) X-Complaints-To: usenet@irisa.fr NNTP-Posting-Date: 2 Aug 2001 18:22:08 GMT X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!isdnet!ciril.fr!univ-angers.fr!univ-rennes1.fr!irisa.fr!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8832 "Andy Peters > > Steven Derrien wrote: > > > We have somes on-chip blockrams which serves as ROM, and off-chip > > asynchronous > > SRAM whiwh serves as main memory. Our problem is that we get frequent > > errors when accessing the off-chip SRAM banks. Generally a single bit > > wrong in a 16 bit data word every 200-300 access. > > > > All simulation (RTL,gate-level,post place and route) went fine. > > Right now, our system is clocked at 1Mhz far below its maximum > > frequency. > > Besides, the SRAM Write Enable command output signal is registered > > (although not in a IOB register) to avoid glitches which could cause > > wrong write operations. > > > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > > config) > > > > We have been beating our heads on this problem for almost a week now, > > are there any experts around there to offer some tips/ideas/advices ? > > In addition to registering the write enable, I'd register the SRAM data > and address busses, too. Many years ago, as a "green" engineer, I was > bitten by an extremely weird problem similar to yours: I was writing to > a Xicor NovRAM from an 8051 via an Altera EPLD. The EPLD (among other > things) had a mux that drove the RAM address lines (one source was the > 8051, the other was "something else"). Initially, I did not register > the address outputs, and the thing would not work -- corrupted data. > Looking at it on a logic analyzer, and a fast digitizing 'scope, showed > me that I was meeting setup requirements by a WEEK (well, you know what > I mean). After about a week of flattening my forehead against various > hard structural objects, I asked another engineer what I was doing > wrong. The first question he asked: "Are your outputs synchronous?" > The answer, of course, was no. He said, "Register the address outputs." > I did so, and everything was hunky AND dory. I'll try to do that, thanks. > I would also use the IOB registers. You'll get "highly-similar" > clock-to-out times for all of your signals. > > Why aren't you putting the write enable register in an IOB? They're > free, ya know. yep, this is just because the register is in a inner edif module and apparently the map -b does not manage to put it it in the IOB, but that's to check again. > > The other obvious thing is to make sure that you're meeting setup and > hold requirements around the SRAM write enable. Check your simulation model. Setup and hold should be OK (WE is active for a clock cycle aka for 1000 ns) > > -andy Thanks again steven ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Thu, 02 Aug 2001 11:50:45 -0700 Organization: Xilinx Lines: 23 Message-ID: <3B69A104.B841C3A@xilinx.com> References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <3B698F7B.73A2211A@irisa.fr> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.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.7 (Macintosh; U; PPC) X-Accept-Language: en To: Steven Derrien Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8749 Steven Derrien wrote: > Is this also a strong issue when the system is clocked below 1MHz ? > (sorry I have very little knowledge of PCB layout issues) > Yes, unfortunately it is. Signal integrity problems are instigated by a signal edge, often a clock edge, and the time distance until the following edge is usually of no consequence. Therefore, signal integrity problems are as bad and devious at 1 MHz, as they are at 100 MHz. It's the inherent speed of the device that matters, not the clock rate of the application. This bites the designer of slow systems so badly, when he uses simple instruments, limited board-layout skills etc, but then inserts these very fast modern chips that can react to a 1-ns blip. A 250-MHz scope does not even show this blip... Peter Alfke, Xilinx Applications ###### Message-ID: <3B69A4EB.C6A1BCC2@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: Spartan II and asynchronous memory interface References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <3B698F7B.73A2211A@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 20 Date: Thu, 02 Aug 2001 19:05:54 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 996779154 24.13.238.93 (Thu, 02 Aug 2001 12:05:54 PDT) NNTP-Posting-Date: Thu, 02 Aug 2001 12:05:54 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8769 Yes. The problem is in the di/dt caused by very fast edges on the signals. You can help it out some be selecting the low slew rate drive and setting the output currents at the lowest possible values consistent with what you are driving. You can also intentionally skew outputs if you have a higher clock available to minimize the number of outputs changing at once. Steven Derrien wrote: > Is this also a strong issue when the system is clocked below 1MHz ? > (sorry I have very little knowledge of PCB layout issues) > -- -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 ###### Reply-To: "david garnett" From: "david garnett" Newsgroups: comp.arch.fpga References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <3B698F7B.73A2211A@irisa.fr> Subject: Re: Spartan II and asynchronous memory interface Date: Thu, 2 Aug 2001 20:27:03 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Lines: 36 Message-ID: <3b69aaf4$0$3761$cc9e4d1f@news.dial.pipex.com> NNTP-Posting-Host: userka97.uk.uudial.com X-Trace: 996780788 news.dial.pipex.com 3761 62.188.72.183 X-Complaints-To: abuse@uk.uu.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!news1.ebone.net!news.ebone.net!lnewspeer00.lnd.ops.eu.uu.net!lnewspost00.lnd.ops.eu.uu.net!emea.uu.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8811 "Steven Derrien" wrote in message news:3B698F7B.73A2211A@irisa.fr... > ground 'plane' at least under the chip. Perhaps your problems are related - > > things happen really fast inside something like a Spartan II and if your > > decoupling is not perfect ... > > Is this also a strong issue when the system is clocked below 1MHz ? > (sorry I have very little knowledge of PCB layout issues) Absolutely ! - what matters is that lots of things change state on the clock edge, and for these changes to take place currents must flow - possibly quite a lot of current, although for a very short time. If the ground/vcc connections present any significant impedance, then different parts of the chip will find themselves with different ground/vcc levels during the changes, and just about anything could happen ! Depending on what you are doing in the fpga, everything will settle in a few tens of nanoseconds - so, providing your clock is slow enough to let this happen plus a bit, the clock speed will not have a great effect - except to make the fault occur more often, which is often a help in tracking it down ! My experience is that, even with a very fast scope, it is very difficult to observe ground bounce type faults directly - you certainly see all sorts of bouncing and glitches, but they are often caused by probing problems ... > > > Thank you, > Steven > ###### From: "Shane Tow" Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Thu, 2 Aug 2001 15:32:13 -0400 Organization: Broadcom Corporation -- Irvine, California Lines: 17 Message-ID: <9kc9rt$6dn$1@sunset.broadcom.com> References: <3B697EF9.E5BDF155@irisa.fr> <3B699A51.FA525484@irisa.fr> NNTP-Posting-Host: dhcp-10-24-65-161.atlanta.broadcom.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!cleanfeed.casema.net!leda.casema.net!isdnet!howland.erols.net!newshub2.home.com!news.home.com!news.mindspring.net!ix.netcom.com!sunset.broadcom.com!usenet Xref: chonsp.franklin.ch comp.arch.fpga:8799 > Setup and hold should be OK (WE is active for a clock cycle aka for 1000 > ns) Registering the WE, Data Bus, and Address Bus is a very good idea. Also make sure that you send the Address Bus and Data Bus out to the SRAM at least one clock cycle before you assert the WE. Also, hold the Address Bus and Data Bus at least one clock cycle after clearing WE. You don't want to send the Address, Data, and WE on the same clock edge or clear them on the same clock edge. Good Luck, Shane ###### Message-ID: <3B69FE70.5C55BA90@iprimus.com.au> From: Russell Shaw X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <3B698F7B.73A2211A@irisa.fr> <3b69aaf4$0$3761$cc9e4d1f@news.dial.pipex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: 202.138.29.166 X-Original-Trace: 3 Aug 2001 11:30:45 +1000, 202.138.29.166 Lines: 35 Date: Fri, 03 Aug 2001 11:29:20 +1000 NNTP-Posting-Host: 203.134.67.67 X-Trace: news0.optus.net.au 996802147 203.134.67.67 (Fri, 03 Aug 2001 11:29:07 EST) NNTP-Posting-Date: Fri, 03 Aug 2001 11:29:07 EST Organization: CWO Customer - reports relating to abuse should be sent to abuse@cwo.net.au Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!news0.optus.net.au!news.iprimus.com.au Xref: chonsp.franklin.ch comp.arch.fpga:8782 david garnett wrote: > > "Steven Derrien" wrote in message > news:3B698F7B.73A2211A@irisa.fr... > > > ground 'plane' at least under the chip. Perhaps your problems are > related - > > > things happen really fast inside something like a Spartan II and if your > > > decoupling is not perfect ... > > > > Is this also a strong issue when the system is clocked below 1MHz ? > > (sorry I have very little knowledge of PCB layout issues) > > Absolutely ! - what matters is that lots of things change state on the clock > edge, and for these changes to take place currents must flow - possibly > quite a lot of current, although for a very short time. If the ground/vcc > connections present any significant impedance, then different parts of the > chip will find themselves with different ground/vcc levels during the > changes, and just about anything could happen ! > > Depending on what you are doing in the fpga, everything will settle in a few > tens of nanoseconds - so, providing your clock is slow enough to let this > happen plus a bit, the clock speed will not have a great effect - except to > make the fault occur more often, which is often a help in tracking it down ! > > My experience is that, even with a very fast scope, it is very difficult to > observe ground bounce type faults directly - you certainly see all sorts of > bouncing and glitches, but they are often caused by probing problems ... It would be interesting to know what the inductance is of the chip bond wires. That way, the layout person could determine how long they could leave pwr/gnd tracks without much effect relative to the bond-wires. ###### From: Steven Derrien Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Fri, 03 Aug 2001 10:07:50 +0200 Organization: INRIA - RENNES Lines: 35 Message-ID: <3B6A5BD6.C5208CDE@irisa.fr> References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <3B698F7B.73A2211A@irisa.fr> <3B69A4EB.C6A1BCC2@andraka.com> NNTP-Posting-Host: spyder.irisa.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.irisa.fr 996826070 21054 131.254.51.10 (3 Aug 2001 08:07:50 GMT) X-Complaints-To: usenet@irisa.fr NNTP-Posting-Date: 3 Aug 2001 08:07:50 GMT X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!fr.usenet-edu.net!usenet-edu.net!enst!univ-angers.fr!univ-rennes1.fr!irisa.fr!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8840 Ray Andraka wrote: > > Yes. The problem is in the di/dt caused by very fast edges on the signals. You > can help it out some be selecting the low slew rate drive and setting the output > currents at the lowest possible values consistent with what you are driving. You > can also intentionally skew outputs if you have a higher clock available to > minimize the number of outputs changing at once. Isn't it possible to add some kind of passive low-pass filter to copensate for these fast edges ? And BTW, would you have some reference about suche PCB issues (a book for example). Thank you for your help. Steven > > Steven Derrien wrote: > > > Is this also a strong issue when the system is clocked below 1MHz ? > > (sorry I have very little knowledge of PCB layout issues) > > > > -- > -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 ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Fri, 3 Aug 2001 09:32:28 +0100 Message-ID: <996837651.23299.0.nnrp-08.9e9832fa@news.demon.co.uk> References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <3B698F7B.73A2211A@irisa.fr> <3B69A4EB.C6A1BCC2@andraka.com> <3B6A5BD6.C5208CDE@irisa.fr> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 996837651 nnrp-08:23299 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Lines: 31 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!news1.ebone.net!news.ebone.net!easynet-monga!easynet.net!dispose.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8826 "Steven Derrien" wrote in message news:3B6A5BD6.C5208CDE@irisa.fr... > > > Ray Andraka wrote: > > > > Yes. The problem is in the di/dt caused by very fast edges on the signals. You > > can help it out some be selecting the low slew rate drive and setting the output > > currents at the lowest possible values consistent with what you are driving. You > > can also intentionally skew outputs if you have a higher clock available to > > minimize the number of outputs changing at once. > > Isn't it possible to add some kind of passive low-pass filter to > copensate for these > fast edges ? > > And BTW, would you have some reference about suche PCB issues (a book > for example). > The standard text is Johnson and Graham's 'High-Speed Digital Design'. There is also a new text, whose title escapes me at the moment. ###### From: Steven Derrien Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Fri, 03 Aug 2001 11:11:08 +0200 Organization: INRIA - RENNES Lines: 40 Message-ID: <3B6A6AAC.42386279@irisa.fr> References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <7tga7.1193$B.110132@newsread1.prod.itd.earthlink.net> NNTP-Posting-Host: spyder.irisa.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.irisa.fr 996829868 25015 131.254.51.10 (3 Aug 2001 09:11:08 GMT) X-Complaints-To: usenet@irisa.fr NNTP-Posting-Date: 3 Aug 2001 09:11:08 GMT X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!fr.usenet-edu.net!usenet-edu.net!ciril.fr!univ-angers.fr!univ-rennes1.fr!irisa.fr!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8834 "Andy Peters > > david garnett wrote: > > > > The BurchED Spartan board is only two layer, > > That's good to know. > > If it were me, I'd do at least four layers - top and bottom for signal, > middle two for VCC and GND. BTW, just to get an idea, let's say I m an inexperienced PCB designer and that I want to have my own PCB board for a specific app. (let's say a 4 layers board with a SPII-pq208, SRAM, and and ethernet controller + transceiver) i'd need around 100 sample of them (so it's very low volume) 1) I could can ask for PCB designer services, to design the layout and handle the production but then it's likely to be expensive (price range ?) 2) I can do the layout on my own using for ex Orcad, since i am inexperienced do I have a chance to succeed (I mean to get a working board) and if so how long will it take ? and in such a case how much it would cost ? Thanks, steven app an > > -andy ###### From: martin.j.thompson@trw.com Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: 03 Aug 2001 10:22:16 +0100 Lines: 27 Sender: Thompsm@977845-DT Message-ID: References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <3B698F7B.73A2211A@irisa.fr> <3B69A4EB.C6A1BCC2@andraka.com> <3B6A5BD6.C5208CDE@irisa.fr> NNTP-Posting-Host: 194.74.228.16 X-Trace: fu-berlin.de 996830523 4249251 194.74.228.16 (16 [98603]) X-Newsreader: Gnus v5.7/Emacs 20.6 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!uni-berlin.de!194.74.228.16!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8747 Steven Derrien writes: > And BTW, would you have some reference about suche PCB issues (a book > for example). > You could have a look at some of the docs written by Doug Brooks at http://www.ultracad.com/articles.htm There is also a signal integrity forum on freelists.org... and many more useful documents scattered around the web. > Thank you for your help. > Not at all! Cheers, Martin > Steven > > > > Steven Derrien wrote: > > > > > Is this also a strong issue when the system is clocked below 1MHz > > >? (sorry I have very little knowledge of PCB layout issues) > > > ###### From: "Martin Schoeberl" Newsgroups: comp.arch.fpga References: <3B697EF9.E5BDF155@irisa.fr> Subject: Re: Spartan II and asynchronous memory interface Lines: 54 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Fri, 03 Aug 2001 12:12:37 GMT NNTP-Posting-Host: 213.47.18.244 X-Complaints-To: abuse@news.chello.at X-Trace: news.chello.at 996840757 213.47.18.244 (Fri, 03 Aug 2001 14:12:37 MET DST) NNTP-Posting-Date: Fri, 03 Aug 2001 14:12:37 MET DST Organization: Customers chello Austria Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeed.germany.net!newsrouter.chello.at!news.chello.at!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8792 Hi Steven, I had a simmilar problem with my own board (for Altera ACEX) also with bad ground (because of saving money for two layer... the wrong decision). I connected the printer port (long cable) to communicate via ECP with a PC and got wrong data when to many bits switched. I think this led to a 'ground bounce'. One dirty solution (for me) was: Becaus I worked with a clock at 24 MHz and ECP is below 1 MHz I switched the data lines one after the other. If your clock is higher than the access time of the RAM you could try to split the switching outputs. Martin -- Whant to see the evolution of a Java processor? http://www.jopdesign.com "Steven Derrien" schrieb im Newsbeitrag news:3B697EF9.E5BDF155@irisa.fr... > Hi, > > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) > to a VHDL targeted to the BurchEd Spartan II board > (http://www.burched.com) > > We plan to make our work freely available, but are currently stuck on > a problem. The design is a 16 CPU-SOC which interfaced to a parallel > port. > > We have somes on-chip blockrams which serves as ROM, and off-chip > asynchronous > SRAM whiwh serves as main memory. Our problem is that we get frequent > errors when accessing the off-chip SRAM banks. Generally a single bit > wrong in a 16 bit data word every 200-300 access. > > All simulation (RTL,gate-level,post place and route) went fine. > Right now, our system is clocked at 1Mhz far below its maximum > frequency. > Besides, the SRAM Write Enable command output signal is registered > (although not in a IOB register) to avoid glitches which could cause > wrong write operations. > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > config) > > We have been beating our heads on this problem for almost a week now, > are there any experts around there to offer some tips/ideas/advices ? > > Thanks, > > Steven ###### Message-ID: <3B6AA313.9CB922B1@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: Spartan II and asynchronous memory interface References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <7tga7.1193$B.110132@newsread1.prod.itd.earthlink.net> <3B6A6AAC.42386279@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 54 Date: Fri, 03 Aug 2001 13:10:17 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 996844217 24.13.238.93 (Fri, 03 Aug 2001 06:10:17 PDT) NNTP-Posting-Date: Fri, 03 Aug 2001 06:10:17 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!enews.sgi.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8762 You'll need to use a layout program with an output format that is acceptable to the shop doing the board fab. Pads is one that seems to be fairly common. You'll wind up spending more for the software than you would have for contracting the board layout out to one of the design houses. The layout cost is roughly proportional to the number of pins. A few years ago, I was paying about $1 per pin for layout. I suspect this has gone up some in the mean time, and the price will vary from shop to shop. Steven Derrien wrote: > "Andy Peters > > > > david garnett wrote: > > > > > > The BurchED Spartan board is only two layer, > > > > That's good to know. > > > > If it were me, I'd do at least four layers - top and bottom for signal, > > middle two for VCC and GND. > > BTW, just to get an idea, let's say I m an inexperienced PCB designer > and > that I want to have my own PCB board for a specific app. (let's say a 4 > layers board with a SPII-pq208, SRAM, and and ethernet controller + > transceiver) i'd need around 100 sample of them (so it's very low > volume) > > 1) I could can ask for PCB designer services, to design the layout and > handle the production but then it's likely to be expensive (price range > ?) > > 2) I can do the layout on my own using for ex Orcad, since i am > inexperienced > do I have a chance to succeed (I mean to get a working board) and if so > how > long will it take ? and in such a case how much it would cost ? > > Thanks, > > steven > > app an > > > > -andy -- -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 ###### From: Steven Derrien Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Fri, 03 Aug 2001 16:39:08 +0200 Organization: INRIA - RENNES Lines: 73 Message-ID: <3B6AB78C.E31AEBA@irisa.fr> References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <7tga7.1193$B.110132@newsread1.prod.itd.earthlink.net> <3B6A6AAC.42386279@irisa.fr> <3B6AA313.9CB922B1@andraka.com> NNTP-Posting-Host: spyder.irisa.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.irisa.fr 996849547 13486 131.254.51.10 (3 Aug 2001 14:39:07 GMT) X-Complaints-To: usenet@irisa.fr NNTP-Posting-Date: 3 Aug 2001 14:39:07 GMT X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!fr.usenet-edu.net!usenet-edu.net!enst!univ-angers.fr!univ-rennes1.fr!irisa.fr!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8835 Ray Andraka wrote: > > You'll need to use a layout program with an output format that is acceptable > to the shop doing the board fab. Pads is one that seems to be fairly > common. You'll wind up spending more for the software than you would have > for contracting the board layout out to one of the design houses. What do they take as input data : board level schematic I guess, do they also handle all additionnal stuff like adding all the decoupling capacitors and line termination when required or is it the customer ? > The layout cost is roughly proportional to the number of pins. A few years ago, I was > paying about $1 per pin for layout. I suspect this has gone up some in the > mean time, and the price will vary from shop to shop. Do you mean $1 per pin for the layout design (seems pretty cheap to me) ? Wait a minute let's say I have may SPII with 128kx16 plus 100 pin this makes less than 1000$ which remains very affordable. (Am i wrong ?) Thanks again, Steven > > Steven Derrien wrote: > > > "Andy Peters > > > > > > david garnett wrote: > > > > > > > > The BurchED Spartan board is only two layer, > > > > > > That's good to know. > > > > > > If it were me, I'd do at least four layers - top and bottom for signal, > > > middle two for VCC and GND. > > > > BTW, just to get an idea, let's say I m an inexperienced PCB designer > > and > > that I want to have my own PCB board for a specific app. (let's say a 4 > > layers board with a SPII-pq208, SRAM, and and ethernet controller + > > transceiver) i'd need around 100 sample of them (so it's very low > > volume) > > > > 1) I could can ask for PCB designer services, to design the layout and > > handle the production but then it's likely to be expensive (price range > > ?) > > > > 2) I can do the layout on my own using for ex Orcad, since i am > > inexperienced > > do I have a chance to succeed (I mean to get a working board) and if so > > how > > long will it take ? and in such a case how much it would cost ? > > > > Thanks, > > > > steven > > > > app an > > > > > > -andy > > -- > -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 ###### Message-ID: <3B6AE47D.18B81D6F@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: Spartan II and asynchronous memory interface References: <3B697EF9.E5BDF155@irisa.fr> <3b698a69$0$3763$cc9e4d1f@news.dial.pipex.com> <7tga7.1193$B.110132@newsread1.prod.itd.earthlink.net> <3B6A6AAC.42386279@irisa.fr> <3B6AA313.9CB922B1@andraka.com> <3B6AB78C.E31AEBA@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 106 Date: Fri, 03 Aug 2001 17:49:21 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 996860961 24.13.238.93 (Fri, 03 Aug 2001 10:49:21 PDT) NNTP-Posting-Date: Fri, 03 Aug 2001 10:49:21 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.stealth.net!gestalt.direcpc.com!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8767 The input is generally a text netlist. You'll have to confer with the vendor for the exact format. Most schematic editors have an option of exporting netlists in various formats. At least one of those can be imported by the layout tools. You are responsible for putting your decoupling caps, terminators etc in your design. For decoupling caps, the layout guy can obviously move them around the board, so you also generally have to supply a set of guidelines for the layout. Generally I give them rules for decoupling caps, a mechanical drawing of the board showing size, keep-out areas, height restricted areas, connector and switch locations etc and a board stack up showing the order of layers if it is multi-layer. You probably also have a feel for how things would get situated on the board, so you can give him a "suggested starting point" for the layout. You will also want to give him any manufacturing rules that need to be followed to keep the cost of populating the board down. Depending on the assembly shop, this might be restrictions as to what if anything can go on the back side, orientation of parts, additional keep-out rules, via restrictions, tooling hole requirements etc. You'll be expected to approve a preliminary layout before the board is routed, and to approve the gerber plots before the final artwork is generated. A good layout guy will already know what makes a board more manufacturable and will tell you if you want something that is a PITA. The number of pins means pins on _everything_. Decoupling caps each have 2 pins, each device has a number of pins. Connectors, switches etc all have pins. Still, at the prices I last used it worked out to about $1 a pin. $1000 is probably in the ballpark, although the $1 per pin number is a couple of years old. Steven Derrien wrote: > Ray Andraka wrote: > > > > You'll need to use a layout program with an output format that is acceptable > > to the shop doing the board fab. Pads is one that seems to be fairly > > common. You'll wind up spending more for the software than you would have > > for contracting the board layout out to one of the design houses. > > What do they take as input data : board level schematic I guess, do they > also handle all additionnal stuff like adding all the decoupling > capacitors > and line termination when required or is it the customer ? > > > The layout cost is roughly proportional to the number of pins. A few years ago, I was > > paying about $1 per pin for layout. I suspect this has gone up some in the > > mean time, and the price will vary from shop to shop. > > Do you mean $1 per pin for the layout design (seems pretty cheap to me) > ? > Wait a minute let's say I have may SPII with 128kx16 plus 100 pin this > makes > less than 1000$ which remains very affordable. (Am i wrong ?) > > Thanks again, > > Steven > > > > > Steven Derrien wrote: > > > > > "Andy Peters > > > > > > > > david garnett wrote: > > > > > > > > > > The BurchED Spartan board is only two layer, > > > > > > > > That's good to know. > > > > > > > > If it were me, I'd do at least four layers - top and bottom for signal, > > > > middle two for VCC and GND. > > > > > > BTW, just to get an idea, let's say I m an inexperienced PCB designer > > > and > > > that I want to have my own PCB board for a specific app. (let's say a 4 > > > layers board with a SPII-pq208, SRAM, and and ethernet controller + > > > transceiver) i'd need around 100 sample of them (so it's very low > > > volume) > > > > > > 1) I could can ask for PCB designer services, to design the layout and > > > handle the production but then it's likely to be expensive (price range > > > ?) > > > > > > 2) I can do the layout on my own using for ex Orcad, since i am > > > inexperienced > > > do I have a chance to succeed (I mean to get a working board) and if so > > > how > > > long will it take ? and in such a case how much it would cost ? > > > > > > Thanks, > > > > > > steven > > > > > > app an > > > > > > > > -andy > > > > -- > > -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 -- -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 ###### Reply-To: "Rob Finch" From: "Rob Finch" Newsgroups: comp.arch.fpga References: <3B697EF9.E5BDF155@irisa.fr> Subject: Re: Spartan II and asynchronous memory interface Lines: 47 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <_Oib7.1949$5c.133840@news20.bellglobal.com> Date: Sun, 5 Aug 2001 16:55:44 -0400 NNTP-Posting-Host: 65.92.35.208 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 997046586 65.92.35.208 (Sun, 05 Aug 2001 17:23:06 EDT) NNTP-Posting-Date: Sun, 05 Aug 2001 17:23:06 EDT Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!newsfeed.rt.ru!news.rosnet.ru!newsfeed.sovam.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8943 I know this is a really dumb question but, is the sram module connected to a pair of module ports that will work with the sram ? Several of the ports will 'almost' work except they have an input only signal on one of the pins. Which I believe ends up being connected to the OE of the ram. Are you using the constraints editor to set the pin locations ? I am using a B3 Spartan2+ board and the only port the sram module can be connected to is the J6, J9 pair. Also I have written a little test hardware that tests the ram using a checkerboard pattern, and it's not found any errors. I could mail it to you if you're interested. I've only tested at 8MHz so far, but as other posts point out, it's not necessarily the clock frequency that causes a problem. "Steven Derrien" wrote in message news:3B697EF9.E5BDF155@irisa.fr... > Hi, > > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) > to a VHDL targeted to the BurchEd Spartan II board > (http://www.burched.com) > > We plan to make our work freely available, but are currently stuck on > a problem. The design is a 16 CPU-SOC which interfaced to a parallel > port. > > We have somes on-chip blockrams which serves as ROM, and off-chip > asynchronous > SRAM whiwh serves as main memory. Our problem is that we get frequent > errors when accessing the off-chip SRAM banks. Generally a single bit > wrong in a 16 bit data word every 200-300 access. > > All simulation (RTL,gate-level,post place and route) went fine. > Right now, our system is clocked at 1Mhz far below its maximum > frequency. > Besides, the SRAM Write Enable command output signal is registered > (although not in a IOB register) to avoid glitches which could cause > wrong write operations. > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > config) > > We have been beating our heads on this problem for almost a week now, > are there any experts around there to offer some tips/ideas/advices ? > > Thanks, > > Steven ###### From: Steven Derrien Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Mon, 06 Aug 2001 11:06:19 +0200 Organization: INRIA - RENNES Lines: 62 Message-ID: <3B6E5E0B.82EE990D@irisa.fr> References: <3B697EF9.E5BDF155@irisa.fr> <_Oib7.1949$5c.133840@news20.bellglobal.com> NNTP-Posting-Host: spyder.irisa.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.irisa.fr 997088779 4294 131.254.51.10 (6 Aug 2001 09:06:19 GMT) X-Complaints-To: usenet@irisa.fr NNTP-Posting-Date: 6 Aug 2001 09:06:19 GMT X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!opentransit.net!jussieu.fr!univ-lille1.fr!news!univ-rennes1.fr!irisa.fr!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8987 Rob Finch wrote: > > I know this is a really dumb question but, is the sram module connected to a > pair of module ports that will work with the sram ? Several of the ports > will 'almost' work except they have an input only signal on one of the pins. > Which I believe ends up being connected to the OE of the ram. Are you using > the constraints editor to set the pin locations ? I am using a B3 Spartan2+ > board and the only port the sram module can be connected to is the J6, J9 > pair. We just checked, abnd the module is connected to J6 and J9. > Also I have written a little test hardware that tests the ram using a > checkerboard pattern, and it's not found any errors. I could mail it to you > if you're interested. Yes, please that would help us a lot !! > I've only tested at 8MHz so far, but as other posts > point out, it's not necessarily the clock frequency that causes a problem. We'll perform additional check to see if it works at higher frequencies. Steven > > "Steven Derrien" wrote in message > news:3B697EF9.E5BDF155@irisa.fr... > > Hi, > > > > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) > > to a VHDL targeted to the BurchEd Spartan II board > > (http://www.burched.com) > > > > We plan to make our work freely available, but are currently stuck on > > a problem. The design is a 16 CPU-SOC which interfaced to a parallel > > port. > > > > We have somes on-chip blockrams which serves as ROM, and off-chip > > asynchronous > > SRAM whiwh serves as main memory. Our problem is that we get frequent > > errors when accessing the off-chip SRAM banks. Generally a single bit > > wrong in a 16 bit data word every 200-300 access. > > > > All simulation (RTL,gate-level,post place and route) went fine. > > Right now, our system is clocked at 1Mhz far below its maximum > > frequency. > > Besides, the SRAM Write Enable command output signal is registered > > (although not in a IOB register) to avoid glitches which could cause > > wrong write operations. > > > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > > config) > > > > We have been beating our heads on this problem for almost a week now, > > are there any experts around there to offer some tips/ideas/advices ? > > > > Thanks, > > > > Steven ###### From: Steven Derrien Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Tue, 07 Aug 2001 14:53:50 +0200 Organization: INRIA - RENNES Lines: 34 Message-ID: <3B6FE4DE.3BAB7CE8@irisa.fr> References: <3B697EF9.E5BDF155@irisa.fr> NNTP-Posting-Host: spyder.irisa.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.irisa.fr 997188830 13753 131.254.51.10 (7 Aug 2001 12:53:50 GMT) X-Complaints-To: usenet@irisa.fr NNTP-Posting-Date: 7 Aug 2001 12:53:50 GMT X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!opentransit.net!jussieu.fr!univ-angers.fr!univ-rennes1.fr!irisa.fr!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8988 Hi, After extending the write cycle operation to keep address and data stable when the WE signal gos intactive, the design finally works OK at 9MHz, above, we get 100% which makes me think it a timing problem rather than a PCB layout issue. Steven Steven Derrien wrote: > > Hi, > > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) > to a VHDL targeted to the BurchEd Spartan II board > (http://www.burched.com) > > We plan to make our work freely available, but are currently stuck on > a problem. The design is a 16 CPU-SOC which interfaced to a parallel > port. > > We have somes on-chip blockrams which serves as ROM, and off-chip > asynchronous > SRAM whiwh serves as main memory. Our problem is that we get frequent > errors when accessing the off-chip SRAM banks. Generally a single bit > wrong in a 16 bit data word every 200-300 access. > > All simulation (RTL,gate-level,post place and route) went fine. > Right now, our system is clocked at 1Mhz far below its maximum > frequency. > Besides, the SRAM Write Enable command output signal is registered > (although not in a IOB register) to avoid glitches which could cause > wrong write operations. > ###### From: "Jan Gray" Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Tue, 7 Aug 2001 07:35:04 -0700 Organization: Gray Research LLC Lines: 166 Message-ID: <9kouj2$shp$1@slb6.atl.mindspring.net> References: <3B697EF9.E5BDF155@irisa.fr> <3B6FE4DE.3BAB7CE8@irisa.fr> NNTP-Posting-Host: 04.21.a0.48 X-Server-Date: 7 Aug 2001 14:39:30 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!howland.erols.net!portc.blue.aol.com.MISMATCH!portc01.blue.aol.com!news.gtei.net.MISMATCH!washdc3-snh1.gtei.net!news.gtei.net!news.mindspring.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8946 "Steven Derrien" wrote in message news:3B6FE4DE.3BAB7CE8@irisa.fr... > After extending the write cycle operation to keep address and > data stable when the WE signal gos intactive, the design finally > works OK at 9MHz, above, we get 100% which makes me think it a timing > problem rather than a PCB layout issue. [Copied to fpga-cpu@yahoogroups.com] You certainly must hold address and data stable while WE/ is deasserted! Here's some background on how XSOC does this, and on the XSOC async SRAM controller in general :- In the original XSOC/xr16 project (www.fpgacpu.org/xsoc/), as described in the article series (www.fpgacpu/xsoc/cc.html and www.fpgacpu.org/papers/xsoc-series-drafts.pdf), we introduce a little complexity in order to run the processor at 1X the XESS XS40 proto board clock rather than 1/2X. The early XESS XS40s (up to and including version 1.2) had a fixed oscillator at 12 MHz. (Newer revisions have a programmable oscillator, up to 100 MHz. More on this below.) One goal was to run the processor at 12 MHz rather than 6 MHz. However, the CPU needs a new 16-bit instruction (two bytes) every cycle, and the XS40 had only a single byte-wide async SRAM. And another goal was to correctly run XSOC/xr16 with a slow (1 Hz) or stopped clock. Therefore, on read cycles, it reads two bytes per cycle. The design synchronously clocks A[N:1] in IOB FFs, but derives A[0] from CLK, and latches D[7:0] in on both rising and falling CLK edges. On write cycles, the design is optimized but still conservative, deriving all write control signal transitions from clock *edges*. A byte write takes 3 clock edges, (2 cycles), and a (two-byte) word write requires 6 edges (3 cycles). With async SRAMs, if you carefully read the data sheets, it is imperative that each write 1. asserts address (and perhaps data), waits (for address to settle) 2. asserts /WE and data, waits (for data to settle) 3. deasserts /WE, while holding address and data asserted and stable As previously discusssed here (see http://www.fpga-faq.com/archives/threads_1998_04.html#10076), successfully doing a write in two clock edges is fraught with races and perils. And for the really curious, I have attached an old discussion of this issue, to the end of this message. The memory controller, briefly described in part three of the XSOC articles (see the timing diagram on p.19 and the schematic on p. 24, of www.fpgacpu.org/papers/xsoc-series-drafts.pdf), does this while deriving A[0], /WE, and /OE, with care to be guaranteed glitch-free, from state-machine clocked both on rising and falling edges of CLK. Article #3: "It follows that we need one-half clock to settle the write address, one-half clock to assert /WE, and one-half clock to deassert it." It is easy to see how this detail might have been lost in a rewrite. Now then, later XS40 boards (ver 1.3 and later) have programmable oscillators, and it is now possible to run the clock up at approximately the read latency of the async SRAM. For example, run the clock at 33 MHz, reading a byte every 30 ns, and insert a pipeline stall (wait state) on each 16-bit instruction fetch, effectively running the processor (out of byte-wide external RAM) at 16.7 MHz. To that end, and to add 32-bit long word read/write support, I redesigned MEMCTRL to be a simpler state machine, and now all A[], particularly A[1:0], are clocked on CLK rising edge IOB FFs, although I still use a small pos + neg edge clocked state machine to generate /WE. In this design, byte writes still take three edges (two cycles) and word writes six edges (now four cycles), (and longword writes, eight). [[Otherwise, in a strictly positive edge clocked state machine, byte writes would take three clocks, and word writes six, (and longword writes, 12).]] Sorry, this MEMCTRL revision has not been released. Jan Gray, Gray Research LLC [Disclaimer: these are my opinions -- do you own due diligence.] ------------------------------ Attachment: early XSOC async SRAM write design discussion (view with fixed-pitch font for best results). -----Original Message----- From: JG Sent: Sunday, January 03, 1999 11:34 PM Subject: RE: writing to static RAM > [Someone relates their negative experiences of writing to async SRAM using two clock edges.] Thanks for your comments. I agree. I have reviewed the data sheets of about six different async SRAMs and they all say the same things: 1. address must be valid before WE/ or CE/ is asserted (I'll just say WE/ throughout). 2. data must be valid a certain setup-time before WE/ is deasserted. 3. 0-ns hold times on addr and data after WE/ is deasserted. 4. WE/ must be deasserted for a minimum of 0 ns, but it must be deasserted. Considering my constraints, e.g. 5. address is not available until store instruction's EX stage ENDS. 6. must achieve a fully synchronous, static-ready design. 7. unwilling to do any async delay element tricks, like funny routings of clocks or enables in order to delay WE/ relative to valid addr or to advance deasserting WE/ relative to deasserting valid addr/data. 8. constrained by existing board -- e.g. might be nice if CE/ was driven by external CLK/ but it's not. I see little choice but do a straightforward simple design, e.g. 3 half-cycles to write a byte: 1. assert address, data-in, deassert OE/ 2. assert WE/ for one-half cycle 3. continue to assert address, data-in, deassert OE/ Thus a byte store will require three cycles and a word store will require four. External SRAM word store: Cycle EX(sw) W1 W2 W3 EX' CLK ----____----____----____----____----____ CE/ ________________________________________ A[14:1] A0 ____----____________------------____---- D[7:0] DT ------------____________________-------- OE/ ________------------------------________ WE/ ------------____--------____------------ Notes: 1. The PC and PC' bus transactions are instruction fetches. 2. DT is the external SRAM data-out pins' active-low output enable. DT is held asserted until half-way through W1 to minimize bus contention between the SRAM outputs turning off and the FPGA data outputs turning on. I'd similarly like to deassert DT half-way through W3 but can't because it could deassert data-out before the RAM captures it on the deassertion of WE/. External SRAM byte store: Cycle EX(sb) W1 W2 EX' CLK ----____----____----____----____ CE/ ________________________________ A[14:1] A0 ____----<==============>____---- D[7:0] DT ------------________------------ OE/ ________----------------________ WE/ ------------____---------------- Notes: 1. In this case we do deassert DT half-way through W2 so the data bus is 3-stated for 1/2 cycle and there is no possible bus contention as W2 ends/EX' begins. That's the plan! Jan. ###### From: "Jan Gray" Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Tue, 7 Aug 2001 07:35:33 -0700 Organization: Gray Research LLC Lines: 168 Message-ID: <9koumi$9om$1@slb6.atl.mindspring.net> References: <3B697EF9.E5BDF155@irisa.fr> <3B6FE4DE.3BAB7CE8@irisa.fr> NNTP-Posting-Host: 04.21.a0.48 X-Server-Date: 7 Aug 2001 14:41:22 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!4538!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8947 "Steven Derrien" wrote in message news:3B6FE4DE.3BAB7CE8@irisa.fr... > After extending the write cycle operation to keep address and > data stable when the WE signal gos intactive, the design finally > works OK at 9MHz, above, we get 100% which makes me think it a timing > problem rather than a PCB layout issue. [Copied to fpga-cpu@yahoogroups.com] You certainly must hold address and data stable while WE/ is deasserted! Here's some background on how XSOC does this, and on the XSOC async SRAM controller in general :- In the original XSOC/xr16 project (www.fpgacpu.org/xsoc/), as described in the article series (www.fpgacpu/xsoc/cc.html and www.fpgacpu.org/papers/xsoc-series-drafts.pdf), we introduce a little complexity in order to run the processor at 1X the XESS XS40 proto board clock rather than 1/2X. The early XESS XS40s (up to and including version 1.2) had a fixed oscillator at 12 MHz. (Newer revisions have a programmable oscillator, up to 100 MHz. More on this below.) One goal was to run the processor at 12 MHz rather than 6 MHz. However, the CPU needs a new 16-bit instruction (two bytes) every cycle, and the XS40 had only a single byte-wide async SRAM. And another goal was to correctly run XSOC/xr16 with a slow (1 Hz) or stopped clock. Therefore, on read cycles, it reads two bytes per cycle. The design synchronously clocks A[N:1] in IOB FFs, but derives A[0] from CLK, and latches D[7:0] in on both rising and falling CLK edges. On write cycles, the design is optimized but still conservative, deriving all write control signal transitions from clock *edges*. A byte write takes 3 clock edges, (2 cycles), and a (two-byte) word write requires 6 edges (3 cycles). With async SRAMs, if you carefully read the data sheets, it is imperative that each write 1. asserts address (and perhaps data), waits (for address to settle) 2. asserts /WE and data, waits (for data to settle) 3. deasserts /WE, while holding address and data asserted and stable As previously discusssed here (see http://www.fpga-faq.com/archives/threads_1998_04.html#10076), successfully doing a write in two clock edges is fraught with races and perils. And for the really curious, I have attached an old discussion of this issue, to the end of this message. The memory controller, briefly described in part three of the XSOC articles (see the timing diagram on p.19 and the schematic on p. 24, of www.fpgacpu.org/papers/xsoc-series-drafts.pdf), does this while deriving A[0], /WE, and /OE, with care to be guaranteed glitch-free, from state-machine clocked both on rising and falling edges of CLK. Article #3: "It follows that we need one-half clock to settle the write address, one-half clock to assert /WE, and one-half clock to deassert it." It is easy to see how this detail might have been lost in a rewrite. Now then, later XS40 boards (ver 1.3 and later) have programmable oscillators, and it is now possible to run the clock up at approximately the read latency of the async SRAM. For example, run the clock at 33 MHz, reading a byte every 30 ns, and insert a pipeline stall (wait state) on each 16-bit instruction fetch, effectively running the processor (out of byte-wide external RAM) at 16.7 MHz. To that end, and to add 32-bit long word read/write support, I redesigned MEMCTRL to be a simpler state machine, and now all A[], particularly A[1:0], are clocked on CLK rising edge IOB FFs, although I still use a small pos + neg edge clocked state machine to generate /WE. In this design, byte writes still take three edges (two cycles) and word writes six edges (now four cycles), (and longword writes, eight). [[Otherwise, in a strictly positive edge clocked state machine, byte writes would take three clocks, and word writes six, (and longword writes, 12).]] Sorry, this MEMCTRL revision has not been released. Jan Gray, Gray Research LLC [Disclaimer: these are my opinions -- do you own due diligence.] ------------------------------ Attachment: early XSOC async SRAM write design discussion (view with fixed-pitch font for best results). -----Original Message----- From: JG Sent: Sunday, January 03, 1999 11:34 PM Subject: RE: writing to static RAM > [Someone relates their negative experiences of writing to async SRAM using two clock edges.] Thanks for your comments. I agree. I have reviewed the data sheets of about six different async SRAMs and they all say the same things: 1. address must be valid before WE/ or CE/ is asserted (I'll just say WE/ throughout). 2. data must be valid a certain setup-time before WE/ is deasserted. 3. 0-ns hold times on addr and data after WE/ is deasserted. 4. WE/ must be deasserted for a minimum of 0 ns, but it must be deasserted. Considering my constraints, e.g. 5. address is not available until store instruction's EX stage ENDS. 6. must achieve a fully synchronous, static-ready design. 7. unwilling to do any async delay element tricks, like funny routings of clocks or enables in order to delay WE/ relative to valid addr or to advance deasserting WE/ relative to deasserting valid addr/data. 8. constrained by existing board -- e.g. might be nice if CE/ was driven by external CLK/ but it's not. I see little choice but do a straightforward simple design, e.g. 3 half-cycles to write a byte: 1. assert address, data-in, deassert OE/ 2. assert WE/ for one-half cycle 3. continue to assert address, data-in, deassert OE/ Thus a byte store will require three cycles and a word store will require four. External SRAM word store: Cycle EX(sw) W1 W2 W3 EX' CLK ----____----____----____----____----____ CE/ ________________________________________ A[14:1] A0 ____----____________------------____---- D[7:0] DT ------------____________________-------- OE/ ________------------------------________ WE/ ------------____--------____------------ Notes: 1. The PC and PC' bus transactions are instruction fetches. 2. DT is the external SRAM data-out pins' active-low output enable. DT is held asserted until half-way through W1 to minimize bus contention between the SRAM outputs turning off and the FPGA data outputs turning on. I'd similarly like to deassert DT half-way through W3 but can't because it could deassert data-out before the RAM captures it on the deassertion of WE/. External SRAM byte store: Cycle EX(sb) W1 W2 EX' CLK ----____----____----____----____ CE/ ________________________________ A[14:1] A0 ____----<==============>____---- D[7:0] DT ------------________------------ OE/ ________----------------________ WE/ ------------____---------------- Notes: 1. In this case we do deassert DT half-way through W2 so the data bus is 3-stated for 1/2 cycle and there is no possible bus contention as W2 ends/EX' begins. That's the plan! Jan. ###### From: "Jan Gray" Newsgroups: comp.arch.fpga Subject: Re: Spartan II and asynchronous memory interface Date: Tue, 7 Aug 2001 07:37:21 -0700 Organization: Gray Research LLC Lines: 170 Message-ID: <9koumu$9om$2@slb6.atl.mindspring.net> References: <3B697EF9.E5BDF155@irisa.fr> <3B6FE4DE.3BAB7CE8@irisa.fr> NNTP-Posting-Host: 04.21.a0.48 X-Server-Date: 7 Aug 2001 14:41:34 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!newsfeeds.belnet.be!news.belnet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:8949 "Steven Derrien" wrote in message news:3B6FE4DE.3BAB7CE8@irisa.fr... > After extending the write cycle operation to keep address and > data stable when the WE signal gos intactive, the design finally > works OK at 9MHz, above, we get 100% which makes me think it a timing > problem rather than a PCB layout issue. [Copied to fpga-cpu@yahoogroups.com] You certainly must hold address and data stable while WE/ is deasserted! Here's some background on how XSOC does this, and on the XSOC async SRAM controller in general :- In the original XSOC/xr16 project (www.fpgacpu.org/xsoc/), as described in the article series (www.fpgacpu/xsoc/cc.html and www.fpgacpu.org/papers/xsoc-series-drafts.pdf), we introduce a little complexity in order to run the processor at 1X the XESS XS40 proto board clock rather than 1/2X. The early XESS XS40s (up to and including version 1.2) had a fixed oscillator at 12 MHz. (Newer revisions have a programmable oscillator, up to 100 MHz. More on this below.) One goal was to run the processor at 12 MHz rather than 6 MHz. However, the CPU needs a new 16-bit instruction (two bytes) every cycle, and the XS40 had only a single byte-wide async SRAM. And another goal was to correctly run XSOC/xr16 with a slow (1 Hz) or stopped clock. Therefore, on read cycles, it reads two bytes per cycle. The design synchronously clocks A[N:1] in IOB FFs, but derives A[0] from CLK, and latches D[7:0] in on both rising and falling CLK edges. On write cycles, the design is optimized but still conservative, deriving all write control signal transitions from clock *edges*. A byte write takes 3 clock edges, (2 cycles), and a (two-byte) word write requires 6 edges (3 cycles). With async SRAMs, if you carefully read the data sheets, it is imperative that each write 1. asserts address (and perhaps data), waits (for address to settle) 2. asserts /WE and data, waits (for data to settle) 3. deasserts /WE, while holding address and data asserted and stable As previously discussed here (see http://www.fpga-faq.com/archives/threads_1998_04.html#10076), successfully doing a write in two clock edges is fraught with races and perils. And for the really curious, I have attached an old discussion of this issue, to the end of this message. The memory controller, briefly described in part three of the XSOC articles (see the timing diagram on p.19 and the schematic on p. 24, of www.fpgacpu.org/papers/xsoc-series-drafts.pdf), does this while deriving A[0], /WE, and /OE, with care to be guaranteed glitch-free, from state-machine clocked both on rising and falling edges of CLK. Article #3: "It follows that we need one-half clock to settle the write address, one-half clock to assert /WE, and one-half clock to deassert it." It is easy to see how this detail might have been lost in a rewrite. Now then, later XS40 boards (ver 1.3 and later) have programmable oscillators, and it is now possible to run the clock up at approximately the read latency of the async SRAM. For example, run the clock at 33 MHz, reading a byte every 30 ns, and insert a pipeline stall (wait state) on each 16-bit instruction fetch, effectively running the processor (out of byte-wide external RAM) at 16.7 MHz. To that end, and to add 32-bit long word read/write support, I redesigned MEMCTRL to be a simpler state machine, and now all A[], particularly A[1:0], are clocked on CLK rising edge IOB FFs, although I still use a small pos + neg edge clocked state machine to generate /WE. In this design, byte writes still take three edges (two cycles) and word writes six edges (now four cycles), (and longword writes, eight). [[Otherwise, in a strictly positive edge clocked state machine, byte writes would take three clocks, and word writes six, (and longword writes, 12).]] Sorry, this MEMCTRL revision has not been released. Jan Gray, Gray Research LLC [Disclaimer: these are my opinions -- do you own due diligence.] ------------------------------ Attachment: early XSOC async SRAM write design discussion (view with fixed-pitch font for best results). -----Original Message----- From: JG Sent: Sunday, January 03, 1999 11:34 PM Subject: RE: writing to static RAM > [Someone relates their negative experiences of writing to async SRAM using two clock edges.] Thanks for your comments. I agree. I have reviewed the data sheets of about six different async SRAMs and they all say the same things: 1. address must be valid before WE/ or CE/ is asserted (I'll just say WE/ throughout). 2. data must be valid a certain setup-time before WE/ is deasserted. 3. 0-ns hold times on addr and data after WE/ is deasserted. 4. WE/ must be deasserted for a minimum of 0 ns, but it must be deasserted. Considering my constraints, e.g. 5. address is not available until store instruction's EX stage ENDS. 6. must achieve a fully synchronous, static-ready design. 7. unwilling to do any async delay element tricks, like funny routings of clocks or enables in order to delay WE/ relative to valid addr or to advance deasserting WE/ relative to deasserting valid addr/data. 8. constrained by existing board -- e.g. might be nice if CE/ was driven by external CLK/ but it's not. I see little choice but do a straightforward simple design, e.g. 3 half-cycles to write a byte: 1. assert address, data-in, deassert OE/ 2. assert WE/ for one-half cycle 3. continue to assert address, data-in, deassert OE/ Thus a byte store will require three cycles and a word store will require four. External SRAM word store: Cycle EX(sw) W1 W2 W3 EX' CLK ----____----____----____----____----____ CE/ ________________________________________ A[14:1] A0 ____----____________------------____---- D[7:0] DT ------------____________________-------- OE/ ________------------------------________ WE/ ------------____--------____------------ Notes: 1. The PC and PC' bus transactions are instruction fetches. 2. DT is the external SRAM data-out pins' active-low output enable. DT is held asserted until half-way through W1 to minimize bus contention between the SRAM outputs turning off and the FPGA data outputs turning on. I'd similarly like to deassert DT half-way through W3 but can't because it could deassert data-out before the RAM captures it on the deassertion of WE/. External SRAM byte store: Cycle EX(sb) W1 W2 EX' CLK ----____----____----____----____ CE/ ________________________________ A[14:1] A0 ____----<==============>____---- D[7:0] DT ------------________------------ OE/ ________----------------________ WE/ ------------____---------------- Notes: 1. In this case we do deassert DT half-way through W2 so the data bus is 3-stated for 1/2 cycle and there is no possible bus contention as W2 ends/EX' begins. That's the plan! Jan.