Article 6200746 of comp.lang.vhdl: Path: newsreader.wustl.edu!newspump.wustl.edu!data.ramona.vix.com!sonysjc!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!rill.news.pipex.net!pipex!azure.xara.net!xara.net!newsfeed.uk.ibm.net!ibm.net!newsfeed.de.ibm.net!ibm.net!news-m01.ny.us.ibm.net!news.ibm.net!news-s01.ca.us.ibm.net!not-for-mail From: "Tom Phinney" Newsgroups: comp.lang.vhdl Subject: Re: OUT, INOUT and BUFFER Date: 3 Apr 1997 05:57:48 GMT Lines: 44 Message-ID: <01bc3ff3$c7969a70$50e32581@t_phinney_2> References: <333BEB3B.41C67EA6@lucent.com> <01bc3e07$15a7c160$dce42381@gaia> <3340AE07.5697@martis.fi> <334128C2.41C6@austin.ibm.com> <33425FC2.7039@synnet.com> NNTP-Posting-Host: slip129-37-227-80.az.us.ibm.net X-Newsreader: Microsoft Internet News 4.70.1155 Xref: newsreader.wustl.edu comp.lang.vhdl:6200746 Shannon Hill wrote in article <33425FC2.7039@synnet.com > Ports of mode OUT may have some benefit to someone, > but we NEVER use them here. (Long live BUFFER.) -------------- When I started using VHDL, I had to work with a vendor's synthesizer with a Beta VHDL front-end that did not support BUFFER. So I used only OUT and std_logic/std_logic_vector. Later I worked with more-experienced colleagues who had a number of space- and aircraft-qualified chips under their belts. They taught me to use BUFFER and std_ulogic/std_ulogic_vector wherever possible (i.e., wherever the driven net should have exactly one driver). Why? Because BUFFER and std_ulogic/std_ulogic_vector imply exactly one driver, and the available tools will note an error either if the net is undriven or if it has more than one driver. No testing or synthesis required. Also, a BUFFER output is available locally for internal use, since the value on the driven net is always the value that the BUFFER is driving. (This is not true for an OUT, where the net value can be different than that driven by the OUT.) Within a chip we use OUTs and std_logic/std_logic_vector only for multi-driven nets, and BUFFERs everywhere else that an output is needed. When we need to do low-level structural design, we use core cell models with BUFFERs for 2-state outputs, and with OUTs for 3-state outputs. Pad cell models are as needed: BUFFER for 2-state outputs, OUT for 3-state outputs, INOUT for bidirectionals or input pads with pullups, pulldowns, or integral bus repeaters. I haven't used LINKAGE yet, but I've seen it used in pad cell models for non-signals: analog and Vdd/Vss. In summary, VHDL permits fine specification of intent, which designers of life-critical or mission-critical chips frequently use. Tom Phinney Honeywell Article 6200768 of comp.lang.vhdl: Newsgroups: comp.lang.vhdl Path: newsreader.wustl.edu!newspump.wustl.edu!crcnews.unl.edu!news.mid.net!newsfeeder.gi.net!news.dra.com!news.visi.net!news.mathworks.com!howland.erols.net!vixen.cso.uiuc.edu!sdd.hp.com!hpscit.sc.hp.com!news.dtc.hp.com!hplntx!hplb!hpcpb!andrew From: andrew@bri.hp.com (Andrew Hana) Subject: Re: OUT, INOUT and BUFFER Sender: news@bri.hp.com (News User) Message-ID: Date: Sat, 5 Apr 1997 13:57:50 GMT Reply-To: andrew@bri.hp.com References: <333BEB3B.41C67EA6@lucent.com> <01bc3e07$15a7c160$dce42381@gaia> Nntp-Posting-Host: warp6.bri.hp.com Organization: Hewlett-Packard, Computer Peripherals Division, Bristol, UK X-Newsreader: TIN [version 1.2 PL2.9] Lines: 30 Xref: newsreader.wustl.edu comp.lang.vhdl:6200768 Richard Iachetta (iachetta@vnet.ibm.com) wrote: : and 2) There are a number of restrictions and : limitations on ports of mode BUFFER that caused Peter : Ashenden to write in the book THE DESIGNERS GUIDE TO : VHDL, "These restrictions severely limit the uses : of buffer ports, so they are not commonly used in practice". : So, we've been avoiding them and using internal signals that : are assigned at the end to the port of mode OUT. : -- I've never had any problems with using BUFFER. What are these restrictions? The only 'restriction' that I can think off that has any major impact is the one that restricts direct connects of BUFFERs and OUTs and INOUTs. Yes, there is a restriction, but generally, 1) Connectivity is easily handled with a graphical entry tool - which should generate the correct VHDL when mixing BUFFERs and OUTs - all that is needed is a connecting signal. Any VHDL generating tool should be able to handle that. 2) If you're not using a graphical entry tool, then component instantiations must be a real pain for you, and having the extra complexity of inserting a connecting signal is something you could do without. In this instance, sticking to one mode is best. 3) If OUTs are never used, then BUFFERs work just fine. Have I missed something? Andrew Article 6200762 of comp.lang.vhdl: Path: newsreader.wustl.edu!newspump.wustl.edu!data.ramona.vix.com!sonysjc!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news-peer.sprintlink.net!howland.erols.net!rill.news.pipex.net!pipex!uunet!in1.uu.net!129.35.248.10!ausnews.austin.ibm.com!not-for-mail From: "Richard Iachetta" Newsgroups: comp.lang.vhdl Subject: Re: OUT, INOUT and BUFFER Date: 4 Apr 1997 23:48:26 GMT Organization: IBM Austin Lines: 34 Message-ID: <01bc4153$91b0def0$dce42381@gaia> References: <333BEB3B.41C67EA6@lucent.com> <01bc3ec4$7851a520$dce42381@gaia> <3341B003.41C67EA6@qualis.com> <01bc3f88$ce5f8580$dce42381@gaia> <5i0n10$m6a@news.rain.net> NNTP-Posting-Host: gaia.austin.ibm.com X-Newsreader: Microsoft Internet News 4.70.1155 Xref: newsreader.wustl.edu comp.lang.vhdl:6200762 Janick Bergeron wrote in article <5i0n10$m6a@news.rain.net>... > In article <01bc3f88$ce5f8580$dce42381@gaia>, > Richard Iachetta wrote: > > But VHDL is forcing us > >to treat every 'internal' module as a mini-chip in itself. For internal > >modules, the concept of "driving out of the module" does not apply. > >There is no driver or buffer other than the gate creating the signal. > Why? I can just as easily put another driver on the signal connected to > the OUT port internally in a chip. That additional driver, once implemented, > will affect the feedback value because there is no output buffer, hence the > port is really an INOUT. Whether that was the intent or not is another matter. > Janick, This is the best explanation I've seen for the restriction. I didn't think about other drivers outside the module that can drive onto the output and would hence have to affect the feedback into the module. I never do that myself inside a chip but I know some people do internal tri-stateable busses, etc. Thanks. -- Richard Iachetta IBM Corporation iachetta@vnet.ibm.com Article 6200764 of comp.lang.vhdl: Path: newsreader.wustl.edu!newspump.wustl.edu!data.ramona.vix.com!sonysjc!su-news-feed4.bbnplanet.com!su-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!uunet!in3.uu.net!165.87.194.248!news-m01.ny.us.ibm.net!ibm.net!news-s01.ca.us.ibm.net!not-for-mail From: "Tom Phinney" Newsgroups: comp.lang.vhdl Subject: how to use BUFFERs (was Re: OUT, INOUT and BUFFER) Date: 5 Apr 1997 04:01:25 GMT Lines: 91 Message-ID: <01bc4175$df2f0130$70e32581@t_phinney_2> References: <333BEB3B.41C67EA6@lucent.com> <3342C9C4.215@est07.md.essd.northgrum.com> NNTP-Posting-Host: slip129-37-227-112.az.us.ibm.net X-Newsreader: Microsoft Internet News 4.70.1155 Xref: newsreader.wustl.edu comp.lang.vhdl:6200764 Ross Swanson wrote in article <3342C9C4.215@est07.md.essd.northgrum.com>... > Paul Uiterlinden wrote: > > > > All in all, in my opinion the `correct' usage of the modes is: > > > > IN : inputs > > BUFFER : outputs that never are tri-stated > > OUT : tri-statable outputs (unidirectional) > > INOUT : real bidirectional ports > > > > I know problems occur when combining components written according > > to the rules above, and components not using BUFFER. However, when > > applied consistently, these rules only has advantages, and seem > > more in line with the `spirit of VHLD' ... > > > Buffer ports are to restrictive so its to diffcult > to be 'consistent' when a team of people are sharing/reusing > code: > > If a component instance has a port of type buffer tied to > a port of the entity then that port must be type buffer. > > If a entity has a port of type buffer which is associated > to a formal port of a component instance then the formal > port can not be type out. > > Buffer ports can only have one source. > ----------- VHDL's features can help you if you let them. Here is a set of rules which we arrived at empirically, and which really work for us: 1) Any net that logically has a single driver should be declared, at all module levels in the hierarchy, as std_ulogic or std_ulogic_vector and the port type at the module interfaces should be IN or BUFFER. 2) Any net that logically has multiple drivers should be declared, at all driving module levels in the hierarchy, as std_logic or std_logic_vector and the port type at the module interfaces should be OUT or INOUT. If all of the drivers are limited to a single module (and perhaps its instantiated sub-modules), and the signal is to be exported from the module (toward the root of the hierarchy), then the signal should be cast/converted to a similarly-named std_ulogic or std_ulogic_vector and then exported through a BUFFER port. This rule can be ignored where external considerations (such as testbench requirements) require that the driven signal be std_logic or std_logic_vector. 3) In general, IN ports should use std_ulogic or std_ulogic_vector. This means that a cast/conversion from std_logic or std_logic_vector may be necessary in the instantiating hierarchy level. This rule can be ignored where it makes more sense to do the cast/conversion within the module, such as at the level of the chip pads. 4) Within library cells, all 2-state outputs where both states are actively driven (the norm) should be declared as BUFFERs. All 3-state outputs and single-ended outputs of library cells should be declared as OUTs. Within a chip, these rules lead to heavy use of BUFFERs and std_ulogic / std_ulogic_vector for normal nets. Tri-state nets and some nets with multiple single-ended drivers (fast carry logic and some dynamic logic come to mind) become the only internal std_logic / std_logic_vector nets. Externally, the environment is not as well determined, and so external inputs to the chip can be declared either as std_logic or std_ulogic; this decision should be based on your standard project practice. Declaring the external signals as std_logic means that the inputs will need a conversion/cast at the point of logical pad-cell instantiation; declaring the external signals as std_ulogic is more consistent with the internal practice, facilitating reuse of the design as a macro, but may require cast/conversion in the testbench or board level of the hierarchy. Many may disagree with these rules; no problem :-). But these rules do use the capabilities of VHDL for maximal early error detection -- each std_ulogic net must have EXACTLY one driver. Also, in general the number of extra signals required for std_logic nets which have dual std_ulogic nets [because of the conversion/casts of (2) and (3)] will be less than the number of extra signals that will be required to provide output values within a module declared with OUTs. It took us quite a while to evolve this set of rules; they do work well. Tom Phinney Honeywell Inc. Industrial Automation and Control Article 6200774 of comp.lang.vhdl: Path: newsreader.wustl.edu!newspump.wustl.edu!data.ramona.vix.com!news1.digital.com!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsfeed.nacamar.de!news.nacamar.de!uunet!in1.uu.net!158.101.112.7!bagit.synnet.com!egraham@synnet.com From: Shannon Hill Newsgroups: comp.lang.vhdl Subject: Re: how to use BUFFERs (was Re: OUT, INOUT and BUFFER) Date: Mon, 07 Apr 1997 08:22:28 -0400 Organization: 3COM Switching Division Lines: 34 Message-ID: <3348E703.1701@synnet.com> References: <333BEB3B.41C67EA6@lucent.com> <3342C9C4.215@est07.md.essd.northgrum.com> <01bc4175$df2f0130$70e32581@t_phinney_2> NNTP-Posting-Host: dale.synnet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (X11; I; HP-UX A.09.07 9000/770) Xref: newsreader.wustl.edu comp.lang.vhdl:6200774 Tom Phinney wrote: > ... > 1) Any net that logically has a single driver should be declared, at all > module levels in the hierarchy, as std_ulogic or std_ulogic_vector and the > port type at the module interfaces should be IN or BUFFER. > ... -- The problem with using std_ulogic and std_ulogic_vector is that the standard IEEE (and the synopsys-supplied add-ons) packages do not fully overload all the functions for both flavors; std_logic and std_ulogic are fully implemented, while std_ulogic and std_ulogic_vector are not. Trying to follow this practice where unidriver nets are all std_ulogic* turned into a big hassle, so we gave up. The fundamental 9-state type we use is std_logic & std_logic_vector, which seems to work well for both our sim and synth tools. We also noticed a tremendous difference in simulation performance depending on whether the design was std_ulogic or std_logic. Surprisingly, some simulators are faster with std_logic, others are faster with std_ulogic. Amazing. +----------------------------+----------------------------+ | Shannon Hill | em: hill@synnet.com | | 3COM Switching Division | fx: 508-264-1861 | | 80 Central Street | ph: 508-264-1420 | | Boxborough, MA 01719 | (email or fax preferred) | | gender=M +----------------------------+ +----------------------------+ Article 6200780 of comp.lang.vhdl: From: "Stephen A. Bailey" Subject: Re: OUT, INOUT and BUFFER References: <333BEB3B.41C67EA6@lucent.com> <3342C9C4.215@est07.md.essd.northgrum.com> Message-ID: <01bc4368$678c29b0$106d8781@grenoble> X-Newsreader: Microsoft Internet News 4.70.1155 Newsgroups: comp.lang.vhdl Date: Mon, 07 Apr 1997 10:29:43 -0500 Lines: 36 Path: newsreader.wustl.edu!newspump.wustl.edu!data.ramona.vix.com!sonysjc!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news.maxwell.syr.edu!news.msfc.nasa.gov!news.ingr.com Xref: newsreader.wustl.edu comp.lang.vhdl:6200780 Ross Swanson wrote in article <3342C9C4.215@est07.md.essd.northgrum.com>... > Paul Uiterlinden wrote: > > > > All in all, in my opinion the `correct' usage of the modes is: > > > > IN : inputs > > BUFFER : outputs that never are tri-stated > > OUT : tri-statable outputs (unidirectional) > > INOUT : real bidirectional ports > > > > I know problems occur when combining components written according > > to the rules above, and components not using BUFFER. However, when > > applied consistently, these rules only has advantages, and seem > > more in line with the `spirit of VHLD' ... > > > Buffer ports are to restrictive so its to diffcult > to be 'consistent' when a team of people are sharing/reusing > code: Perhaps you should find a vendor that supports VHDL '93. In VHDL '93, you can read the driving value of an output port using new predefined attributes: if P'Driving_Value = '1' then ... else ... end if; Also, if you use guarded signals (BUS or REGISTER kind), you can use the predefined attribute 'Driving to determine if the process is currently driving the signal before getting the driving value via 'Driving_Value. -- Stephen Bailey VeriBest Inc. 6101 Lookout Rd., Suite A Boulder, CO 80301 mailto:sbailey@veribest.com http://www.veribest.com voice: 303-581-2467 fax: 303-581-9972 Article 6200767 of comp.lang.vhdl: Newsgroups: comp.lang.vhdl Path: newsreader.wustl.edu!newspump.wustl.edu!crcnews.unl.edu!news.mid.net!newsfeeder.gi.net!news.dra.com!news.visi.net!news.mathworks.com!howland.erols.net!vixen.cso.uiuc.edu!sdd.hp.com!hpscit.sc.hp.com!news.dtc.hp.com!hplntx!hplb!hpcpb!andrew From: andrew@bri.hp.com (Andrew Hana) Subject: Re: OUT, INOUT and BUFFER Sender: news@bri.hp.com (News User) Message-ID: Date: Sat, 5 Apr 1997 13:50:20 GMT Reply-To: andrew@bri.hp.com References: <333BEB3B.41C67EA6@lucent.com> Nntp-Posting-Host: warp6.bri.hp.com Organization: Hewlett-Packard, Computer Peripherals Division, Bristol, UK X-Newsreader: TIN [version 1.2 PL2.9] Lines: 11 Xref: newsreader.wustl.edu comp.lang.vhdl:6200767 : All in all, in my opinion the `correct' usage of the modes is: : IN : inputs : BUFFER : outputs that never are tri-stated : OUT : tri-statable outputs (unidirectional) : INOUT : real bidirectional ports I agree - it is the usage that we have used for many years - without any problems. Andrew Article 6200818 of comp.lang.vhdl: Path: newsreader.wustl.edu!newspump.wustl.edu!data.ramona.vix.com!sonysjc!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!worldnet.att.net!cbgw2.lucent.com!nntphub.cb.lucent.com!ssbunews.ih.lucent.com!news From: nsi0412110-alblas Newsgroups: comp.lang.vhdl Subject: Re: OUT, INOUT and BUFFER Date: Fri, 11 Apr 1997 09:24:46 +0200 Organization: Lucent Technologies, Indian Hill Lines: 48 Message-ID: <334DE73E.41C67EA6@lucent.com> References: <333BEB3B.41C67EA6@lucent.com> NNTP-Posting-Host: hzsac73.nl.lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.4 sun4m) Xref: newsreader.wustl.edu comp.lang.vhdl:6200818 Andrew Hana wrote: > > : All in all, in my opinion the `correct' usage of the modes is: > > : IN : inputs > : BUFFER : outputs that never are tri-stated > : OUT : tri-statable outputs (unidirectional) > : INOUT : real bidirectional ports > > I agree - it is the usage that we have used for many years - without any problems. > > Andrew I agree, but there is one exception. In a vhdl netlist (after synthesis, with the 'real' components) sometimes 2-state buffers are put in parallel. At least these buffers should have a port of type 'OUT'. Normally, at this level vhdl is generated and not written, so this is not really a designer's problem. Up to now, I haven't seen a book about VHDL in which the reasons of certain rules and limitations are explained. This would help a lot in 'understanding' VHDL and would prevent people to work around limitations (like adding intermediate signals to read from ports of type 'out'). In my opinion most limitations of 'out' and 'buffer' are actually not disadvantages, but advantages. Treating them as such makes life much easier... There is, however, one rule I don't understand: "It is not allowed to connect a signal, coming from a port of type 'out' at a lower level, to a port of type 'buffer'" (almost equivalent with: "A port of type 'buffer' may have just 1 source"). Does anyone know why?? +----------------------+ | +---------+ | | | out | buffer | | | --->|--------->|---- | | | | | +---------+ | +----------------------+ Rob Alblas Lucent Technologies r.alblas@lucent.com Article 6200770 of comp.lang.vhdl: Path: newsreader.wustl.edu!newspump.wustl.edu!news.ecn.bgu.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.mathworks.com!out2.nntp.cais.net!news2.cais.com!news From: "Johnny Smooth" Newsgroups: comp.lang.vhdl Subject: Re: OUT, INOUT and BUFFER Date: 6 Apr 1997 19:06:26 GMT Organization: Posted via CAIS Internet Lines: 16 Message-ID: <01bc42bc$a1c8af60$1f2972cf@bulldog> References: <333BEB3B.41C67EA6@lucent.com> <333C50B1.CA4@ti.com> NNTP-Posting-Host: 207.114.41.31 X-Newsreader: Microsoft Internet News 4.70.1155 Xref: newsreader.wustl.edu comp.lang.vhdl:6200770 Jumpin' in late, but I haven't seen it mentioned yet... In VHDL'93 I believe there is an attribute sig'DRIVING_VALUE (I think that's its name ) that you can use on an OUT to make it's value available internal to the block. At least you don't have to create another signal... :-/ -- John "Whoever undertakes to set himself up as a judge in the field of Truth and Knowledge is shipwrecked by the laughter of the gods." Albert Einstein Article 6200772 of comp.lang.vhdl: Path: newsreader.wustl.edu!newspump.wustl.edu!news.ecn.bgu.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news-peer.sprintlink.net!cs.utexas.edu!news.ti.com!not-for-mail From: Brandon Azbell Newsgroups: comp.lang.vhdl Subject: Re: OUT, INOUT and BUFFER Date: Sun, 06 Apr 1997 23:17:11 -0500 Organization: Texas Instruments Lines: 26 Message-ID: <33487547.103@ti.com> References: <333BEB3B.41C67EA6@lucent.com> <333C50B1.CA4@ti.com> <01bc42bc$a1c8af60$1f2972cf@bulldog> Reply-To: b-azbell@ti.com NNTP-Posting-Host: 192.157.144.171 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (WinNT; I) Xref: newsreader.wustl.edu comp.lang.vhdl:6200772 Johnny Smooth wrote: > > Jumpin' in late, but I haven't seen it mentioned yet... > > In VHDL'93 I believe there is an attribute sig'DRIVING_VALUE > (I think that's its name ) that you can use on an OUT > to make it's value available internal to the block. At > least you don't have to create another signal... :-/ > -- > John > > "Whoever undertakes to set himself up as a judge in > the field of Truth and Knowledge is shipwrecked by > the laughter of the gods." > > Albert Einstein That is true. Unfortunately, when working with Synopsys, which currently only supports VHDL'87, that is a "feature" which can not be exploited. -- Regards, Brandon Azbell Texas Instruments Technical Staff - ASIC Applications and Design Chicago Design Center b-azbell@ti.com