From: Jamil Khatib Newsgroups: comp.arch.fpga Subject: Internal tri states Date: Sat, 26 May 2001 23:03:52 +0200 Organization: OpenCores Organization Lines: 6 Message-ID: <3B101A38.588AC93@ieee.org> Reply-To: khatib@ieee.org NNTP-Posting-Host: s225.jerusalem.palnet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.att.net.il!attglobal.net 990907315 36144 (none) 217.66.225.226 X-Complaints-To: postmaster@att.net.il X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.stealth.net!news.att.net.il!attglobal.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6658 Is there any drawbacks for using internal tristate buffers to implement busses? or should I keep using muxs? Thanks Jamil ###### Message-ID: <3B106121.620D8A85@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: Internal tri states References: <3B101A38.588AC93@ieee.org> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 24 Date: Sun, 27 May 2001 02:06:38 GMT NNTP-Posting-Host: 209.179.244.31 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 990929198 209.179.244.31 (Sat, 26 May 2001 19:06:38 PDT) NNTP-Posting-Date: Sat, 26 May 2001 19:06:38 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Sat, 26 May 2001 19:04:45 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.direct.ca!look.ca!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:6638 Internal 3-states are great, but: If you use the longline with resistive pull-up, (DTL-fashion, wired AND) it is very safe, but slow. If you switch between active drivers, you are responsible for making sure that only one driver is on at any one time, otherwise you get contention. The drivers are deliberately designed to be faster in turn-off than in turn-on, so if you think you have a seemless change, there actually is a small idle time between the two drivers being active. Good! Short contentions are not destrucive, but generate a lot of noise, and unnecassary power consumption. On very large chips, the longlines represent a lot of capacitance, that's why Virtex implements 3-state buffering differently. Peter Alfke ================================== Jamil Khatib wrote: > Is there any drawbacks for using internal tristate buffers to implement > busses? or should I keep using muxs? > > Thanks > Jamil ###### From: "Tony Burch" Newsgroups: comp.arch.fpga References: <3B101A38.588AC93@ieee.org> Subject: Re: Internal tri states Lines: 55 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 X-Original-NNTP-Posting-Host: tntwc01-3-73.idx.com.au Message-ID: <3b111781@news1.idx.com.au> Date: Mon, 28 May 2001 00:57:03 +1000 NNTP-Posting-Host: 203.14.30.196 X-Complaints-To: abuse@telstra.net X-Trace: nsw.nnrp.telstra.net 990975221 203.14.30.196 (Mon, 28 May 2001 00:53:41 EST) NNTP-Posting-Date: Mon, 28 May 2001 00:53:41 EST Organization: Customer of Telstra Big Pond Direct Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news.mel.connect.com.au!news.syd.connect.com.au!nsw.nnrp.telstra.net!news1.idx.com.au!tntwc01-3-73.idx.com.au Xref: chonsp.franklin.ch comp.arch.fpga:6625 Hi Jamil, Definitely keep using MUXs for implementing on-chip buses ! There are three main issues (maybe more, if anyone can add?....) (1) Potential Bus Contention: The obvious issue is that MUXs avoid the potential problem with tristate buses - bus contention, with multiple drivers active at the same time (increases power consumption, reduces reliablility of the chip). (2) Design Portability: If your design is HDL based, MUX based buses are technology independent, hence your design is more portable. Tristate resources are limited in FPGAs, and if you transfer your design to ASIC, tristate buses must never be allowed to float (FPGAs have weak-keepers on tristate resources, so floating doesn't occur). This is a "design for reuse" issue. (3) System Reset: This relates to point (1). If you use tristate buses in your design, you must use an asynchronous reset for your design. This is because with a synchronous reset, you may have contention on start-up, because your system will reset to the known start-up state only on the first system clock. It is almost always better to use a synchronous system reset, or at least synchronise/register your incoming system reset signal. So, don't use tristate buses if you have a synchronous reset. It follows that if you have tristate buses, you must use an asynchronous reset. However, at the board level, tristate buses are OK, of course - you can use tristate logic for the IOs of your top level design, but not for the internals of your FPGA or ASIC. Hope that helps :) Best regards Tony Burch http://www.BurchED.com.au Lowest cost, easiest-to-use FPGA prototyping kits! "Jamil Khatib" wrote in message news:3B101A38.588AC93@ieee.org... > Is there any drawbacks for using internal tristate buffers to implement > busses? or should I keep using muxs? > > Thanks > Jamil > ###### Message-ID: <3B1131FC.75E854DC@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: Internal tri states References: <3B101A38.588AC93@ieee.org> <3b111781@news1.idx.com.au> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 55 Date: Sun, 27 May 2001 16:57:41 GMT NNTP-Posting-Host: 209.179.194.54 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 990982661 209.179.194.54 (Sun, 27 May 2001 09:57:41 PDT) NNTP-Posting-Date: Sun, 27 May 2001 09:57:41 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Sun, 27 May 2001 09:55:52 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!newspeer1.nac.net!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:6642 Here are some distributed comments by somebody who likes on-chip 3-state busses for their efficiency. Tony Burch wrote: > Hi Jamil, > > (1) Potential Bus Contention: > The obvious issue is that MUXs avoid the potential problem > with tristate buses - bus contention, with multiple drivers active > at the same time (increases power consumption, reduces reliablility > of the chip). For reliability problems to exist, there would have to be massive contention, lasting a long time, which can only happen in an faulty design. > > > (2) Design Portability: > If your design is HDL based, MUX based buses are technology > independent, hence your design is more portable. Tristate > resources are limited in FPGAs, and if you transfer your design > to ASIC, tristate buses must never be allowed to float > (FPGAs have weak-keepers on tristate resources, so floating > doesn't occur). This is a "design for reuse" issue. True, but then: Only certain FPGA designs ever get ported to an ASIC. > > > (3) System Reset: > This relates to point (1). If you use tristate buses in your > design, you must use an asynchronous reset for your > design. This is because with a synchronous reset, you > may have contention on start-up, The global reset that is active during the whole configuration process is asynchronous, and moreover, the user clock is actually coming in and is being distributed during the configuration time. ( Speaking for Xilinx, I don't know the Altera details enough). So, unless the whole design is done in a weird way, there is no problem during configuration and start-up. > because your system > will reset to the known start-up state only on the first system > clock. It is almost always better to use a synchronous > system reset, or at least synchronise/register your incoming > system reset signal. So, don't use tristate buses if you > have a synchronous reset. It follows that if you have > tristate buses, you must use an asynchronous reset. Have a good Memorial Day weekend ! Peter Alfke, Xilinx Applications ###### From: Kent Orthner Newsgroups: comp.arch.fpga Subject: Re: Internal tri states Date: 28 May 2001 10:56:26 +0900 Organization: ... Lines: 63 Sender: korthner@=?iso-8859-1?q?=91=E5=8D=BB=8C=92=90l?= Message-ID: References: <3B101A38.588AC93@ieee.org> <3B106121.620D8A85@earthlink.net> NNTP-Posting-Host: dhcp248.inf.furukawa.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) 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.media.kyoto-u.ac.jp!news.ksw.feedmania.org!nf1.xephion.ne.jp!fintnews!ifnews!inf-gw!postmaster Xref: chonsp.franklin.ch comp.arch.fpga:6701 Peter, a bit more followup, if you will. Does that mean it is safe to do something like the following: process(Clk) is being if rising_edge(Clk) then if enable = '0' then tri_bus <= value_a; else tri_bus <= (others => 'Z'); end if; end if; end process; process(Clk) is being if rising_edge(Clk) then if enable = '1' then tri_bus <= value_b; else tri_bus <= (others => 'Z'); end if; end if; end process; When enable changes, one set of drivers turn off at the clock edge, and another set turn on at the clock edge (+/- skew). I've always avoided this, because it seemed that there was a tiny bit of time when both drivers were on. Is the 'small idle time between the two drivers being active' greater than the skew on on a clock buffer? If it is, then it's safe to replace all of my big sychronous muxes with tri-states, without a heat/damage penalty? (Note: I'm using Spartan-II) Thanks! -Kent Peter Alfke writes: > Internal 3-states are great, but: > > If you use the longline with resistive pull-up, (DTL-fashion, wired AND) > it is very safe, but slow. > If you switch between active drivers, you are responsible for making sure > that only one driver is on at any one time, otherwise you get contention. > The drivers are deliberately designed to be faster in turn-off than in > turn-on, so if you think you have a seemless change, there actually is a > small idle time between the two drivers being active. Good! Short > contentions are not destrucive, but generate a lot of noise, and > unnecassary power consumption. > On very large chips, the longlines represent a lot of capacitance, that's > why Virtex implements 3-state buffering differently. > > Peter Alfke > ================================== > Jamil Khatib wrote: > > > Is there any drawbacks for using internal tristate buffers to implement > > busses? or should I keep using muxs? > > > > Thanks > > Jamil ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Internal tri states Date: Sun, 27 May 2001 20:24:39 -0700 Organization: Xilinx Lines: 75 Message-ID: <3B11C4F6.7A616273@xilinx.com> References: <3B101A38.588AC93@ieee.org> <3B106121.620D8A85@earthlink.net> Reply-To: peter.alfke@xilinx.com NNTP-Posting-Host: peter.xsj.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en To: Kent Orthner 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.mathworks.com!wn3feed!worldnet.att.net!12.120.32.16!attsl1!attsl2!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:6663 If you use a global clock, known to have very little skew, (it's something like 100 ps) then it is definitely ok to use the same clock edge to turn off one 3-state driver and to turn on another. If you use local lines to distribute the clock, then this is very iffy and I would argue against the 3-state solution unless you can investigate the timing very carefully. Peter Alfke Xilinx is closed this week, but I may check my e-mail occasionally. ================================ Kent Orthner wrote: > Peter, a bit more followup, if you will. > > Does that mean it is safe to do something like the following: > > process(Clk) is > being > if rising_edge(Clk) then > if enable = '0' then > tri_bus <= value_a; > else > tri_bus <= (others => 'Z'); > end if; > end if; > end process; > > process(Clk) is > being > if rising_edge(Clk) then > if enable = '1' then > tri_bus <= value_b; > else > tri_bus <= (others => 'Z'); > end if; > end if; > end process; > > When enable changes, one set of drivers turn off at the clock edge, and > another set turn on at the clock edge (+/- skew). I've always avoided > this, because it seemed that there was a tiny bit of time when both > drivers were on. Is the 'small idle time between the two drivers > being active' greater than the skew on on a clock buffer? If it is, then > it's safe to replace all of my big sychronous muxes with tri-states, > without a heat/damage penalty? (Note: I'm using Spartan-II) > > Thanks! > -Kent > > Peter Alfke writes: > > > Internal 3-states are great, but: > > > > If you use the longline with resistive pull-up, (DTL-fashion, wired AND) > > it is very safe, but slow. > > If you switch between active drivers, you are responsible for making sure > > that only one driver is on at any one time, otherwise you get contention. > > The drivers are deliberately designed to be faster in turn-off than in > > turn-on, so if you think you have a seemless change, there actually is a > > small idle time between the two drivers being active. Good! Short > > contentions are not destrucive, but generate a lot of noise, and > > unnecassary power consumption. > > On very large chips, the longlines represent a lot of capacitance, that's > > why Virtex implements 3-state buffering differently. > > > > Peter Alfke > > ================================== > > Jamil Khatib wrote: > > > > > Is there any drawbacks for using internal tristate buffers to implement > > > busses? or should I keep using muxs? > > > > > > Thanks > > > Jamil ###### From: "Tony Burch" Newsgroups: comp.arch.fpga References: <3B101A38.588AC93@ieee.org> <3b111781@news1.idx.com.au> <3B1131FC.75E854DC@earthlink.net> Subject: Re: Internal tri states Lines: 110 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 X-Original-NNTP-Posting-Host: tntwc01-3-87.idx.com.au Message-ID: <3b11e927@news1.idx.com.au> Date: Mon, 28 May 2001 15:51:31 +1000 NNTP-Posting-Host: 203.14.30.196 X-Complaints-To: abuse@telstra.net X-Trace: nsw.nnrp.telstra.net 991028970 203.14.30.196 (Mon, 28 May 2001 15:49:30 EST) NNTP-Posting-Date: Mon, 28 May 2001 15:49:30 EST Organization: Customer of Telstra Big Pond Direct Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!intgwpad.nntp.telstra.net!nsw.nnrp.telstra.net!news1.idx.com.au!tntwc01-3-87.idx.com.au Xref: chonsp.franklin.ch comp.arch.fpga:6666 Hi all, Well, I have learned something: Never tell someone who likes on-chip 3-state buses that they "definitely should use muxed buses" :) And if you do, chose your words very carefully :) :) What I really should have said, after pondering it again, is: "Definitely use muxes for on-chip buses, if you want your design to be portable and re-usable". By "portable", I mean that your design can be targeted to multiple technologies and vendors, without significant redesign for the architectural features of the target. By "re-usable", I mean that your design can be used again as a black box, or grey box, by designers in a future project. As an example, if you are a company that produces IP cores for FPGAs and ASICs, then you would definitely want to use technology-independent coding style as much as possible (which includes using on-chip muxed buses, not tri-state). I have been around for long enough to know that when someone widely known and well respected like Peter Alfke speaks, you will do well to take note and listen carefully (well, I do, anyway :) ). His points relating to Xilinx FPGAs, in response to my previous post, are perfectly valid. In particular, the responses relating to bus contention, reliablitlity, and the Xilinx FPGA global reset, are right-on. Peter, thankyou for making those points. > Have a good Memorial Day weekend ! Our Memorial Day (we have "Anzac Day") is on a different day here in Australia, but I appreciate the sentiment. Hope you have a good one. I'm interested to hear others' views on muxed vs tristate implementations of on-chip buses... Best regards Tony Burch http://www.BurchED.com.au Lowest cost, easiest-to-use FPGA prototyping kits! "Peter Alfke" wrote in message news:3B1131FC.75E854DC@earthlink.net... > Here are some distributed comments by somebody who likes on-chip 3-state > busses for their efficiency. > > Tony Burch wrote: > > > Hi Jamil, > > > > (1) Potential Bus Contention: > > The obvious issue is that MUXs avoid the potential problem > > with tristate buses - bus contention, with multiple drivers active > > at the same time (increases power consumption, reduces reliablility > > of the chip). > > For reliability problems to exist, there would have to be massive > contention, lasting a long time, which can only happen in an faulty design. > > > > > > > (2) Design Portability: > > If your design is HDL based, MUX based buses are technology > > independent, hence your design is more portable. Tristate > > resources are limited in FPGAs, and if you transfer your design > > to ASIC, tristate buses must never be allowed to float > > (FPGAs have weak-keepers on tristate resources, so floating > > doesn't occur). This is a "design for reuse" issue. > > True, but then: Only certain FPGA designs ever get ported to an ASIC. > > > > > > > (3) System Reset: > > This relates to point (1). If you use tristate buses in your > > design, you must use an asynchronous reset for your > > design. This is because with a synchronous reset, you > > may have contention on start-up, > > The global reset that is active during the whole configuration process is > asynchronous, and moreover, the user clock is actually coming in and is > being distributed during the configuration time. ( Speaking for Xilinx, I > don't know the Altera details enough). > So, unless the whole design is done in a weird way, there is no problem > during configuration and start-up. > > > because your system > > will reset to the known start-up state only on the first system > > clock. It is almost always better to use a synchronous > > system reset, or at least synchronise/register your incoming > > system reset signal. So, don't use tristate buses if you > > have a synchronous reset. It follows that if you have > > tristate buses, you must use an asynchronous reset. > > Have a good Memorial Day weekend ! > > Peter Alfke, Xilinx Applications >