From: rickman Newsgroups: comp.arch.fpga Subject: Async logic in FPGAs Date: Tue, 19 Aug 2003 00:17:58 -0400 Organization: Arius, Inc Lines: 70 Message-ID: <3F41A4F6.E37A7BA3@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSValr8WFOS7tbO7QxSIt/PIZQIdtGvpUKC2Cp938j9MF2i3woGS0T3Dp X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 19 Aug 2003 04:18:12 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!feed.news.nacamar.de!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31965 After reading a post by Jonathan Bromley on the VME interface, I thought I would see if anyone had any comments on a design I am doing. I have to interface to the PC104 bus which is just the PC ISA interface on a small board. After beating my head against the wall for a couple of trys, I decided to dump the BCLK since it is not really part of the spec and treat the command stobes as async lines. My design is further complicated by the fact that my system clock ranges from 2 MHz to 50 MHz to allow power conservation. I finally decided that the only way to get the job done was to treat the command strobes as clock lines. Read cycles are done normally by muxing the data from various registers based on the address lines and the tristate outputs are controlled with the strobes. Writes to simple registers are done on the trailing edge of the write strobe. For reads that need to update or clear bits, a strobe is generated that is sync'ed to the system clock using a circuit to remove the metastable problem. The same circuit works with writes that need to set flags or control FIFOs. I don't see any problem with any of the circuits I have used. I don't even see the need to use a clock tree for the command strobes since there are no race conditions where a few ns will matter. Unless there are *huge* differences in routing delays, this circuit should work just fine. Anyone had big problems with similar async circuits? BTW, here is the simple sync circuit to generate a single pulse in the target clock domain regardless of the relative speed of the clocks. |------- Metastable -------| __________ | | _____ |------O| inverter |-------|---------------| | Pulse | |__________| | | XOR |----> | ______ ______ | ______ |--|_____| Out | | | | | | | | | |---| D Q |-----| D Q |--|--| D Q |--| Strobe | | | | | | /Clock | | | | | | -------|> | ---|> | |---|> | |______| | |______| | |______| | | |___________|___________ Output Clock The pulse out should be clean by the next clock edge as long as the routing is kept short. Or if the clock period is very short another FF can be added to feed the other leg of the XOR gate and assure a clean output. If the input clock is faster than the output clock, extra clock edges on the input will be ignored until the signal has clocked through the other clock domain. You can also tap the second FF for the feedback if you want to use it for a handshake. A second FF on the input side and an XOR gate will give you a pulse on "acknowledge" of the pulse crossing the clock domain. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: Martin Thompson Newsgroups: comp.arch.fpga Subject: Re: Async logic in FPGAs Date: 19 Aug 2003 09:00:13 +0100 Organization: TRW Conekt Lines: 37 Sender: thompsonmj@1WVMP0J-DT Message-ID: References: <3F41A4F6.E37A7BA3@yahoo.com> NNTP-Posting-Host: 194.74.228.66 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.uni-berlin.de 1061280015 2946489 194.74.228.66 (16 [98603]) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news-fra1.dfn.de!fu-berlin.de!uni-berlin.de!194.74.228.66!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31966 rickman writes: > After reading a post by Jonathan Bromley on the VME interface, I thought > I would see if anyone had any comments on a design I am doing. I have > to interface to the PC104 bus which is just the PC ISA interface on a > small board. After beating my head against the wall for a couple of > trys, I decided to dump the BCLK since it is not really part of the spec > and treat the command stobes as async lines. My design is further > complicated by the fact that my system clock ranges from 2 MHz to 50 MHz > to allow power conservation. > > I finally decided that the only way to get the job done was to treat the > command strobes as clock lines. Read cycles are done normally by muxing > the data from various registers based on the address lines and the > tristate outputs are controlled with the strobes. Writes to simple > registers are done on the trailing edge of the write strobe. For reads > that need to update or clear bits, a strobe is generated that is sync'ed > to the system clock using a circuit to remove the metastable problem. > The same circuit works with writes that need to set flags or control > FIFOs. > That sounds about what we did for a PC/104 interface (some years ago, so the memory is a bit woolly - sorry!) I couldn't see a sensible way to use the BCLK line. We did it in a MAX7064 IIRC - everything worked fine once we dumped the Max plus II VHDL compiler and did it in schematics and AHDL! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt ###### From: symon_brewer@hotmail.com (Symon) Newsgroups: comp.arch.fpga Subject: Re: Async logic in FPGAs Date: 19 Aug 2003 10:26:17 -0700 Organization: http://groups.google.com/ Lines: 14 Message-ID: References: <3F41A4F6.E37A7BA3@yahoo.com> NNTP-Posting-Host: 67.121.165.33 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1061313979 18675 127.0.0.1 (19 Aug 2003 17:26:19 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 19 Aug 2003 17:26:19 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32002 rickman wrote in message news:<3F41A4F6.E37A7BA3@yahoo.com>... > > Anyone had big problems with similar async circuits? Hey Rick, I guess loads of us have had a BIG problem with this type of circuit! Half the time the async circuit works fine, but it always gets the blame for some other design deficiency! Anyway, one circuit I've used for crossing between clock domains that works well is the Self Addressing FIFO. See Xilinx APP note XAPP291. The incoming (or outgoing depending on topology) clock only feeds one clock pin, so no clock skew problems and no global clock net resource used. Maybe a little over the top for most designs, but (fairly) safe! HTH, Syms. ###### Message-ID: <3F4669DC.FDE21E93@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Async logic in FPGAs References: <3F41A4F6.E37A7BA3@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 101 Date: Fri, 22 Aug 2003 15:07:08 -0400 NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: lakeread05 1061578747 68.15.41.165 (Fri, 22 Aug 2003 14:59:07 EDT) NNTP-Posting-Date: Fri, 22 Aug 2003 14:59:07 EDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!newsfeed.vmunix.org!peer02.cox.net!cox.net!p01!lakeread05.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32065 Use the command strobes like you are as the clock to an input register, but also toggle a toggle flip-flop with the command. Use the address and any qualifiers to produce the clock enable to both the input register and the toggle flip-flop. The toggle flip-flop switches state each time a valid write is performed. Resync the toggle flip-flop output to your local clock, and then run it into a simple state machine that generates a 1 cycle wide pulse as a response to a change on the input. That pulse , which is sync'ed to your local clock can then be used to validate the contents of the input registers. I usually use it to copy the input register contents to a second layer input register that is clocked by the local clock. It is also used in your control logic to let the rest of the circuit know that there is new write data. As long as the bus write frequency is less than about 3 cycles of your local clock this works fine as described. If the bus can write faster, then you can write successive writes into a shift register or memory and transfer to the local in parallel every Nth write. rickman wrote: > After reading a post by Jonathan Bromley on the VME interface, I thought > I would see if anyone had any comments on a design I am doing. I have > to interface to the PC104 bus which is just the PC ISA interface on a > small board. After beating my head against the wall for a couple of > trys, I decided to dump the BCLK since it is not really part of the spec > and treat the command stobes as async lines. My design is further > complicated by the fact that my system clock ranges from 2 MHz to 50 MHz > to allow power conservation. > > I finally decided that the only way to get the job done was to treat the > command strobes as clock lines. Read cycles are done normally by muxing > the data from various registers based on the address lines and the > tristate outputs are controlled with the strobes. Writes to simple > registers are done on the trailing edge of the write strobe. For reads > that need to update or clear bits, a strobe is generated that is sync'ed > to the system clock using a circuit to remove the metastable problem. > The same circuit works with writes that need to set flags or control > FIFOs. > > I don't see any problem with any of the circuits I have used. I don't > even see the need to use a clock tree for the command strobes since > there are no race conditions where a few ns will matter. Unless there > are *huge* differences in routing delays, this circuit should work just > fine. > > Anyone had big problems with similar async circuits? BTW, here is the > simple sync circuit to generate a single pulse in the target clock > domain regardless of the relative speed of the clocks. > > |------- Metastable -------| > __________ > | | _____ > |------O| inverter |-------|---------------| | Pulse > | |__________| | | XOR |----> > | ______ ______ | ______ |--|_____| Out > | | | | | | | | | > |---| D Q |-----| D Q |--|--| D Q |--| > Strobe | | | | | | > /Clock | | | | | | > -------|> | ---|> | |---|> | > |______| | |______| | |______| > | | > |___________|___________ Output Clock > > The pulse out should be clean by the next clock edge as long as the > routing is kept short. Or if the clock period is very short another FF > can be added to feed the other leg of the XOR gate and assure a clean > output. > > If the input clock is faster than the output clock, extra clock edges on > the input will be ignored until the signal has clocked through the other > clock domain. > > You can also tap the second FF for the feedback if you want to use it > for a handshake. A second FF on the input side and an XOR gate will > give you a pulse on "acknowledge" of the pulse crossing the clock > domain. > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Async logic in FPGAs Date: Fri, 22 Aug 2003 20:46:58 -0400 Organization: Arius, Inc Lines: 132 Message-ID: <3F46B982.454C0D23@yahoo.com> References: <3F41A4F6.E37A7BA3@yahoo.com> <3F4669DC.FDE21E93@andraka.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVb807MhL6q/KzjU3SjwhvIrG5ArZn6nomp69a7+8oV6CcdnKtE8qCiw X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 23 Aug 2003 00:46:55 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!nntp.abs.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:32133 Ray Andraka wrote: > > Use the command strobes like you are as the clock to an input register, but > also toggle a toggle flip-flop with the command. Use the address and any > qualifiers to produce the clock enable to both the input register and the > toggle flip-flop. The toggle flip-flop switches state each time a valid > write is performed. Resync the toggle flip-flop output to your local clock, > and then run it into a simple state machine that generates a 1 cycle wide > pulse as a response to a change on the input. That pulse , which is sync'ed > to your local clock can then be used to validate the contents of the input > registers. I usually use it to copy the input register contents to a second > layer input register that is clocked by the local clock. It is also used in > your control logic to let the rest of the circuit know that there is new > write data. As long as the bus write frequency is less than about 3 cycles > of your local clock this works fine as described. If the bus can write > faster, then you can write successive writes into a shift register or memory > and transfer to the local in parallel every Nth write. That is exactly what the diagram below does. The FSM is mearly a couple of sequential registers and the one clock wide strobe is gated at the difference point. The circuit below does not require a fast clock if you have control over the cycle length with a wait signal. That is how I am able to work with a clock range of some 20x the bus write rate to about 1.5x. The wait signal slows the bus rate to whatever rate the circuit will run at. With the async nature, sometimes it takes an extra clock before the wait signal is seen by the bus. I am pretty sure I have the kinks worked out on paper. But one problem with using the control strobes as clocks is that the software wants to use clock routing for them. We will see what happens when all the clock resources are used up. I guess I will be able to control this manually. > rickman wrote: > > > After reading a post by Jonathan Bromley on the VME interface, I thought > > I would see if anyone had any comments on a design I am doing. I have > > to interface to the PC104 bus which is just the PC ISA interface on a > > small board. After beating my head against the wall for a couple of > > trys, I decided to dump the BCLK since it is not really part of the spec > > and treat the command stobes as async lines. My design is further > > complicated by the fact that my system clock ranges from 2 MHz to 50 MHz > > to allow power conservation. > > > > I finally decided that the only way to get the job done was to treat the > > command strobes as clock lines. Read cycles are done normally by muxing > > the data from various registers based on the address lines and the > > tristate outputs are controlled with the strobes. Writes to simple > > registers are done on the trailing edge of the write strobe. For reads > > that need to update or clear bits, a strobe is generated that is sync'ed > > to the system clock using a circuit to remove the metastable problem. > > The same circuit works with writes that need to set flags or control > > FIFOs. > > > > I don't see any problem with any of the circuits I have used. I don't > > even see the need to use a clock tree for the command strobes since > > there are no race conditions where a few ns will matter. Unless there > > are *huge* differences in routing delays, this circuit should work just > > fine. > > > > Anyone had big problems with similar async circuits? BTW, here is the > > simple sync circuit to generate a single pulse in the target clock > > domain regardless of the relative speed of the clocks. > > > > |------- Metastable -------| > > __________ > > | | _____ > > |------O| inverter |-------|---------------| | Pulse > > | |__________| | | XOR |----> > > | ______ ______ | ______ |--|_____| Out > > | | | | | | | | | > > |---| D Q |-----| D Q |--|--| D Q |--| > > Strobe | | | | | | > > /Clock | | | | | | > > -------|> | ---|> | |---|> | > > |______| | |______| | |______| > > | | > > |___________|___________ Output Clock > > > > The pulse out should be clean by the next clock edge as long as the > > routing is kept short. Or if the clock period is very short another FF > > can be added to feed the other leg of the XOR gate and assure a clean > > output. > > > > If the input clock is faster than the output clock, extra clock edges on > > the input will be ignored until the signal has clocked through the other > > clock domain. > > > > You can also tap the second FF for the feedback if you want to use it > > for a handshake. A second FF on the input side and an XOR gate will > > give you a pulse on "acknowledge" of the pulse crossing the clock > > domain. > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX