BUFFER mode ports

[Winston Smith]

Our team has been under pressure to start using mode BUFFER ports instead of
mode OUT in our VHDL projects. My limited attempt to use buffer a while ago
demonstrated that they were more trouble than they were worth. My research
has found a technical article by Xilinx that claims that there are possible
synthesis problems with using mode buffer. Both Ashenden and Bhasker, (both
on the IEEE committee for VHDL) both discourage it in their books. Ashenden
says it is rarely used - I think for good reason. Of course Ashenden is
correct, in many years of VHDL coding I have never seen anyone persist in
using it.

It obviously becomes another headache in wiring up a large design, with IP
cores that do not necessarily have mode BUFFER outputs. The structural code
is usually the most tedious and time consuming code in a design (even using
emacs, where if there are enough changes, its easier to start over from
scratch). The purported benefit is the effect in compilation when it gives
an error if 2-ports drive the same signal. Of course if you do due diligence
and examine your synthesis log files, you see it there or in your MTI
simulation window where you see a nice X.

Does anyone else have an objective opinion on BUFFER, especially any
synthesis issues? Besides it being a pain in the ass.

SOS

 

[Allan Herriman]

Our team has been under pressure to start using mode BUFFER ports instead of
mode OUT in our VHDL projects. My limited attempt to use buffer a while ago
demonstrated that they were more trouble than they were worth. My research
has found a technical article by Xilinx that claims that there are possible
synthesis problems with using mode buffer. Both Ashenden and Bhasker, (both
on the IEEE committee for VHDL) both discourage it in their books. Ashenden
says it is rarely used - I think for good reason. Of course Ashenden is
correct, in many years of VHDL coding I have never seen anyone persist in
using it.

It obviously becomes another headache in wiring up a large design, with IP
cores that do not necessarily have mode BUFFER outputs. The structural code
is usually the most tedious and time consuming code in a design (even using
emacs, where if there are enough changes, its easier to start over from
scratch). The purported benefit is the effect in compilation when it gives
an error if 2-ports drive the same signal. Of course if you do due diligence
and examine your synthesis log files, you see it there or in your MTI
simulation window where you see a nice X.

Does anyone else have an objective opinion on BUFFER, especially any
synthesis issues? Besides it being a pain in the ass.

The next rev of VHDL will allow 'out' ports to be read within an
architecture. This makes 'buffer' even less useful.

Why are you under pressure to start using buffer ports, when the
language is moving the other way?

http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft12_read_out_ports.txt

Regards,
Allan

 

[Neo]

Its very rarely used but I think some go for it to avoid declaring
those extra signals reqd otherwise. still its not a good idea as you've
stated.

 

[Pieter Hulshoff]

Does anyone else have an objective opinion on BUFFER, especially any
synthesis issues? Besides it being a pain in the ass.

Our team consistently uses BUFFER throughout our designs, and it has given
us no problems whatsoever. We use BUFFER upto core level of the chip, and
then switch to OUT for the final top-level. As long as you use it
consistently, your team should be fine.

Regards,

Pieter Hulshoff

 

[Jezwold]

I am just interested in how anyone would put a design team under
pressure to do anything,hearding cats while riding a unicycle and
juggling at the same time would be easier I should think.

 

[Paul Uiterlinden]

Does anyone else have an objective opinion on BUFFER, especially any
synthesis issues? Besides it being a pain in the ass.

It is not a pain if it is used consistently. Only then it will become a
gain in stead of a pain.

Years ago the design teams I was working in decided to use BUFFER, with
a few simple rules when to use IN, OUT, INOUT or BUFFER. See

http://www.google.nl/groups?hl=nl&l...idirectional+group:comp.lang.vhdl&btnG=Zoeken

We still use these rules and it works just fine, both for simulation as
well for synthesis.

Another thing is that there seem to be some relaxations underway in the
new VHDL standard with respect to BUFFER and OUT. I don't know the
details though.

Paul.

 

[Dave Higton]

In message <[email protected]>

The next rev of VHDL will allow 'out' ports to be read within an
architecture. This makes 'buffer' even less useful.

This looks like a good move. It's always seemed silly to me that VHDL
doesn't allow you to read the value of an output port. Why not? You're
entitled to know, since it was you that set it. But in order to satisfy
VHDL, you have to go through this clumsy procedure of setting an internal
signal, then copying the internal signal to the output port; then you
have to remember to reference the internal signal, not the external one.
Clumsy.

Using buffer instead of output seemed to be good; it looks to me like an
output whose value you can read. Great. I don't know of any other
difference - but I'm ready to learn! However, ModelSim is pedantic, too.
If I create an entity containing a signal of type buffer in a lower
level, and connect it to a signal of type output on a higher level,
ModelSim objects. The signal has to be of type buffer all the way
up the hierarchy, right to the output pin. There's some reason, that I
can't remember right now, why that's inconvenient. (It's a long time
ago that I last tried it.)

Dave

 

[Winston Smith]

I am just interested in how anyone would put a design team under
pressure to do anything,hearding cats while riding a unicycle and
juggling at the same time would be easier I should think.

In large corporations there is always a push to standardize and control
everything. That way all initiative can be safely removed and only a mere
set of processes remain.

That is why small start-ups come up with all the great new ideas.

Some significant degree of coordination is needed on a big team, especially
if one were to use BUFFERS. Then there is a a need to coordinate the INs
and OUTs usually there are few INOUTs that are well known.

 

[Winston Smith]

More Research on Buffers:

Xilinx had a problem at one point. Have not hear of a lot more.

http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/coding4.html


Then the textbook references.

The Designers Guide to VHDL 2nd Edition, Ashenden, Morgan Kaufamann Pub.
Page 617 - This guy was on the IEEE VHDL committee.

VHDL-87 and VHDL-93 impose a number of restrictions on how buffer ports
may be interconnected with other ports. First, if the actual object
associated with a buffer port of a component instance is a port of the
enclosing entity, it must also be a buffer port. Second, if we associate
a buffer port as an actual object with some formal port of component
instance, the formal port must also be of mode in, buffer or linkage. It
may not be a port of mode out. Thus, the D_flipflop component in Figure
21-1 would have to be a buffer mode output port. Any flipflop entity
bound to the flipflop instances in the counter would also require a
buffer output port. Third, a buffer port can only have one source.
Hence , we cannot resolve a number of sources to determine the value of
a buffer port, Finally, while we can associate an actual signal with a
buffer port of a component instance, that port must be the only source
of the signal. Thus, we cannot use a buffer port of a component as one
of a number of contributors to a resolved signal. These restrictions
severely limit the uses of buffer ports, so they are not commonly used
in VHDL-87 or VHDL-93.



Vhdl for Logic Synthesis, Andrew Rushton, page 26-7. McGraw Hill

There is often confusion between mode out and mode buffer. Mode buffer
is an anachronism and the reason for its existence in the language is
obscure. The full behavior of a buffer port is a restricted form of mode
inout. However, to make the mode usable for synthesis, the rules for
buffer ports are constrained so that they act like mode out ports with
the added convenience that it is possible to read from the port within
the architecture.

Unfortunately, the rule for mode buffer are more complex than this; this
interpretation of mode buffer is a simplification to make the mode
useful for synthesis and is common to most synthesizers. The full rules
also prevent mode buffer and mode out from being mixed in a hierarchical
design. That is, it is not possible to connect a buffer mode port of a
subcomponent to an out mode port of a higher level component.

These restrictions on the mixing of the modes and cause inconvenience,
at the very least. It is therefore recommended that only one of the
output modes is ever used. Furthermore, owing to the anachronistic
nature of mode buffer, it is recommended that only out mode is used.



Of course all of us engineers in the US and Europe are probably an
anachronisn anyway, since the future of technology seems to lie in Asia.

 

[Paul Uiterlinden]

In message <[email protected]>
Allan Herriman


This looks like a good move. It's always seemed silly to me that
VHDL
doesn't allow you to read the value of an output port. Why not?

Playing the devil's advocate: because two output ports may be
connected to a single resolved signal. The value that you read back
from the output internally (if it would be allowed) is not
necessarily the same as on the connected signal. With BUFFER this
problem does not exist, because the BUFFER output may only be the
single driver on the connected signal.

You're
entitled to know, since it was you that set it. But in order to
satisfy VHDL, you have to go through this clumsy procedure of
setting an internal signal, then copying the internal signal to the
output port; then you have to remember to reference the internal
signal, not the external one. Clumsy.

That's why we decided to use buffer. But is has to be used
consistently. That may be a problem with existing code.

Paul.

 

[Charles Bailey]

output whose value you can read. Great. I don't know of any other
difference - but I'm ready to learn! However, ModelSim is pedantic, too.
If I create an entity containing a signal of type buffer in a lower
level, and connect it to a signal of type output on a higher level,
ModelSim objects. The signal has to be of type buffer all the way
up the hierarchy, right to the output pin. There's some reason, that I
can't remember right now, why that's inconvenient. (It's a long time
ago that I last tried it.)

That's been exactly my experience. You make a change to your logic down
deep in the hierarchy somewhere and you need to use a signal internally
besides routing it to an output. So, you change the port type to
"buffer", thinking that is an easy way to handle the situation. Then
you find that you need to change the port types to "buffer" all the way
up the hierarchy. That led us to quickly abandon the use of the
"buffer" port type. It's more trouble than it's worth.

Charles Bailey

 

[Brian Drummond]

That's been exactly my experience. You make a change to your logic down
deep in the hierarchy somewhere and you need to use a signal internally
besides routing it to an output. So, you change the port type to
"buffer", thinking that is an easy way to handle the situation. Then
you find that you need to change the port types to "buffer" all the way
up the hierarchy. That led us to quickly abandon the use of the
"buffer" port type. It's more trouble than it's worth.

Or, in the instantiating entity, revert to an internal signal between
the component's "buffer" and the entity's "output", which IMO is no more
or less of a hack than using an internal signal in the component to
remove the need for a "buffer".

Changing from "out" to "buffer" is only a problem because it's an
interface change, which therefore affects other modules.

I wonder why exactly the "BUFFER" mode must propagate all the way up
through output ports? Wouldn't it be appropriate and consistent to treat
a BUFFER to OUT connection as though it was made through an internal
signal? Thus any resolution between the entity's OUT port and other
(presumably mis-wired) drivers would appear on the "internal signal" but
not propagate down through the BUFFER.

I guess I just don't see what would break if this rule were relaxed.
Any ideas?

Relaxing the "cannot read OUTPUT" rule looks similar, but I would expect
it to act differently, in that the "resolved" value would propagate down
through the OUT port into the component, exactly as happens in an INOUT
port. The only difference being that the behaviour is usually
intentional in INOUT, but probably erroneous in OUT. However
http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft12_read_out_ports.txt
suggests the driving value will be read; as in BUFFER; while also making
it clear that you're not supposed to use the facility except for
verification.

This doesn't make BUFFER any less useful directly, but it tempts us to
misuse OUT and so avoid BUFFER.

-------------------------------

There is a nice synergy between "BUFFER" and unresolved types
(std_ulogic[_vector]), but I rarely take advantage of it, because I
rarely use the latter. The reason? It is good to use the highest
practical level of abstraction, and that (for datapaths anyway) usually
means numeric_std, and signed or unsigned. Which are based on the
resolved types...

Thus there is a conflict of interest between bug avoidance (through
using appropriate abstraction) and early bug detection (through
unresolved types) which seems unfortunate... though I doubt that a
proliferation of "numeric_std_unresolved" types is the right answer!

- Brian

 

[Brian Drummond]

Our team consistently uses BUFFER throughout our designs, and it has given
us no problems whatsoever. We use BUFFER upto core level of the chip, and
then switch to OUT for the final top-level. As long as you use it
consistently, your team should be fine.

That has been my experience too. It seems to me that some of the
warnings against BUFFER use are either FUD or based on poor support for
it "because nobody uses it". The Xilinx link posted in this thread
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/coding4.html
appears to fall into this category - it says "don't do that" but without
really explaining why. (If the "buffer" output in the example is
directly connected to a port, then that port must be "IN" or "BUFFER"
type, but if it's connected to a signal, no problem).

Similarly, XST "HDL Advisor" warns against BUFFERs with a vague allusion
to "difficulty validating the design by simulation" which is odd, since
BUFFER is intended to simplify verification by localising design errors,
and Modelsim has never given me problems in that regard.

Does anybody have any idea what "difficulty" XST could be referring to?

Interestingly, though XST checks formal ports against actual connections
when compiling, and complains, it seems quite happy to substitute "OUT"
for "BUFFER" (or was it vice-versa?) at the elaboration phase.

- Brian