Good practice for signal types

[Alex Young]

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,

 

[Ralf Hildebrandt]

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?

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?

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]

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);



-- Mike Treseler

 

[Alan Fitch]

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.


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


Sure: alu_v := signed(alu_port);


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);

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:
(e-mail address removed)
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.