port's types

[moonlight]

hello,
can anyone give an illustrative example from the actual life to be
similar to INOUT & BUFFER types of port in vhdl?If it is possible
please give me some examples in VHDL's code too...
thanks for attention.

 

[Duane Clark]

moonlight wrote:

hello,
can anyone give an illustrative example from the actual life to be
similar to INOUT & BUFFER types of port in vhdl?If it is possible
please give me some examples in VHDL's code too...
thanks for attention.

In 6-7 years of VHDL coding, I have never used a BUFFER type port. I
doubt there is a situation where I would ever use it.

 

[Noway2]

I haven't used a type BUFFER either, but if my memory is correct it is
an output that can also be fed back (i.e. read) by structures inside
the block. A possible example might be an accumulator, though there
are other ways to accomplish the same thing.

 

[Mike Treseler]

moonlight wrote:

can anyone give an illustrative example from the actual life to be
similar to INOUT & BUFFER types of port in vhdl?

Never use buffer.

Use inout only for tristate device pins
with logic for output enable.

Google for examples.

-- Mike Treseler

 

[krby_xtrm]

buffer, output but data can be read back,
it's like an output port with reference to an internal signal.

 

[mindenpilot]

In addition to a bidirectional/tristateable bus, I use inout to read
outputs, too.
I've ascertained that's not good practice.
Am I being lazy?
What's the preferred method?

Regards,

Adam

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:3thddlFsqgk2U1@individual.net...

moonlight wrote:

can anyone give an illustrative example from the actual life to be
similar to INOUT & BUFFER types of port in vhdl?

Never use buffer.

Use inout only for tristate device pins
with logic for output enable.

Google for examples.

-- Mike Treseler

 

[Reiner Huober]

If you want to read an output port in VHDL , the preferred method is to
declare the port as OUT, not INOUT, to let the entity definition be
clean.

In the architecture, declare an internal signal and use a concurrent
signal assignment to the output port. Example:

entity x is ...
port Q: out std_logic_vector(3 downto 0);
end;

archtitecture y of x is
signal Q_int: std_logic_vector(Q'range);
begin
Q<=Q_int;
... use Q_int on all other places inside the architecture. Q_int can
be
... read and written.
Ctr: process(CLK)
begin
if rising_edge(CLK) then
Q_int<=add(Q_int,"0001"); -- read and write Q_int
end if;
end process;


In simulation, this inserts an additional delta cycle, which should not
be a problem in standard cases. If it is (p.e. in testbenches), Q and
Q_int can be assigend always parallel, but this is a bit ugly.


Using the numeric_std package, the shadow signal can be declared as
signed or unsigned, giving the right behaviour for counters and leaving
std_logic_vector on outputs:

library ieee;
use ieee.numeric_std.all; -- prefered package
...
port Count: out std_logic_vector(15 downto 0;
...
architecture y of x is
signal Count_int: unsigned(Count'range); -- unsigned type from
numeric_std
begin
Count<=std_logic_vector(Count_int);

process(Clk)
begin
if rising_edge(CLK) then
Count_int<=Count_int + 1; -- '+' from numeric_std
end if;
end process;
....

Hubble

 

[Mike Treseler]

mindenpilot wrote:

I use inout to read outputs, too.
I've ascertained that's not good practice.
Am I being lazy?

Not if you got an inout port to actually
work in simulation and synthesis.
That's not easy.

What's the preferred method?

I prefer to declare a process variable
for each output.
Others prefer an architecture signal.
Good luck.

-- Mike Treseler

 

[mindenpilot]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:3tjsdiFskcu4U1@individual.net...

mindenpilot wrote:
I use inout to read outputs, too.
I've ascertained that's not good practice.
Am I being lazy?

Not if you got an inout port to actually
work in simulation and synthesis.
That's not easy.

It's not too hard, either. Just need to be cautious!

What's the preferred method?

I prefer to declare a process variable
for each output.
Others prefer an architecture signal.
Good luck.

-- Mike Treseler

Of the two methods, is one preferred or more standard?

Thanks and regards,

Adam Weiss

 

[Mike Treseler]

mindenpilot wrote:

Of the two methods, is one preferred or more standard?

Not really.
You have my preference.
Try it both ways and see what you think.

-- Mike Treseler

 

[Andy]

Using a process variable has the advantage of maintaining an
all-synchronous description, which will simulate faster in modern
simulators (where all processes with same sensitivity list are merged).
Having a bunch of combinatorial processes (or implied ones from
concurrent assignments) thwarts this cycle-based optimization. Good
synthesis tools will optimize out the duplicate flop.

process (clk)
variable count : natural range 0 to 15;
begin
if rising_edge(clk) then
count := (count + 1) mod 16;
output <= count; -- output and count are duplicates (no clock
delay)
end if;
end process;

Andy

Mike Treseler wrote:

mindenpilot wrote:

Of the two methods, is one preferred or more standard?

Not really.
You have my preference.
Try it both ways and see what you think.

-- Mike Treseler