enumeration types

[Charlie]

This might be a silly question but hopefully it can be easily answered.

I have defined an enumeration

type MODE_typ is (CLR_RST, OPEN_LOOP, POS_COM, RATE_COM, TRQ_DRIVE_CAL,
AtoD_CAL, NORMAL, WRITE_DD);

It is only 8 values, so I would imagine that it would snythesize to be
a 3 bit std_logic_vector. In the future, I might add more values to
this type, I could end up needing 5 bits to define them all.

I am also using a schematic based design tool for the structural level
of my design where I have to explicitly define the number of pins on
each module. So, what I want to do is force that MODE_typ to be a 5
bit std_logic_value. I don't care what each specific value synthesizes
to, I just want to make sure that it is five bits wide. I don't want
to explicitly set each value because I would like it to do the
optimization for me. How can I accomplish this?

 

[Mike Treseler]

Charlie wrote:

type MODE_typ is (CLR_RST, OPEN_LOOP, POS_COM, RATE_COM, TRQ_DRIVE_CAL,
AtoD_CAL, NORMAL, WRITE_DD);

It is only 8 values, so I would imagine that it would snythesize to be
a 3 bit std_logic_vector.

Unless you change the synthesis encoding
setting from AUTO to BINARY, you will get
an 8 bit vector.

I am also using a schematic based design tool for the structural level
of my design where I have to explicitly define the number of pins on
each module.

Consider keeping everything accessing
MODE_typ objects inside the same process.

-- Mike Treseler

 

[David.Stanford@gmail.com]

I would expect as Mike Treseler said, that your synthesizer will use
one-hot encoding if it has a choice. You can typically constrain the
type of encoding your synthesizer uses without hard-codeing each states
value. However, if you are passing this type from one process to
another, hard-coding is probably the best way to keep from driving
yourself crazy debugging it.

 

[Charlie]

Thanks for your help, everyone. I went with Charles' way, but before I
read his, I did it with a case statement, but this method is much more
readable. Thanks again

 

[Charles Gardiner]

You could also retain the often very useful enumeration type within the
modules, but convert it to std_logic_vector(4 downto 0) at the
boundaries by means of a function.

e.g.
function to_ulv(sig : enum_xyz_t) return std_ulogic_vector;
function to_enum_xyz(sig : std_ulogic_vector) return enum_xyz_t;

-- Module 1: Port as output
port_xyz_out <= to_ulv(sig_xyz);


-- Module 2: Port as input
sig_xyz <= to_enum_xyz(port_xyz_in);


A suggestion for the functions could be something like:
-- Syntax not tested but hopefully pretty close
function to_ulv(sig : enum_xyz_t) return std_ulogic_vector is
begin
-- Using the synopsys conversion functions
return to_stdulogicvector(conv_std_logic_vector(enum_xyz_t'pos(sig),
5));
end to_ulv;

function to_enum_xyz(sig : std_ulogic_vector) return enum_xyz_t is
begin
return enum_xyz_t'val(conv_integer(unsigned(sig));
end to_ulv;


Hope this helps