Convert enumeration to std_logic_vector

[Stef]

I have a problem converting an enum with known encoding to a
std_logic_vector. Here's some fragments of the code:

entity controller is
port (
...
ledsel : out std_logic_vector(1 downto 0);
...
);


ctrl_proc : process(clock)
type opmode_t is (OPMODE_IDENT, OPMODE_CONFIG, OPMODE_ACQ);
attribute enum_encoding : string;
attribute enum_encoding of opmode_t : type is "00 01 10";
variable opmode_v : opmode_t;


I now want to assign opmode_v to the ledsel output and thought to do it
like this:

ledsel <= std_logic_vector(opmode_v);

That didn't work: " Illegal type conversion from opmode_t to
ieee.std_logic_1164.std_logic_vector (non-numeric to array)."

Is there another way to do it? Didn't find anythmh yet wityh google.

 

[Stef]

In comp.lang.vhdl,

I have a problem converting an enum with known encoding to a
std_logic_vector. Here's some fragments of the code:

entity controller is
port (
...
ledsel : out std_logic_vector(1 downto 0);
...
);


ctrl_proc : process(clock)
type opmode_t is (OPMODE_IDENT, OPMODE_CONFIG, OPMODE_ACQ);
attribute enum_encoding : string;
attribute enum_encoding of opmode_t : type is "00 01 10";
variable opmode_v : opmode_t;


I now want to assign opmode_v to the ledsel output and thought to do it
like this:

ledsel <= std_logic_vector(opmode_v);

That didn't work: " Illegal type conversion from opmode_t to
ieee.std_logic_1164.std_logic_vector (non-numeric to array)."

Just after hitting the send button, I had a thought. I don't even
need the encoding if I do it like this:

ledsel <= std_logic_vector(to_unsigned(opmode_t'pos(opmode_v), ledsel'length));

Problem solved for now, but I would still like to know how to do it with
use of the encoding as this solution only works for straight forward
encoding.

 

[KJ]

In comp.lang.vhdl,












Just after hitting the send button, I had a thought. I don't even
need the encoding if I do it like this:

   ledsel <= std_logic_vector(to_unsigned(opmode_t'pos(opmode_v), ledsel'length));

Problem solved for now, but I would still like to know how to do it with
use of the encoding as this solution only works for straight forward
encoding.

Enumerated types do not have any encoding. Say that 100 times. Now
ask yourself, since enumerated types do not have any encoding then how
would can you convert from an enumerated type to a std_logic_vector?
(Hint: The answer is you have to write your own conversion function).

The 'enum_encoding' attribute may (or may not) get used by a synthesis
tool to encode your enumerated type but that will not affect the
language syntax in any way.

There is nothing built into the language or any of the standard
packages that will convert an enumerated type that you create into a
std_logic_vector. (If at this point you feel yourself ready to say
"But I told it what the encoding was with the enum_encoding
attribute..." then go back to the first sentence of this post and
start over.

So now go about writing your conversion function (Hint: A good name
to use might be 'to_sdd_logic_vector'...conversions the other way
might well be called 'from_std_logic_vector). For your particular
case, this can be the one liner that you posted with the 'pos
attribute, but it doesn't have to be.

Kevin Jennings

 

[Stef]

In comp.lang.vhdl,

Enumerated types do not have any encoding. Say that 100 times. Now

My understanding has always been that there will be some sort of
encoding and that that encoding can be 'forced' by the encoding
attribute. So that is wrong from when talking about the language
alone? Ok, then I say that 0x4 times.

ask yourself, since enumerated types do not have any encoding then how
would can you convert from an enumerated type to a std_logic_vector?
(Hint: The answer is you have to write your own conversion function).

That is clear as soon as you know there's no encoding.

The 'enum_encoding' attribute may (or may not) get used by a synthesis
tool to encode your enumerated type but that will not affect the
language syntax in any way.

Are you aware of any tools that do not use the enum_encoding
attribute? I once wrote a state machine and encoded the states so
that each transition would only be a single-bit change. I would
gave been upset if the tool just ignored my carefull state layout,
but fortunately it didn't

There is nothing built into the language or any of the standard
packages that will convert an enumerated type that you create into a
std_logic_vector. (If at this point you feel yourself ready to say
"But I told it what the encoding was with the enum_encoding
attribute..." then go back to the first sentence of this post and
start over.

But..., okay, I'll try to surpress it. But there would still be
dissapointment if the synthesis tool had just ignored my suggested
encoding.

So now go about writing your conversion function (Hint: A good name
to use might be 'to_sdd_logic_vector'...conversions the other way
might well be called 'from_std_logic_vector). For your particular
case, this can be the one liner that you posted with the 'pos
attribute, but it doesn't have to be.

Ok, I'll keep it in mind for the next time I need a less than straight
forward conversion.

Thanks for clearing the matter up.

 

[Stef]

In comp.lang.vhdl,

-- You can separate the encoding from the enumeration
type encoding_array is array(opmode_t) of std_logic_vector(1 downto 0);
-- constant encode : encoding_array := ("00", "01", "10");
-- or for easier maintenance
constant encode : encoding_array :=
( OPMODE_IDENT => "00",
OPMODE_CONFIG => "01",
OPMODE_ACQ => "10");

ledsel <= encode(opmode_v);

Nice solution, thanks. And usable to implement that conversion function
as well.

 

[KJ]

In comp.lang.vhdl,


Are you aware of any tools that do not use the enum_encoding
attribute? I once wrote a state machine and encoded the states so
that each transition would only be a single-bit change. I would
gave been upset if the tool just ignored my carefull state layout,
but fortunately it didn't

I'm not aware of any but that's also because I don't use enum_encoding
because there are no guarantees that
- It will work
- It is portable

But..., okay, I'll try to surpress it. But there would still be
dissapointment if the synthesis tool had just ignored my suggested
encoding.

But now that you know the proper way to avoid possible future
disappointments with that approach.

KJ

 

[Thomas Rouam]

Hi Guys,

I wanted to give a little comment on Kevin's statement :

I'm not aware of any but that's also because I don't use enum_encoding
because there are no guarantees that
- It will work
- It is portable

A synthesis tool that does not handle the enum_encoding attribute, is
then not compliant with the IEEE Standard for VHDL Register Tranfer
Level (RTL) Synthesis (IEEE Std 1076.6). It is said in there :

An attribute named ENUM_ENCODING shall provide a means of encoding
enumeration type values. The attribute specification for this
attribute shall specify the encoding of the enumeration type literals
in the form of a string. This string shall be made up of tokens
separated by one or more spaces. There shall be as many tokens as
there are literals in the enumeration type, with the first token
corresponding to the first enumeration literal, the second token
corresponding to the second enumeration literal, and so on.

The word shall here is equivalent to required to.

Hope this helps as well.

Thomas.

 

[rickman]

Hi Guys,

I wanted to give a little comment on Kevin's statement :


A synthesis tool that does not handle the enum_encoding attribute, is
then not compliant with the IEEE Standard for VHDL Register Tranfer
Level (RTL) Synthesis (IEEE Std 1076.6). It is said in there :

An attribute named ENUM_ENCODING shall provide a means of encoding
enumeration type values. The attribute specification for this
attribute shall specify the encoding of the enumeration type literals
in the form of a string. This string shall be made up of tokens
separated by one or more spaces. There shall be as many tokens as
there are literals in the enumeration type, with the first token
corresponding to the first enumeration literal, the second token
corresponding to the second enumeration literal, and so on.

The word shall here is equivalent to required to.

Hope this helps as well.

Thomas.

Maybe I am missing something, but I don't see where your information
contradicts Kevin's statements. I don't see where the nature of the
"token" is specified. That means that the tokens are not standardized
(Kevin's second point) and therefor may not work (Kevin's second
point).

Unless the IEEE standard specifies the *method* of describing the
enumeration encoding it has not done a lot of good regardless of
whether it is "required" or not.

Rick