From: shabana_rizvi@yahoo.com (rider) Newsgroups: comp.arch.fpga Subject: Regulator for Spartan 2 Date: 24 Sep 2003 00:34:25 -0700 Organization: http://groups.google.com/ Lines: 24 Message-ID: NNTP-Posting-Host: 203.215.160.162 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1064388867 12322 127.0.0.1 (24 Sep 2003 07:34:27 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 24 Sep 2003 07:34:27 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33275 Hi ! Thanks for the great help offered by the group to our FPGA issues. This time the queries are: 1) I am planning to use a LM317(National Semi) Regulator to power my board having Spartan2 XC2S150 and some other TTL Ics. Would this regulator be able to provide the required POS current [power on surge current] for the FPGA? What current rating is recommended? 2A or more? If this is not good, which regulator would be OK? 2)I have a 20MHz clock in my design that is used in some flip flops in the design. Most of the circuit is combinational and with about 18 combinational clocks. What bypass capacitor ratings would be OK for my design .01uf would be OK? 3)In XST 5.1i , there is a synthesis option which says "Add I/O buffers". Does that mean that if i check this option, the XST would automatically insert I/O buffers[IBUF,OBUF,IBUFG,OBUFT etc] into my top-level module ports and i don't have to instantiate these I/O buffers into my HDL code? Thanks Rider ###### From: antti@case2000.com (Antti Lukats) Newsgroups: comp.arch.fpga Subject: Re: Regulator for Spartan 2 Date: 24 Sep 2003 06:13:16 -0700 Organization: http://groups.google.com/ Lines: 36 Message-ID: <80a3aea5.0309240513.246afbee@posting.google.com> References: NNTP-Posting-Host: 80.142.106.225 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1064409199 3374 127.0.0.1 (24 Sep 2003 13:13:19 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 24 Sep 2003 13:13:19 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33283 shabana_rizvi@yahoo.com (rider) wrote in message news:... > Hi ! > > Thanks for the great help offered by the group to our FPGA issues. > This time the queries are: > > 1) I am planning to use a LM317(National Semi) Regulator to power my > board having Spartan2 XC2S150 and some other TTL Ics. Would this > regulator be able to provide the required POS current [power on surge > current] for the FPGA? What current rating is recommended? 2A or more? > If this is not good, which regulator would be OK? LM317 is fine, but is kind old style the rating depends on the voltage drop on regulator if the incoming voltage is low then you can use some nice regulators in SOT223 package they are sufficient (but will get a little hot/warm) with LDO regulators check the special required bypass caps! > 2)I have a 20MHz clock in my design that is used in some flip flops in > the design. Most of the circuit is combinational and with about 18 > combinational clocks. What bypass capacitor ratings would be OK for my > design .01uf would be OK? I use always 0.1 there is not much difference in size or prics its 0603 package always > 3)In XST 5.1i , there is a synthesis option which says "Add I/O > buffers". Does that mean that if i check this option, the XST would > automatically insert I/O buffers[IBUF,OBUF,IBUFG,OBUFT etc] into my > top-level module ports and i don't have to instantiate these I/O > buffers into my HDL code? correct. antti ###### From: Austin Lesea Newsgroups: comp.arch.fpga Subject: Re: Regulator for Spartan 2 Date: Wed, 24 Sep 2003 08:34:59 -0700 Organization: Xilinx, Inc. Lines: 38 Message-ID: <3F71B9A3.CB80B489@xilinx.com> References: NNTP-Posting-Host: 149.199.53.89 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!ctu-gate!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33255 1) the LM317 meet sthe datasheet requirements (current and current limiting) 2) use 0.1uF caps. surface mount 0402, or 0406. One each for every power and ground pin pair. X7R material. Keep inductance down to min. Read th SI Central web pages on power distribution systems. 20MHz is not the issue, it is the edge rates. Austin rider wrote: > Hi ! > > Thanks for the great help offered by the group to our FPGA issues. > This time the queries are: > > 1) I am planning to use a LM317(National Semi) Regulator to power my > board having Spartan2 XC2S150 and some other TTL Ics. Would this > regulator be able to provide the required POS current [power on surge > current] for the FPGA? What current rating is recommended? 2A or more? > If this is not good, which regulator would be OK? > > 2)I have a 20MHz clock in my design that is used in some flip flops in > the design. Most of the circuit is combinational and with about 18 > combinational clocks. What bypass capacitor ratings would be OK for my > design .01uf would be OK? > > 3)In XST 5.1i , there is a synthesis option which says "Add I/O > buffers". Does that mean that if i check this option, the XST would > automatically insert I/O buffers[IBUF,OBUF,IBUFG,OBUFT etc] into my > top-level module ports and i don't have to instantiate these I/O > buffers into my HDL code? > > Thanks > Rider ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Regulator for Spartan 2 Date: Thu, 25 Sep 2003 13:21:53 -0700 Organization: Xilinx,Inc Lines: 45 Message-ID: <3F734E61.3300CE68@xilinx.com> References: <3F71C1CB.D1576A6@xilinx.com> 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: rider Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!zen.net.uk!news.cabal.org.uk!news-peer.gradwell.net!newsfeed.media.kyoto-u.ac.jp!ctu-gate!news.nctu.edu.tw!feeder.seed.net.tw!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33346 I remember the 70's well. :-) The TTL logic we used was slow by today's standards, with output delays of 25 ns and gentle rise and fall times. But the interconnect was fast, just wires, at 1 to 2 ns per foot. Now, in FPGAs, you have very fast logic, with extremely short transition times of <1ns, but the FPGA-internal interconnects are comparatively slow. It is now fairly normal to spend as much time travelling in the on-chip interconnects, as propagating through the logic. In the old TTL/MSI days, the logic and the flip-flops were very much slower than the interconnect. That means: The slow logic used to tolerate and swallow up interconnect delays, and the transitions were so slow that there were hardly any transmission-line effects. Now the logic is so fast and unforgiving, that the interconnect delays can no longer be ignored, and almost any pc-board trace must be treated as a transmission line. These "cultural differences" may bite you in your translation effort. So, beware of decoding glitches on the clock lines, of uncontrolled clock distribution delay differences, and hold time issues. And crank the chip-output drivers down to the weakest drive strength! You do not need speed; speed is your enemy, but the enemy is very much alive... Have fun! Peter Alfke ========================== rider wrote: > >. You are right about the synchronous > clock issue. I know its not good to use asynchronous designs, but i > have a different problem at hand. I am actually doing reverse > engineering of a board made in probably 1980. It has more than 200 > I/Os and over 180 TTL ICs. I have a rough schematic of it and no other > info. So, I thought it wouldn't be practical to start tracing the > boards functionality and make it SYNCHRONOUS ...and it may never be > possible i feel...so i had to go with combinatorial clocks which the > design is already using.. > > Now i know synchronous design has its advantages, but does that mean > that asynchronous design will never work..in discrete ICs or in FPGA? > Please comment.. > > Rider ###### From: symon_brewer@hotmail.com (Symon) Newsgroups: comp.arch.fpga Subject: Re: Regulator for Spartan 2 Date: 25 Sep 2003 13:48:28 -0700 Organization: http://groups.google.com/ Lines: 36 Message-ID: References: NNTP-Posting-Host: 67.121.164.17 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1064522913 10460 127.0.0.1 (25 Sep 2003 20:48:33 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 25 Sep 2003 20:48:33 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33348 Hi Rider, As others have said, you'll probably find 2) quite tricky. Why not synchronously clock the whole thing a lot faster, say 100MHz, and make synchronous models of the slow logic and FFs? This way you overcome the hideous skew problems? The old TTL switches slowly so any 10ns latency due to the 100MHz clock won't matter. Modern FPGAs have many orders of magnitude more logic than TTL so the extra gates aren't a problem. Just an idea, Syms. shabana_rizvi@yahoo.com (rider) wrote in message news:... > Hi ! > > Thanks for the great help offered by the group to our FPGA issues. > This time the queries are: > > 1) I am planning to use a LM317(National Semi) Regulator to power my > board having Spartan2 XC2S150 and some other TTL Ics. Would this > regulator be able to provide the required POS current [power on surge > current] for the FPGA? What current rating is recommended? 2A or more? > If this is not good, which regulator would be OK? > > 2)I have a 20MHz clock in my design that is used in some flip flops in > the design. Most of the circuit is combinational and with about 18 > combinational clocks. What bypass capacitor ratings would be OK for my > design .01uf would be OK? > > 3)In XST 5.1i , there is a synthesis option which says "Add I/O > buffers". Does that mean that if i check this option, the XST would > automatically insert I/O buffers[IBUF,OBUF,IBUFG,OBUFT etc] into my > top-level module ports and i don't have to instantiate these I/O > buffers into my HDL code? > > Thanks > Rider ###### From: shabana_rizvi@yahoo.com (rider) Newsgroups: comp.arch.fpga Subject: Re: Regulator for Spartan 2 Date: 26 Sep 2003 00:16:50 -0700 Organization: http://groups.google.com/ Lines: 79 Message-ID: References: <3F71C1CB.D1576A6@xilinx.com> <3F734E61.3300CE68@xilinx.com> NNTP-Posting-Host: 203.215.160.162 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1064560612 26326 127.0.0.1 (26 Sep 2003 07:16:52 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 26 Sep 2003 07:16:52 GMT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!nntp.cs.ubc.ca!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33398 Peter Alfke wrote in message news:<3F734E61.3300CE68@xilinx.com>... > I remember the 70's well. :-) > The TTL logic we used was slow by today's standards, with output delays > of 25 ns and gentle rise and fall times. > But the interconnect was fast, just wires, at 1 to 2 ns per foot. > > Now, in FPGAs, you have very fast logic, with extremely short transition > times of <1ns, but the FPGA-internal interconnects are comparatively > slow. It is now fairly normal to spend as much time travelling in the > on-chip interconnects, as propagating through the logic. In the old > TTL/MSI days, the logic and the flip-flops were very much slower than > the interconnect. > > That means: The slow logic used to tolerate and swallow up interconnect > delays, and the transitions were so slow that there were hardly any > transmission-line effects. > Now the logic is so fast and unforgiving, that the interconnect delays > can no longer be ignored, and almost any pc-board trace must be treated > as a transmission line. > > These "cultural differences" may bite you in your translation effort. > So, beware of decoding glitches on the clock lines, of uncontrolled > clock distribution delay differences, and hold time issues. And crank > the chip-output drivers down to the weakest drive strength! > You do not need speed; speed is your enemy, but the enemy is very much alive... > > Have fun! > Peter Alfke > ========================== Hi All! Thanks for everyone for comments on my design. All those comments are scaring me . So please help me out in this situation. I try to explain the design a bit. As i told, the design has around 200+ IO's with more than 80 inputs and nearly 180 ICs. No information on these inputs is avaialble apart from their connections, from the schematic. There are around 24 Flip flops (D and JK type) and few other ICs requiring clocks. We have an on board clock of 20Mhz which is clocking some of FFs, while some are clocked from external port inputs and some from Combinatorial clocks. The design is clearly Asynchronous. Also due to non-avaialability of information about IOs, i cant trace the design functionality(due to massive nets). What i have done is modeled the possible ICS in Verilog and instantiated them as per schematic. the few observations are: 1)Some FFs have their inputs permanently tied to 1 or 0. (OK i feel?) 2)Some FFs share common clock but their inputs are combinational logic comprised of other FFs(same clock). (Its OK i guess). 3)Here seems a problem: A FF is clocked by local 20MHz clock, but its input is a combinational logic which itself derives it inputs from outputs of FFs clocked by signals from 2 external ports. (Clearly Asynchronous. So why did the designer use it? How could he have been sure at that time that their is no asynchronous effect?) 4)An input from IO port passes through a buffer IC . This buffer's output makes input to a clocked IC, which is inturn clocked by a combinatorial logic. Again asynchronous. The card is authentic and from a reliable company. My question is that wasn't there any concern at that time(1980) of asynchronous design that the designer has used so much asynchronous techniques? Is it possible that there is no such REQUIREMENT of synchronism in this design(the system interfacing to IOs of card can handle it ? of which we have no knowledge). Isn't asynchronous design a necessasity times when either synchronous design is neither possible nor feasible? Also why i am gonna be in trouble? Because i am shifting to FPGA OR theere would be same problems even if i redesign the card with same components it is now using? If FPGA is a problem, then why do they claim that we can translate our obselete components into FPGA? If a design is asynchronous inherently, should we forcibly synchronise it mere for the sake of FPGA implemenatation? Thanks to all who commented. Rider ###### From: Magnus Homann Newsgroups: comp.arch.fpga Subject: Re: Regulator for Spartan 2 Date: 26 Sep 2003 10:55:19 +0200 Organization: Chalmers univ. of Technology Lines: 21 Message-ID: References: <3F71C1CB.D1576A6@xilinx.com> <3F734E61.3300CE68@xilinx.com> NNTP-Posting-Host: mis.dtek.chalmers.se X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!newsfeed.vmunix.org!uio.no!uninett.no!news.net.uni-c.dk!newsfeed.sunet.se!news01.sunet.se!dd.chalmers.se!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33378 Only 24 FFs? Sounds like the board synchronizes incoming data+clock to one system clock. Maybe there is som metastability improvmenet technique incorporated. Do the FF IC:s have clock enable? If not, that could be done by using combinatorial clocks. Is there much feedback between all the FF:s? If so, I guess there is some state machine in there (scary...), if not then I'm sure it's relatively easy to reverse engineer the board. What's the board'sfunction, anyway? That would give you a good start. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.se From: Magnus Homann Newsgroups: comp.arch.fpga Subject: Re: Regulator for Spartan 2 Date: 26 Sep 2003 10:55:19 +0200 Organization: Chalmers univ. of Technology Lines: 21 Message-ID: References: <3F71C1CB.D1576A6@xilinx.com> <3F734E61.3300CE68@xilinx.com> NNTP-Posting-Host: mis.dtek.chalmers.se X-Newsreader: Gnus v5.7/Emacs 20.7 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!newsfeed.vmunix.org!uio.no!uninett.no!news.net.uni-c.dk!newsfeed.sunet.se!news01.sunet.se!dd.chalmers.se!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33378 Only 24 FFs? Sounds like the board synchronizes incoming data+clock to one system clock. Maybe there is som metastability improvmenet technique incorporated. Do the FF IC:s have clock enable? If not, that could be done by using combinatorial clocks. Is there much feedback between all the FF:s? If so, I guess there is some state machine in there (scary...), if not then I'm sure it's relatively easy to reverse engineer the board. What's the board'sfunction, anyway? That would give you a good start. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.se ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Regulator for Spartan 2 Date: Sat, 27 Sep 2003 03:02:00 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3F71C1CB.D1576A6@xilinx.com> <3F734E61.3300CE68@xilinx.com> X-Complaints-To: abuse@supernews.com Lines: 36 Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:33431 >The card is authentic and from a reliable company. My question is that >wasn't there any concern at that time(1980) of asynchronous design >that the designer has used so much asynchronous techniques? Do you have the schematics? If so, look for the standard clock-qualifier pattern. The clock will run into one side of an '00 and the qualifying signal will run into the other side. The output is a qualified clock. It will look like an asynchronous clock to the FPGA tools, but it really was synchronous in the designer's mind. This was used because chips like a '374 didn't have a clock qualifing input pin. A common clock distribution scheme in the old TTL days was that the master clock from the osc clocked a FF to square things up and the output of the FF then fanned out to several buffers and they went to another layer of '00s which were buffers and qualifiers. Allways running clocks went through a dummy '00 to balance the skew (and get the polarity right). You could also get similar qualified clocks out of a '138 or '139 by feeding the clock into the enable pin. This gets you 1 of N decoding for things like writing to 1 of several chips. The skew wasn't as well balanced but it generally worked well enough. Note that all of the '00s used in the clock distribution chain were the same technology - no mixing LS and F as that would mess up the clock skew. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### From: "Paul Leventis" Newsgroups: comp.arch.fpga References: <3F71C1CB.D1576A6@xilinx.com> <3F7207E7.9030502@artsci.wustl.edu> Subject: Re: Regulator for Spartan 2 Lines: 33 X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Tue, 30 Sep 2003 03:34:44 GMT NNTP-Posting-Host: 24.157.169.82 X-Complaints-To: abuse@rogers.com X-Trace: news01.bloor.is.net.cable.rogers.com 1064892884 24.157.169.82 (Mon, 29 Sep 2003 23:34:44 EDT) NNTP-Posting-Date: Mon, 29 Sep 2003 23:34:44 EDT Path: chonsp.franklin.ch!pfaff2.ethz.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!news-out.cwix.com!newsfeed.cwix.com!cyclone01.bloor.is.net.cable.rogers.com!news01.bloor.is.net.cable.rogers.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:33560 Hi Jon, > Well, he's certainly using the right (read ONLY) architecture that will > do it. > I got started with Xilinx on a project where I needed 72 flip-flops on a > board, all essentially asynchronous from any other. (This was a timing and > logic controller for nuclear detector applications). Xilinx was the ONLY > architecture that could handle lots of acynchronous clocks at the time. It > may still be. There certainly can be complications with things like this. I'm curious -- why do you believe that "ONLY" Xilinx architectures will work for "asynchronous" clocks? I know the Stratix/Cyclone families of Altera very well, and cannot see why they cannot handle such designs. I am also hard-pressed to figure out where the defficiency is in APEX/FLEX too, though I am less familiar with them. One thing I'd like to point out is that Stratix (when I compare to Virtex-II) has significantly more global clocking available. There are 16 global clocks (8 to each quadrant) in Virtex II, while Stratix has 16 truely global clocks, plus 16 quadrant clocks (4 per quadrant) and 2 quadrant/octant fast clocks. In a 1S80 device, this means there are a total of 48 independent clocks available to you. What does this mean? You're less likely to have to rely on locally routed clocks or other such things that make getting a design right that much harder. Regards, Paul Leventis Altera Corp.