out ports on the right side

[John Smith]

Is there a good reason why VHDL doesnt allow to appear out ports on right side?

For example:
a <= s1;
This is allowed when s1 is signal and a is out port.

a <= b;
Isnt allowed when b is "out"


Thanks

 

[Mike Treseler]

Is there a good reason why VHDL doesnt allow to appear out ports on
right side?

Yes. The are OUT ports, not IN ports.

For example:
a <= s1;
This is allowed when s1 is signal and a is out port.
a <= b;
Isnt allowed when b is "out"

The OUT port ID goes on the left
and the value goes on the right.
The value can be a constant, variable,
signal, or and expression using these.
For example:

q <= std_logic_vector(reg_v);

see http://home.comcast.net/~mike_treseler/
for more examples.

-- Mike Treseler

 

[John Smith]

Yes. The are OUT ports, not IN ports.


The OUT port ID goes on the left
and the value goes on the right.
The value can be a constant, variable,
signal, or and expression using these.
For example:

q <= std_logic_vector(reg_v);

see http://home.comcast.net/~mike_treseler/
for more examples.

-- Mike Treseler

Yes, maybe somebody can clear what is the reason that OUT ports cannot appear on
the right side.

Thanks for your help.

 

[Jonathan Bromley]

Yes, maybe somebody can clear what is the reason
that OUT ports cannot appear on
the right side.

It's a rule of the language, and a standard FAQ.

Let's try some reasons. Decide for yourself which,
if any, you find convincing. All have some truth
in them.

1) User discipline
~~~~~~~~~~~~~~~~~~
It's an OUT port. You're sending information out
of the design unit. It is probably a user error to
attempt to read it, because there is a risk that you
imagine you are reading a value that came in through
the port from the outside world - which, of course,
would need an input or inout port.

2) Port transparency
~~~~~~~~~~~~~~~~~~~~
Unlike Verilog, ports in VHDL are completely transparent.
After the model has been elaborated, the signal inside
the design unit and the connected signal outside are
one and the same signal; there is no implicit driver
across the port boundary. Consequently, reading an
OUT port makes no sense because there *might* be another
driver on the signal, outside your design unit. When
you try to read an OUT port, do you want the value
that you are driving, or do you want the value that
appears on the signal as a result of its multiple
drivers? It's too ambiguous. VHDL has a very simple
solution to the first question - use an internal
variable, and drive that variable onto the out port - and
a simple solution to the second question - use inout.
You decide; there is no ambiguity, everyone knows what
you are trying to do, and your design unit's behaviour
is (as we would hope) unaffected by its environment.

3) Delta delays
~~~~~~~~~~~~~~~
It is a common newbie VHDL error to write something like
this:

process (A)
begin
B <= A + 1;
Y <= B + 1; -- newbie expects to get Y = A+2
end process;

We can't stop people making that mistake on internal
signals, but making OUT ports unreadable is a way to
reduce the risk in at least some situations.

4) Job protection
~~~~~~~~~~~~~~~~~
If VHDL did not put obstacles of this kind in the beginner's
way, I might be out of a job soon.


Oh, and you might like to find out about buffer ports, and
the VHDL-2002 changes that affect how you can connect buffer
and out ports to one another.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Shannon]

Oh, and you might like to find out about buffer ports, and
the VHDL-2002 changes that affect how you can connect buffer
and out ports to one another.

And as a beginner that has recently been through all this, I would
suggest looking into the difference between ports, signals, and
variables. If 'b' in the above example was a signal for example...all
would be fine.

Shannon

 

[Andy]

And as a beginner that has recently been through all this, I would
suggest looking into the difference between ports, signals, and
variables. If 'b' in the above example was a signal for example...all
would be fine.

Shannon

I suspect you meant to say "if 'b' was a VARIABLE". But it still would
not work... you'd need to change the assignment operator to ":=" too.

Just one of the many reasons I like variables: the code "reads" like
software. The synthesis tool will insert registers (or not) to make
the hardware behave the same way that the code executes, and the code
executes the same way that it reads.

Andy

 

[Tricky]

Just one of the many reasons I like variables: the code "reads" like
software. The synthesis tool will insert registers (or not) to make
the hardware behave the same way that the code executes, and the code
executes the same way that it reads.

Andy

That is true, but that can make the code harder to read for someone
else. If you use variables to imply registers or not, then it can be
hard for someone to work out when or if a register is implied. Never
hold a variable value over a clock edge.

I find it best to use variables ONLY for combinational logic and let
Signals imply the registers. It then makes the code easier to read for
others. It also means if you need to access that that register value
in another process, its always available.

 

[Mike Treseler]

That is true, but that can make the code harder to read for someone
else. If you use variables to imply registers or not, then it can be
hard for someone to work out when or if a register is implied.

Fortunately, synthesis works this out for me.
I verify my work with simulation, not by
synthesizing the code in my head.

Here are some synthesis examples and results
using *no* signals at all.
http://home.comcast.net/~mike_treseler/

Never
hold a variable value over a clock edge.

That is strictly a matter of style.
If I followed that rule, it would
be much more difficult for me to
match the algorithms that I need to synthesize.

I find it best to use variables ONLY for combinational logic and let
Signals imply the registers.

You are free to use that style.
Many do. But this is not a logical
reason for others be accept such
a limitation.

It then makes the code easier to read for
others.

Some others perhaps. Not me.
I prefer reading code with
well-named procedures and functions.

It also means if you need to access that that register value
in another process, its always available.

In a single process entity, this is also true.
See my examples.

-Mike Treseler

 

[Andy]

That is true, but that can make the code harder to read for someone
else. If you use variables to imply registers or not, then it can be
hard for someone to work out when or if a register is implied. Never
hold a variable value over a clock edge.

I find it best to use variables ONLY for combinational logic and let
Signals imply the registers. It then makes the code easier to read for
others. It also means if you need to access that that register value
in another process, its always available.

I find most "readers" are more interested in the functionality, rather
than the resulting structure of the implementation. Thus, a
description that executes more like SW (what most folks are most used
to reading) is more "readable".

If I cannot divine the implemented structure from a piece of code, I
run it through a synthesis tool and look at the schematic (RTL or
gates) view. Synplify Pro is really good at that. Besides, if you rely
on the structure you think you will get from reading the code, you
will likely miss optimizations, etc. that a specific synthesis tool
will make (or not).

If I wanted my code to describe the smallest structural level of the
design (i.e. gates & flops), I'd code a net list. The whole point of
HDL is to be able to describe a functionality over time, and have the
tool figure out the best way to implement that in gates and flops. If
I don't like that implementation (it takes up too much time and/or
resources), then I worry about giving more hints about a structure I
think will help. But that is a last, rather than a first, resort.

Using variables also PREVENTS other processes from accessing the data,
unless it is "passed" to them on a signal. This keeps local things
local, and global things global (within an architecture). I could use
blocks and signals to accomplish that, but I prefer variables for
other reasons, as stated. In my designs, signals are used ONLY for
data passed between processes and/or ports. This also makes
synchronization boundaries easier to police without requiring separate
blocks or entity/architectures.

Andy

 

[Jim Lewis]

Is there a good reason why VHDL doesnt allow to appear out ports on

right side?

For example:
a <= s1;
This is allowed when s1 is signal and a is out port.

a <= b;
Isnt allowed when b is "out"


Thanks

This is fixed in the next revision of VHDL (Accellera VHDL-2006).
So if you want this feature, submit a bug report against it.

Jim

 

[Shannon]

This is fixed in the next revision of VHDL (Accellera VHDL-2006).
So if you want this feature, submit a bug report against it.

Jim

Fixed? How is it broken? Seems fine to me.

Shannon

 

[Jim Lewis]

Fixed? How is it broken? Seems fine to me.

The feature came from ADA. ADA removed the feature
in its 1995 revision.

When you start to write assertions (such as PSL in VHDL
- also a new capability with Accellera VHDL-2006),
you need to be able to read outputs. Sometimes these are
written by Verification engineers who are not permitted
to change the VHDL code.