From: "Chris G. Schneider" Newsgroups: comp.arch.fpga Subject: Best design for asyn. interface DSP <-> FPGA? Date: Thu, 18 Jan 2001 20:40:19 +0100 Lines: 29 Message-ID: <3A6746A3.96FFA382@cgschneider.com> NNTP-Posting-Host: f-34-216.cvx-munchen.ipdial.viaginterkom.de (62.180.216.34) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 979846717 13097570 62.180.216.34 (16 [68826]) X-Mailer: Mozilla 4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!merapi!feed2.news.luth.se!luth.se!newsfeeds.belnet.be!news.belnet.be!newsfeed1.news.nl.uu.net!sun4nl!fu-berlin.de!uni-berlin.de!f-34-216.cvx-munchen.ipdial.viaginterkom.DE!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3976 I want to design an interface between a DSP and a FPGA. The DSP should be able to access FPGA registers, via the DSP parallel port. The DSP parallel port has address, data, chip select, read and write lines. Just the usual stuff. I just designed this interface, but I am not happy with the results in terms of speed and design stability. So I want to ask this audience for some design hints. 1) Write access: I just synchronize the DSP write signal and generate an internal write strobe to fetch the data. Is it a better solution to use the write signal to store the data in a register and then synchronize the register contents to the internal clock? This makes it possible to detect very short write strobes of the DSP and to reduce the number of WS, in the application. 2) Read access: I use a async. read access at the moment. Is it possible to make this work synchronously? The problem is that synchronizing just eats up a lot of time, and timing constraints of modern DSP are pretty tight. There will be a problem if the FPGA does not release the DSP data bus fast enough, because read and write accesses can appear very soon after each other. Any suggestions, or literature tips? -- chris ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Best design for asyn. interface DSP <-> FPGA? Date: Thu, 18 Jan 2001 16:53:30 -0800 Organization: Xilinx Lines: 89 Message-ID: <3A679009.5A8A132F@xilinx.com> References: <3A6746A3.96FFA382@cgschneider.com> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------25706E7DA74EADA6AEACA0EE" X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en To: "Chris G. Schneider" 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!ptdnetP!newsgate.ptd.net!attmtf.ip.att.net!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3939 --------------25706E7DA74EADA6AEACA0EE Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Chris, you may want to look at an article about crossing asynchronous clock boundaries that I published about a year ago. Mayeb it helps you. http://www.isdmag.com/editorial/2000/design0003.html Peter Alfke, Xilinx Applications ================================ "Chris G. Schneider" wrote: > I want to design an interface between a DSP and a FPGA. The DSP should > be able to access FPGA registers, via the DSP parallel port. The > DSP parallel port has address, data, chip select, read and write lines. > Just the usual stuff. > > I just designed this interface, but I am not happy with the results in > terms of speed and design stability. So I want to ask this audience for > some design hints. > > 1) Write access: I just synchronize the DSP write signal and generate an > internal write strobe to fetch the data. Is it a better solution to use > the write signal to store the data in a register and then synchronize > the register contents to the internal clock? This makes it possible to > detect very short write strobes of the DSP and to reduce the number of > WS, in the application. > > 2) Read access: I use a async. read access at the moment. Is it possible > to make this work synchronously? The problem is that synchronizing just > eats up a lot of time, and timing constraints of modern DSP are pretty > tight. There will be a problem if the FPGA does not release the DSP data > bus fast enough, because read and write accesses can appear very soon > after each other. > > Any suggestions, or literature tips? > > -- > chris --------------25706E7DA74EADA6AEACA0EE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Chris, you may want to look at an article about crossing asynchronous clock boundaries that I published about a year ago. Mayeb it helps you.

http://www.isdmag.com/editorial/2000/design0003.html

Peter Alfke, Xilinx Applications
================================
"Chris G. Schneider" wrote:

I want to design an interface between a DSP and a FPGA. The DSP should
be able to access FPGA registers, via the DSP parallel port. The
DSP parallel port has address, data, chip select, read and write lines.
Just the usual stuff.

I just designed this interface, but I am not happy with the results in
terms of speed and design stability. So I  want to ask this audience for
some design hints.

1) Write access: I just synchronize the DSP write signal and generate an
internal write strobe to fetch the data. Is it a better solution to use
the write signal to store the data in a register and then synchronize
the register contents to the internal clock? This makes it possible to
detect very short write strobes of the DSP and to reduce the number of
WS, in the application.

2) Read access: I use a async. read access at the moment. Is it possible
to make this work synchronously? The problem is that synchronizing just
eats up a lot of time, and timing constraints of modern DSP are pretty
tight. There will be a problem if the FPGA does not release the DSP data
bus fast enough, because read and write accesses can appear very soon
after each other.

Any suggestions, or literature tips?

--
chris

--------------25706E7DA74EADA6AEACA0EE-- ###### From: "Chris G. Schneider" Newsgroups: comp.arch.fpga Subject: Re: Best design for asyn. interface DSP <-> FPGA? Date: Fri, 19 Jan 2001 21:40:50 +0100 Lines: 108 Message-ID: <3A68A652.7E81B1EF@cgschneider.com> References: <3A6746A3.96FFA382@cgschneider.com> <3A679009.5A8A132F@xilinx.com> NNTP-Posting-Host: f-102-216.cvx-munchen.ipdial.viaginterkom.de (62.180.216.102) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 979936741 13500368 62.180.216.102 (16 [68826]) X-Mailer: Mozilla 4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fu-berlin.de!uni-berlin.de!f-102-216.cvx-munchen.ipdial.viaginterkom.DE!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3977 Peter Alfke wrote: > Chris, you may want to look at an article about crossing asynchronous > clock boundaries that I published about a year ago. Mayeb it helps > you. > > http://www.isdmag.com/editorial/2000/design0003.html > > Peter Alfke, Xilinx Applications > ================================ Peter, I have just reread your nice article. The asynchonous FIFO is a perfect solution when it comes to streams of data that the FPGA processes. In my application FPGA registers are maped into the DSP memory. These registers can set hardware switches, and in some cases the DSP data will be transfered to a synchronous FIFO through a pipeline, or the other way round: data from an other FIFO can be read by the DSP as well. Using synchronous FIFOs forced me to operate these FIFOs at the speed of the DSP interface (120MHz), but the real data rates are much lower. The fastest part in my design are the DSP interfaces, all other stuff is much much slower. The DSP is able to write to a register and read from it in the next access. The effictive data rate of the DSP is about 25 MHz, but DSP write strobes are very short (12 ns), and the DSP expects to valid data 23 ns after read assertion which is less than 3 clock cycles at 120 MHz. This is the reason for choosing an asynchronous read access. But unfortunately, async. logic can produce glitches, this may be a problem. I don't know how to use async. FIFOs in this case. I cannot implement a FIFO for each register bank, and the read after a write access makes the use of FIFOs difficult. I have to implement a lot of these kind of interfaces and I am looking for a clean solution. May a cache build of BlockRAM be a possiblity? My Virtex-E has some free RAM cells left. The DSP can have fast access to the cache, and all write accesses to the registers can be pipelined then. But what external clock can be used for this cache? There is just the read and write signal of the DSP. Originally I thought of this as a school book example, because mapping FPGA registers into DSP memory seems to be pretty standard. I'm not sure any more. Best regards, Chris > > "Chris G. Schneider" wrote: > >> I want to design an interface between a DSP and a FPGA. The DSP >> should >> be able to access FPGA registers, via the DSP parallel port. The >> DSP parallel port has address, data, chip select, read and write >> lines. >> Just the usual stuff. >> >> I just designed this interface, but I am not happy with the results >> in >> terms of speed and design stability. So I want to ask this audience >> for >> some design hints. >> >> 1) Write access: I just synchronize the DSP write signal and >> generate an >> internal write strobe to fetch the data. Is it a better solution to >> use >> the write signal to store the data in a register and then >> synchronize >> the register contents to the internal clock? This makes it possible >> to >> detect very short write strobes of the DSP and to reduce the number >> of >> WS, in the application. >> >> 2) Read access: I use a async. read access at the moment. Is it >> possible >> to make this work synchronously? The problem is that synchronizing >> just >> eats up a lot of time, and timing constraints of modern DSP are >> pretty >> tight. There will be a problem if the FPGA does not release the DSP >> data >> bus fast enough, because read and write accesses can appear very >> soon >> after each other. >> >> Any suggestions, or literature tips? >> >> -- >> chris > ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Best design for asyn. interface DSP <-> FPGA? Date: Fri, 19 Jan 2001 16:25:31 -0800 Organization: Xilinx Lines: 131 Message-ID: <3A68DAFB.7F08FC3F@xilinx.com> References: <3A6746A3.96FFA382@cgschneider.com> <3A679009.5A8A132F@xilinx.com> <3A68A652.7E81B1EF@cgschneider.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.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en To: "Chris G. Schneider" 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.mathworks.com!ptdnetP!newsgate.ptd.net!attmtf.ip.att.net!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:4009 Chris, the article I mentioned also describes, in the beginning, how to transfer a single register across the clock boundary... Just in general terms, 120 MHz and 12 ns are no longer scary values. Not for the recent Virtex-E and Spartan-II devices, and definitely not for the newest Virtex-II, where synchronous 24-bit counters can run at 300 MHz ( without allowing for external delays). Asynchronous FIFOs in either BlockRAMs or CLBs can run at 200 MHz, but to generate reliable FULL and EMPTY handshake signals you must use Grey counters, as described in our App note XAPP051 ( and if you want to use that, send me an e-mail for newer improvements ). It is impossible for me to evaluate all aspects of your design, but I want to give you confidence that the newer chips are much faster than they were in the past. And the most recent designs have amazed me. Half a nanosecond is the new standard value for clock-to-Q, or set-up time, or routing to the nearest CLB. And ripple-carry delay per bit are ten times less. Greetings Peter Alfke, Xilinx Applications ================================= "Chris G. Schneider" wrote: > Peter Alfke wrote: > > > Chris, you may want to look at an article about crossing asynchronous > > clock boundaries that I published about a year ago. Mayeb it helps > > you. > > > > http://www.isdmag.com/editorial/2000/design0003.html > > > > Peter Alfke, Xilinx Applications > > ================================ > > Peter, > > I have just reread your nice article. The asynchonous FIFO is a perfect > solution when it comes to streams of data that the FPGA processes. > > In my application FPGA registers are maped into the DSP memory. These > registers can set hardware switches, and in some cases the DSP data will > be > transfered to a synchronous FIFO through a pipeline, or the other way > round: data from an other FIFO can be read by the DSP as well. > > Using synchronous FIFOs forced me to operate these FIFOs at the speed of > > the DSP interface (120MHz), but the real data rates are much lower. > > The fastest part in my design are the DSP interfaces, all other stuff is > > much much slower. > > The DSP is able to write to a register and read from it in the next > access. The effictive data rate of the DSP is about 25 MHz, but DSP > write strobes are very short (12 ns), and the DSP expects to valid data > 23 ns after read assertion which is less than 3 clock cycles at 120 MHz. > > This is the reason for choosing an asynchronous read access. But > unfortunately, async. logic can produce glitches, this may be a problem. > > I don't know how to use async. FIFOs in this case. I cannot implement a > FIFO for each register bank, and the read after a write access makes the > > use of FIFOs difficult. > > I have to implement a lot of these kind of interfaces and I am looking > for a clean solution. May a cache build of BlockRAM be a possiblity? > My Virtex-E has some free RAM cells left. The DSP can have fast access > to the cache, and all write accesses to the registers can be pipelined > then. But what external clock can be used for this cache? There is just > the read and write signal of the DSP. > > Originally I thought of this as a school book example, because mapping > FPGA registers into DSP memory seems to be pretty standard. I'm not sure > > any more. > > Best regards, > > Chris > > > > > "Chris G. Schneider" wrote: > > > >> I want to design an interface between a DSP and a FPGA. The DSP > >> should > >> be able to access FPGA registers, via the DSP parallel port. The > >> DSP parallel port has address, data, chip select, read and write > >> lines. > >> Just the usual stuff. > >> > >> I just designed this interface, but I am not happy with the results > >> in > >> terms of speed and design stability. So I want to ask this audience > >> for > >> some design hints. > >> > >> 1) Write access: I just synchronize the DSP write signal and > >> generate an > >> internal write strobe to fetch the data. Is it a better solution to > >> use > >> the write signal to store the data in a register and then > >> synchronize > >> the register contents to the internal clock? This makes it possible > >> to > >> detect very short write strobes of the DSP and to reduce the number > >> of > >> WS, in the application. > >> > >> 2) Read access: I use a async. read access at the moment. Is it > >> possible > >> to make this work synchronously? The problem is that synchronizing > >> just > >> eats up a lot of time, and timing constraints of modern DSP are > >> pretty > >> tight. There will be a problem if the FPGA does not release the DSP > >> data > >> bus fast enough, because read and write accesses can appear very > >> soon > >> after each other. > >> > >> Any suggestions, or literature tips? > >> > >> -- > >> chris > > ###### Message-ID: <3A68F5C6.FFA3F627@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Best design for asyn. interface DSP <-> FPGA? References: <3A6746A3.96FFA382@cgschneider.com> <3A679009.5A8A132F@xilinx.com> <3A68A652.7E81B1EF@cgschneider.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 144 Date: Sat, 20 Jan 2001 02:16:34 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 979956994 24.13.238.93 (Fri, 19 Jan 2001 18:16:34 PST) NNTP-Posting-Date: Fri, 19 Jan 2001 18:16:34 PST 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!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:4012 It can be done without block rams. Depending on what the registers hold, you may not need synchronizing logic (a mode bit for instance often can be set without timing consequence if the processor it controls is idle). Let's assume you need to write synchronously into a sytem with an async DSP write. The DSP write occurs on a write strobe that is async to any clocks you have. What you do is let the DSP write pulse clock an input register(s) that essentially gets written with the DSP data. You might also want to write a few bits of the address so you can figure out where the data is supposed to go. So far, we're not doing anything to get into the timing of our FPGA logic, this is all self timed from the DSP (you may want to connect the write pulse to a clock buffer). For readback, internally select the register using just the address, as it comes earlier, then turn on the output buffers with the qualified read. Now, if you need the data syncrhonized to your FPGA clock, you toggle an additional flip-flop with the write pulse, so that each time a write occurs, the toggle flop changes to the opposite state. You synchronize that toggle flop output to the FPGA clock domain through a flip-flop or two, and then drive a state machine that generates a 1 clock wide write pulse each time it sees that synchronized toggle change state. That write pulse can then be used to synchronously and safely copy the data captured in the write register to another register in your FPGA clock domain. The only requirement is you have to guarantee the capture register is not changed before the transfer occurs, which can usually be done by making sure the local clock goes through at least 3 or 4 cycles in the fastest possible DSP write time (if not, you can assemble several DSP writes into a long word and transfer only after the nth write). Reading back can be a little trickier, but the same sort of set up can be used. Here, it helps if the read address is known ahead of time. "Chris G. Schneider" wrote: > > Peter Alfke wrote: > > ? Chris, you may want to look at an article about crossing asynchronous > ? clock boundaries that I published about a year ago. Mayeb it helps > ? you. > ? > ? http://www.isdmag.com/editorial/2000/design0003.html > ? > ? Peter Alfke, Xilinx Applications > ? ================================ > > Peter, > > I have just reread your nice article. The asynchonous FIFO is a perfect > solution when it comes to streams of data that the FPGA processes. > > In my application FPGA registers are maped into the DSP memory. These > registers can set hardware switches, and in some cases the DSP data will > be > transfered to a synchronous FIFO through a pipeline, or the other way > round: data from an other FIFO can be read by the DSP as well. > > Using synchronous FIFOs forced me to operate these FIFOs at the speed of > > the DSP interface (120MHz), but the real data rates are much lower. > > The fastest part in my design are the DSP interfaces, all other stuff is > > much much slower. > > The DSP is able to write to a register and read from it in the next > access. The effictive data rate of the DSP is about 25 MHz, but DSP > write strobes are very short (12 ns), and the DSP expects to valid data > 23 ns after read assertion which is less than 3 clock cycles at 120 MHz. > > This is the reason for choosing an asynchronous read access. But > unfortunately, async. logic can produce glitches, this may be a problem. > > I don't know how to use async. FIFOs in this case. I cannot implement a > FIFO for each register bank, and the read after a write access makes the > > use of FIFOs difficult. > > I have to implement a lot of these kind of interfaces and I am looking > for a clean solution. May a cache build of BlockRAM be a possiblity? > My Virtex-E has some free RAM cells left. The DSP can have fast access > to the cache, and all write accesses to the registers can be pipelined > then. But what external clock can be used for this cache? There is just > the read and write signal of the DSP. > > Originally I thought of this as a school book example, because mapping > FPGA registers into DSP memory seems to be pretty standard. I'm not sure > > any more. > > Best regards, > > Chris > > ? > ? "Chris G. Schneider" wrote: > ? > ?? I want to design an interface between a DSP and a FPGA. The DSP > ?? should > ?? be able to access FPGA registers, via the DSP parallel port. The > ?? DSP parallel port has address, data, chip select, read and write > ?? lines. > ?? Just the usual stuff. > ?? > ?? I just designed this interface, but I am not happy with the results > ?? in > ?? terms of speed and design stability. So I want to ask this audience > ?? for > ?? some design hints. > ?? > ?? 1) Write access: I just synchronize the DSP write signal and > ?? generate an > ?? internal write strobe to fetch the data. Is it a better solution to > ?? use > ?? the write signal to store the data in a register and then > ?? synchronize > ?? the register contents to the internal clock? This makes it possible > ?? to > ?? detect very short write strobes of the DSP and to reduce the number > ?? of > ?? WS, in the application. > ?? > ?? 2) Read access: I use a async. read access at the moment. Is it > ?? possible > ?? to make this work synchronously? The problem is that synchronizing > ?? just > ?? eats up a lot of time, and timing constraints of modern DSP are > ?? pretty > ?? tight. There will be a problem if the FPGA does not release the DSP > ?? data > ?? bus fast enough, because read and write accesses can appear very > ?? soon > ?? after each other. > ?? > ?? Any suggestions, or literature tips? > ?? > ?? -- > ?? chris > ? -- -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 or http://www.fpga-guru.com ###### From: "Chris G. Schneider" Newsgroups: comp.arch.fpga Subject: Re: Best design for asyn. interface DSP <-> FPGA? Date: Sat, 20 Jan 2001 10:08:29 +0100 Lines: 196 Message-ID: <3A69558C.6748DAEB@cgschneider.com> References: <3A6746A3.96FFA382@cgschneider.com> <3A679009.5A8A132F@xilinx.com> <3A68A652.7E81B1EF@cgschneider.com> <3A68F5C6.FFA3F627@andraka.com> NNTP-Posting-Host: f-54-215.cvx-munchen.ipdial.viaginterkom.de (62.180.215.54) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 979981600 14016871 62.180.215.54 (16 [68826]) X-Mailer: Mozilla 4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fu-berlin.de!uni-berlin.de!f-54-215.cvx-munchen.ipdial.viaginterkom.DE!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:4016 Ray Andraka wrote: > It can be done without block rams. Depending on what the registers hold, you > may not need synchronizing logic (a mode bit for instance often can be set > without timing consequence if the processor it controls is idle). Let's assume > you need to write synchronously into a sytem with an async DSP write. The DSP > write occurs on a write strobe that is async to any clocks you have. > > What you do is let the DSP write pulse clock an input register(s) that > essentially gets written with the DSP data. You might also want to write a few > bits of the address so you can figure out where the data is supposed to go. So > far, we're not doing anything to get into the timing of our FPGA logic, this is > all self timed from the DSP (you may want to connect the write pulse to a clock > buffer). This is nearer to the solution I thought of, thanks Ray. I just wonder how many FF you can use safely when its clock is not connected to a dedicated pin, or if all clock buffers are in use already. Setting a LOWSKEWNET will help. But what are your experiences? > For readback, internally select the register using just the address, > as it comes earlier, then turn on the output buffers with the qualified read. Yes, but you have to take care on the read signal as well, may be I forgot to mention, that the DSP data bus is a bidirectional one. This is exactly where my problem occurs: I use async. logic for read accesses and depending on the mood of the tools glitches are produced at the external data bus. I don't know how to control them without FFs. > Now, if you need the data syncrhonized to your FPGA clock, you toggle an > additional flip-flop with the write pulse, so that each time a write occurs, the > toggle flop changes to the opposite state. You synchronize that toggle flop > output to the FPGA clock domain through a flip-flop or two, and then drive a > state machine that generates a 1 clock wide write pulse each time it sees that > synchronized toggle change state. That write pulse can then be used to > synchronously and safely copy the data captured in the write register to another > register in your FPGA clock domain. The only requirement is you have to > guarantee the capture register is not changed before the transfer occurs, which > can usually be done by making sure the local clock goes through at least 3 or 4 > cycles in the fastest possible DSP write time (if not, you can assemble several > DSP writes into a long word and transfer only after the nth write). Good idea, I don't think that the writing of the data is a problem anymore. > Reading back can be a little trickier, but the same sort of set up can be used. I am not sure what you mean. For readback I can use the address to select a register, in parallel I can generate a read pulse to store the selected data in an output register. If the read signal is deasserted, the output can be tristated aynchronously. > Here, it helps if the read address is known ahead of time. Sure, some kind of a piplined read would be perfect, unfortunately the DSP does not support such kind of transfers. To be honest, the address is valid only a few ns before the read access, so this won't help much. So I just can forget about implementing a read-after-write feature, beause pipeling takes a lot of time. It is very likely that a read after write to same register would result in reading the old data instead of the new one. We discussed three differnt aspects up to now: 1) registers for external control: best without synchronizing 2) data streams best with asyn. FIFO 3) data to be used internally sync at internal clock. All of these problems occur in my design. Using the internal synchronization seems to be a solution for all of this three situations. Best regards, Chris > "Chris G. Schneider" wrote: > > > > Peter Alfke wrote: > > > > ? Chris, you may want to look at an article about crossing asynchronous > > ? clock boundaries that I published about a year ago. Mayeb it helps > > ? you. > > ? > > ? http://www.isdmag.com/editorial/2000/design0003.html > > ? > > ? Peter Alfke, Xilinx Applications > > ? ================================ > > > > Peter, > > > > I have just reread your nice article. The asynchonous FIFO is a perfect > > solution when it comes to streams of data that the FPGA processes. > > > > In my application FPGA registers are maped into the DSP memory. These > > registers can set hardware switches, and in some cases the DSP data will > > be > > transfered to a synchronous FIFO through a pipeline, or the other way > > round: data from an other FIFO can be read by the DSP as well. > > > > Using synchronous FIFOs forced me to operate these FIFOs at the speed of > > > > the DSP interface (120MHz), but the real data rates are much lower. > > > > The fastest part in my design are the DSP interfaces, all other stuff is > > > > much much slower. > > > > The DSP is able to write to a register and read from it in the next > > access. The effictive data rate of the DSP is about 25 MHz, but DSP > > write strobes are very short (12 ns), and the DSP expects to valid data > > 23 ns after read assertion which is less than 3 clock cycles at 120 MHz. > > > > This is the reason for choosing an asynchronous read access. But > > unfortunately, async. logic can produce glitches, this may be a problem. > > > > I don't know how to use async. FIFOs in this case. I cannot implement a > > FIFO for each register bank, and the read after a write access makes the > > > > use of FIFOs difficult. > > > > I have to implement a lot of these kind of interfaces and I am looking > > for a clean solution. May a cache build of BlockRAM be a possiblity? > > My Virtex-E has some free RAM cells left. The DSP can have fast access > > to the cache, and all write accesses to the registers can be pipelined > > then. But what external clock can be used for this cache? There is just > > the read and write signal of the DSP. > > > > Originally I thought of this as a school book example, because mapping > > FPGA registers into DSP memory seems to be pretty standard. I'm not sure > > > > any more. > > > > Best regards, > > > > Chris > > > > ? > > ? "Chris G. Schneider" wrote: > > ? > > ?? I want to design an interface between a DSP and a FPGA. The DSP > > ?? should > > ?? be able to access FPGA registers, via the DSP parallel port. The > > ?? DSP parallel port has address, data, chip select, read and write > > ?? lines. > > ?? Just the usual stuff. > > ?? > > ?? I just designed this interface, but I am not happy with the results > > ?? in > > ?? terms of speed and design stability. So I want to ask this audience > > ?? for > > ?? some design hints. > > ?? > > ?? 1) Write access: I just synchronize the DSP write signal and > > ?? generate an > > ?? internal write strobe to fetch the data. Is it a better solution to > > ?? use > > ?? the write signal to store the data in a register and then > > ?? synchronize > > ?? the register contents to the internal clock? This makes it possible > > ?? to > > ?? detect very short write strobes of the DSP and to reduce the number > > ?? of > > ?? WS, in the application. > > ?? > > ?? 2) Read access: I use a async. read access at the moment. Is it > > ?? possible > > ?? to make this work synchronously? The problem is that synchronizing > > ?? just > > ?? eats up a lot of time, and timing constraints of modern DSP are > > ?? pretty > > ?? tight. There will be a problem if the FPGA does not release the DSP > > ?? data > > ?? bus fast enough, because read and write accesses can appear very > > ?? soon > > ?? after each other. > > ?? > > ?? Any suggestions, or literature tips? > > ?? > > ?? -- > > ?? chris > > ? > > -- > -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 or http://www.fpga-guru.com -- To be shocked is not worth while.