Message-ID: <3A5C2AE9.52717DAD@earthlink.net> From: Bill Lenihan Reply-To: lenihan3weNOSPAM@earthlink.net X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: grey code counters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 17 Date: Wed, 10 Jan 2001 09:25:22 GMT NNTP-Posting-Host: 209.179.210.51 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 979118722 209.179.210.51 (Wed, 10 Jan 2001 01:25:22 PST) NNTP-Posting-Date: Wed, 10 Jan 2001 01:25:22 PST Organization: EarthLink Inc. -- http://www.EarthLink.net 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!xfer10.netnews.com!netnews.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3713 I know how to make binary up/down counters and LFSR-based counters in verilog, but does anyone know of an algorithmic/equation-based way to make grey-code counters? The only examples I've seen are from old PAL application notes, and they are for 4-bit grey counters that are described as 16-state state machines, which is ok if you are keeping the counter at 4-bits, but impractical if you are going to much wider bit widths. -- ============================== William Lenihan lenihan3weNOSPAM@earthlink.net .... remove "NOSPAM" when replying ============================== ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Wed, 10 Jan 2001 09:20:04 -0800 Organization: Xilinx Lines: 49 Message-ID: <3A5C99C5.6B1A0CBC@xilinx.com> References: <3A5C2AE9.52717DAD@earthlink.net> 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: lenihan3we@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.mathworks.com!news.idt.net!attmtf.ip.att.net!attla1!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3724 I recently had reason to investigate this for the design of an asynchronous BlockRAM-based FIFO in Virtex and Virtex-II. ( BTW: I got it to run at 200 MHz, with proper FULL and EMPTY handshake, while running with with two independent unrelated clocks) Here are my notes: Grey-Coded Addresses Only one bit/address changes at any time Therefore no glitches from the identity comparator Implementation: Build binary counter Generate XOR of two adjacent D-inputs (that is the trick ! Don't use the binary Q, use the binary D) Feed these XORs to a register = Grey ! MSB binary = MSB Grey Advantage: very fast and easily epandable. Please excuse the terse (PowerPoint) notation. Yes, it wastes flip-flops. But I think it is still the most compact (cheapest) solution in Virtex, where one CLB implements two bits, since it has 4 flip-flops. I tried various other ways, and -while they did not waste flip-flops- they were no cheaper. BTW: You can of course use the simultaneous binary output "for free". You can also run the counter in both directions "for free". I will gladly accept a more compact solution. Peter Alfke, Xilinx Applications Bill Lenihan wrote: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > > The only examples I've seen are from old PAL application notes, and they > are for 4-bit grey counters that are described as 16-state state > machines, which is ok if you are keeping the counter at 4-bits, but > impractical if you are going to much wider bit widths. > > -- > ============================== > William Lenihan > lenihan3weNOSPAM@earthlink.net > .... remove "NOSPAM" when replying > ============================== ###### From: "Kevin Neilson" Newsgroups: comp.arch.fpga References: <3A5C2AE9.52717DAD@earthlink.net> Subject: Re: grey code counters Lines: 34 X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: Date: Wed, 10 Jan 2001 17:44:04 GMT NNTP-Posting-Host: 209.245.10.200 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 979148644 209.245.10.200 (Wed, 10 Jan 2001 09:44:04 PST) NNTP-Posting-Date: Wed, 10 Jan 2001 09:44:04 PST Organization: EarthLink Inc. -- http://www.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.skycache.com!Cidera!news-out.usenetserver.com!newsfeed2.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:3717 Bill, Making a Gray counter is surprisingly simple. I have some code, which I can't give out, but it is basically just a conventional counter and some XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. "Gray" can just be the output of the flipflops, or you can pipeline the output for extra speed. In that case the Gray counter would run at whatever speed the convential counter ran. You may hardcode this or use a loop to make Gray counters of N size. -Kevin Neilson, IDS Jaan Sirp wrote in message ... >Hello Bill. > >I have made grey-code counter, it has N + 1 T-type FFs, where N is number of output bits. I have used ALDEC schematics capture, but converting it to Verilog is very simple. Let me know, if you are interested. > >Jaan Sirp. > >>I know how to make binary up/down counters and LFSR-based counters in >>verilog, but does anyone know of an algorithmic/equation-based way to >>make grey-code counters? >> >> >>The only examples I've seen are from old PAL application notes, and they >>are for 4-bit grey counters that are described as 16-state state >>machines, which is ok if you are keeping the counter at 4-bits, but >>impractical if you are going to much wider bit widths. ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Wed, 10 Jan 2001 10:13:19 -0800 Organization: Xilinx Lines: 40 Message-ID: <3A5CA63F.1DF501B9@xilinx.com> References: <3A5C2AE9.52717DAD@earthlink.net> 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 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!news.idt.net!attmtf.ip.att.net!attla1!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3722 I suggested a slight twist to this design: Same logic, but feed the XOR from the D-inputs of the binary counter, not their Q outputs. This way the binary and grey counters are "in step". Peter Alfke Kevin Neilson wrote: > Bill, > Making a Gray counter is surprisingly simple. I have some code, which I > can't give out, but it is basically just a conventional counter and some > XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. > Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = > (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. > "Gray" can just be the output of the flipflops, or you can pipeline the > output for extra speed. In that case the Gray counter would run at whatever > speed the convential counter ran. > > You may hardcode this or use a loop to make Gray counters of N size. > > -Kevin Neilson, IDS > > Jaan Sirp wrote in message ... > >Hello Bill. > > > >I have made grey-code counter, it has N + 1 T-type FFs, where N is number > of output bits. I have used ALDEC schematics capture, but converting it to > Verilog is very simple. Let me know, if you are interested. > > > >Jaan Sirp. > > > >>I know how to make binary up/down counters and LFSR-based counters in > >>verilog, but does anyone know of an algorithmic/equation-based way to > >>make grey-code counters? > >> > >> > >>The only examples I've seen are from old PAL application notes, and they > >>are for 4-bit grey counters that are described as 16-state state > >>machines, which is ok if you are keeping the counter at 4-bits, but > >>impractical if you are going to much wider bit widths. ###### From: Arrigo Benedetti Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: 10 Jan 2001 10:23:34 -0800 Organization: Caltech Lines: 31 Sender: arrigo@modena.vision.caltech.edu Message-ID: References: <3A5C2AE9.52717DAD@earthlink.net> NNTP-Posting-Host: modena.vision.caltech.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.3 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!logbridge.uoregon.edu!nntp-server.caltech.edu!news Xref: chonsp.franklin.ch comp.arch.fpga:3719 Bill Lenihan writes: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > Grab the design files for Xilinx Application note 131 on FIFOs and look at fifoctlr_ic.vhd. The read and write address pointers are implemented as gray code counters... -Arrigo -- Dr. Arrigo Benedetti e-mail: arrigo@vision.caltech.edu Caltech, MS 136-93 phone: (626) 395-3129 Pasadena, CA 91125 fax: (626) 795-8649 > The only examples I've seen are from old PAL application notes, and they > are for 4-bit grey counters that are described as 16-state state > machines, which is ok if you are keeping the counter at 4-bits, but > impractical if you are going to much wider bit widths. > > -- > ============================== > William Lenihan > lenihan3weNOSPAM@earthlink.net > .... remove "NOSPAM" when replying > ============================== > > ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Wed, 10 Jan 2001 11:27:32 -0800 Organization: Xilinx Lines: 22 Message-ID: <3A5CB7A4.EC07468@xilinx.com> References: <3A5C2AE9.52717DAD@earthlink.net> 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: Arrigo Benedetti Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!wn4feed!worldnet.att.net!12.127.16.134!attmtf.ip.att.net!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3721 XAPP131 is just a straightforward binary-to-gray converter, as described in the 1972 Fairchild applications handbook ( by yours truly). The trick of using the XOR of the binary D-inputs is smarter, if I may say so. Same brain, just 29 years additional experience. :-) Peter Alfke ====================================== Arrigo Benedetti wrote: > > > Grab the design files for Xilinx Application note 131 on FIFOs and look > at fifoctlr_ic.vhd. The read and write address pointers are implemented > as gray code counters... > > -Arrigo > -- > Dr. Arrigo Benedetti e-mail: arrigo@vision.caltech.edu > Caltech, MS 136-93 phone: (626) 395-3129 > Pasadena, CA 91125 fax: (626) 795-8649 > ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: comp.arch.fpga Subject: Re: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> X-Disclaimer: Everything I write is false. Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 10 Jan 2001 12:45:54 -0800 Message-ID: Lines: 14 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 10 Jan 2001 12:50:47 -0800, ruckus.brouhaha.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!news.kjsl.com!news.spies.com!ruckus.brouhaha.com Xref: chonsp.franklin.ch comp.arch.fpga:3751 "Kevin Neilson" writes: > Making a Gray counter is surprisingly simple. I have some code, which I > can't give out, but it is basically just a conventional counter and some > XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. > Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = > (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. > "Gray" can just be the output of the flipflops, or you can pipeline the > output for extra speed. In that case the Gray counter would run at whatever > speed the convential counter ran. If you're using Gray counters because you have counters in two clock domains (e.g., for a FIFO), doesn't implmenting them as binary counters with converters defeat the purpose? With that implementation you can have glitches where multiple bits change simultaneously. ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Wed, 10 Jan 2001 12:58:34 -0800 Organization: Xilinx Lines: 16 Message-ID: <3A5CCCFA.8A23B2DA@xilinx.com> References: <3A5C2AE9.52717DAD@earthlink.net> 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: Eric Smith Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news-stu1.dfn.de!news-koe1.dfn.de!news-fra1.dfn.de!news.tele.dk!144.212.100.101!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:3726 Eric Smith wrote: > "If you're using Gray counters because you have counters in two clock > domains (e.g., for a FIFO), doesn't implmenting them as binary counters > with converters defeat the purpose? With that implementation you can > have glitches where multiple bits change simultaneously. Only if you do a combinatorial (XOR) decode of the binary. No problem if you re-register the Gray, and also no problem if you derive the input to the Gray registers from the binary Ds. Peter Alfke ###### From: "Kevin Neilson" Newsgroups: comp.arch.fpga References: <3A5C2AE9.52717DAD@earthlink.net> Subject: Re: grey code counters Lines: 28 X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: Date: Wed, 10 Jan 2001 23:49:30 GMT NNTP-Posting-Host: 209.245.10.145 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 979170570 209.245.10.145 (Wed, 10 Jan 2001 15:49:30 PST) NNTP-Posting-Date: Wed, 10 Jan 2001 15:49:30 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!informatik.tu-muenchen.de!news.csl-gmbh.net!newsfeed01.sul.t-online.de!t-online.de!fr.clara.net!heighliner.fr.clara.net!xfer10.netnews.com!netnews.com!howland.erols.net!newsfeed.mindspring.net.MISMATCH!news.mindspring.net!newsfeed2.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:3730 You are right that the design wouldn't work if you just read the unregistered XOR outputs in another domain. The second set of flops are required. That is, you clock the conventional counter and the Gray pipeline registers on clock A, and then you can read the Gray registers from domain B safely. The XOR outputs can glitch so they need to be registered. Eric Smith wrote in message ... >"Kevin Neilson" writes: >> Making a Gray counter is surprisingly simple. I have some code, which I >> can't give out, but it is basically just a conventional counter and some >> XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. >> Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = >> (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. >> "Gray" can just be the output of the flipflops, or you can pipeline the >> output for extra speed. In that case the Gray counter would run at whatever >> speed the convential counter ran. > >If you're using Gray counters because you have counters in two clock >domains (e.g., for a FIFO), doesn't implmenting them as binary counters >with converters defeat the purpose? With that implementation you can >have glitches where multiple bits change simultaneously. > ###### From: "Kevin Neilson" Newsgroups: comp.arch.fpga References: <3A5C2AE9.52717DAD@earthlink.net> <3A5CB7A4.EC07468@xilinx.com> Subject: Re: grey code counters Lines: 15 X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: Date: Thu, 11 Jan 2001 05:10:35 GMT NNTP-Posting-Host: 209.245.10.145 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 979189835 209.245.10.145 (Wed, 10 Jan 2001 21:10:35 PST) NNTP-Posting-Date: Wed, 10 Jan 2001 21:10:35 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!merapi!feed2.news.luth.se!luth.se!nntp.primenet.com!nntp.gblx.net!newsfeed.wirehub.nl!64.154.60.72.MISMATCH!news-out.usenetserver.com!newsfeed2.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:3741 Using the D-inputs would probably be a bit slower, since the combinational path would include the adder logic in addition to the XORs. Peter Alfke wrote in message <3A5CB7A4.EC07468@xilinx.com>... >XAPP131 is just a straightforward binary-to-gray converter, as described in >the 1972 Fairchild applications handbook ( by yours truly). >The trick of using the XOR of the binary D-inputs is smarter, if I may say >so. >Same brain, just 29 years additional experience. :-) >Peter Alfke >====================================== ###### Message-ID: <3A5D4587.D5001813@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> <3A5C99C5.6B1A0CBC@xilinx.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 90 Date: Thu, 11 Jan 2001 05:32:57 GMT NNTP-Posting-Host: 209.179.196.214 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 979191177 209.179.196.214 (Wed, 10 Jan 2001 21:32:57 PST) NNTP-Posting-Date: Wed, 10 Jan 2001 21:32:57 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!xfer13.netnews.com!netnews.com!howland.erols.net!newsfeed.mindspring.net.MISMATCH!news.mindspring.net!newsfeed2.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:3740 Interesting, but hard to understand. And in my case, there was no need to make the counter faster than the FIFO data storage in BlockRAM, which limits the cycle time to about 4 ns ( 200 MHz was my usual conservatism, I could have said 250 MHZ, but that would be bragging :-) I would also feel a bit queasy using 256 shifting bits to implement what is really a 12-bit counter. What if one bit ever goes wrong? It will never straighten itself out. Maybe this is heresy in a digital world, but the reliability of a fast-clocked shift register bit may perhaps not be as good as that of a static configuration bit. I always feel uneasy when there are lots of redundant flip-flops sloshing around. Call me chicken... Peter Alfke Kevin Neilson wrote: > SRL Johson Rings: > > Provided one is using a Virtex architecture, a smaller and faster > implementation would be to use the SRL (shift-register LUTs) as 16-bit > Johnson rings. A 4-bit Gray counter would use only 4 LUTs and no CLB flops. > You just configure the LSB SRL as a 16-bit Johnson ring with the initial > pattern 01100110_01100110, the next bit as an SRL loaded with > 00111100_00111100, and so on. After 4 bits, it gets a little harder. To do > an 8-bit counter, you would need 10 SRLs (10 LUTs). Bit 3 would need 2 > SRLs, since it repeats after 32 ticks. Then you would need a "terminal > count" SRL which is a Johnson ring with one '1' so the output goes hi every > 16th cycle. This would be used at the clock enable to another 4-SRL Johnson > Ring Gray counter. You could keep stringing them together like this. A > 12-bit counter would have 3 quad-Johnson-rings and the third would have a > clock enable of the AND of the terminal counts of the lower 2. So that's > about 16 LUTs for a 12-bit Gray counter. Which is better than the 24 flops > and 24 luts you would normally need. Of course this only works for Virtex > and Spartan-II. But this would be the fastest and smallest implementation > for that family. It only counts forward, though, and can't be reset, which > is a big drawback. > > -Kevin > > Peter Alfke wrote in message <3A5C99C5.6B1A0CBC@xilinx.com>... > >I recently had reason to investigate this for the design of an asynchronous > >BlockRAM-based FIFO in Virtex and Virtex-II. ( BTW: I got it to run at 200 > >MHz, with proper FULL and EMPTY handshake, while running with with two > >independent unrelated clocks) > >Here are my notes: > > > >Grey-Coded Addresses > >Only one bit/address changes at any time > >Therefore no glitches from the identity comparator > > > >Implementation: > >Build binary counter > >Generate XOR of two adjacent D-inputs > >(that is the trick ! Don't use the binary Q, use the binary D) > >Feed these XORs to a register = Grey ! > >MSB binary = MSB Grey > >Advantage: very fast and easily epandable. > > > >Please excuse the terse (PowerPoint) notation. > >Yes, it wastes flip-flops. But I think it is still the most compact > >(cheapest) solution in Virtex, where one CLB implements two bits, since it > >has 4 flip-flops. > >I tried various other ways, and -while they did not waste flip-flops- they > >were no cheaper. > >BTW: You can of course use the simultaneous binary output "for free". > >You can also run the counter in both directions "for free". > >I will gladly accept a more compact solution. > > > >Peter Alfke, Xilinx Applications > > > > > >Bill Lenihan wrote: > > > >> I know how to make binary up/down counters and LFSR-based counters in > >> verilog, but does anyone know of an algorithmic/equation-based way to > >> make grey-code counters? > >> > >> The only examples I've seen are from old PAL application notes, and they > >> are for 4-bit grey counters that are described as 16-state state > >> machines, which is ok if you are keeping the counter at 4-bits, but > >> impractical if you are going to much wider bit widths. > >> > >> -- > >> ============================== > >> William Lenihan > >> lenihan3weNOSPAM@earthlink.net > >> .... remove "NOSPAM" when replying > >> ============================== > > > > ###### From: "John L. Smith" Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Wed, 10 Jan 2001 21:49:17 -0800 Organization: Visicom Imaging Products Lines: 33 Message-ID: <3A5D495D.704DCDEC@visicom.com> References: <3A5C2AE9.52717DAD@earthlink.net> Reply-To: jsmith@visicom.com NNTP-Posting-Host: cassandra.vigra.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!merapi!feed2.news.luth.se!luth.se!nntp.primenet.com!nntp.gblx.net!news.maxwell.syr.edu!news.he.net!mercury.cts.com!newsfeed.cts.com!cheetah.visicom.com!usenet Xref: chonsp.franklin.ch comp.arch.fpga:3733 Here is some direct logic for a 4 bit Gray code counter: G0 <- !( G3 @ G2 @ G1 ) G1 <- G0 !( G3 @ G2 ) + !G0 G1 G2 <- !G3 G1 !G0 + G2 ( !G3 + !G1 + G0 ) G3 <- G2 !G1 !G0 + G3 ( G2 + G1 + G0 ) ( + = or, @ = xor, ! = not, and is implied) Generally, the reflected code is logic intensive, because _every_ bit depends _every_ other bit (except G0 does not depend on itself!) Here's the reverse conversion as well: G(N) = B(N) G[n] = B[n] @ B[n+1] B[n] = G[N] @ G[N-1] @ G[N-2] ... @ G[n] (N = MS bit, n = any smaller bit) Kevin Neilson wrote: > > You are right that the design wouldn't work if you just read the > unregistered XOR outputs in another domain. The second set of flops are > required. That is, you clock the conventional counter and the Gray pipeline > registers on clock A, and then you can read the Gray registers from domain > B safely. The XOR outputs can glitch so they need to be registered. > > Eric Smith wrote in message ... > >If you're using Gray counters because you have counters in two clock > >domains (e.g., for a FIFO), doesn't implmenting them as binary counters > >with converters defeat the purpose? With that implementation you can > >have glitches where multiple bits change simultaneously. > > ###### From: Petter Gustad Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: 11 Jan 2001 10:42:53 +0100 Organization: 502 You are not allowed to talk Lines: 67 Message-ID: <87zogy2zmq.fsf@scintight.dolphinics.no> References: <3A5C2AE9.52717DAD@earthlink.net> NNTP-Posting-Host: scintight.dolphinics.no X-Trace: oslo-nntp.eunet.no 979206323 28535 193.71.152.60 (11 Jan 2001 09:45:23 GMT) X-Complaints-To: newsmaster@eunet.no NNTP-Posting-Date: 11 Jan 2001 09:45:23 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!EU.net!Norway.EU.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3756 Bill Lenihan writes: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > > The only examples I've seen are from old PAL application notes, and they > are for 4-bit grey counters that are described as 16-state state > machines, which is ok if you are keeping the counter at 4-bits, but > impractical if you are going to much wider bit widths. I've done this the brute force way - 6-7 years ago I wrote a program to generate the verilog case statements for grey code counters (or Johnson counters). I've uploaded the program at ftp://ftp.gustad.com/pub/eda/jc.tgz ./jct 4 will generate the following table: case 10'b0000: ns = 10'b0001; case 10'b0001: ns = 10'b0011; case 10'b0011: ns = 10'b0010; case 10'b0010: ns = 10'b0110; case 10'b0110: ns = 10'b0111; case 10'b0111: ns = 10'b0101; case 10'b0101: ns = 10'b0100; case 10'b0100: ns = 10'b1100; case 10'b1100: ns = 10'b1101; case 10'b1101: ns = 10'b1111; case 10'b1111: ns = 10'b1110; case 10'b1110: ns = 10'b1010; case 10'b1010: ns = 10'b1011; case 10'b1011: ns = 10'b1001; case 10'b1001: ns = 10'b1000; case 10'b1000: ns = 10'b0000; You'll have to update the bit size manually before you include it in your code. The jc program will find all possible sequences which changes in only a single bit: 0 1 3 2 6 4 5 7 0 1 3 2 6 7 5 4 circular 0 1 3 7 5 4 6 2 circular 0 1 5 4 6 2 3 7 0 1 5 4 6 7 3 2 circular 0 1 5 7 3 2 6 4 circular 0 2 3 1 5 4 6 7 0 2 3 1 5 7 6 4 circular 0 2 3 7 6 4 5 1 circular 0 2 6 4 5 1 3 7 0 2 6 4 5 7 3 1 circular 0 2 6 7 3 1 5 4 circular ... Sequences which wraps around with only a single bit change are marked circular. Please note that this is not production code (simply I hack I used myself). Use at your own risk. If you use and like the program, please tell Xilinx that you would like their tools ported to Linux :-) Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://www.gustad.com #include /* compile/run this program to get my email address */ int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");} ###### From: Wolfgang Friedrich Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Thu, 11 Jan 2001 11:52:06 +0100 Organization: Heitec AG Lines: 34 Message-ID: <3A5D9056.98B3AE5B@heitec.de> References: <3A5C2AE9.52717DAD@earthlink.net> <3A5CA63F.1DF501B9@xilinx.com> NNTP-Posting-Host: paladin.heitec.net (193.101.232.30) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 979210299 11095112 193.101.232.30 (16 [54254]) X-Mailer: Mozilla 4.75 [de]C-CCK-MCD DT (WinNT; U) X-Accept-Language: de Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!fu-berlin.de!uni-berlin.de!paladin.heitec.NET!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3760 Hello, Peter Alfke schrieb: > > I suggested a slight twist to this design: > Same logic, but feed the XOR from the D-inputs of the binary counter, not their > Q outputs. This way the binary and grey counters are "in step". > Peter Alfke How do I get access to the D-inputs of the binary counter in VHDL? > > Kevin Neilson wrote: > > > Bill, > > Making a Gray counter is surprisingly simple. I have some code, which I > > can't give out, but it is basically just a conventional counter and some > > XORs. Say you have an N-bit counter, CNT, and want an N-bit Gray counter. > > Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] = > > (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1]. > > "Gray" can just be the output of the flipflops, or you can pipeline the > > output for extra speed. In that case the Gray counter would run at whatever > > speed the convential counter ran. > > > > You may hardcode this or use a loop to make Gray counters of N size. > > > > -Kevin Neilson, IDS > > -- Wolfgang Friedrich wolfgang.friedrich@heitec.de /\ /\ Heitec AG __/ \\ \__ 91052 Erlangen, Schuhstr. 30, Germany \ // / Tel: +49(0)9131/877-237 Fax: +49(0)9131/877-222 \/ \/ ###### From: Utku Ozcan Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Thu, 11 Jan 2001 17:45:39 +0200 Organization: Netas Nortelnetworks Lines: 22 Message-ID: <3A5DD523.C9B9830D@netas.com.tr> References: <3A5C2AE9.52717DAD@earthlink.net> <3A5CA63F.1DF501B9@xilinx.com> <3A5D9056.98B3AE5B@heitec.de> NNTP-Posting-Host: 47.165.145.191 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.61C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!join.news.pipex.net!pipex!news.kvaerner.com!warm.news.pipex.net!pipex!znsgs00r.europe.nortel.com!qnsgh006.europe.nortel.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3771 Wolfgang Friedrich wrote: > Hello, > > Peter Alfke schrieb: > > > > I suggested a slight twist to this design: > > Same logic, but feed the XOR from the D-inputs of the binary counter, not their > > Q outputs. This way the binary and grey counters are "in step". > > Peter Alfke > > How do I get access to the D-inputs of the binary counter in VHDL? you have to seperate counter asynchronous logic and D-FFs by using an intermediate vector. This intermediate vector will go to Peter Alfke's suggestion. If necessary, you might have to design the binary counter in gate-level (handcrafty). Utku ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Thu, 11 Jan 2001 08:58:33 -0800 Organization: Xilinx Lines: 44 Message-ID: <3A5DE638.CF877F49@xilinx.com> References: <3A5C2AE9.52717DAD@earthlink.net> <3A5D495D.704DCDEC@visicom.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: jsmith@visicom.com 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!cyclone.swbell.net!bos-service1.ext.raytheon.com!attla1!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3764 Any 4-bit counter is trivial, since 4-input LUTs allow us to create any of the 15! different possible counters, a humunous number of differnt designs, all at the same trivial cost. There isn't even a need nor a benefit of the carry structure. 16 to 24 bits is a much more interesting and fruitful area... Peter Alfke ================== "John L. Smith" wrote: > Here is some direct logic for a 4 bit Gray code counter: > > G0 <- !( G3 @ G2 @ G1 ) > G1 <- G0 !( G3 @ G2 ) + !G0 G1 > G2 <- !G3 G1 !G0 + G2 ( !G3 + !G1 + G0 ) > G3 <- G2 !G1 !G0 + G3 ( G2 + G1 + G0 ) > > ( + = or, @ = xor, ! = not, and is implied) > > Generally, the reflected code is logic intensive, > because _every_ bit depends _every_ other bit > (except G0 does not depend on itself!) > > Here's the reverse conversion as well: > > G(N) = B(N) > G[n] = B[n] @ B[n+1] B[n] = G[N] @ G[N-1] @ G[N-2] ... @ G[n] > (N = MS bit, n = any smaller bit) > > Kevin Neilson wrote: > > > > You are right that the design wouldn't work if you just read the > > unregistered XOR outputs in another domain. The second set of flops are > > required. That is, you clock the conventional counter and the Gray pipeline > > registers on clock A, and then you can read the Gray registers from domain > > B safely. The XOR outputs can glitch so they need to be registered. > > > > Eric Smith wrote in message ... > > >If you're using Gray counters because you have counters in two clock > > >domains (e.g., for a FIFO), doesn't implmenting them as binary counters > > >with converters defeat the purpose? With that implementation you can > > >have glitches where multiple bits change simultaneously. > > > ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Thu, 11 Jan 2001 10:39:16 -0800 Organization: Xilinx Lines: 34 Message-ID: <3A5DFDD4.D6CFF6A1@xilinx.com> References: <3A5C2AE9.52717DAD@earthlink.net> <3A5CA63F.1DF501B9@xilinx.com> <3A5D9056.98B3AE5B@heitec.de> 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: Wolfgang Friedrich Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news-stu1.dfn.de!news-mue1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!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:3766 Wolfgang Friedrich wrote: > Hello, > > Peter Alfke schrieb: > > > > I suggested a slight twist to this design: > > Same logic, but feed the XOR from the D-inputs of the binary counter, not their > > Q outputs. This way the binary and grey counters are "in step". > > Peter Alfke > > How do I get access to the D-inputs of the binary counter in VHDL? > Well, on the chip these Ds are brought out on the X and Y outputs of the CLB or slice, whether you ask for it or not. So there clearly is no hardware obstacle. I leave it to the software wizards to figure out a way. Maybe create a specialized macro... BTW, somebody mentioned the loss of speed. I am looking at the next generation data sheet ( yes, you will have access to it very soon..) The additional delay going through an extra LUT is max 0.50 ns for the slowest speed grade, the set-up time is even less, and the clock-to-Q is max 0.48 ns for the slowest part. So the Grey counter will not be the speed-limiting part in a FIFO. 250 MHz, aiming for 300. I have not given up on building a 1 GHz frequency counter in XC2V40... Moore's Law is definitely still working for us. :-) Peter Alfke, Xilinx Applications ###### Message-ID: <3A5E10B0.CF152E97@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: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> <3A5CA63F.1DF501B9@xilinx.com> <3A5D9056.98B3AE5B@heitec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 31 Date: Thu, 11 Jan 2001 19:56:47 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 979243007 24.13.238.93 (Thu, 11 Jan 2001 11:56:47 PST) NNTP-Posting-Date: Thu, 11 Jan 2001 11:56:47 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:3765 Wolfgang Friedrich wrote: > > Hello, > > Peter Alfke schrieb: > > > > I suggested a slight twist to this design: > > Same logic, but feed the XOR from the D-inputs of the binary counter, not their > > Q outputs. This way the binary and grey counters are "in step". > > Peter Alfke > > How do I get access to the D-inputs of the binary counter in VHDL? > describe the counter as a combinatorial increment function: count_d<=count+1; process(clk) if clk'event and clk='1' then count<=count_d; end if; -- -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: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Thu, 11 Jan 2001 18:04:26 -0700 Organization: National Optical Astronomy Observatory Lines: 29 Message-ID: <93ll93$rcm$2@noao.edu> References: <3A5C2AE9.52717DAD@earthlink.net> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 979261539 28054 140.252.18.68 (12 Jan 2001 01:05:39 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 12 Jan 2001 01:05:39 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!merapi!news-ge.switch.ch!news.maxwell.syr.edu!arclight.uoregon.edu!news.asu.edu!ennfs.eas.asu.edu!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3789 Bill Lenihan wrote: > > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > > The only examples I've seen are from old PAL application notes, and they > are for 4-bit grey counters that are described as 16-state state > machines, which is ok if you are keeping the counter at 4-bits, but > impractical if you are going to much wider bit widths. What I'd like to see (and I think I suggested this to the Synplicity guys) is an attribute or something in the synthesis tool that lets you select gray-code or binary-code counters. That would be useful. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt." ###### From: Kent Orthner Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: 12 Jan 2001 15:17:07 +0900 Organization: ... Lines: 49 Sender: korthner@KENT Message-ID: References: <3A5C2AE9.52717DAD@earthlink.net> NNTP-Posting-Host: dhcp238.inf.furukawa.co.jp X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" 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!telocity-west!TELOCITY!enews.sgi.com!news.ksw.feedmania.org!nf1.xephion.ne.jp!fintnews!ifnews!inf-gw!postmaster Xref: chonsp.franklin.ch comp.arch.fpga:3784 Bill Lenihan writes: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > > The only examples I've seen are from old PAL application notes, and they > are for 4-bit grey counters that are described as 16-state state > machines, which is ok if you are keeping the counter at 4-bits, but > impractical if you are going to much wider bit widths. When I wanted the same thing, a generic grey code counter, without having to do it manually for each bit-width, I did the following: Created an bin2grey function, and a grey2bin function, each of which converted a unsigned or slv of any width from grey to bin or vice-versa. When I went to implement it, I wrote: next_grey_counter <= bin2grey( grey2bin( grey_counter ) +1 ); and let my synthesizer loose on ity to see what it came up with. I'm sure this isn't the highest performance way of doing it, but for moderate speeds, it *is* easy. Synthesized with Foundation Express v3.3, each counter has Reset, Clk, Enable, and Count output, counting up only. Counter 4-input FFs CYs Width LUTs 4 4 4 5 8 5 6 9 6 7 11 7 20 38 20 19 I place and routed all of these counters in a Spartan-II 150-5, not adjusting any synthesis or place-and-route options, and came up with a frequency of 160MHz for the 7-bit counter. Anyone who's intereseted in the code (VHDL only.) is welcome to it, just let me know. -Kent ###### From: seamus Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Fri, 12 Jan 2001 13:47:08 GMT Organization: Deja.com Lines: 120 Message-ID: <93n1sq$a6h$1@nnrp1.deja.com> References: <3A5C2AE9.52717DAD@earthlink.net> NNTP-Posting-Host: 208.29.88.5 X-Article-Creation-Date: Fri Jan 12 13:47:08 2001 GMT X-Http-User-Agent: Mozilla/4.7 [en] (Win98; U) X-Http-Proxy: 1.0 x62.deja.com:80 (Squid/1.1.22) for client 208.29.88.5 X-MyDeja-Info: XMYDJUIDwoodyj 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.he.net!news-hog.berkeley.edu!newsfeed.berkeley.edu!ucberkeley!nntp2.deja.com!nnrp1.deja.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3772 In article <3A5C2AE9.52717DAD@earthlink.net>, lenihan3weNOSPAM@earthlink.net wrote: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? Here is a VHDL package to use gray-code structures in a high-level manner. Below that is a sample program that uses the package. - WJ ------------------------------------------------------------------------ ------ library ieee; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; package gray_pkg is type gray is array (natural range <>) of std_logic; function TO_GRAY (arg: unsigned) return gray; function TO_GRAY (arg, size: natural) return gray; function TO_UNSIGNED (arg: gray) return unsigned; function TO_INTEGER (arg: gray) return natural; function "+" (l: gray; r: natural) return gray; function "-" (l: gray; r: natural) return gray; function "=" (l: gray; r: natural) return boolean; end gray_pkg; package body gray_pkg is function TO_GRAY (arg: unsigned) return gray is begin return gray(arg xor '0' & arg(arg'LEFT downto arg'RIGHT+1)); end; -- TO_GRAY function TO_GRAY (arg, size: natural) return gray is begin return TO_GRAY(TO_UNSIGNED(arg, size)); end; -- TO_GRAY function TO_UNSIGNED (arg: gray) return unsigned is variable vect: unsigned(arg'RANGE); begin vect := unsigned(arg); for i in vect'LEFT-1 downto VECT'RIGHT loop vect(i) := vect(i+1) xor vect(i); end loop; return vect; end; -- TO_UNSIGNED function TO_INTEGER (arg: gray) return natural is begin return TO_INTEGER(TO_UNSIGNED(arg)); end; -- TO_INTEGER function "+" (l: gray; r: natural) return gray is variable vect : unsigned(l'RANGE); variable num : natural; begin return TO_GRAY(TO_UNSIGNED(l) + r); end; -- "+" function "-" (l: gray; r: natural) return gray is begin return TO_GRAY(TO_UNSIGNED(l) - r); end; -- "-" function "=" (l: gray; r: natural) return boolean is begin return r = TO_UNSIGNED(l); end; -- "=" end gray_pkg; ------------------------------------------------------------------------ ------ library ieee; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; use WORK.gray_pkg.all; entity gray_tst is port ( Rst : in std_logic; -- High active reset. Clk : in std_logic; -- Clock. Ena : in std_logic; -- Active-high syncronous count enable. Cnt : out std_logic_vector(9 downto 0));-- Gray code count. end gray_tst; architecture rtl of gray_tst is signal cnt_q : gray(9 downto 0); -- Counter register bits. begin --rtl ------------------------------------------------------------------------ ------ -- cnt_reg - gray counter that counts from 700 to 779 ------------------------------------------------------------------------ ------ cnt_reg : process (Clk, Rst) begin -- cnt_reg if (Rst = '1') then cnt_q <= TO_GRAY(700, cnt_q'LENGTH); elsif (Clk'event and Clk = '1') then if ( Ena = '1' ) then if ( cnt_q = 779 ) then cnt_q <= TO_GRAY(0, cnt_q'LENGTH); else cnt_q <= cnt_q + 1; end if; end if; end if; end process cnt_reg; Cnt <= std_logic_vector(TO_UNSIGNED(cnt_q)); end rtl; Sent via Deja.com http://www.deja.com/ ###### Message-ID: <3A60E39B.B6CDBAF@earthlink.net> From: Bill Lenihan Reply-To: lenihan3weNOSPAM@earthlink.net X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 38 Date: Sat, 13 Jan 2001 23:22:27 GMT NNTP-Posting-Host: 209.178.178.155 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 979428147 209.178.178.155 (Sat, 13 Jan 2001 15:22:27 PST) NNTP-Posting-Date: Sat, 13 Jan 2001 15:22:27 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news-stu1.dfn.de!news-mue1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.onemain.com!feed1.onemain.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3821 This sounds convenient, but the problem remains .... if a normal binary up counter looks like this: always @(posedge clk) count <= count +1; and we want the synthesis tool to turn this into a grey code counter for us: always @(posedge clk) count <= count +1 /* synthesis counter = grey */ ; .... then there's going to be a big discrepency between RTL & gate-level simulation results, if our simulator checks the counter! > > What I'd like to see (and I think I suggested this to the Synplicity > guys) is an attribute or something in the synthesis tool that lets you > select gray-code or binary-code counters. > > That would be useful. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u -- ============================== William Lenihan lenihan3weNOSPAM@earthlink.net .... remove "NOSPAM" when replying ============================== ###### Message-ID: <3A613623.42074BCA@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 48 Date: Sun, 14 Jan 2001 05:16:22 GMT NNTP-Posting-Host: 209.179.246.76 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 979449382 209.179.246.76 (Sat, 13 Jan 2001 21:16:22 PST) NNTP-Posting-Date: Sat, 13 Jan 2001 21:16:22 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-fra1.dfn.de!news-lei1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.onemain.com!feed1.onemain.com!newsfeed2.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:3819 I do not want to sound arrogant or pretentious, but I have already described a Grey counter design ( XORing the D inputs of a binary counter) that offers the fastest, most flexible and even cheapest solution in a Virtex-like environment. Why look at anything else ? A 24-bit synchronous binary counter runs 300 MHz in Virtex-II, and the Grey addition slows this down by less than one ns per period, still over 230 MHz in a fully synchronous and non-pipelined operation. What more do we need? All that still remains is to make available the right VHDL/Verilog code. Peter Alfke ============================= Bill Lenihan wrote: > This sounds convenient, but the problem remains .... if a normal binary up > counter looks like this: > > always @(posedge clk) count <= count +1; > > and we want the synthesis tool to turn this into a grey code counter for us: > > always @(posedge clk) count <= count +1 /* synthesis counter = grey */ ; > > .... then there's going to be a big discrepency between RTL & gate-level > simulation results, if our simulator checks the counter! > > > > > What I'd like to see (and I think I suggested this to the Synplicity > > guys) is an attribute or something in the synthesis tool that lets you > > select gray-code or binary-code counters. > > > > That would be useful. > > > > -- a > > ---------------------------- > > Andy Peters > > Sr. Electrical Engineer > > National Optical Astronomy Observatory > > 950 N Cherry Ave > > Tucson, AZ 85719 > > apeters (at) n o a o [dot] e d u > > -- > ============================== > William Lenihan > lenihan3weNOSPAM@earthlink.net > .... remove "NOSPAM" when replying > ============================== ###### Message-ID: <3A616749.2819FA4B@aracnet.com> From: bob elkind 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: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 153 Date: Sun, 14 Jan 2001 00:46:01 -0800 NNTP-Posting-Host: 216.99.198.186 X-Complaints-To: news@aracnet.com X-Trace: typhoon.aracnet.com 979461693 216.99.198.186 (Sun, 14 Jan 2001 00:41:33 PST) NNTP-Posting-Date: Sun, 14 Jan 2001 00:41:33 PST Organization: Aracnet Internet Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-fra1.dfn.de!news.tele.dk!216.218.192.242!news.he.net!typhoon.aracnet.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3810 The challenge was tempting... Here is an 8-bit grey counter, coded to make the "algorithm" clearly understood (hopefully). It is coded in Altera HDL (or AHDL), but the syntax is simple enough to be decipherable by the legions of VHDL/Verilogs designers out there. The code could be modified without much effort to have width determined by parameter passing. If you take this step, please post it to the newsgroup. The advantage of this coding is that the delay paths and bit "dependencies" are much closer to the conventional binary counter structure than some of the other algorithms mentioned in this thread. A disadvantage is that for N bits of counter, N x 1.5 FFs are needed. Each pair of bits in the count is treated as an 8-state value, where the extra bit represents the current count direction for the bit-pair. An advantage is that the "immediate" dependencies (or logic equations) are limited to three input terms, rather than the entire width of the counter (as long as you ignore carry terms!). Hopefully inspection of the code will be more clear than my attempts at explanation. -- Bob Elkind, eteam@aracnet.com Code follows: SUBDESIGN grey8 % 8-bit grey code counter, generalised to be extensible. structure is a unidirectional ripple carry, similar to conventional binary counter. counter is up *only*, not bidirectional. Bob Elkind, eteam@aracnet.com % ( clock : INPUT; -- main clock enable : input=vcc; -- clock enable reset : input=gnd; -- reset the puppy, default is off out[7..0] : output; -- outputs ) variable up[4..1] : srffe; temp[4..1][1..0] : node; cry[4..0] : node; cnt[4..1][1..0] : dffe; begin up[].clk = clock; up[].ena = enable; up[].prn = !reset; cnt[][].clk = clock; cnt[][].ena = enable; cnt[][].clrn = !reset; cry[0] = vcc; % The grey counter is segmented into bit pairs. For each bit-pair, there are 4 count values, and 2 direction-of-count values, hence 8 states. Sequence is: value direction carry out 0 up 0 1 up 0 3 up 0 2 up 1 2 down 0 3 down 0 1 down 0 0 down 1 This is sequence is implemented as a case statement or state machine, for each of the bit-pair segments. Also note that a "carry out" from the bit-pair to the next more significant bit-pair occurs on the same "states" which produce count direction changes. % FOR i IN 1 to 4 GENERATE case cnt[i][] is when 0 => if up[i] then temp[i][] = 1; else temp[i][] = 0; end if; when 1 => if up[i] then temp[i][] = 3; else temp[i][] = 0; end if; when 2 => if up[i] then temp[i][] = 2; else temp[i][] = 3; end if; when 3 => if up[i] then temp[i][] = 2; else temp[i][] = 1; end if; end case; if cry[i-1] then cnt[i][].d = temp[i][]; up[i].s = (cnt[i][]==0); -- change direction to up up[i].r = (cnt[i][]==2); -- change direction to down cry[i] = !cnt[i][0] and (cnt[i][1] == !up[i]); else cnt[i][].d = cnt[i][]; up[i].s = gnd; up[i].r = gnd; cry[i] = gnd; end if; END GENERATE; out[1..0] = cnt[1][]; out[3..2] = cnt[2][]; out[5..4] = cnt[3][]; out[7..6] = cnt[4][]; end; Bill Lenihan wrote: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? > ###### Message-ID: <3A61699E.96FCB2B1@aracnet.com> From: bob elkind 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: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 142 Date: Sun, 14 Jan 2001 00:55:58 -0800 NNTP-Posting-Host: 216.99.198.186 X-Complaints-To: news@aracnet.com X-Trace: typhoon.aracnet.com 979462290 216.99.198.186 (Sun, 14 Jan 2001 00:51:30 PST) NNTP-Posting-Date: Sun, 14 Jan 2001 00:51:30 PST Organization: Aracnet Internet Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-fra1.dfn.de!fu-berlin.de!news.maxwell.syr.edu!news.he.net!typhoon.aracnet.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3812 The challenge was tempting... Here is an 8-bit grey counter, coded to make the "algorithm" clearly understood (hopefully). It is coded in Altera HDL (or AHDL), but the syntax is simple enough to be decipherable by the legions of VHDL/Verilogs designers out there. The code could be modified without much effort to have width determined by parameter passing. If you take this step, please post it to the newsgroup. The advantage of this coding is that the delay paths and bit "dependencies" are much closer to the conventional binary counter structure than some of the other algorithms mentioned in this thread. A disadvantage is that for N bits of counter, N x 1.5 FFs are needed. Each pair of bits in the count is treated as an 8-state value, where the extra bit represents the current count direction for the bit-pair. An advantage is that the "immediate" dependencies (or logic equations) are limited to three input terms, rather than the entire width of the counter (as long as you ignore carry terms!). Hopefully inspection of the code will be more clear than my attempts at explanation. -- Bob Elkind, eteam@aracnet.com Code follows: SUBDESIGN grey8 % 8-bit grey code counter, generalised to be extensible. structure is a unidirectional ripple carry, similar to conventional binary counter. counter is up *only*, not bidirectional. Bob Elkind, eteam@aracnet.com % ( clock : INPUT; -- main clock enable : input=vcc; -- clock enable reset : input=gnd; -- reset the puppy, default is off out[7..0] : output; -- outputs ) variable up[4..1] : srffe; temp[4..1][1..0] : node; cry[4..0] : node; cnt[4..1][1..0] : dffe; begin up[].clk = clock; up[].ena = enable; up[].prn = !reset; cnt[][].clk = clock; cnt[][].ena = enable; cnt[][].clrn = !reset; cry[0] = vcc; % The grey counter is segmented into bit pairs. For each bit-pair, there are 4 count values, and 2 direction-of-count values, hence 8 states. Sequence is: value direction carry out 0 up 0 1 up 0 3 up 0 2 up 1 2 down 0 3 down 0 1 down 0 0 down 1 This is sequence is implemented as a case statement or state machine, for each of the bit-pair segments. Also note that a "carry out" from the bit-pair to the next more significant bit-pair occurs on the same "states" which produce count direction changes. % FOR i IN 1 to 4 GENERATE case cnt[i][] is when 0 => if up[i] then temp[i][] = 1; else temp[i][] = 0; end if; when 1 => if up[i] then temp[i][] = 3; else temp[i][] = 0; end if; when 2 => if up[i] then temp[i][] = 2; else temp[i][] = 3; end if; when 3 => if up[i] then temp[i][] = 2; else temp[i][] = 1; end if; end case; if cry[i-1] then cnt[i][].d = temp[i][]; up[i].s = (cnt[i][]==0); -- change direction to up up[i].r = (cnt[i][]==2); -- change direction to down cry[i] = !cnt[i][0] and (cnt[i][1] == !up[i]); else cnt[i][].d = cnt[i][]; up[i].s = gnd; up[i].r = gnd; cry[i] = gnd; end if; END GENERATE; out[1..0] = cnt[1][]; out[3..2] = cnt[2][]; out[5..4] = cnt[3][]; out[7..6] = cnt[4][]; end; Bill Lenihan wrote: > I know how to make binary up/down counters and LFSR-based counters in > verilog, but does anyone know of an algorithmic/equation-based way to > make grey-code counters? ###### From: erika_uk@my-deja.com Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Mon, 15 Jan 2001 16:38:25 GMT Organization: Deja.com Lines: 49 Message-ID: <93v921$ks0$1@nnrp1.deja.com> References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> NNTP-Posting-Host: 143.117.60.33 X-Article-Creation-Date: Mon Jan 15 16:38:25 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 95) X-Http-Proxy: 1.1 x61.deja.com:80 (Squid/1.1.22) for client 143.117.60.33 X-MyDeja-Info: XMYDJUIDerika_uk Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!blackbush.xlink.net!uni-erlangen.de!news-nue1.dfn.de!news-lei1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!nntp2.deja.com!nnrp1.deja.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3840 me i'll ask, why grey counter and not a simple binary ? In article <3A60E39B.B6CDBAF@earthlink.net>, lenihan3weNOSPAM@earthlink.net wrote: > This sounds convenient, but the problem remains .... if a normal binary up > counter looks like this: > > always @(posedge clk) count <= count +1; > > and we want the synthesis tool to turn this into a grey code counter for us: > > always @(posedge clk) count <= count +1 /* synthesis counter = grey */ ; > > .... then there's going to be a big discrepency between RTL & gate- level > simulation results, if our simulator checks the counter! > > > > > What I'd like to see (and I think I suggested this to the Synplicity > > guys) is an attribute or something in the synthesis tool that lets you > > select gray-code or binary-code counters. > > > > That would be useful. > > > > -- a > > ---------------------------- > > Andy Peters > > Sr. Electrical Engineer > > National Optical Astronomy Observatory > > 950 N Cherry Ave > > Tucson, AZ 85719 > > apeters (at) n o a o [dot] e d u > > -- > ============================== > William Lenihan > lenihan3weNOSPAM@earthlink.net > .... remove "NOSPAM" when replying > ============================== > > Sent via Deja.com http://www.deja.com/ ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Mon, 15 Jan 2001 09:42:28 -0800 Organization: Xilinx Lines: 62 Message-ID: <3A633683.2B844283@xilinx.com> References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> <93v921$ks0$1@nnrp1.deja.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: erika_uk@my-deja.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!ptdnetP!newsgate.ptd.net!attmtf.ip.att.net!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3826 Good Question: In a Grey counter, only one bit changes on any count. So when you run two Grey counters asynchronously ( like the address counters in an asynchronous FIFO) you can compare the two counters reliably, even during the transition, because there will never be a "far-out" code. You cannot do that with a binary counter, e.g. when it changes from 7 to 8. During that transition, you might accidentally read any possible 4-bit code. Peter Alfke ===================== erika_uk@my-deja.com wrote: > me i'll ask, why grey counter and not a simple binary ? > > In article <3A60E39B.B6CDBAF@earthlink.net>, > lenihan3weNOSPAM@earthlink.net wrote: > > This sounds convenient, but the problem remains .... if a normal > binary up > > counter looks like this: > > > > always @(posedge clk) count <= count +1; > > > > and we want the synthesis tool to turn this into a grey code counter > for us: > > > > always @(posedge clk) count <= count +1 /* synthesis counter = grey > */ ; > > > > .... then there's going to be a big discrepency between RTL & gate- > level > > simulation results, if our simulator checks the counter! > > > > > > > > What I'd like to see (and I think I suggested this to the Synplicity > > > guys) is an attribute or something in the synthesis tool that lets > you > > > select gray-code or binary-code counters. > > > > > > That would be useful. > > > > > > -- a > > > ---------------------------- > > > Andy Peters > > > Sr. Electrical Engineer > > > National Optical Astronomy Observatory > > > 950 N Cherry Ave > > > Tucson, AZ 85719 > > > apeters (at) n o a o [dot] e d u > > > > -- > > ============================== > > William Lenihan > > lenihan3weNOSPAM@earthlink.net > > .... remove "NOSPAM" when replying > > ============================== > > > > > > Sent via Deja.com > http://www.deja.com/ ###### From: Theron Hicks Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Mon, 15 Jan 2001 17:06:27 -0500 Organization: Michigan State University Lines: 67 Message-ID: <3A637462.63691335@egr.msu.edu> References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> <93v921$ks0$1@nnrp1.deja.com> <3A633683.2B844283@xilinx.com> NNTP-Posting-Host: dfti.egr.msu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-fra1.dfn.de!news0.de.colt.net!colt.net!news.maxwell.syr.edu!logbridge.uoregon.edu!msunews!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3827 Also, the switching noise may be substantially less as only one bit is changing at a time. Peter Alfke wrote: > Good Question: > In a Grey counter, only one bit changes on any count. So when you run two > Grey counters asynchronously ( like the address counters in an asynchronous > FIFO) you can compare the two counters reliably, even during the > transition, because there will never be a "far-out" code. > You cannot do that with a binary counter, e.g. when it changes from 7 to 8. > During that transition, you might accidentally read any possible 4-bit > code. > > Peter Alfke > ===================== > erika_uk@my-deja.com wrote: > > > me i'll ask, why grey counter and not a simple binary ? > > > > In article <3A60E39B.B6CDBAF@earthlink.net>, > > lenihan3weNOSPAM@earthlink.net wrote: > > > This sounds convenient, but the problem remains .... if a normal > > binary up > > > counter looks like this: > > > > > > always @(posedge clk) count <= count +1; > > > > > > and we want the synthesis tool to turn this into a grey code counter > > for us: > > > > > > always @(posedge clk) count <= count +1 /* synthesis counter = grey > > */ ; > > > > > > .... then there's going to be a big discrepency between RTL & gate- > > level > > > simulation results, if our simulator checks the counter! > > > > > > > > > > > What I'd like to see (and I think I suggested this to the Synplicity > > > > guys) is an attribute or something in the synthesis tool that lets > > you > > > > select gray-code or binary-code counters. > > > > > > > > That would be useful. > > > > > > > > -- a > > > > ---------------------------- > > > > Andy Peters > > > > Sr. Electrical Engineer > > > > National Optical Astronomy Observatory > > > > 950 N Cherry Ave > > > > Tucson, AZ 85719 > > > > apeters (at) n o a o [dot] e d u > > > > > > -- > > > ============================== > > > William Lenihan > > > lenihan3weNOSPAM@earthlink.net > > > .... remove "NOSPAM" when replying > > > ============================== > > > > > > > > > > Sent via Deja.com > > http://www.deja.com/ ###### Message-ID: <3A63ECE5.F06E7D19@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> <93v921$ks0$1@nnrp1.deja.com> <3A633683.2B844283@xilinx.com> <3A637462.63691335@egr.msu.edu> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 13 Date: Tue, 16 Jan 2001 06:40:42 GMT NNTP-Posting-Host: 209.179.192.76 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 979627242 209.179.192.76 (Mon, 15 Jan 2001 22:40:42 PST) NNTP-Posting-Date: Mon, 15 Jan 2001 22:40:42 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-fra1.dfn.de!news-lei1.dfn.de!news-nue1.dfn.de!uni-erlangen.de!newsfeed.germany.net!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!howland.erols.net!newsfeed.mindspring.net.MISMATCH!news.mindspring.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3852 Theoretically correct, but in reality it depends on the complexity of the Grey-control logic. In the design I am touting, there is actually a binary counter enclosed. Bye-bye power saving. Peter Alfke Theron Hicks wrote: > Also, the switching noise may be substantially less as only one bit is changing > at a time. > ###### Message-ID: <3A6398EA.35E066F4@aracnet.com> From: eteam Reply-To: eteam@aracnet.com Organization: The E-Team X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: grey code counters -- BUG FIX (OOPS!) References: <3A5C2AE9.52717DAD@earthlink.net> <3A61699E.96FCB2B1@aracnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 129 Date: Mon, 15 Jan 2001 16:42:18 -0800 NNTP-Posting-Host: 198.102.179.71 X-Complaints-To: news@aracnet.com X-Trace: typhoon.aracnet.com 979605731 198.102.179.71 (Mon, 15 Jan 2001 16:42:11 PST) NNTP-Posting-Date: Mon, 15 Jan 2001 16:42:11 PST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-fra1.dfn.de!news.tele.dk!216.218.192.242!news.he.net!typhoon.aracnet.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3838 Apologies to all, there was a bug in the code previously posted. There goes my reputation, shot to pieces! Sadly, netscape translates TAB characters to spaces, and messes up the columnation... - fixed a bug in the most significant bit-pair - parameterised the counter width - mapped the reset/init function to look up table logic, rather than async clear/preset If anyone wants the MAX+2 source code file and/or simulation file, drop me an email and I'll email it out to you. Posting binaries on this newsgroup is a no-no. -- Bob Elkind, eteam@aracnet.com ========= START OF CODE =========================== constant last = 4; -- specify the counter width in bit-pairs (i.e. if last == 4, then counter is 8 bits wide) -- this parameter can just as easily be passed from the subroutine "call" SUBDESIGN grey8 % REVISED -- MSBs aware, so that most-significant bit-pair counts on every "carry in". 8-bit grey code counter, generalised to be extensible. structure is a unidirectional ripple carry, similar to conventional binary counter. counter is up *only*, not bidirectional. Bob Elkind, eteam@aracnet.com % ( clock : INPUT; -- main clock enable : input=vcc; -- clock enable (or count enable) (or could use the cry[0] term) reset : input=gnd; -- reset the puppy, default is off out[(last*2-1)..0] : output; -- outputs ) variable up[last..1] : srffe; temp[last..1][1..0] : node; cry[last..0] : node; cnt[last..1][1..0] : dffe; begin up[].clk = clock; up[].ena = enable; cnt[][].clk = clock; cnt[][].ena = enable; cry[0] = vcc; -- carry in to LSB is always asserted % The grey counter is segmented into bit pairs. For each bit-pair, there are 4 count values, and 2 direction-of-count values, hence 8 states. Sequence is: value direction carry out 0 up 0 1 up 0 3 up 0 2 up 1 2 down 0 3 down 0 1 down 0 0 down 1 This is sequence is implemented as a case statement or state machine, for each of the bit-pair segments. Also note that a "carry out" from the bit-pair to the next more significant bit-pair occurs on the same "states" which produce count direction changes. % FOR i IN 1 to last GENERATE case cnt[i][] is when 0 => if up[i] or (i == last) then -- if up[i] then temp[i][] = 1; else temp[i][] = 0; end if; when 1 => if up[i] then temp[i][] = 3; else temp[i][] = 0; end if; when 2 => if up[i] and (i != last) then -- if up[i] then temp[i][] = 2; else temp[i][] = 3; end if; when 3 => if up[i] then temp[i][] = 2; else temp[i][] = 1; end if; end case; if cry[i-1] then -- if carry in, then update count and maybe assert carry out cnt[i][].d = temp[i][] and !reset; up[i].s = (cnt[i][]==0) or reset; -- change direction to up up[i].r = (cnt[i][]==2) and !reset; -- change direction to down cry[i] = !cnt[i][0] and (cnt[i][1]==up[i]) and !reset; -- carry out from this bit-pair else cnt[i][].d = cnt[i][] and !reset; -- no carry in, so no count up[i].s = reset; up[i].r = gnd; cry[i] = gnd; end if; out[(i*2-1)..(i*2-2)] = cnt[i][]; -- map bit-pairs of counter to function outputs END GENERATE; end; ###### From: Andy Peters <"apeters <"@> n o a o [.] e d u> Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Wed, 17 Jan 2001 11:17:19 -0700 Organization: National Optical Astronomy Observatory Lines: 40 Message-ID: <944nl8$nuh$2@noao.edu> References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> NNTP-Posting-Host: theremin.tuc.noao.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: noao.edu 979755496 24529 140.252.18.68 (17 Jan 2001 18:18:16 GMT) X-Complaints-To: abuse@noao.edu NNTP-Posting-Date: 17 Jan 2001 18:18:16 GMT X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en 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.cwix.com!ncar!noao!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3930 Bill Lenihan wrote: > > This sounds convenient, but the problem remains .... if a normal binary up > counter looks like this: > > always @(posedge clk) count <= count +1; > > and we want the synthesis tool to turn this into a grey code counter for us: > > always @(posedge clk) count <= count +1 /* synthesis counter = grey */ ; > > .... then there's going to be a big discrepency between RTL & gate-level > simulation results, if our simulator checks the counter! I see your point. Might be a problem for sign-off. Yeah, but what if your _simulator_ looked at the attribute and "did the right thing"? That's probably too much to ask. > > > > What I'd like to see (and I think I suggested this to the Synplicity > > guys) is an attribute or something in the synthesis tool that lets you > > select gray-code or binary-code counters. > > > > That would be useful. -- ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt." ###### Message-ID: <3A6DA613.55FA2B31@sqf.hp.com> Date: Tue, 23 Jan 2001 15:41:07 +0000 From: Nial Stewart Reply-To: nials@sqf.hp.com Organization: Agilent X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> <93v921$ks0$1@nnrp1.deja.com> <3A633683.2B844283@xilinx.com> <3A637462.63691335@egr.msu.edu> <3A63ECE5.F06E7D19@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: hpqt0797.britain.agilent.com X-Original-Trace: 23 Jan 2001 15:41:08 GMT, hpqt0797.britain.agilent.com Lines: 20 NNTP-Posting-Host: claymore.sqf.hp.com X-Trace: 23 Jan 2001 08:40:25 -0700, claymore.sqf.hp.com 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!nntp.primenet.com!nntp.gblx.net!enews.sgi.com!sdd.hp.com!hp-corv.cv.hp.com!hpb10302.boi.hp.com!claymore!hpqt0797.britain.agilent.com Xref: chonsp.franklin.ch comp.arch.fpga:4038 Peter Alfke wrote: > > Theoretically correct, > but in reality it depends on the complexity of the Grey-control logic. > In the design I am touting, there is actually a binary counter enclosed. > Bye-bye power saving. > > Peter Alfke > > Theron Hicks wrote: > > > Also, the switching noise may be substantially less as only one bit is changing > > at a time. > > But it could be a usefule technique if driving the address lines of a bank of external parrallel memory devices. Nial. ###### From: Rick Collins Newsgroups: comp.arch.fpga Subject: Re: grey code counters Date: Thu, 25 Jan 2001 23:26:50 -0500 Organization: Arius, Inc Lines: 47 Message-ID: <3A70FC8A.C15FE20@yahoo.com> References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> <93v921$ks0$1@nnrp1.deja.com> <3A633683.2B844283@xilinx.com> <3A637462.63691335@egr.msu.edu> <3A63ECE5.F06E7D19@earthlink.net> <3A6DA613.55FA2B31@sqf.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYEZoF+IpAcnxy4iVeyRhisN/qCdgb89gr07Xm60onJwvPj4pu11/BQ X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 26 Jan 2001 04:26:52 GMT X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news-stu1.dfn.de!news-mue1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:4210 Nial Stewart wrote: > > Peter Alfke wrote: > > > > Theoretically correct, > > but in reality it depends on the complexity of the Grey-control logic. > > In the design I am touting, there is actually a binary counter enclosed. > > Bye-bye power saving. > > > > Peter Alfke > > > > Theron Hicks wrote: > > > > > Also, the switching noise may be substantially less as only one bit is changing > > > at a time. > > > > > But it could be a usefule technique if driving the address > lines of a bank of external parrallel memory devices. > > Nial. I don't know that the power savings is tremendous. On the average a binary counter has two bits changing on each clock cycle. The lsb changes on every cycle, then next bit changes on every other, the next every fourth,... This series approaches 2 as the number of bits gets large. The Gray code counter has one bit changing on each clock. So the difference is a factor of two, useful, but not huge. -- 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX URL http://www.arius.com ###### Message-ID: <3A75786A.B7AF3E2D@sqf.hp.com> Date: Mon, 29 Jan 2001 14:04:26 +0000 From: Nial Stewart Reply-To: nials@sqf.hp.com Organization: Agilent X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: grey code counters References: <3A5C2AE9.52717DAD@earthlink.net> <93ll93$rcm$2@noao.edu> <3A60E39B.B6CDBAF@earthlink.net> <93v921$ks0$1@nnrp1.deja.com> <3A633683.2B844283@xilinx.com> <3A637462.63691335@egr.msu.edu> <3A63ECE5.F06E7D19@earthlink.net> <3A6DA613.55FA2B31@sqf.hp.com> <3A70FC8A.C15FE20@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: hpqt0797.britain.agilent.com X-Original-Trace: 29 Jan 2001 14:04:27 GMT, hpqt0797.britain.agilent.com Lines: 47 NNTP-Posting-Host: claymore.sqf.hp.com X-Trace: 29 Jan 2001 07:03:33 -0700, claymore.sqf.hp.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed1.earthlink.net!newsfeed.earthlink.net!feeder.via.net!enews.sgi.com!sdd.hp.com!hp-corv.cv.hp.com!hpb10302.boi.hp.com!claymore!hpqt0797.britain.agilent.com Xref: chonsp.franklin.ch comp.arch.fpga:4219 Rick Collins wrote: > > Nial Stewart wrote: > > > > Peter Alfke wrote: > > > > > > Theoretically correct, > > > but in reality it depends on the complexity of the Grey-control logic. > > > In the design I am touting, there is actually a binary counter enclosed. > > > Bye-bye power saving. > > > > > > Peter Alfke > > > > > > Theron Hicks wrote: > > > > > > > Also, the switching noise may be substantially less as only one bit is changing > > > > at a time. > > > > > > > > But it could be a usefule technique if driving the address > > lines of a bank of external parrallel memory devices. > > > > Nial. > > I don't know that the power savings is tremendous. On the average a > binary counter has two bits changing on each clock cycle. The lsb > changes on every cycle, then next bit changes on every other, the next > every fourth,... This series approaches 2 as the number of bits gets > large. The Gray code counter has one bit changing on each clock. So the > difference is a factor of two, useful, but not huge. Except where you're driving the address bus of a parralel bank of say 4 128K*8 Rams. If you had an instance where the address rolled over from 0 to 2^17 you'd be driving a load of 72 pins from 0 -> 1. This could potentially give you bad ground bounce problems. If you were driving the address bus with a grey code counter (and it's ram so you may as well) you'll always only be driving a load of 4 inputs on each address transition. It'll not help with power consumption, but might help but EMC/grounding issues. Nial.