From: "..:: Gabster ::.." Newsgroups: comp.arch.fpga Subject: Reseting the whole thing Lines: 12 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Fri, 25 Jul 2003 00:40:44 -0400 NNTP-Posting-Host: 24.202.119.98 X-Complaints-To: abuse@videotron.ca X-Trace: weber.videotron.net 1059108149 24.202.119.98 (Fri, 25 Jul 2003 00:42:29 EDT) NNTP-Posting-Date: Fri, 25 Jul 2003 00:42:29 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!nntp-relay.ihug.net!ihug.co.nz!nntp.cs.ubc.ca!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!wesley.videotron.net!weber.videotron.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31163 Hi, I want to use a simple reset circuit to reset my FPGA, but I'm unsure how to handle it because of the PROM. The point is the PROM has to program the FPGA before the FPGA is reset. How the reset circuit could to be implemented considering this. I was thinking about a reset circuit with a built-in delay, but I'm sure there's a easier way to do it. thanks, Gabriel ###### From: Andrew Paule User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Reseting the whole thing References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 25 Message-ID: Date: Fri, 25 Jul 2003 00:28:48 -0500 NNTP-Posting-Host: 63.229.197.216 X-Trace: news.uswest.net 1059110753 63.229.197.216 (Fri, 25 Jul 2003 00:25:53 CDT) NNTP-Posting-Date: Fri, 25 Jul 2003 00:25:53 CDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!switch.ch!news.tele.dk!news.tele.dk!small.news.tele.dk!news-out.visi.com!petbe.visi.com!feed.news.qwest.net!news.uswest.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31148 Ti makes reset controllers with programmable delay (Ti7733/7705/7725 etc) that you could either put a simple RC on that gives enough delay - make it longer that the programming time, or you could use the done pin on a Xilinx or Altera part to kick the reset controller - I'm guessing that you are using one of the two, but I'm shooting in the dark Andrew ..:: Gabster ::.. wrote: >Hi, > > I want to use a simple reset circuit to reset my FPGA, but I'm unsure >how to handle it because of the PROM. The point is the PROM has to program >the FPGA before the FPGA is reset. How the reset circuit could to be >implemented considering this. I was thinking about a reset circuit with a >built-in delay, but I'm sure there's a easier way to do it. > >thanks, >Gabriel > > > > ###### From: John Williams Newsgroups: comp.arch.fpga Subject: Re: Reseting the whole thing Date: Fri, 25 Jul 2003 15:46:36 +1000 Organization: ITEE, University of Queensland Lines: 17 Message-ID: References: Reply-To: jwilliams@itee.uq.edu.au NNTP-Posting-Host: g435-9029.itee.uq.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: bunyip.cc.uq.edu.au 1059111609 12542 130.102.66.250 (25 Jul 2003 05:40:09 GMT) X-Complaints-To: news@uq.edu.au NNTP-Posting-Date: 25 Jul 2003 05:40:09 GMT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en In-Reply-To: Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!newsfeed.vmunix.org!news1.optus.net.au!optus!news.mel.connect.com.au!news.syd.connect.com.au!news.bri.connect.com.au!bunyip.cc.uq.edu.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31156 ..:: Gabster ::.. wrote: > Hi, > > I want to use a simple reset circuit to reset my FPGA, but I'm unsure > how to handle it because of the PROM. The point is the PROM has to program > the FPGA before the FPGA is reset. How the reset circuit could to be > implemented considering this. I was thinking about a reset circuit with a > built-in delay, but I'm sure there's a easier way to do it. Isn't there a setting in the configuration control whereby the FPGA will assert a global reset signal after configuration? It means you need to route said reset signal around your entire design, but you'd have to do that anyway if I'm understanding the question properly. John ###### Reply-To: "Martin Euredjian" <0_0_0_0_@pacbell.net> From: "Martin Euredjian" <0_0_0_0_@pacbell.net> Newsgroups: comp.arch.fpga References: Subject: Re: Reseting the whole thing Lines: 48 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: NNTP-Posting-Host: 64.170.224.250 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr22.news.prodigy.com 1059113370 ST000 64.170.224.250 (Fri, 25 Jul 2003 02:09:30 EDT) NNTP-Posting-Date: Fri, 25 Jul 2003 02:09:30 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: O@XURZ_DPJUQBFH[OZK@_TDAYZOZ@GXOXJXNMRQIMASJETAANVW[AKWZE\]^XQWIGNE_[EBL@^_\^JOCQ^RSNVLGTFTKHTXHHP[NB\_C@\SD@EP_[KCXX__AGDDEKGFNB\ZOKLRNCY_CGG[RHT_UN@C_BSY\G__IJIX_PLSA[CCFAULEY\FL\VLGANTQQ]FN Date: Fri, 25 Jul 2003 06:09:30 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!in.100proofnews.com!in.100proofnews.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr22.news.prodigy.com.POSTED!003b42bf!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31184 Why is it that you want to reset the FPGA after configuration? For all intents and purposes it is coming out of reset after configuration. If you need to do so in order to wait for an event build that into a startup state machine. If you need to guarantee that other portions of the board are ready you can also build that into a startup state machine. If you need to ensure that certain flip-flops and logic come-up in a specific state you can do that through the bitmap itself. I've read quite a bit about global reset not being a reliable approach. Do a Google search of this N.G. using "GSR". Imagine flip-flops in different portions of the design coming out of reset at slighly different times. Or maybe even flip-flops holding the state of a state machine. I believe I've experienced this first hand (not using GSR, but my own global reset) and it wasn't fun to debug, it took longer than I care to admit to figure out what was going on. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "..:: Gabster ::.." wrote in message news:Vy2Ua.10962$Fo3.164756@weber.videotron.net... > Hi, > > I want to use a simple reset circuit to reset my FPGA, but I'm unsure > how to handle it because of the PROM. The point is the PROM has to program > the FPGA before the FPGA is reset. How the reset circuit could to be > implemented considering this. I was thinking about a reset circuit with a > built-in delay, but I'm sure there's a easier way to do it. > > thanks, > Gabriel > > ###### From: Andrew Paule User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Reseting the whole thing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 43 Message-ID: Date: Fri, 25 Jul 2003 01:57:42 -0500 NNTP-Posting-Host: 63.229.197.216 X-Trace: news.uswest.net 1059116087 63.229.197.216 (Fri, 25 Jul 2003 01:54:47 CDT) NNTP-Posting-Date: Fri, 25 Jul 2003 01:54:47 CDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-out1.nntp.be!propagator2-sterling!In.nntp.be!priapus.visi.com!phobos.visi.com!news-out.visi.com!petbe.visi.com!feed.news.qwest.net!news.uswest.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31152 Martin - a global reset is one of the foundations of most of the current "big iron" (Teradyne, Schlumberger, Agilent) testers - why? - because it brings things into a known state. Some FPGA's don't have the capability to load bitmaps and other things necessary for reliable start conditions, and even if yours does, if you were to try to get it through test at a company like that, you would be forced to do it anyway (probably for good reason). The processor in the machine you are using right now was tested and qualified under these conditions (100% guaranteed), and a global reset is required on all the boards in the test head that did it. Global reset is a reliable approach, and is required for many purposes. Andrew Martin Euredjian wrote: >Why is it that you want to reset the FPGA after configuration? For all >intents and purposes it is coming out of reset after configuration. > >If you need to do so in order to wait for an event build that into a startup >state machine. > >If you need to guarantee that other portions of the board are ready you can >also build that into a startup state machine. > >If you need to ensure that certain flip-flops and logic come-up in a >specific state you can do that through the bitmap itself. > >I've read quite a bit about global reset not being a reliable approach. Do >a Google search of this N.G. using "GSR". Imagine flip-flops in different >portions of the design coming out of reset at slighly different times. Or >maybe even flip-flops holding the state of a state machine. I believe I've >experienced this first hand (not using GSR, but my own global reset) and it >wasn't fun to debug, it took longer than I care to admit to figure out what >was going on. > > > > ###### Reply-To: "Martin Euredjian" <0_0_0_0_@pacbell.net> From: "Martin Euredjian" <0_0_0_0_@pacbell.net> Newsgroups: comp.arch.fpga References: Subject: Re: Reseting the whole thing Lines: 98 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: NNTP-Posting-Host: 64.170.224.250 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr22.news.prodigy.com 1059118475 ST000 64.170.224.250 (Fri, 25 Jul 2003 03:34:35 EDT) NNTP-Posting-Date: Fri, 25 Jul 2003 03:34:35 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: TSUGW\KE\RUYRPLYNCOF_W\@PJ_^PBQLGPQRJWQHBATBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN Date: Fri, 25 Jul 2003 07:34:35 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!peer01.cox.net!cox.net!rip!news.webusenet.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr22.news.prodigy.com.POSTED!003b42bf!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31185 I'm not disputing the need for reliable reset. From what I've read on this N.G. the GSR approach does not seem to be the recommended way to go. On my current design I implement an "intelligent" global reset module that issues reset signals to various portions of the design and verifies that the module being reset is OK before moving forward. For example, the DCM's need to be checked for lock before allowing related modules to even think about intializing, much less operating. I also have several modules that set a flag when their state machine enters the "RESET" or "INIT" state. The reset generator looks for this flag as confirmation that the particular module is OK. Since my design requires modules to be reset/released-from-reset in a specific sequence this works very well. There are modules that have their own reset or startup requirements. I guess I now think of an external reset signal as just another input that triggers actions (in my case a state machine) as opposed to the reset inputs of all the flip-flops within the FPGA. Are you saying that it is OK to rely on a global reset signal that is directly connected to all flip-flops within the FPGA? Again, reading through the N.G. archives the experts seem to agree on that this is potentially dangerous. I only have experience with Xilinx Virtex II, so my field of vision is seriously impared. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Andrew Paule" wrote in message news:Xu4Ua.189$TT2.95507@news.uswest.net... > Martin - > > a global reset is one of the foundations of most of the current "big > iron" (Teradyne, Schlumberger, Agilent) testers - why? - because it > brings things into a known state. Some FPGA's don't have the capability > to load bitmaps and other things necessary for reliable start > conditions, and even if yours does, if you were to try to get it through > test at a company like that, you would be forced to do it anyway > (probably for good reason). The processor in the machine you are using > right now was tested and qualified under these conditions (100% > guaranteed), and a global reset is required on all the boards in the > test head that did it. > > Global reset is a reliable approach, and is required for many purposes. > > Andrew > > Martin Euredjian wrote: > > >Why is it that you want to reset the FPGA after configuration? For all > >intents and purposes it is coming out of reset after configuration. > > > >If you need to do so in order to wait for an event build that into a startup > >state machine. > > > >If you need to guarantee that other portions of the board are ready you can > >also build that into a startup state machine. > > > >If you need to ensure that certain flip-flops and logic come-up in a > >specific state you can do that through the bitmap itself. > > > >I've read quite a bit about global reset not being a reliable approach. Do > >a Google search of this N.G. using "GSR". Imagine flip-flops in different > >portions of the design coming out of reset at slighly different times. Or > >maybe even flip-flops holding the state of a state machine. I believe I've > >experienced this first hand (not using GSR, but my own global reset) and it > >wasn't fun to debug, it took longer than I care to admit to figure out what > >was going on. > > > > > > > > > ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Reseting the whole thing Date: Fri, 25 Jul 2003 09:17:13 -0700 Organization: Xilinx,Inc Lines: 12 Message-ID: <3F215808.BE8CF213@xilinx.com> References: NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: Martin Euredjian <0_0_0_0_@pacbell.net> Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!nntp.wetware.com!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31138 Global reset is obviously a good thing, but it also has a problem: What happens after the trailing edge of global reset? Cab you take away the global reset "simultaneously" from all affected circuits, and if you cannot, what happens when one circuit stays in reset a few clock ticks longer than the others ? All Xilinx FPGAs have a built-in global reset that gets released at the end of configuration, and that release can also automatically be internally synchronized with the user clock. Inspite of this, at high clock rates some state machines may need individually resynchronized reset. This has been discussed in many threads in this ng. Peter Alfke, Xilinx Applications ###### From: symon_brewer@hotmail.com (Symon) Newsgroups: comp.arch.fpga Subject: Re: Reseting the whole thing Date: 25 Jul 2003 09:25:13 -0700 Organization: http://groups.google.com/ Lines: 55 Message-ID: References: NNTP-Posting-Host: 67.121.165.32 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1059150314 16292 127.0.0.1 (25 Jul 2003 16:25:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 25 Jul 2003 16:25:14 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!switch.ch!news.belwue.de!newsfeed.arcor-online.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31167 Hi, The problem with a global reset can occur if, a) the reset is asynchronous b) there are synchronous elements in the design clocked by clocks different from the one that's synchronous with the reset If the global reset is cleared at the same time as, for example, a flip flop is being clocked, then you might encounter metastability problems, or state machines being initialised into illegal states. Try reading the TechXclusive by Ken Chapman on the Xilinx site called "Get Smart About Reset (Think Local, Not Global)". He describes it better than I can! Cheers, Syms. "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:... > I'm not disputing the need for reliable reset. From what I've read on this > N.G. the GSR approach does not seem to be the recommended way to go. > > On my current design I implement an "intelligent" global reset module that > issues reset signals to various portions of the design and verifies that the > module being reset is OK before moving forward. For example, the DCM's need > to be checked for lock before allowing related modules to even think about > intializing, much less operating. I also have several modules that set a > flag when their state machine enters the "RESET" or "INIT" state. The reset > generator looks for this flag as confirmation that the particular module is > OK. Since my design requires modules to be reset/released-from-reset in a > specific sequence this works very well. There are modules that have their > own reset or startup requirements. > > I guess I now think of an external reset signal as just another input that > triggers actions (in my case a state machine) as opposed to the reset inputs > of all the flip-flops within the FPGA. > > Are you saying that it is OK to rely on a global reset signal that is > directly connected to all flip-flops within the FPGA? Again, reading > through the N.G. archives the experts seem to agree on that this is > potentially dangerous. > > I only have experience with Xilinx Virtex II, so my field of vision is > seriously impared. > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu" > > > > > ###### From: "..:: Gabster ::.." Newsgroups: comp.arch.fpga References: Subject: Re: Reseting the whole thing Lines: 67 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Fri, 25 Jul 2003 14:32:12 -0400 NNTP-Posting-Host: 24.202.119.98 X-Complaints-To: abuse@videotron.ca X-Trace: weber.videotron.net 1059157921 24.202.119.98 (Fri, 25 Jul 2003 14:32:01 EDT) NNTP-Posting-Date: Fri, 25 Jul 2003 14:32:01 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newshosting.com!news-xfer1.atl.newshosting.com!167.206.3.103.MISMATCH!news3.optonline.net!rip!c03.atl99!news.webusenet.com!wesley.videotron.net!weber.videotron.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:31162 You guys are right, there's no need for an external reset on power up. Using the GSR to reset my state machine and start the whole thing is the simple solution. thanks "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:uQ3Ua.3774$m%4.3163@newssvr22.news.prodigy.com... > Why is it that you want to reset the FPGA after configuration? For all > intents and purposes it is coming out of reset after configuration. > > If you need to do so in order to wait for an event build that into a startup > state machine. > > If you need to guarantee that other portions of the board are ready you can > also build that into a startup state machine. > > If you need to ensure that certain flip-flops and logic come-up in a > specific state you can do that through the bitmap itself. > > I've read quite a bit about global reset not being a reliable approach. Do > a Google search of this N.G. using "GSR". Imagine flip-flops in different > portions of the design coming out of reset at slighly different times. Or > maybe even flip-flops holding the state of a state machine. I believe I've > experienced this first hand (not using GSR, but my own global reset) and it > wasn't fun to debug, it took longer than I care to admit to figure out what > was going on. > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu" > > > > "..:: Gabster ::.." wrote in message > news:Vy2Ua.10962$Fo3.164756@weber.videotron.net... > > Hi, > > > > I want to use a simple reset circuit to reset my FPGA, but I'm unsure > > how to handle it because of the PROM. The point is the PROM has to program > > the FPGA before the FPGA is reset. How the reset circuit could to be > > implemented considering this. I was thinking about a reset circuit with a > > built-in delay, but I'm sure there's a easier way to do it. > > > > thanks, > > Gabriel > > > > > >