defining all output ports in VHDL as type "buffer"

[shaiko]

Hello people.

Can you list any good reason NOT to use type "buffer" for ALL entity outputs?

When describing a complex block of logic, I like being able to read back an output port without having to use an auxiliary signal. I know that all output ports in Verilog HDL are automatically buffers. So...why not in VHDL ?

What are the cons of declaring all outputs as buffers?

 

[std_match]

It is a good idea in theory, but you will probably get into trouble.
You must use "buffer" in all levels in the design.
The problem is that if you instantiate an entity with port type "buffer", you can't connect it to port type "out".

It could work if you do a complete design by yourself, or if the project have a strict rule to only use "buffer".

I suggest that you use the attribute "driving_value" instead. That allows you to read what the process is trying to drive
(which can be different from the real value).

The reason for this behavior is that a process can not know the value of it's output's!
At least not for "std_logic", "unsigned" and "signed". The output can be connected to another output, outside of the process.

 

[shaiko]

Can you explain how to use the "driving_value" attribute?

 

[TrickyDicky]

driving value is an attribute of a signal that gives it's value as defined in the current process. It works the same as assigning a temporary variable.

eg:

process
begin

  a <= b and c;
  x <= d and a'driving value;

end process;

is the same as

process
  variable a_v : std_logic;
begin

  a_v := b and c;
  a <= a_v;
  x <= d and a_v;
end process;

So it would allow you to access an out port inside the same process, without having to resort to buffer (as 99% of engineers do not bother with buffer, and some company coding guidelines forbid the use of buffer).

 

[shaiko]

So,
if entity port "a" is defiend as "out std_logic" and I want to read it back - I can avoid redefining it as "buffer" and instead write:
internal_sig <= a'driving value;

Is this what you mean?

 

[TrickyDicky]

yes, but you can only do that from the same process that a is driven in.

so if a is defined outside a process like:

a <= b and c;

you cannot access the 'driving_value attribute.

But from your example, I dont know you would do it the other way round:

a <= internal_sig;

unless you wanted extra logic on the internal signal.

 

[shaiko]

What I want is to drive 'a' directly and be able to read it back (without having to use an "auxiliary" signal).

The 'driving_value attribute gives only a partial solution, so...it can't be used always.
This leaves us again with the need to use auxiliary signals which in turn makes the long signal list of our complex design even longer!

"99% of engineers do not bother with buffer, and some company coding guidelines forbid the use of buffer"
I see that the only good reason not to use the buffer type is because of compatability with other designs.
But that's like avoiding the use of electric cars because there're way too many gas stations around...

 

[FvM]

std-match initially mentioned the fact, that some design compilers, that are referring to an old VHDL version, allow buffer ports to be only connected to type buffer in the upper hierarchy. This isn't however required by recent tools as far as I'm aware of, e.g. Altera Quartus doesn't require it since ever, also ModelSim doesn't. They even tolerate, that the buffer property is hidden in a component definition in an upper entity by renaming a buffer to out.

Functionally, there's no difference between buffer and a temporary signal usage for output ports, presuming the assignment of temporary signal to output signal is done in concurrent code.

I also didn't hear, that in Verilog, where every output reg or wire can be read back without special prerequisites, anyone made a thing of it.

 

[TrickyDicky]

This leaves us again with the need to use auxiliary signals which in turn makes the long signal list of our complex design even longer!

How about scoping your signals? You can decalre signals inside generate regions (assuming they are only used inside the generate)
Also, use variables inside processes for your pipeline stages to replace signals. Just remember about variable assignment rules.

 

[shaiko]

TrickyDicky,

It doesn't matter if it's a signal or variable...
My point is, that declaring a signal/variable that is essentially a wire whose sole purpose is to serve as a mediator between the logic and the output port - makes the code unnecessarily verbose.
With all 'out' ports defined as buffers, we easily avoid the unnecessary text and make our code more tidy.

 

[FvM]

Defining all output ports as buffers creates a strange look of the port and is potentially confusing, I would restrict it to the outputs actually read back, then the buffer type helps to identify those signals.

 

[shaiko]

FvM,

That's a good idea.
And I think that this was the originial intention of the language...
However, for some reason as TrickyDicky mentioned 99% of engineers do not bother with buffers.

 

[FvM]

However, for some reason as TrickyDicky mentioned 99% of engineers do not bother with buffers.

Yes, but I don't exactly know why. I won't use buffers for signals that are primarly internal to an entity, only copied to the outer world for informational purposes. Simply because it confuses the signal's purpose. Signals that are primarly output signals of the entity, but needed additional internally are typical buffer candidates.

 

[TrickyDicky]

As with many things in VHDL (the std_logic_unsigned/arith libraries, component instantiations, blocks, register signals) there are some things that have been taken up or dropped over the years due to their lack of support from synthesis vendors. And then habits have formed using (or not) these things that are supported in the language. Im guessing buffer is one of those things.

The problem with buffer now, is that it is mentioned in other places (IO buffers on FPGAs) and could also cause some people to think that because it is special, it is automatically registered (which it is not), or cause some confusion with inout. These might be a bit remote, but Im sure they've happened.

 

[FvM]

As an additional remark, the restrictions for out ports have been removed in VHDL 2008.

Some authors still see buffer related to hardware signal buffering. I'm not sure, if a different handling can be expected with ASIC synthesis tools, but it can't with usual FPGA design compilers as far as I'm aware of.