From: Jonathan Bromley on
On Wed, 7 Apr 2010 06:56:35 -0700 (PDT), Kappa wrote:

>#################### [CODE] ####################
>
>din : in std_logic_vector (3 downto 0);
>dout : out std_logic_vector (1 downto 0)
>
>begin
>
> process(din)
> begin
> case(din) is
> when "000" => dout <= conv_std_logic_vector(2, 2);
> when "001" => dout <= conv_std_logic_vector(0, 2);
[...]
> when others => null;
> end case;
> end process;
>
>#################### [/CODE] ####################

YUCK.

You're fighting against VHDL's strict rules, instead of getting
them to work for you.

Do you like this version better?

constant input_bit_width: positive := din'length;
constant output_bit_width: positive := dout'length;
subtype T_input_code is integer range 0 to (2**input_bit_width-1);
subtype T_output_code is integer range 0 to (2**output_bit_width-1);
type T_code_map is array(T_input_code) of T_output_code;

----------------- HERE IS THE LOOKUP TABLE ---------
constant code_map: T_code_map := (
0 => 2,
1 => 0,
2 => 1,
3 => 1,
4 => 2,
5 => 3,
6 => 3,
7 => 0);
------------------------------------------------------
-- You will get errors if you don't provide the full set
-- of map values, but you can use OTHERS if you wish.
...
process (din)
variable code_in: T_input_code;
variable code_out: T_output_code;
begin
code_in := to_integer(unsigned(din));
code_out := code_map(code_in);
dout <= std_logic_vector(to_unsigned(code_out, output_bit_width));
end process;

There are lots of other possibilities; the precise way you choose to
parameterize this design, and set up the constants, depends on how it
fits into the rest of your design and how it will be used. If you
are careful and lucky, you can probably avoid the type conversions
in this part of the code, because you are using appropriate numeric
data types in the body of your design. But that's another discussion.

If you absolutely insist on hex representation, you can easily
rewrite the map table:

constant code_map: T_code_map := (
16#0# => 16#2#,
...
16#7# => 16#0#);

Oh, and I've used numeric_std instead of std_logic_horrible
for the numeric conversions.

Named types, subtypes and constants are your friend, especially
when revisiting the code later, if you choose the names wisely.

I'll leave it to someone else to open a discussion about
the incomplete case statement.
--
Jonathan Bromley
From: Kappa on
Hi,

> You're fighting against VHDL's strict rules, instead of getting
> them to work for you.

I ask those who know more than me ...

> Do you like this version better?
>
>   constant  input_bit_width: positive := din'length;
>   constant output_bit_width: positive := dout'length;
>   subtype T_input_code is integer range 0 to (2**input_bit_width-1);
>   subtype T_output_code is integer range 0 to (2**output_bit_width-1);
>   type T_code_map is array(T_input_code) of T_output_code;
>
>   ----------------- HERE IS THE LOOKUP TABLE ---------
>   constant code_map: T_code_map := (
>     0 => 2,
>     1 => 0,
>     2 => 1,
>     3 => 1,
>     4 => 2,
>     5 => 3,
>     6 => 3,
>     7 => 0);

How use HEX value ... my request came from them do not want to return
to decimal format ... :-| ...

>   ------------------------------------------------------
>   -- You will get errors if you don't provide the full set
>   -- of map values, but you can use OTHERS if you wish.
>   ...
>   process (din)
>     variable code_in: T_input_code;
>     variable code_out: T_output_code;
>   begin
>     code_in := to_integer(unsigned(din));
>     code_out := code_map(code_in);
>     dout <= std_logic_vector(to_unsigned(code_out, output_bit_width));
>   end process;

Is somewhat more complicated for me but certainly more
professional ...

> There are lots of other possibilities; the precise way you choose to
> parameterize this design, and set up the constants, depends on how it
> fits into the rest of your design and how it will be used.  If you
> are careful and lucky, you can probably avoid the type conversions
> in this part of the code, because you are using appropriate numeric
> data types in the body of your design.  But that's another discussion.

This is our main problem, avoid conversion of format, I'm translating
a simple C code in VHDL using HEX, I wanted to keep reading two code.

> If you absolutely insist on hex representation, you can easily
> rewrite the map table:
>
>   constant code_map: T_code_map := (
>     16#0# => 16#2#,
>     ...
>     16#7# => 16#0#);

Is perfect ...

> Oh, and I've used numeric_std instead of std_logic_horrible
> for the numeric conversions.
>
> Named types, subtypes and constants are your friend, especially
> when revisiting the code later, if you choose the names wisely.

You are quite right, especially if you often revises the code.

> I'll leave it to someone else to open a discussion about
> the incomplete case statement.

Thanks.

secureasm