Message-ID: <3B0FF987.125EB16B@comundo.de> Date: Sat, 26 May 2001 20:44:23 +0200 From: Henning Trispel X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Xilinx XC4010E Problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 35 Organization: COMUNDO -- CLICK TO QUALITY NNTP-Posting-Host: 62.54.209.116 X-Trace: 990902568 news-2.comundo.de 9237 62.54.209.116 X-Complaints-To: abuse@mediaways.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!newsfeed.r-kom.de!bignews.mediaways.net!cluster.news.mediaWays.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6628 Hello, I had to do some changes in an earlier design using a XC4010E-4 device. The design is a fully synchronous design using a single 8 MHz clock, all transitions are sampled on rising clock edge. The design controls a CPU access to a FIFO (hosted on a MVME IP-bus). In my simulations - functional as well as timing - the design works as required. However, in real world, the FPGA outputs are mostly correct, but partly false. Even bits, which are defined as constant low, are sometimes high. This phenomenon is different for each compilation / PROM version, but within that version 100% reproducable. There is no obvious timing problem, since I measured the setup/holds with fast scope. My only clue right now is that my configuration PROM - a XC1701 device - does not contain what it should. (I use the 1Mbits, since I have still plenty of these, while I have only three 256k PROMs left). Workflow: Compilation -> Creation of a MCS86 prom file -> reading the design using my HiLo-Programmer (as Intel-Hex, unused bytes set to 0) -> burn When I view the programming data loaded into the programmer, the data seem correct (I checked the first dozen bytes - but not all). I am using the 3.1i Xilinx foundation software. (BTW can anybody tell me why the heck the timing for a >3 year old FPGA is "prelimanary" in the FND3.1i?) Right now I can't believe that the simulated timing is so much off the real behaviour. And a 8 MHz synchronous design should be that big of a deal anyway. (Usage is 80% of the CLBs, the design contains mainly three one-hot-state state machines). Any hints or help is highly welcome. Thank you, Henning Trispel ###### Message-ID: <3B105EE5.6D4308AC@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: Xilinx XC4010E Problem References: <3B0FF987.125EB16B@comundo.de> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 61 Date: Sun, 27 May 2001 01:57:06 GMT NNTP-Posting-Host: 209.179.244.31 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 990928626 209.179.244.31 (Sat, 26 May 2001 18:57:06 PDT) NNTP-Posting-Date: Sat, 26 May 2001 18:57:06 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Sat, 26 May 2001 18:55:14 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-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!newsfeed1.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:6641 Here is one wild guess, triggered by your words "one-hot state machines" You might have a problem at the end of configuration, at start-up. I have often described this as a complicated step, analoguous to a baby being born, changing from one oxygen-supply system to another. It takes a doctor's defty clap so synchronize things... In your case, you have CCLK doing the configuring, then your ( I assume totally unrelated ) user clock takes over, and inow the global reset that kept everything quiet during configuration gets released. But that release is not instantaneous. It is a signal travelling all over the chip, and it may take 30 ns to do so. In the meantime your clock is clocking all over the chip. Things could get messed up. The best cure is to give the state machine bits their own extra, longer-lasting reset that is synchronously controlled by your user clock. Just use a 2-bit shift register for that, so you stretch global reset, and it ends in a proper synchronous fashion. As I said, just a wild guess, but it has worked before... Alles Gute und viel Erfolg ! Peter Alfke, Xilinx Applications ========================================= Henning Trispel wrote: > Hello, > > I had to do some changes in an earlier design using a XC4010E-4 device. > The design is a fully synchronous design using a single 8 MHz clock, all > transitions are sampled on rising clock edge. The design controls a CPU > access to a FIFO (hosted on a MVME IP-bus). > > In my simulations - functional as well as timing - the design works as > required. However, in real world, the FPGA outputs are mostly correct, > but partly false. Even bits, which are defined as constant low, are > sometimes high. This phenomenon is different for each compilation / PROM > version, but within that version 100% reproducable. There is no obvious > timing problem, since I measured the setup/holds with fast scope. > > My only clue right now is that my configuration PROM - a XC1701 device - > does not contain what it should. (I use the 1Mbits, since I have still > plenty of these, while I have only three 256k PROMs left). Workflow: > Compilation -> Creation of a MCS86 prom file -> reading the design using > my HiLo-Programmer (as Intel-Hex, unused bytes set to 0) -> burn > > When I view the programming data loaded into the programmer, the data > seem correct (I checked the first dozen bytes - but not all). I am using > the 3.1i Xilinx foundation software. (BTW can anybody tell me why the > heck the timing for a >3 year old FPGA is "prelimanary" in the FND3.1i?) > > Right now I can't believe that the simulated timing is so much off the > real behaviour. And a 8 MHz synchronous design should be that big of a > deal anyway. (Usage is 80% of the CLBs, the design contains mainly three > one-hot-state state machines). > > Any hints or help is highly welcome. > > Thank you, > > Henning Trispel ###### Message-ID: <3B109880.F6A8CFB6@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: Xilinx XC4010E Problem References: <3B0FF987.125EB16B@comundo.de> <3B105EE5.6D4308AC@earthlink.net> Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 8bit Lines: 82 Date: Sun, 27 May 2001 06:02:47 GMT NNTP-Posting-Host: 209.179.194.43 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 990943367 209.179.194.43 (Sat, 26 May 2001 23:02:47 PDT) NNTP-Posting-Date: Sat, 26 May 2001 23:02:47 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Sat, 26 May 2001 23:01:03 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-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.skycache.com!Cidera!netnews.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:6643 Henning, I think I have a simpler solution that does not require any redesign. My previous suggestion is appropriate for very high clock rates, 100 MHz and more. (Most of our activity these days is with 100 to 500 MHz clocks...) For a slow clock, you only need to synchronize the start-up to your clock, the "user clock", and you do that by invoking the UCLK_NOSYNC option, as descibed in the XC4000 data sheet, page 6-53, figure 47. The same figure is also shown in some XAPP notes on configuration. I wrote that stuff, so get back to me if there are questions... Again, this is a wild guess... Gruß Peter Alfke, Xilinx Applications (Xilinx is mainly shut down for the whole of next week, but this is my home e-mail address , and I'll be there ) Peter Alfke wrote: > Here is one wild guess, triggered by your words "one-hot state machines" > > You might have a problem at the end of configuration, at start-up. I have > often described this as a complicated step, analoguous to a baby being > born, changing from one oxygen-supply system to another. It takes a > doctor's defty clap so synchronize things... > In your case, you have CCLK doing the configuring, then your ( I assume > totally unrelated ) user clock takes over, and inow the global reset that > kept everything quiet during configuration gets released. But that release > is not instantaneous. It is a signal travelling all over the chip, and it > may take 30 ns to do so. In the meantime your clock is clocking all over > the chip. Things could get messed up. > > The best cure is to give the state machine bits their own extra, > longer-lasting reset that is synchronously controlled by your user clock. > Just use a 2-bit shift register for that, so you stretch global reset, and > it ends in a proper synchronous fashion. > > As I said, just a wild guess, but it has worked before... > > Alles Gute und viel Erfolg ! > Peter Alfke, Xilinx Applications > ========================================= > Henning Trispel wrote: > > > Hello, > > > > I had to do some changes in an earlier design using a XC4010E-4 device. > > The design is a fully synchronous design using a single 8 MHz clock, all > > transitions are sampled on rising clock edge. The design controls a CPU > > access to a FIFO (hosted on a MVME IP-bus). > > > > In my simulations - functional as well as timing - the design works as > > required. However, in real world, the FPGA outputs are mostly correct, > > but partly false. Even bits, which are defined as constant low, are > > sometimes high. This phenomenon is different for each compilation / PROM > > version, but within that version 100% reproducable. There is no obvious > > timing problem, since I measured the setup/holds with fast scope. > > > > My only clue right now is that my configuration PROM - a XC1701 device - > > does not contain what it should. (I use the 1Mbits, since I have still > > plenty of these, while I have only three 256k PROMs left). Workflow: > > Compilation -> Creation of a MCS86 prom file -> reading the design using > > my HiLo-Programmer (as Intel-Hex, unused bytes set to 0) -> burn > > > > When I view the programming data loaded into the programmer, the data > > seem correct (I checked the first dozen bytes - but not all). I am using > > the 3.1i Xilinx foundation software. (BTW can anybody tell me why the > > heck the timing for a >3 year old FPGA is "prelimanary" in the FND3.1i?) > > > > Right now I can't believe that the simulated timing is so much off the > > real behaviour. And a 8 MHz synchronous design should be that big of a > > deal anyway. (Usage is 80% of the CLBs, the design contains mainly three > > one-hot-state state machines). > > > > Any hints or help is highly welcome. > > > > Thank you, > > > > Henning Trispel ###### From: Henning Trispel Newsgroups: comp.arch.fpga Subject: Re: Xilinx XC4010E Problem Date: Sun, 27 May 2001 18:04:20 +0200 Organization: Thales Lines: 21 Message-ID: <3B112583.DF7F147B@thomelektronik.thomson-csf.com> References: <3B0FF987.125EB16B@comundo.de> NNTP-Posting-Host: ts3011.dial.comcity.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Trace: news.comcity.de 990979324 8400 217.70.193.139 (27 May 2001 16:02:04 GMT) X-Complaints-To: abuse@comcity.de NNTP-Posting-Date: 27 May 2001 16:02:04 GMT X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!fu-berlin.de!news.comcity.de!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6626 Hello, the problem was traced down and has been cured now. (Peter, thanks again for your quick hints - however, the bone was buried somewere else). The Motorola MVME IP-bus has bidirectional data ports. In the design I used the OE-controlled BUFT8 tristate drivers. I always assumed the enable to be high active, since I didn't find any clue on it being low active. Curious enough did the problem not show up in the simulation runs. Luckily, this morning I saw a scope measurement showing exactly the data bus in tri-state while it should be active. The other time when only one driver should have been active only one "won" (had the much stronger driver), since the signals were definately really high or low - no in between. Thanks again, Best regards, Henning Trispel ###### From: "Austin Franklin" Newsgroups: comp.arch.fpga Subject: Re: Xilinx XC4010E Problem Date: Thu, 31 May 2001 10:17:32 -0400 Organization: MindSpring Enterprises Lines: 32 Message-ID: <9f5jr9$m55$1@slb4.atl.mindspring.net> References: <3B0FF987.125EB16B@comundo.de> <3B105EE5.6D4308AC@earthlink.net> NNTP-Posting-Host: a5.f7.0a.8a X-Server-Date: 31 May 2001 14:18:17 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!feed2.onemain.com!feed1.onemain.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6769 > In your case, you have CCLK doing the configuring, then your ( I assume > totally unrelated ) user clock takes over, and inow the global reset that > kept everything quiet during configuration gets released. But that release > is not instantaneous. It is a signal travelling all over the chip, and it > may take 30 ns to do so. In the meantime your clock is clocking all over > the chip. Things could get messed up. FLAME ON... And this is a HUGE beef I've had with Xilinx for nearly ten years! Why is the global reset signal NOT hard routed using a LOW SKEW net? Come on, this isn't rocket science guys! I characterized this back on the 4k series in the early 90's. I actually found that the GSR in a 4010 had nearly 80ns skew across the part! You've got lots of clocks routed with low skew nets, why has this not been done with the global reset? And then Xilinx tells users to NOT use the global reset even in the current series parts, but TO burn routing resources in the chip for a reset signal! This causes other issues, simply because the routing resources that are taken up by this reset signal can significantly effect performance of the design. I have always been able to use the GSR and accommodate the shortcomings of the bad GSR routing with careful logic design. If you did follow Xilinx "advice" and provide your own reset signal, take a look using FPGA Editor at how much routing resources it takes! My compile times went from forty five minutes to TEN minutes by using the GSR instead of a routed reset signal. FLAME turned down...but still burning with a trigger finger.... ###### Message-ID: <3B169EEF.C6BF945D@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: Xilinx XC4010E Problem References: <3B0FF987.125EB16B@comundo.de> <3B105EE5.6D4308AC@earthlink.net> <9f5jr9$m55$1@slb4.atl.mindspring.net> 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: 37 Date: Thu, 31 May 2001 20:43:43 +0100 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 991338228 62.254.210.251 (Thu, 31 May 2001 20:43:48 BST) NNTP-Posting-Date: Thu, 31 May 2001 20:43:48 BST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!feed.news.nacamar.de!newsfeed.icl.net!dispose.news.demon.net!demon!diablo.theplanet.net!btnet-peer!btnet-peer0!btnet!news5-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6799 Austin Franklin wrote: > > In your case, you have CCLK doing the configuring, then your ( I assume > > totally unrelated ) user clock takes over, and inow the global reset that > > kept everything quiet during configuration gets released. But that release > > is not instantaneous. It is a signal travelling all over the chip, and it > > may take 30 ns to do so. In the meantime your clock is clocking all over > > the chip. Things could get messed up. > > FLAME ON... > > And this is a HUGE beef I've had with Xilinx for nearly ten years! Why is > the global reset signal NOT hard routed using a LOW SKEW net? Come on, this > isn't rocket science guys! I characterized this back on the 4k series in > the early 90's. I actually found that the GSR in a 4010 had nearly 80ns > skew across the part! You've got lots of clocks routed with low skew nets, > why has this not been done with the global reset? > > And then Xilinx tells users to NOT use the global reset even in the current > series parts, but TO burn routing resources in the chip for a reset signal! > This causes other issues, simply because the routing resources that are > taken up by this reset signal can significantly effect performance of the > design. > > I have always been able to use the GSR and accommodate the shortcomings of > the bad GSR routing with careful logic design. If you did follow Xilinx > "advice" and provide your own reset signal, take a look using FPGA Editor at > how much routing resources it takes! My compile times went from forty five > minutes to TEN minutes by using the GSR instead of a routed reset signal. > > FLAME turned down...but still burning with a trigger finger.... Maybe this will be fixed with the Linux s/w release ? ###### From: "Austin Franklin" Newsgroups: comp.arch.fpga Subject: Re: Xilinx XC4010E Problem Date: Thu, 31 May 2001 18:48:19 -0400 Organization: MindSpring Enterprises Lines: 16 Message-ID: <9f6hnm$5l6$1@nntp9.atl.mindspring.net> References: <3B0FF987.125EB16B@comundo.de> <3B105EE5.6D4308AC@earthlink.net> <9f5jr9$m55$1@slb4.atl.mindspring.net> <3B169EEF.C6BF945D@algor.co.uk> NNTP-Posting-Host: a5.f7.06.c3 X-Server-Date: 31 May 2001 22:48:22 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.skycache.com!Cidera!news-reader.ntrnet.net!uunet!ash.uu.net!finch!news.mindspring.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6821 > > FLAME ON... > > > > Why is > > the global reset signal NOT hard routed using a LOW SKEW net? > > > > FLAME turned down...but still burning with a trigger finger.... > > > Maybe this will be fixed with the Linux s/w release ? Damn. Is Linux the answer to everything, even "bad" hardware design and implementation ;-) ###### Message-ID: <3B16EDD1.74ED6248@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: Xilinx XC4010E Problem References: <3B0FF987.125EB16B@comundo.de> <3B105EE5.6D4308AC@earthlink.net> <9f5jr9$m55$1@slb4.atl.mindspring.net> <3B169EEF.C6BF945D@algor.co.uk> <9f6hnm$5l6$1@nntp9.atl.mindspring.net> 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: 25 Date: Fri, 01 Jun 2001 02:20:17 +0100 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 991358419 62.254.210.251 (Fri, 01 Jun 2001 02:20:19 BST) NNTP-Posting-Date: Fri, 01 Jun 2001 02:20:19 BST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!colt.net!newspeer.clara.net!news.clara.net!newsfeed.icl.net!nntp.news.xara.net!xara.net!gxn.net!news5-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6797 Austin Franklin wrote: > > > FLAME ON... > > > > > > Why is > > > the global reset signal NOT hard routed using a LOW SKEW net? > > > > > > FLAME turned down...but still burning with a trigger finger.... > > > > > Maybe this will be fixed with the Linux s/w release ? > > Damn. Is Linux the answer to everything, even "bad" hardware design and > implementation ;-) Austin, Remember that Xilinx's attitude to Linux is basically ``There's no call for it''. ``Its a sort of a joke you see, never was very good at them'' - Slarty Bardfast, planet designer, in HGTTG. ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: comp.arch.fpga Subject: Re: Xilinx XC4010E Problem References: <3B0FF987.125EB16B@comundo.de> <3B105EE5.6D4308AC@earthlink.net> <9f5jr9$m55$1@slb4.atl.mindspring.net> X-Disclaimer: Everything I write is false. Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 01 Jun 2001 11:41:13 -0700 Message-ID: Lines: 9 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: 1 Jun 2001 11:58:13 -0700, ruckus.brouhaha.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news.he.net!news.kjsl.com!news.spies.com!ruckus.brouhaha.com Xref: chonsp.franklin.ch comp.arch.fpga:6818 "Austin Franklin" writes: > And this is a HUGE beef I've had with Xilinx for nearly ten years! Why is > the global reset signal NOT hard routed using a LOW SKEW net? Come on, this > isn't rocket science guys! I characterized this back on the 4k series in > the early 90's. I actually found that the GSR in a 4010 had nearly 80ns > skew across the part! You've got lots of clocks routed with low skew nets, > why has this not been done with the global reset? Is there any way you can use one of the clock nets for reset? ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: comp.arch.fpga Subject: Re: Xilinx XC4010E Problem Date: 02 Jun 2001 01:15:50 +0200 Organization: My own Private Self Lines: 28 Message-ID: <6uelt3kd09.fsf@chonsp.franklin.ch> References: <3B0FF987.125EB16B@comundo.de> <3B105EE5.6D4308AC@earthlink.net> <9f5jr9$m55$1@slb4.atl.mindspring.net> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 991437353 598 10.0.3.2 (1 Jun 2001 23:15:53 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 1 Jun 2001 23:15:53 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch comp.arch.fpga:6830 Eric Smith writes: > "Austin Franklin" writes: > > And this is a HUGE beef I've had with Xilinx for nearly ten years! Why is > > the global reset signal NOT hard routed using a LOW SKEW net? Come on, this > > isn't rocket science guys! I characterized this back on the 4k series in > > the early 90's. I actually found that the GSR in a 4010 had nearly 80ns > > skew across the part! You've got lots of clocks routed with low skew nets, > > why has this not been done with the global reset? > > Is there any way you can use one of the clock nets for reset? No you can't. At lest not in Vortex and Sparran-II. I just looked at the Jbits docs. FF set/reset can only be driven from the GSR or the "SR" input to the CLB. SR can not be driven from the clock lines. There are 4*6 transistors per CLB missing there. :-( Dito for the CE input. That would also be nice, together with driving individual colums clock lines separately. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual Robbery ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Xilinx XC4010E Problem Date: Mon, 04 Jun 2001 10:58:00 -0700 Organization: Xilinx Lines: 130 Message-ID: <3B1BCC27.227F5E88@xilinx.com> References: <3B0FF987.125EB16B@comundo.de> <3B105EE5.6D4308AC@earthlink.net> <9f5jr9$m55$1@slb4.atl.mindspring.net> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------65DC0298D3B7C00B0C17C9A4" X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en To: Austin Franklin Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!pinatubo.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!sunqbc.risq.qc.ca!news3.bellglobal.com!border1.nntp.aus1.giganews.com!nntp2.aus1.giganews.com!NetNews1!attws2!attsl2!attla2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6910 --------------65DC0298D3B7C00B0C17C9A4 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit There are several solutions to this problem. First, let me apologize for the XC4000 situation, where the GSR is just plain too long, and special tricks must be used to keep state machines properly reset. With Virtex and Spartan-II, we have sped up the GSR distribution to a few ns, so there should be no problem at global clock rates up to 150 MHz ( somewhat chip-size dependent, smaller chips are even better). You can also use a global clock line to drive all critical Clock Enables inactive, but you have only 4 clock lines available, and you may not want to interconnect all CEs. Virtex-II is even better. It gives you far more global clocks that might be used to distribute CE, and here is a much better solution: Disable any global clock for a few clock ticks after the end of GSR. Each Virtex-II global clock buffer is actually a clock multiplexer or clock enable circuit. So just feed a delayed version of GSR into the Global Clock Enable input, and the global clock will only become active after all flip-flops are no longer being held (re)set. As we explained in the data sheet and in our seminars, this clock enable or clock multiplexer circuit is absolutely positively glitch-free. Peter Alfke, Xilinx Applications Austin Franklin wrote: > FLAME ON... > > And this is a HUGE beef I've had with Xilinx for nearly ten years! Why is > the global reset signal NOT hard routed using a LOW SKEW net? Come on, this > isn't rocket science guys! I characterized this back on the 4k series in > the early 90's. I actually found that the GSR in a 4010 had nearly 80ns > skew across the part! You've got lots of clocks routed with low skew nets, > why has this not been done with the global reset? > > And then Xilinx tells users to NOT use the global reset even in the current > series parts, but TO burn routing resources in the chip for a reset signal! > This causes other issues, simply because the routing resources that are > taken up by this reset signal can significantly effect performance of the > design. > > I have always been able to use the GSR and accommodate the shortcomings of > the bad GSR routing with careful logic design. If you did follow Xilinx > "advice" and provide your own reset signal, take a look using FPGA Editor at > how much routing resources it takes! My compile times went from forty five > minutes to TEN minutes by using the GSR instead of a routed reset signal. > > FLAME turned down...but still burning with a trigger finger.... --------------65DC0298D3B7C00B0C17C9A4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit There are several solutions to this problem.

First, let me apologize for the XC4000 situation, where the GSR is just plain too long, and special tricks must be used to keep state machines properly reset.

With Virtex and Spartan-II, we have sped up the GSR distribution to a few ns, so there should be no problem at global clock rates up to 150 MHz ( somewhat chip-size dependent, smaller chips are even better). You can also use a global clock line to drive all critical Clock Enables inactive, but you have only 4 clock lines available, and you may not want to interconnect all CEs.

Virtex-II is even better. It gives you far more global clocks that might be used to distribute CE,

and here is a much better solution:


Disable any global clock for a few clock ticks after the end of GSR.
Each Virtex-II global clock buffer is actually a clock multiplexer or clock enable circuit. So just feed a delayed version of GSR into the Global Clock Enable input, and the global clock will only become active after all flip-flops are no longer being held (re)set.
As we explained in the data sheet and in our seminars, this clock enable or clock multiplexer circuit is absolutely positively glitch-free.

Peter Alfke, Xilinx Applications
 
 
 
 

Austin Franklin wrote:

FLAME ON...

And this is a HUGE beef I've had with Xilinx for nearly ten years!  Why is
the global reset signal NOT hard routed using a LOW SKEW net?  Come on, this
isn't rocket science guys!  I characterized this back on the 4k series in
the early 90's.   I actually found that the GSR in a 4010 had nearly 80ns
skew across the part!   You've got lots of clocks routed with low skew nets,
why has this not been done with the global reset?

And then Xilinx tells users to NOT use the global reset even in the current
series parts, but TO burn routing resources in the chip for a reset signal!
This causes other issues, simply because the routing resources that are
taken up by this reset signal can significantly effect performance of the
design.

I have always been able to use the GSR and accommodate the shortcomings of
the bad GSR routing with careful logic design.  If you did follow Xilinx
"advice" and provide your own reset signal, take a look using FPGA Editor at
how much routing resources it takes!  My compile times went from forty five
minutes to TEN minutes by using the GSR instead of a routed reset signal.

FLAME turned down...but still burning with a trigger finger....

--------------65DC0298D3B7C00B0C17C9A4--