From: jasjasjasjas@hotmail.com (jas) Newsgroups: comp.arch.fpga Subject: FPGA reset Date: 8 Oct 2001 23:49:23 -0700 Organization: http://groups.google.com/ Lines: 12 Message-ID: NNTP-Posting-Host: 47.211.0.13 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1002610163 8872 127.0.0.1 (9 Oct 2001 06:49:23 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 9 Oct 2001 06:49:23 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!feeder.qis.net!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10481 Hi, Are there timing issues on a Spartan device if the reset is asynchronous to the system clock, i.e could a problem occur where by the device is taken out of reset on the active clock edge, hence certain registers in the device remain in reset and the others are not. If so how is this solved, by registering the reset and not reseting that register?. Thanks jon ###### From: hmurray-nospam@megapathdsl.net (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: FPGA reset Date: Tue, 09 Oct 2001 07:13:14 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@hgm (Hal Murray) References: X-Complaints-To: newsabuse@supernews.com Lines: 25 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!sn-xit-03!sn-post-01!supernews.com!corp.supernews.com!hgm!hmurray-nospam Xref: chonsp.franklin.ch comp.arch.fpga:10475 >Are there timing issues on a Spartan device if the reset is >asynchronous to the system clock, i.e could a problem occur where by >the device is taken out of reset on the active clock edge, hence >certain registers in the device remain in reset and the others are >not. If so how is this solved, by registering the reset and not >reseting that register?. There was a lot of discussion on this area a year or so ago. My memory... The global reset signal isn't really as useful as you would like. It's just too slow. There are various kludges you can work out that will (roughly) do the right thing. I seem to remember that one of them was to generate a local reset signal and use that to startup a FSM. That takes a separate "reset" signal for each FSM and some mental checking to work it into the FSM logic. -- These are my opinions, not necessarily my employeers. I hate spam. ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: FPGA reset Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: <8f95st0rbpmptudhvkgfe8imjkfcjk0cbj@4ax.com> References: X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 28 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr14.news.prodigy.com 1002612344 ST000 216.103.85.188 (Tue, 09 Oct 2001 03:25:44 EDT) NNTP-Posting-Date: Tue, 09 Oct 2001 03:25:44 EDT X-UserInfo1: Q[R_PJSCTS@_BPLX^BN@^QLAUKXD@D@MGPW^OBPLAH[\BQUBLNTC@AWZWDXZXQ[K\FFSKCVM@F_N_DOBWVWG__LG@VVOIPLIGX\\BU_B@\P\PFX\B[APHTWAHDCKJF^NHD[YJAZMCY_CWG[SX\Y]^KC\HSZRWSWKGAY_PC[BQ[BXAS\F\\@DMTLFZFUE@\VL Date: Tue, 09 Oct 2001 07:25:44 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news-hub.siol.net!news-out.cwix.com!newsfeed.cwix.com!newscon01.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr14.news.prodigy.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10463 Good question. This has been covered previously. The thread was titled: "Is it necessary to synchronize the reset signal in an FPGA ?" You can read my comments and others in the Archive at: http://www.fpga-faq.com/archives/27900.html#27917 Philip On 8 Oct 2001 23:49:23 -0700, jasjasjasjas@hotmail.com (jas) wrote: >Hi, > >Are there timing issues on a Spartan device if the reset is >asynchronous to the system clock, i.e could a problem occur where by >the device is taken out of reset on the active clock edge, hence >certain registers in the device remain in reset and the others are >not. If so how is this solved, by registering the reset and not >reseting that register?. > >Thanks > >jon Philip Freidin Fliptronics ###### From: "Andrew Brown" Newsgroups: comp.arch.fpga Subject: Re: FPGA reset Date: Tue, 9 Oct 2001 10:01:37 +0100 Organization: Nortel Lines: 36 Message-ID: <9puedc$bi1$1@bcarh8ab.ca.nortel.com> References: NNTP-Posting-Host: pireyamd.europe.nortel.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!sunqbc.risq.qc.ca!torn!qcarhaaa.nortelnetworks.com!bcarh189.ca.nortel.com!bcarh8ac.ca.nortel.com!bcarh8ab.ca.nortel.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10476 Dedicated reset nets within FPGAs should be 'trees' which means that regardless of how long it takes for the reset to propagate throughout the chip, it arrives at all flops at the same time (roughly). Unfortunately - whether this is true or not, you can still release an asynchronous reset at the same time as a clock and you can't tell which cycle the flops are reset in. The basic idea is that asynchronous resets can be applied asynchronously but must be removed synchronously (very hard to do) to avoid problems. An alternative is to ensure your logic cannot get in a stuck state (good design practice) and use other methods to synchronise the various element of the system. A. "Hal Murray" wrote in message news:ts58san373oj0b@corp.supernews.com... > > >Are there timing issues on a Spartan device if the reset is > >asynchronous to the system clock, i.e could a problem occur where by > >the device is taken out of reset on the active clock edge, hence > >certain registers in the device remain in reset and the others are > >not. If so how is this solved, by registering the reset and not > >reseting that register?. > > The global reset signal isn't really as useful as you would like. > It's just too slow. > > There are various kludges you can work out that will (roughly) > do the right thing. I seem to remember that one of them > was to generate a local reset signal and use that to startup > a FSM. That takes a separate "reset" signal for each FSM > and some mental checking to work it into the FSM logic. ###### From: "Austin Franklin" Newsgroups: comp.arch.fpga Subject: Re: FPGA reset Date: Tue, 9 Oct 2001 10:37:00 -0400 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Complaints-To: newsabuse@supernews.com Lines: 32 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.stanford.edu!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10477 Just a note on using GSR-not using GSR with synthesis. GSR routing is free, it is dedicated copper...and can be used for nothing else. If you do NOT use GSR, and have a reset in your design (as you probably should) you are using regular routing resources for this possibly very prolific global net. In order for synthesis to use GSR (at least Synplicity) EVERY flop must be attached to GSR, or it will use regular routing resources. Why are using regular routing resources bad? If your design is quite full, it can significantly impact timing and tool run time. One design I had in an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR. As Philip's post suggests (hell, says), it is VERY easy to still use the GSR and design such that this does not create any problems with your design. It just takes a little understanding of how your design works, and a bit of engineering. "jas" wrote in message news:fe3da0d7.0110082249.42642566@posting.google.com... > Hi, > > Are there timing issues on a Spartan device if the reset is > asynchronous to the system clock, i.e could a problem occur where by > the device is taken out of reset on the active clock edge, hence > certain registers in the device remain in reset and the others are > not. If so how is this solved, by registering the reset and not > reseting that register?. > > Thanks > > jon ###### From: tom_systek@msn.com (Tom Seim) Newsgroups: comp.arch.fpga Subject: Re: FPGA reset Date: 9 Oct 2001 14:03:39 -0700 Organization: http://groups.google.com/ Lines: 42 Message-ID: <308fd995.0110091303.232e2716@posting.google.com> References: NNTP-Posting-Host: 63.25.45.82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1002661419 23291 127.0.0.1 (9 Oct 2001 21:03:39 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 9 Oct 2001 21:03:39 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!feeder.qis.net!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10486 My greatest grief with Xilinx (right after the blunder Xilinx made switching suppliers of the serial proms - the new supplier couldn't deliver as scheduled and the old one had been axed) has been the power-up sequencing. The FPGAs and serial proms have internal power-up sequencing circuitry so you think: "I'm ok using that". Wrong. I have seen the serial prom & FPGA get out of sync due to either too fast/slow Vcc rise time and/or a small spike on Vcc at the wrong moment. The serial prom's address counter will keep going & eventually recycle, but this takes forever! I've ALWAYS used a seperate power reset circuit after that. "Austin Franklin" wrote in message news:... > Just a note on using GSR-not using GSR with synthesis. GSR routing is free, > it is dedicated copper...and can be used for nothing else. If you do NOT > use GSR, and have a reset in your design (as you probably should) you are > using regular routing resources for this possibly very prolific global net. > In order for synthesis to use GSR (at least Synplicity) EVERY flop must be > attached to GSR, or it will use regular routing resources. > > Why are using regular routing resources bad? If your design is quite full, > it can significantly impact timing and tool run time. One design I had in > an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR. > > As Philip's post suggests (hell, says), it is VERY easy to still use the GSR > and design such that this does not create any problems with your design. It > just takes a little understanding of how your design works, and a bit of > engineering. > > "jas" wrote in message > news:fe3da0d7.0110082249.42642566@posting.google.com... > > Hi, > > > > Are there timing issues on a Spartan device if the reset is > > asynchronous to the system clock, i.e could a problem occur where by > > the device is taken out of reset on the active clock edge, hence > > certain registers in the device remain in reset and the others are > > not. If so how is this solved, by registering the reset and not > > reseting that register?. > > > > Thanks > > > > jon ###### Message-ID: <3BC3AC3C.3007C379@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: FPGA reset References: <308fd995.0110091303.232e2716@posting.google.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 57 Date: Wed, 10 Oct 2001 02:02:38 GMT NNTP-Posting-Host: 209.179.246.203 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1002679358 209.179.246.203 (Tue, 09 Oct 2001 19:02:38 PDT) NNTP-Posting-Date: Tue, 09 Oct 2001 19:02:38 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Tue, 09 Oct 2001 18:59:02 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone2.usenetserver.com!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:10501 Did you make the recommended connection: INIT driving the SPROM Reset ? Xilinx has promoted this as the only reasonable and safe method for at least the past eight years, way back in the XC3000 data sheet. ( I remember, I was the one putting it in, and even explaining the reason why ). Without that connection you can encounter all sorts of grief... With this connection, you would only have a problem if the power-on reset is longer in the SPROM than it is in the FPGA. To the best of my knowledge, that has been the case only in certain Atmel SPROMs. But I am listening...One never stops learning. Peter Alfke, Xilinx Applications =============================== Tom Seim wrote: > My greatest grief with Xilinx (right after the blunder Xilinx made > switching suppliers of the serial proms - the new supplier couldn't > deliver as scheduled and the old one had been axed) has been the > power-up sequencing. The FPGAs and serial proms have internal power-up > sequencing circuitry so you think: "I'm ok using that". Wrong. > I have seen the serial prom & FPGA get out of sync due to either too > fast/slow Vcc rise time and/or a small spike on Vcc at the wrong > moment. The serial prom's address counter will keep going & eventually > recycle, but this takes forever! I've ALWAYS used a seperate power > reset circuit after that. > > "Austin Franklin" wrote in message news:... > > Just a note on using GSR-not using GSR with synthesis. GSR routing is free, > > it is dedicated copper...and can be used for nothing else. If you do NOT > > use GSR, and have a reset in your design (as you probably should) you are > > using regular routing resources for this possibly very prolific global net. > > In order for synthesis to use GSR (at least Synplicity) EVERY flop must be > > attached to GSR, or it will use regular routing resources. > > > > Why are using regular routing resources bad? If your design is quite full, > > it can significantly impact timing and tool run time. One design I had in > > an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR. > > > > As Philip's post suggests (hell, says), it is VERY easy to still use the GSR > > and design such that this does not create any problems with your design. It > > just takes a little understanding of how your design works, and a bit of > > engineering. > > > > "jas" wrote in message > > news:fe3da0d7.0110082249.42642566@posting.google.com... > > > Hi, > > > > > > Are there timing issues on a Spartan device if the reset is > > > asynchronous to the system clock, i.e could a problem occur where by > > > the device is taken out of reset on the active clock edge, hence > > > certain registers in the device remain in reset and the others are > > > not. If so how is this solved, by registering the reset and not > > > reseting that register?. > > > > > > Thanks > > > > > > jon ###### From: tom_systek@msn.com (Tom Seim) Newsgroups: comp.arch.fpga Subject: Re: FPGA reset Date: 10 Oct 2001 09:46:15 -0700 Organization: http://groups.google.com/ Lines: 69 Message-ID: <308fd995.0110100846.49fdf95@posting.google.com> References: <308fd995.0110091303.232e2716@posting.google.com> <3BC3AC3C.3007C379@earthlink.net> NNTP-Posting-Host: 63.22.7.209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1002732375 9299 127.0.0.1 (10 Oct 2001 16:46:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 10 Oct 2001 16:46:15 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!xfer02.netnews.com!newsfeed1.cidera.com!Cidera!sjcppf01.usenetserver.com!usenetserver.com!sn-xit-04!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10514 Peter, I think I talked to you when we were having the problem about 10 years ago. All of our designs have a reset controller anyhow, so this was a mod with only moderate pain (figuring it out, however, is a different level of pain). I drive the DONE pin with the reset controller thru a Shottky diode. This, in turn, is the reset input to the rest of the logic/processor, guaranteeing that the FPGA is configured before the processor starts running. Tom Peter Alfke wrote in message news:<3BC3AC3C.3007C379@earthlink.net>... > Did you make the recommended connection: INIT driving the SPROM Reset ? > Xilinx has promoted this as the only reasonable and safe method for at least the past eight years, way > back in the XC3000 data sheet. ( I remember, I was the one putting it in, and even explaining the reason > > why ). Without that connection you can encounter all sorts of grief... > With this connection, you would only have a problem if the power-on reset is longer in the SPROM than it > is in the FPGA. To the best of my knowledge, that has been the case only in certain Atmel SPROMs. > But I am listening...One never stops learning. > > Peter Alfke, Xilinx Applications > =============================== > > Tom Seim wrote: > > > My greatest grief with Xilinx (right after the blunder Xilinx made > > switching suppliers of the serial proms - the new supplier couldn't > > deliver as scheduled and the old one had been axed) has been the > > power-up sequencing. The FPGAs and serial proms have internal power-up > > sequencing circuitry so you think: "I'm ok using that". Wrong. > > I have seen the serial prom & FPGA get out of sync due to either too > > fast/slow Vcc rise time and/or a small spike on Vcc at the wrong > > moment. The serial prom's address counter will keep going & eventually > > recycle, but this takes forever! I've ALWAYS used a seperate power > > reset circuit after that. > > > > "Austin Franklin" wrote in message news:... > > > Just a note on using GSR-not using GSR with synthesis. GSR routing is free, > > > it is dedicated copper...and can be used for nothing else. If you do NOT > > > use GSR, and have a reset in your design (as you probably should) you are > > > using regular routing resources for this possibly very prolific global net. > > > In order for synthesis to use GSR (at least Synplicity) EVERY flop must be > > > attached to GSR, or it will use regular routing resources. > > > > > > Why are using regular routing resources bad? If your design is quite full, > > > it can significantly impact timing and tool run time. One design I had in > > > an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR. > > > > > > As Philip's post suggests (hell, says), it is VERY easy to still use the GSR > > > and design such that this does not create any problems with your design. It > > > just takes a little understanding of how your design works, and a bit of > > > engineering. > > > > > > "jas" wrote in message > > > news:fe3da0d7.0110082249.42642566@posting.google.com... > > > > Hi, > > > > > > > > Are there timing issues on a Spartan device if the reset is > > > > asynchronous to the system clock, i.e could a problem occur where by > > > > the device is taken out of reset on the active clock edge, hence > > > > certain registers in the device remain in reset and the others are > > > > not. If so how is this solved, by registering the reset and not > > > > reseting that register?. > > > > > > > > Thanks > > > > > > > > jon ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: FPGA reset Date: Wed, 10 Oct 2001 11:46:40 -0700 Organization: Xilinx Lines: 78 Message-ID: <3BC49790.3103A091@xilinx.com> References: <308fd995.0110091303.232e2716@posting.google.com> <3BC3AC3C.3007C379@earthlink.net> <308fd995.0110100846.49fdf95@posting.google.com> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en To: Tom Seim Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!4.1.16.34!cpk-news-hub1.bbnplanet.com!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10489 You are now describing something different, and it seems to work well. I was addressing your original complaint about SPROM and FPGA getting out of sync with respect to each other. That should never occur if INIT resets the SPROM. Peter Alfke, Xilinx Applications =============================== Tom Seim wrote: > Peter, > > I think I talked to you when we were having the problem about 10 years > ago. All of our designs have a reset controller anyhow, so this was a > mod with only moderate pain (figuring it out, however, is a different > level of pain). I drive the DONE pin with the reset controller thru a > Shottky diode. This, in turn, is the reset input to the rest of the > logic/processor, guaranteeing that the FPGA is configured before the > processor starts running. > > Tom > > Peter Alfke wrote in message news:<3BC3AC3C.3007C379@earthlink.net>... > > Did you make the recommended connection: INIT driving the SPROM Reset ? > > Xilinx has promoted this as the only reasonable and safe method for at least the past eight years, way > > back in the XC3000 data sheet. ( I remember, I was the one putting it in, and even explaining the reason > > > > why ). Without that connection you can encounter all sorts of grief... > > With this connection, you would only have a problem if the power-on reset is longer in the SPROM than it > > is in the FPGA. To the best of my knowledge, that has been the case only in certain Atmel SPROMs. > > But I am listening...One never stops learning. > > > > Peter Alfke, Xilinx Applications > > =============================== > > > > Tom Seim wrote: > > > > > My greatest grief with Xilinx (right after the blunder Xilinx made > > > switching suppliers of the serial proms - the new supplier couldn't > > > deliver as scheduled and the old one had been axed) has been the > > > power-up sequencing. The FPGAs and serial proms have internal power-up > > > sequencing circuitry so you think: "I'm ok using that". Wrong. > > > I have seen the serial prom & FPGA get out of sync due to either too > > > fast/slow Vcc rise time and/or a small spike on Vcc at the wrong > > > moment. The serial prom's address counter will keep going & eventually > > > recycle, but this takes forever! I've ALWAYS used a seperate power > > > reset circuit after that. > > > > > > "Austin Franklin" wrote in message news:... > > > > Just a note on using GSR-not using GSR with synthesis. GSR routing is free, > > > > it is dedicated copper...and can be used for nothing else. If you do NOT > > > > use GSR, and have a reset in your design (as you probably should) you are > > > > using regular routing resources for this possibly very prolific global net. > > > > In order for synthesis to use GSR (at least Synplicity) EVERY flop must be > > > > attached to GSR, or it will use regular routing resources. > > > > > > > > Why are using regular routing resources bad? If your design is quite full, > > > > it can significantly impact timing and tool run time. One design I had in > > > > an XCV300 went from 45 minutes to 9 minutes PAR time when I used GSR. > > > > > > > > As Philip's post suggests (hell, says), it is VERY easy to still use the GSR > > > > and design such that this does not create any problems with your design. It > > > > just takes a little understanding of how your design works, and a bit of > > > > engineering. > > > > > > > > "jas" wrote in message > > > > news:fe3da0d7.0110082249.42642566@posting.google.com... > > > > > Hi, > > > > > > > > > > Are there timing issues on a Spartan device if the reset is > > > > > asynchronous to the system clock, i.e could a problem occur where by > > > > > the device is taken out of reset on the active clock edge, hence > > > > > certain registers in the device remain in reset and the others are > > > > > not. If so how is this solved, by registering the reset and not > > > > > reseting that register?. > > > > > > > > > > Thanks > > > > > > > > > > jon ###### From: hmurray-nospam@megapathdsl.net (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: FPGA reset Date: Thu, 11 Oct 2001 07:34:37 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@hgm (Hal Murray) References: X-Complaints-To: newsabuse@supernews.com Lines: 25 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!feeder.qis.net!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!hgm!hmurray-nospam Xref: chonsp.franklin.ch comp.arch.fpga:10604 >Just a note on using GSR-not using GSR with synthesis. GSR routing is free, >it is dedicated copper...and can be used for nothing else. If you do NOT >use GSR, and have a reset in your design (as you probably should) you are >using regular routing resources for this possibly very prolific global net. >In order for synthesis to use GSR (at least Synplicity) EVERY flop must be >attached to GSR, or it will use regular routing resources. Thanks for the reminder. How come all the pictures in the Xilinx data sheets telling us where the muxes are and which signals go where don't show the GSR signal? (Am I just missing it?) Is GSR a not-shown input to some mux or is there an extra GSR input on the FF that's not shown? Does GSR get ORed with the set/reset the picture shows? If I trick the tools into using the GSR signal, am I wasting the normal set/reset logic? (Or are the tools smart enough to use them too, if the hardware supports that?) -- These are my opinions, not necessarily my employeers. I hate spam. ###### Message-ID: <3BC5A472.7730BA95@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: FPGA reset References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 45 Date: Thu, 11 Oct 2001 13:53:10 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 1002808390 24.13.238.93 (Thu, 11 Oct 2001 06:53:10 PDT) NNTP-Posting-Date: Thu, 11 Oct 2001 06:53:10 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news.stealth.net!jfk3-feed1.news.digex.net!dca6-feed2.news.digex.net!intermedia!newsfeed1.cidera.com!Cidera!cpk-news-hub1.bbnplanet.com!news.gtei.net!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10541 GSR is a dedicated net into the FF, which is in addition to, and independent of the S/R input you see in the drawings. The signals are essentially OR'd. As others have mentioned, you can't depend on the GSR signal propagating through the whole tree within a clock cycle even if you synchronize it to the clock if your clock is anywhere near what the FPGA is capable of. You need to use GSR to get it to known start state and not allow anything to strat 'moving' until some delay after GSR goes so that you allow multiple clock cycles for GSR to go away. Hal Murray wrote: > >Just a note on using GSR-not using GSR with synthesis. GSR routing is free, > >it is dedicated copper...and can be used for nothing else. If you do NOT > >use GSR, and have a reset in your design (as you probably should) you are > >using regular routing resources for this possibly very prolific global net. > >In order for synthesis to use GSR (at least Synplicity) EVERY flop must be > >attached to GSR, or it will use regular routing resources. > > Thanks for the reminder. > > How come all the pictures in the Xilinx data sheets telling us > where the muxes are and which signals go where don't show the GSR > signal? (Am I just missing it?) > > Is GSR a not-shown input to some mux or is there an extra GSR > input on the FF that's not shown? Does GSR get ORed with the > set/reset the picture shows? If I trick the tools into using > the GSR signal, am I wasting the normal set/reset logic? (Or > are the tools smart enough to use them too, if the hardware > supports that?) > > -- > These are my opinions, not necessarily my employeers. I hate spam. -- --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