using buffer mode ports

[Valentin Tihomirov]

I experiance a difficulty controlling out port from within an instance. I
think the port should be in *buffer* mode. However, my analyzer throws this
message:
" Actual of mode 'inout' can not be assigned to formal <signal> of mode
'buffer' "

I have took a look into FAQ; it describes my situation:
http://vhdl.org/vi/comp.lang.vhdl/FAQ1.html#buffer_ports
But I cannot conclude from it what is a typical pracice in VHDL for the case
:-(

There is a *linkage* mode which is not described in tutorials I wanted to
know when to use.

 

[Pieter Hulshoff]

I experiance a difficulty controlling out port from within an instance. I

think the port should be in *buffer* mode. However, my analyzer throws
this message:
" Actual of mode 'inout' can not be assigned to formal <signal> of mode
'buffer' "

Personally I try not to use inout as a port type unless it's actually a
tristatable bus. Throughout my design I'll use type BUFFER, and at top
level I'll use an intermediate signal to connect it to a port OUT. An
alternative is to always use internal signals to use the internal value of
a signal, and then connect it to a port of type OUT.

If you insist on using INOUT in combination with BUFFER, just use an
intermediate signal, and connect that to the BUFFER port. Something like:

label_l: component_name
PORT MAP
(
a => a_int -- a of type INOUT, a_int an internal signal
);

a_buf <= a_int; -- connect a_int to buffer port a_buf, where a_buf is
defined as a buffer in the entity

Regards,

Pieter Hulshoff

 

[Valentin Tihomirov]

Whether mode of a port is out or buffer you use intermediate signal to
update it. What is ther reason to use *buffer* at all? Why does LRM prohibit
updating buffer from instance scope?

 

[Pieter Hulshoff]

Whether mode of a port is out or buffer you use intermediate signal to

update it. What is ther reason to use *buffer* at all? Why does LRM
prohibit updating buffer from instance scope?

No, I normally use port BUFFER to allow me to use the internal value of the
output signal. The construction I gave you is one I'd never use, but then
again I don't try to connect a port of type INOUT to one of port BUFFER.
From your words I gathered that was what you were trying to do. If I
misunderstood, please post some examples of your code so that I may
understand your problem and help you to find a proper solution.

Regards,

Pieter Hulshoff

 

[Valentin Tihomirov]

I've already found a solution. I refused using buffer mode, cos I need
intermediate signal anyway.

entity E port (I: in bit; O: out: std_logic) end E;

architecture EXAMPLE of E is
signal O_INTERMEDIATE: std_logic;
begin
unit: entity work.X port map(I, O_INTERMEDIATE);
O <= O_INTERMEDIATE;
end EXAMPLE;

This works the same when 'O' port is either in out or buffer mode.

But I still do not understand what is the reason to use *buffer* mode? Why
does LRM prohibit updating buffer port from instance's scope? I think if
have a right to update port's value (a buffer mode) within my architecture
then I can do it wherever I like.

 

[Pieter Hulshoff]

But I still do not understand what is the reason to use *buffer* mode? Why

does LRM prohibit updating buffer port from instance's scope? I think if
have a right to update port's value (a buffer mode) within my architecture
then I can do it wherever I like.

You have to look at mode BUFFER as a wire with a split: one end goes back
into your architecture (so it can be used for logic), and the other goes
through a buffer out of the block. Anything you do outside the block to the
signal should not influence the value inside the block, because it is
stopped by the buffer (some exceptions apply of course; short-circuit or
high voltage should still have some interesting effects.

Regards,

Pieter Hulshoff

 

[Valentin Tihomirov]

You have to look at mode BUFFER as a wire with a split: one end goes back
into your architecture (so it can be used for logic), and the other goes
through a buffer out of the block. Anything you do outside the block to

the

Yes, I have the same image. But it is not clear due to the details I do not
understand.
1. Internal buffers can be split without any special declarations. The
only thing I suppose one can buffer outgoing signal is to allow for its
greater load. However, VHDL is not powerful enaught and not intended to
worry about technological issues, it is VHDL is simulation, RTL and logic
specification language. I do not talk about tricks with controlling
placement from VHDL, this is tool specific and is not putpose of the
language. So, buffer incurring as a task of implementing tool.

... Anything you do outside the block to the
signal should not influence the value inside the block, because it is
stopped by the buffer (some exceptions apply of course; short-circuit or
high voltage should still have some interesting effects.

2. IMO, *outside* the block means an upper level of hierarchy, i.e.
"parent" of the block. And vise versa, the notion *inside* or within *scope*
of a block does mean that a feature is implemented by any stuctural element
of the block. In my interpretation, signal can be updated by a statement or
any of its sub-modules. Therefore, it is not logical that a statement can
update a port (out or buffe rmode) but instance cannot.

 

[Pieter Hulshoff]

I do not talk about tricks with controlling

placement from VHDL, this is tool specific and is not putpose of the
language. So, buffer incurring as a task of implementing tool.

*nod*, and it will be. I just explained how to envision the VHDL. How it
will be synthesized is a totally different matter.

2. IMO, *outside* the block means an upper level of hierarchy, i.e.
"parent" of the block.

Therefore, it is not
logical that a statement can update a port (out or buffe rmode) but
instance cannot.

From what is synthesized I agree with you; it should be possible to do so.
From a language point of view however it cannot. In the language it
represents a buffered output (even though it will probably not be
synthesized that way), and as such the language will not allow you to drive
the value from outside that hierarchy level. That's even aside from the
tons of trouble you'd get yourself into with multiple drivers on a single
signal if the language _would_ allow it.

Regards,

Pieter Hulshoff

 

[Paul Uiterlinden]

You have to look at mode BUFFER as a wire with a split: one end goes back
into your architecture (so it can be used for logic), and the other goes
through a buffer out of the block. Anything you do outside the block to the
signal should not influence the value inside the block, because it is
stopped by the buffer (some exceptions apply of course; short-circuit or
high voltage should still have some interesting effects.

If I may add to the confusion. ;-)

There isn't anything you can do outside the block, because any actual
associated with a formal buffer port may have at most one source (LRM 93,
page 7, line 107).

For normal (non tri-state) outputs this is exactly what you want. That's
why I always use buffer for normal outputs. In contrast to an output with
mode out, an output with mode buffer may be read internally. Having said that,
in VHDL93 you can read an output with mode out internally by using the 'driving
attribute (which is a kludge, IMO).

There's only one disadvantage with the use of buffer: if you start using it,
you'll have to be consistant. An instantiated module with a mode out output may
not drive the output of the instantiating module if that output is mode buffer.

Finally: the word buffer has nothing to do with actually placing buffers
during synthesis.

Paul.

 

[MM]

There's only one disadvantage with the use of buffer: if you start using it,
you'll have to be consistant. An instantiated module with a mode out output may
not drive the output of the instantiating module if that output is mode

buffer.

I found that there is another disadvantage. Suppose you want to use a
post-par VHDL model for timing simulation with the same test bench you used
for functional simulation. The model will not have buffer type ports since
this spec will have been lost somewhere in the synthesis/implementation
phase and you will have to change your module interface in the test bench to
make it work.

/Mikhail

 

[Paul Uiterlinden]

MM wrote:

I found that there is another disadvantage. Suppose you want to use
a post-par VHDL model for timing simulation with the same test bench
you used for functional simulation. The model will not have buffer
type ports since this spec will have been lost somewhere in the
synthesis/implementation phase and you will have to change your
module interface in the test bench to make it work.

OK, you're right. In that case I would make an exception for the
top-level: use mode out. This of course means some intermediate
signals in the top level architecture though.

Paul.