From: "Martin Heimlicher" Newsgroups: comp.arch.fpga Subject: Is it necessary to synchronize the reset signal in an FPGA ? Date: Wed, 13 Dec 2000 22:13:37 +0100 Lines: 22 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 NNTP-Posting-Host: 212.254.229.137 Message-ID: <3a37e67f@news.datacomm.ch> X-Trace: 13 Dec 2000 22:13:35 +0100, 212.254.229.137 Organization: Customers of Tiscali DataComm AG - http://www.tiscalinet.ch/ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!212.254.229.137 Xref: chonsp.franklin.ch comp.arch.fpga:3280 Dear all, This is a very basic and general FPGA question: How do I assure that an externally supplied reset signal connected to some sort of GSR (global set/reset) net releases all registers simultaneously (in the same clock cycle) and reliably (no metastability) ? Do I need to synchronize the external reset signal through one or two registers before feeding it to the GSR net ? If yes, what do I do in the case of multiple clocks in a design ? Can I use the GSR net only to reset registers clocked by one clock and using other routing ressources to reset registers clocked by the other clocks ? If I am worrying to much about this issue: How do FPGAs circumvent these problems ? Regards, Martin Heimlicher, Supercomputing Systems AG, Switzerland ###### From: Jonas Thor Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Date: Thu, 14 Dec 2000 01:07:33 +0100 Organization: Telenordia Lines: 39 Message-ID: References: <3a37e67f@news.datacomm.ch> NNTP-Posting-Host: sdu129-226.ppp.algonet.se Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: cubacola.tninet.se 976752048 7703 195.163.226.129 (14 Dec 2000 00:00:48 GMT) X-Complaints-To: abuse@algo.net NNTP-Posting-Date: 14 Dec 2000 00:00:48 GMT X-Newsreader: Forte Agent 1.7/32.534 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!newsfeed1.telenordia.se!algonet!pepsi.tninet.se!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3290 On Wed, 13 Dec 2000 22:13:37 +0100, "Martin Heimlicher" wrote: >This is a very basic and general FPGA question: I don't think this is a basic question... and I am pretty sure that you will get better answear that I can provide. >How do I assure that an externally supplied reset signal connected to some >sort of GSR (global set/reset) net releases all registers simultaneously (in >the same clock cycle) and reliably (no metastability) ? If you are using a XC4000 (or any other FPGA as far as I know) you have to know that the GSR net have a maximum but not a minimum delay. This means that you will have a skew on the reset signal and that you can not trust that the GSR signal is released within the setup/hold time of any flipflop. This can be fixed by adding a synchronous reset to FFs that nees a reset (like FSM FFs). >Do I need to synchronize the external reset signal through one or two >registers before feeding it to the GSR net ? I don't think that this is you problem. Not all registers need to be reset. Forget the data path, just reset the (control registers) FSM that controls the data path. Make sure that the reset signal is released synchronusly with th release of the GSr net. >If yes, what do I do in the case of multiple clocks in a design ? Can I use >the GSR net only to reset registers clocked by one clock and using other >routing ressources to reset registers clocked by the other clocks ? > >If I am worrying to much about this issue: How do FPGAs circumvent these >problems ? > >Regards, > Martin Heimlicher, Supercomputing Systems AG, Switzerland > ###### From: "Jamie Sanderson" Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Date: Thu, 14 Dec 2000 14:06:11 -0500 Organization: Nortel Lines: 44 Message-ID: <91b5n3$96q$1@bcarh8ab.ca.nortel.com> References: <3a37e67f@news.datacomm.ch> NNTP-Posting-Host: jamie-2.ca.nortel.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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!arclight.uoregon.edu!!nrchh45.us.nortel.com!zcarh46f.ca.nortel.com!bcarh8ac.ca.nortel.com!bcarh8ab.ca.nortel.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3286 "Martin Heimlicher" wrote in message news:3a37e67f@news.datacomm.ch... > Dear all, > > This is a very basic and general FPGA question: > > How do I assure that an externally supplied reset signal connected to some > sort of GSR (global set/reset) net releases all registers simultaneously (in > the same clock cycle) and reliably (no metastability) ? > > Do I need to synchronize the external reset signal through one or two > registers before feeding it to the GSR net ? > > If yes, what do I do in the case of multiple clocks in a design ? Can I use > the GSR net only to reset registers clocked by one clock and using other > routing ressources to reset registers clocked by the other clocks ? > > If I am worrying to much about this issue: How do FPGAs circumvent these > problems ? > > Regards, > Martin Heimlicher, Supercomputing Systems AG, Switzerland Martin; Read the documentation for your FPGA and you should be able to find numbers for the global reset routing skew. If the skew is larger than your clock period, then you will potentially have registers coming out of reset two clock cycles before others. Depending on your design, this may or may not be a problem. In the case of Xilinx Virtex, they are no longer recommending the use of the global reset (startup block). Instead they use normal routing, which can be constrained to have skew less than your clock period. Otherwise, ensure your design can tolerate some registers being clocked 2-3 times more than others when coming out of reset. This usually just means making sure everything is reset to an in-active state. Cheers, Jamie ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: References: <3a37e67f@news.datacomm.ch> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 128 Date: Thu, 14 Dec 2000 12:57:34 -0800 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@pacbell.net X-Trace: news.pacbell.net 976827562 216.103.85.188 (Thu, 14 Dec 2000 12:59:22 PST) NNTP-Posting-Date: Thu, 14 Dec 2000 12:59:22 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!nntp.primenet.com!nntp.gblx.net!feeder.via.net!cyclone-sf.pbi.net!206.13.28.143!news.pacbell.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3331 On Wed, 13 Dec 2000 22:13:37 +0100, "Martin Heimlicher" wrote: >Dear all, > >This is a very basic and general FPGA question: Basic, and general, and extremely important. >How do I assure that an externally supplied reset signal connected to some >sort of GSR (global set/reset) net releases all registers simultaneously (in >the same clock cycle) and reliably (no metastability) ? It's difficult, and dependent on your clock frequency. The core of the problem is that while the GSR signal is useful, its routing resources are not particularly fast, and Xilinx does not specify a skew parameter for it, or a min delay. Consider the following: case 1) GSR max delay is 20ns, (min delay is 0, guaranteed by reality) and your clock period is 15nS case 2) GSR max delay is 20ns, (min delay is 0, guaranteed by reality) and your clock period is 150nS Let us assume that we are only worried about the relationship between the release of reset, and the next asserting edge of the clock. Let us be pessimistic (which is the ONLY way to design robust systems) and assume that when GSR is de-asserted, some FFs will see the release at close to 0 nS later, and some will see it at the max delay (20 nS), and most will see it at times between these two limits. Also, let's assume the recovery time for a flipflop from reset being de-asserted to clock edges being recognized is 3nS For case 1, there are guaranteed to be problems, unless specific effort is expended to deal with the situation. For case 2, provided that GSR is released (at its source) at less than (150-20-3 => 127) nS AFTER the clock's asserting edge, everything will be ready for the next clock edge. Unfortunatel, case 1 is the more common situation: GSR net delay is greater than clock cycle time. >Do I need to synchronize the external reset signal through one or two >registers before feeding it to the GSR net ? For Case 1, this will not help. For Case 2 this is sufficient. For Case 1, what many of us recommend is this: In your design, add extra logic such that if (when) various FFs have their reset released in different clock cycles, the system still works. So lets look at the FFs in your system. Some wil start toggling immediately when reset is released, and others won't change until after a few clock cycles. For example, in a counter, the LSB will change on the first rising edge, but the rest of the FFs wont change. So only the LSB FF is in danger. If I had two counters that are supposed to be in lock step, and the reset release occurs at different times, and the clock edge occurs between the two releases, one counter will be ahead by 1 count. Here is a (the) recomended solution. Identify all FFs that are the ones that can change state on the first clock edge. If they dont change, no other FF can change. For these FFs, add a synchronous reset signal, or tie their CE pins together. If the CE is held low on just these FFs, or if the Sync Reset is asserted (to just this subset of FFs), then no FF can change. Build a statemachine that controlls this CE or sync-reset signal. The SM is trivial. it is a shft register, with the D pin of the first FF tied high. When the chip comes out of async reset, the SR will go from 0000 to 0001 if the first FF has its reset released, and a clock happens. After the second clock it is 0011 then 0111 and finally 1111 . Note that if GSR is still reseting any of the FFs, the last FF cant go high. Note that the first FF can go metastable. So could the others if the previous bit is high, and reset de-asserts just as the clock arrives. Detect that all bits of the SR are '1', and synchronously use this to enable the set of FFs that have the extra sync reset, or CE control. How long should the shift register be? N = (CEIL(max GSR delay / clock period)) + 1+ paranoid metastable FFs) i.e. max GSR delay 25 nS , clock period is 10ns Ceil( 25 / 10) + 1 + 2 3 + 1 + 2 6 So 6 FFs in the SR. (if you are more paranoid, add a few more, they are cheap.) A 6 input AND looks at all the Q's and that signal goes to 1 more FF, and its output is the system GO signal. The system actually starts up about 70 nS after the GSR is released, well after the GSR has been de-asserted to all FFs. Bonus: No need to externally sync the signal that is supplied as GSR. >If yes, what do I do in the case of multiple clocks in a design ? Can I use >the GSR net only to reset registers clocked by one clock and using other >routing ressources to reset registers clocked by the other clocks ? The GSR is prerouted to ALL FFs, and when it is asserted, ALL FFs will be reset. Use multiple copies of my above described SR base system-GO circuit, one for each clock domain, You may need to link them together so that GO signals reach each domain at the right time. >If I am worrying to much about this issue: How do FPGAs circumvent these >problems ? In the past, Xilinx acknowledged that this net is slow, but no further support. In recent times, rather than explaining that this was a problem, and that there are circuit based solutions (such as the one just described), Xilinx has instead just recommended not to use the GSR net, thereby side stepping the issue, and creating routing nightmares when general routing resources are now used to reset potentially thousands of FFs. I have heard of designs that P&R in 30 minutes with the GSR net, and take 7 hours with a non GSR net doing the same task. Me, I prefer 30 minutes, and a 6 bit shift register. >Regards, > Martin Heimlicher, Supercomputing Systems AG, Switzerland > Philip Freidin Fliptronics ###### From: z80@ds2.com (Peter) Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Date: Mon, 18 Dec 2000 19:59:19 +0000 Organization: - Lines: 22 Message-ID: References: <3a37e67f@news.datacomm.ch> NNTP-Posting-Host: dialup-01-26.netcomuk.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: taliesin2.netcom.net.uk 977169491 1356 194.42.228.90 (18 Dec 2000 19:58:11 GMT) X-Complaints-To: abuse@corp.netcom.net.uk NNTP-Posting-Date: 18 Dec 2000 19:58:11 GMT X-Newsreader: Forte Agent 1.8/32.548 X-No-Archive: yes Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!psinet-eu-nl!psiuk-p4!uknet!diablo.netcom.net.uk!netcom.net.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3355 >>This is a very basic and general FPGA question: > >Basic, and general, and extremely important. > >>How do I assure that an externally supplied reset signal connected to some >>sort of GSR (global set/reset) net releases all registers simultaneously (in >>the same clock cycle) and reliably (no metastability) ? [excellent post snipped] This sort of thing is pretty scary - most people just assume that a global reset will reset everything. In retrospect this is pretty obvious but it would explain some weird FPGA power-up problems I have seen in the past. Peter. -- Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary. ###### From: "Andrew Ince" Newsgroups: comp.arch.fpga References: <3a37e67f@news.datacomm.ch> Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Date: Wed, 20 Dec 2000 17:03:29 -0000 Lines: 31 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 NNTP-Posting-Host: basit47307021.basldn.gecm.com Message-ID: <3a40e580$1@pull.gecm.com> X-Trace: 20 Dec 2000 16:59:44 GMT, basit47307021.basldn.gecm.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!btnet-peer1!btnet-feed5!btnet!newreader.ukcore.bt.net!pull.gecm.com!basit47307021.basldn.gecm.com Xref: chonsp.franklin.ch comp.arch.fpga:3450 "Martin Heimlicher" wrote in message news:3a37e67f@news.datacomm.ch... > How do I assure that an externally supplied reset signal connected to some > sort of GSR (global set/reset) net releases all registers simultaneously (in > the same clock cycle) and reliably (no metastability) ? > Martin Heimlicher, Supercomputing Systems AG, Switzerland On a related point, Why should the 'uncritical' resets be coded? The Synthesis/PAR tools know the VHDL code targets FPGA's, and adds the GSR. Post layout simulation of code resulting from un-Reset VHDL works e.g. "alt_en <= NOT alt_en WHEN Rising_Edge(clk);" However most vendors produce 'VHDL Simulators' that in Pre Layout simulation cannot cope with the FPGA's initialisation of registers and the simulation fails. As most designs target FPGA's, the simulators should have a 'PreSimulation Reset' command that can be overturned by code defaults on individual signals if required. The Tools will then simulate the above 'FPGA code' correctly with out having to code the asynchronous GSR reset or the "risky" signal initial values. Andrew Ince ###### From: eml@riverside-machines.com.NOSPAM Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Date: Wed, 20 Dec 2000 22:08:07 GMT Organization: Riverside Machines Ltd. Lines: 35 Message-ID: <3a412d9b.48590650@news.dial.pipex.com> References: <3a37e67f@news.datacomm.ch> <91b5n3$96q$1@bcarh8ab.ca.nortel.com> <91n6ro$e83@src-news.pa.dec.com> NNTP-Posting-Host: useri607.uk.uudial.com X-Trace: lure.pipex.net 977350140 14756 194.69.106.217 (20 Dec 2000 22:09:00 GMT) X-Complaints-To: abuse@uk.uu.net NNTP-Posting-Date: 20 Dec 2000 22:09:00 GMT X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!join.news.pipex.net!pipex!grot.news.pipex.net!pipex!tube.news.pipex.net!pipex!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3494 On 19 Dec 2000 08:39:20 GMT, murray@pa.dec.com (Hal Murray) wrote: >Speaking of global-reset, how does GSR work on a Virtex? If I look >with the FPGA Editor, I don't see any place where GSR connects up >to a CLB or IOB. > > If I specify an explicit set/reset term, does that replace what GSR > does or does it get ORed in with GSR? OR'ed in > Is there an extra input on some SR mux that isn't shown? Or does GSR > get wired up outside the CLB on some path that isn't shown? Or am I > just not looking in the right place? My guess is that it's an ASIC test structure, ie. it's under the hood and we don't get to see it. The only concession is that we're allowed to OR in our own FPGA-level signal, at our own risk. BTW, the last time I checked both the Virtex and the 4K data sheets there were no relevant skew timings on GSR. None of the important numbers are documented. This is, IMO, either (1) unnecessary embarassment at how slow it is (it has to be slow, I think, or there would be a large current spike at start-up), or (2) part of a conspiracy to remove user-level GSR connectivity on future software or hardware. > The SR input to a CLB is also used as a write-enable when the LUT > memory is used as a RAM or shift-register. Do the FFs still get > reset by GSR? They always get set/reset by GSR - the SR input is just an optional additional term. Evan ###### From: murray@pa.dec.com (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Date: 21 Dec 2000 02:40:38 GMT Organization: Compaq Systems Research Center Lines: 27 Distribution: world Message-ID: <91rqj6$2m2@src-news.pa.dec.com> References: <3a37e67f@news.datacomm.ch> <91b5n3$96q$1@bcarh8ab.ca.nortel.com> <91n6ro$e83@src-news.pa.dec.com> <3a412d9b.48590650@news.dial.pipex.com> NNTP-Posting-Host: quatre.pa.dec.com X-Newsreader: xrn 9.01 Originator: murray@quatre.pa.dec.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.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!newsgate.tandem.com!pa.dec.com!src.dec.com!murray Xref: chonsp.franklin.ch comp.arch.fpga:3484 > They always get set/reset by GSR - the SR input is just an optional > additional term. Thanks. Is that in the documentation someplace? I don't remember seeing it and it's the sort of detail I think I would remember. > BTW, the last time I checked both the Virtex and the 4K data sheets > there were no relevant skew timings on GSR. None of the important > numbers are documented. Why are you interested in skew? Suppose the skew is 1 ns but the prop time is somewhere between 0 and 20. How do I use GSR if my clock time is 10 ns? My copy of the VirtexE data sheet has some GSR data: GSR to Pad, is on the bottom of the IOB Output Switching, Table 21. There is a similar number a few pages earlier for GSR to IQ on the input side. Yes, similar data for CLBs and RAMs would be helpful. (DS022 v1.6, Aug 2000) -- These are my opinions, not necessarily my employers. I hate spam. ###### From: eml@riverside-machines.com.NOSPAM Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Date: Thu, 21 Dec 2000 15:47:01 GMT Organization: Riverside Machines Ltd. Lines: 38 Message-ID: <3a4225e0.26760021@news.dial.pipex.com> References: <3a37e67f@news.datacomm.ch> <91b5n3$96q$1@bcarh8ab.ca.nortel.com> <91n6ro$e83@src-news.pa.dec.com> <3a412d9b.48590650@news.dial.pipex.com> <91rqj6$2m2@src-news.pa.dec.com> NNTP-Posting-Host: userfm33.uk.uudial.com X-Trace: lure.pipex.net 977413674 13623 62.188.24.121 (21 Dec 2000 15:47:54 GMT) X-Complaints-To: abuse@uk.uu.net NNTP-Posting-Date: 21 Dec 2000 15:47:54 GMT X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!join.news.pipex.net!pipex!grot.news.pipex.net!pipex!tube.news.pipex.net!pipex!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3491 On 21 Dec 2000 02:40:38 GMT, murray@pa.dec.com (Hal Murray) wrote: > >> They always get set/reset by GSR - the SR input is just an optional >> additional term. > >Thanks. Is that in the documentation someplace? I don't remember >seeing it and it's the sort of detail I think I would remember. I just had a look at the online docs, and it's pretty much all covered in the first few pages of: Synthesis and Simulation Design Guide Chapter 4: Designing FPGAs with HDL Using Dedicated Global Set/Reset Resource >> BTW, the last time I checked both the Virtex and the 4K data sheets >> there were no relevant skew timings on GSR. None of the important >> numbers are documented. > >Why are you interested in skew? Suppose the skew is 1 ns but the >prop time is somewhere between 0 and 20. How do I use GSR if my clock >time is 10 ns? I just meant delay specs in general - 'skew' was a bad choice of word. >My copy of the VirtexE data sheet has some GSR data: GSR to Pad, >is on the bottom of the IOB Output Switching, Table 21. There is >a similar number a few pages earlier for GSR to IQ on the input >side. > >Yes, similar data for CLBs and RAMs would be helpful. Not to mention a setup/hold parameter to the clock. I don't think it matters, though - you can still use GSR effectively with some extra messing around. Evan ###### From: murray@pa.dec.com (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? Date: 22 Dec 2000 08:34:14 GMT Organization: Compaq Systems Research Center Lines: 13 Distribution: world Message-ID: <91v3m6$a14@src-news.pa.dec.com> References: <3a37e67f@news.datacomm.ch> <91b5n3$96q$1@bcarh8ab.ca.nortel.com> <91n6ro$e83@src-news.pa.dec.com> <3a412d9b.48590650@news.dial.pipex.com> <91rqj6$2m2@src-news.pa.dec.com> <3a4225e0.26760021@news.dial.pipex.com> NNTP-Posting-Host: quatre.pa.dec.com X-Newsreader: xrn 9.01 Originator: murray@quatre.pa.dec.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!171.64.14.106!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!newsgate.tandem.com!mailint03.im.hou.compaq.com!pa.dec.com!src.dec.com!murray Xref: chonsp.franklin.ch comp.arch.fpga:3481 > I just had a look at the online docs, and it's pretty much all covered > in the first few pages of: > > Synthesis and Simulation Design Guide > Chapter 4: Designing FPGAs with HDL > Using Dedicated Global Set/Reset Resource Thanks. Interesting that it doesn't say anything like that in the data sheet. -- These are my opinions, not necessarily my employers. I hate spam. ###### Message-ID: <3A44795A.D7FF1A98@algor.co.uk> From: Rick Filipkiewicz X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ? References: <3a37e67f@news.datacomm.ch> <91b5n3$96q$1@bcarh8ab.ca.nortel.com> <91n6ro$e83@src-news.pa.dec.com> <3a412d9b.48590650@news.dial.pipex.com> <91rqj6$2m2@src-news.pa.dec.com> <3a4225e0.26760021@news.dial.pipex.com> <91v3m6$a14@src-news.pa.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!root@oval.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 20 Date: Sat, 23 Dec 2000 10:07:22 +0000 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news2-win.server.ntlworld.com 977566048 62.254.210.251 (Sat, 23 Dec 2000 10:07:28 GMT) NNTP-Posting-Date: Sat, 23 Dec 2000 10:07:28 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!logbridge.uoregon.edu!server3.netnews.ja.net!server4.netnews.ja.net!news5-gui.server.ntli.net!ntli.net!news2-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:3516 Hal Murray wrote: > > I just had a look at the online docs, and it's pretty much all covered > > in the first few pages of: > > > > Synthesis and Simulation Design Guide > > Chapter 4: Designing FPGAs with HDL > > Using Dedicated Global Set/Reset Resource > > Thanks. Interesting that it doesn't say anything like that > in the data sheet. > > -- > These are my opinions, not necessarily my employers. I hate spam. But with all this there is still no way [according to Evan] to turn off the implicit GSR that happens during config.