From: "Dziadek" Newsgroups: comp.arch.fpga Subject: Spartan-2 reset: sync or async? Date: Fri, 10 Jan 2003 07:57:41 +0100 Organization: tp.internet - http://www.tpi.pl/ Lines: 18 Message-ID: NNTP-Posting-Host: 195.117.126.248 X-Trace: news.tpi.pl 1042181812 21200 195.117.126.248 (10 Jan 2003 06:56:52 GMT) X-Complaints-To: usenet@tpi.pl NNTP-Posting-Date: Fri, 10 Jan 2003 06:56:52 +0000 (UTC) X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MSMail-Priority: Normal X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!proxad.net!newsfeed.tpinternet.pl!news.tpi.pl!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24690 Hi, I have a choice between synchronous and asynchronous global reset in the design. In older devices choosing async reset usually lowered resource utilization due to dedicated async reset input of the CLB. How is it now, with Spartan-2 and newer that have sync/async choice for the dedicated reset input? Which method is recommended? Sync method seems better (simpler timing management), but maybe there are some dark sides. Can you share some experience? Regards, Dziadek ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Spartan-2 reset: sync or async? Date: Fri, 10 Jan 2003 07:27:31 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: X-Complaints-To: abuse@supernews.com Lines: 22 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeeds.sol.net!news-feed.riddles.org.uk!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:24699 >I have a choice between synchronous and asynchronous global reset in the >design. In older devices choosing async reset usually lowered resource >utilization due to dedicated async reset input of the CLB. This gets discussed here occasionally. Check google-groups. There are two major problems the global reset: It's sloooow. So it (normally) doesn't do you any good to make it synchronous. (even if you have only one main clock) It's async, so you have to consider metastability. Mostly, this means looking at what happens when state machines come out of reset. One trick is to have a local FF that is used to reset the state machine. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### From: "John_H" Newsgroups: comp.arch.fpga References: Subject: Re: Spartan-2 reset: sync or async? Lines: 35 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Fri, 10 Jan 2003 16:47:48 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@opbu.xerox.com X-Trace: news-west.eli.net 1042217268 192.65.17.17 (Fri, 10 Jan 2003 09:47:48 MST) NNTP-Posting-Date: Fri, 10 Jan 2003 09:47:48 MST Organization: Xerox Officeprinting NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!logbridge.uoregon.edu!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24696 I've been using synchronous resets in my designs almost exclusively. Since the dedicated reset line is so slow, you would have to design your system to safely start up when there's a clock cycle (more, perhaps) where part of the chip is still in reset while the rest of the chip is on the first clock cycle out of reset even when the reset signal is externally synchronized to the clock. Without external synchronization, even a fast reset resource would often leave part of the chip reset for an extra clock cycle compared to the rest. Timing analysis is cleaner with synchronous resets. Some FPGA features - like the Xilinx shift registers and distributed RAM - don't like to have resets of any kind making the global use of asynchronous reset structures less desireable. "Dziadek" wrote in message news:avlqrk$kmg$1@news.tpi.pl... > Hi, > > I have a choice between synchronous and asynchronous global reset in the > design. In older devices choosing async reset usually lowered resource > utilization due to dedicated async reset input of the CLB. > > How is it now, with Spartan-2 and newer that have sync/async choice for the > dedicated reset input? Which method is recommended? Sync method seems better > (simpler timing management), but maybe there are some dark sides. Can you > share some experience? > > Regards, > Dziadek ###### From: "Rob Finch" Newsgroups: comp.arch.fpga References: Subject: Re: Spartan-2 reset: sync or async? Lines: 62 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Sat, 11 Jan 2003 20:10:58 -0500 NNTP-Posting-Host: 65.95.20.44 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1042333863 65.95.20.44 (Sat, 11 Jan 2003 20:11:03 EST) NNTP-Posting-Date: Sat, 11 Jan 2003 20:11:03 EST Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.cwix.com!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:24770 > I have a choice between synchronous and asynchronous global reset in the > design. In older devices choosing async reset usually lowered resource > utilization due to dedicated async reset input of the CLB. > > How is it now, with Spartan-2 and newer that have sync/async choice for the > dedicated reset input? Which method is recommended? Sync method seems better > (simpler timing management), but maybe there are some dark sides. Can you > share some experience? > Based on the discussions in this newsgroup: I use an asynchronous global reset (with lax timing constraints = none) to make use of the global reset network so routing resource are not wasted on reset. Then I use a locally generated synchronous "critical" reset signal to synchronously reset the few ff's (say a dozen) who's reset state is critical to the operation of the design. The global reset signal resets everything (including the critical reset generator) by taking a varying number of clock cycles (it's async). The critical reset generator holds the reset state of the few ff's until a few cycles after the global reset is gone. Because the critical synchronous reset net is very localized it does not impact meeting timing requirements for the design, which might be a problem if a global synchronous reset were being used. // Generate critical reset always @(posedge clk) if (reset) // this is the async reset fed into the system cres <= 8'hFF; // This is just the timeout pattern (active high reset) else cres <= {cres[6:0],1'b0}; // shift reg // creset is the synch. reset signal which drive the few ff's that need to be synchronously reset // for proper operation. It will be held active until some cycles after the async reset. // How long the creset signal has to be held depends on how many clock cycles difference // there could be between different ff's in the design being reset async. This depends on the // clock operating frequency and the amount of delay in the async reset to various parts of the // design. assign creset = cres[6]; I wonder how hard it would be for FPGA manufacturers to feed a global reset signal to only a few CLB's sprinkled around the FPGA rather than driving every ff with a global reset signal ? This would allow for a few local reset generators. Then, for the few parts of a design that may require synch. reset local routing could be used. The LUT shift registers are great but it sure would be nice if they could accomodate a reset input. Otherwise how about some dedicated shift registers with reset input ? Rob rob@birdcomputer.ca www.birdcomputer.ca