Good practice for signal types

A

Alex Young

Guest
Hi all,

Having only recently started using vhdl I am wondering if there are any
recomendations for how to use types within designs?
It seems that the most generic type is std_logic(_vector). Is it generally a
good idea to use this type to pass data around between modules/entities?
( Argh what is the correct name for these? I am used to Verilog!)

In particular how would you handle the design of something like an ALU. It
would seem to make sense to give it signed/unsigned types. Should I pass
std_logic values and then type convert to signed within the architecture of
the ALU?

A similar question relating to boolean values. It seems that using booleans
will give cleaner code. i.e.
zero_flag := alu_out = 0;
as opposed to
if alu_out = 0 then
zero_flag := '1';
else
zero_flag := '0';
end if;
I guess that this will have problems with uninitialised values though. Again
what would be considered best practice?

Thanks for your help,

--
Alex Young
 
Alex Young wrote:

Having only recently started using vhdl I am wondering if there are any
recomendations for how to use types within designs?
It seems that the most generic type is std_logic(_vector). Is it generally a
good idea to use this type to pass data around between modules/entities?
Click to expand...
I use std_logic_vector for my top entity ports for compatibility
with other designers and other tools. For top bit ports, I use
std_ulogic for IN or OUT and std_logic for INOUT tristates.
For internal instance ports and process variables I often use
unsigned, signed, std_ulogic and boolean.

( Argh what is the correct name for these? I am used to Verilog!)
Click to expand...
I have heard both module and entity meaning entity/architecture pair.
I say "entity" for VHDL audiences or "module" otherwise.

In particular how would you handle the design of something like an ALU. It
would seem to make sense to give it signed/unsigned types. Should I pass
std_logic values and then type convert to signed within the architecture of
the ALU?
Click to expand...
Sure: alu_v := signed(alu_port);

A similar question relating to boolean values. It seems that using booleans
will give cleaner code. i.e.
zero_flag := alu_out = 0;
as opposed to
if alu_out = 0 then
zero_flag := '1';
else
zero_flag := '0';
end if;
I guess that this will have problems with uninitialised values though. Again
what would be considered best practice?
Click to expand...
That's a trade-off discussed here recently:

http://groups.google.com/groups?q=vhdl+boolean+synthesis+me.net

If you are careful with initialization booleans are fine.
You can also write your own conversion functions to std_ulogic:

zero_flag := active_high(alu_out = 0);



-- Mike Treseler
 
Alex Young <spam@evilsloth.plus.com> wrote in
news:cke3em$2ho$1@scotsman.ed.ac.uk:

Hi all,

Having only recently started using vhdl I am wondering if there are
any recomendations for how to use types within designs?
It seems that the most generic type is std_logic(_vector). Is it
generally a good idea to use this type to pass data around between
modules/entities? ( Argh what is the correct name for these? I am used
to Verilog!)

In particular how would you handle the design of something like an
ALU. It would seem to make sense to give it signed/unsigned types.
Should I pass std_logic values and then type convert to signed within
the architecture of the ALU?
Click to expand...
it shouldn't matter. what you're passing from one module to the next do
not concern each other. the output of one module might be signed but the
next module won't care either way. if you use the signed library within
that module, then all the values passed it will be treated as a signed
number. and the same goes if you passed a signed value from one module
into a module using unsigned values. the thing about vhdl is that it's
very strongly typed and forces you to match every thing up. correct me
if anyone out there catches me at a mistake.

A similar question relating to boolean values. It seems that using
booleans will give cleaner code. i.e.
zero_flag := alu_out = 0;
as opposed to
if alu_out = 0 then
zero_flag := '1';
else
zero_flag := '0';
end if;
Click to expand...
here's a better way!

zero_flag <= '1' when (alu_out = 0) else '0';

I guess that this will have problems with uninitialised values though.
Again what would be considered best practice?
Click to expand...
best practice is whatever works.
 
Alex Young wrote:

Having only recently started using vhdl I am wondering if there are any
recomendations for how to use types within designs?
It seems that the most generic type is std_logic(_vector). Is it generally a
good idea to use this type to pass data around between modules/entities?
Click to expand...
Yes, but often it is quite better to use the unresolved
std_Ulogic(_vector). Why?
* Often synthesis tools are configured to change every I/O signal in an
entity to std_ulogic_(vector).
* As this signal is unresolved, multiple drivers are not allowed.
Therefore if one drives to a signal from more than one process (as a
mistake), one will get an error and the bug search is quick.
If you really need multiple drivers (tri-state busses), then use
std_logic(_vector). As this is seldom, it helps you to take care for
these special cases.


In particular how would you handle the design of something like an ALU. It
would seem to make sense to give it signed/unsigned types. Should I pass
std_logic values and then type convert to signed within the architecture of
the ALU?
Click to expand...
Yes. At the very point of conversion it looks ugly, but these
conversions are "seldom" needed. An example for the ALU:

use IEEE.Numeric_std.all;

signal sum,a,b : std_ulogic_vector(15 downto 0);

sum<=std_ulogic_vector(unsigned(a) + unsigned(b));


Ralf
 
"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:YNGdnezQJv8DOffcRVn-tg@comcast.com...
Alex Young wrote:

Having only recently started using vhdl I am wondering if there
are any
recomendations for how to use types within designs?
It seems that the most generic type is std_logic(_vector). Is it
generally a
good idea to use this type to pass data around between
modules/entities?

I use std_logic_vector for my top entity ports for compatibility
with other designers and other tools. For top bit ports, I use
std_ulogic for IN or OUT and std_logic for INOUT tristates.
For internal instance ports and process variables I often use
unsigned, signed, std_ulogic and boolean.

( Argh what is the correct name for these? I am used to Verilog!)

I have heard both module and entity meaning entity/architecture
pair.
I say "entity" for VHDL audiences or "module" otherwise.

In particular how would you handle the design of something like an
ALU. It
would seem to make sense to give it signed/unsigned types. Should
I pass
std_logic values and then type convert to signed within the
architecture of
the ALU?

Sure: alu_v := signed(alu_port);

A similar question relating to boolean values. It seems that using
booleans
will give cleaner code. i.e.
zero_flag := alu_out = 0;
as opposed to
if alu_out = 0 then
zero_flag := '1';
else
zero_flag := '0';
end if;
I guess that this will have problems with uninitialised values
though. Again
what would be considered best practice?

That's a trade-off discussed here recently:

http://groups.google.com/groups?q=vhdl+boolean+synthesis+me.net

If you are careful with initialization booleans are fine.
You can also write your own conversion functions to std_ulogic:

zero_flag := active_high(alu_out = 0);
Click to expand...
Another couple of points - if you are doing arithmetic you can
use either integer or vector types. Integers simulate faster, but
are restricted to 32 bits for synthesis (even if some simulators
support
64 bits!), are harder to use for bit manipulation, and don't represent
initial states correctly.

If you find yourself doing lots of type conversions, that probably
means
you are using the "wrong" types. A good plan is to use
std_logic_vector
/ std_logic ports (or std_u... as discussed above), and then convert
to
appropriate types within the architecture, for instance using
variables
or signals of type unsigned/signed (from Numeric_std). You then just
need to convert the result back to the correct type to drive the
output
port. If you design an alu, and you end up writing

F <= std_logic_vector (unsigned(a) + unsigned(b));
...
F <= std_logic_vector( unsigned(a) sll 1 );

and so on, it makes more sense to do

process(a, b)

variable va, vb : unsigned(7 downto 0); -- assuming a, b 8 bits
variable result : unsigned(8 downto 0);
begin
va := resize(va, 9);
vb := resize(vb, 9);

case...
result := a + b;
result = a sll 1;

...
f <= std_logic_vector(result);
end case;

end process;

and all the arithmetic just "looks nice" :) at the cost of some
initial and final type conversions.


Regarding "entity", the VHDL equivalent for module is strictly "design
entity".
A design entity consists of the interface (entity) and the body
(architecture)

regards
Alan





--
Alan Fitch
Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223 mail:
alan.fitch@doulos.com
Fax: +44 (0)1425 471573 Web:
http://www.doulos.com

The contents of this message may contain personal views which are not
the
views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top