std_logic_vector to constant natural in VHDL - vhdl

Question

I am using NUMERIC_STD library. The incoming PORT signal is RAM_BYTE_EN to be converted as constant integer number RAM_WIDTH.
'''
RAM_BYTE_EN : IN std_logic_vector(3 downto 0); -- Value "0100" passed as RAM_BYTE_EN
constant RAM_WIDTH : natural := to_integer(unsigned(RAM_BYTE_EN)); --convert RAM_BYTE_EN
'''
In simulation, the value RAM_WIDTH is ZERO and not 4.
Don't understand why the conversion is not working. What am I missing?

Answer 1

In simulation, the value RAM_WIDTH is ZERO and not 4.
Setting aside for the moment the anticipated synthesis of an unseen design unit and/or hierarchy and focus on simulation:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity rambyteenab is
port (
RAM_BYTE_EN : IN std_logic_vector(3 downto 0) -- Value "0100" passed as RAM_BYTE_EN -- struck semicolon
);
end entity;
architecture foo of rambyteenab is
constant RAM_WIDTH : natural := to_integer(unsigned(RAM_BYTE_EN)); -- convert RAM_BYTE_EN
begin
process
begin
report "RAM_WIDTH = " & integer'image(RAM_WIDTH);
wait;
end process;
end architecture;
library ieee;
use ieee.std_logic_1164.all;
entity higher_in_hierarchy is
end entity;
architecture working of higher_in_hierarchy is
signal RAM_BYTE_ENAB: std_logic_vector(3 downto 0) := "0100";
begin -- RAM_BYTE_ENAB is "0100" when inst is elaborated
inst:
entity work.rambyteenab
port map (RAM_BYTE_EN => RAM_BYTE_ENAB);
end architecture;
architecture failing of higher_in_hierarchy is
signal RAM_BYTE_ENAB: std_logic_vector(3 downto 0);
begin -- STATEMENTS ELBORATED in order
inst:
entity work.rambyteenab
port map (RAM_BYTE_EN => RAM_BYTE_ENAB);
concurrent_signal_assignment:
RAM_BYTE_ENAB <= "0100";
end architecture;
By analyzing the above four design units and either using a configuration specification or configuration declaration or elaboration time command line options to specify which architecture of higher_in_hierarchy to use with a declaration of signal RAM_BYTE_ENAB used as an actual in associating the port RAM_BYTE_EN of entity rambyteenab we can demonstrate it's possible to rely on the value of a port signal of mode in at elaboration time.
It depends on the port signal having been initialized to a useful value and elaboration order guaranteeing that value prior to it's evaluation.
All four design units are found in order in the same design file which is analyzed into a reference library (work):
ghdl -a rambyteenab.vhdl
The target architecture of higher_in_hierarchy is elaborated separately using both architectures:
ghdl -e higher_in_hierarchy failing
ghdl -e higher_in_hierarchy working
Note that elaborating higher_in_hierarchy without specifying the architecture would result in using the architecture working, which is the last analyzed architecture, working being used by default.
These produce elaborated design hierarchies:
%: ls -aF higher*
/Users/user16145658/Desktop
-rwx--x--x 1 user16145658 staff 1270312 Feb 2 05:32 higher_in_hierarchy-failing*
-rwx--x--x 1 user16145658 staff 1269544 Feb 2 05:33 higher_in_hierarchy-working*
which can be used to demonstrate the ability to use elaboration order and initialization value to pass the value of a signal to be used in the elaboration of a constant, at elaboration time:
%: higher_in_hierarchy-working
rambyteenab.vhdl:16:9:#0ms:(report note): RAM_WIDTH = 4
%: higher_in_hierarchy-failing
../../src/ieee/v93/numeric_std-body.vhdl:2098:7:#0ms:(assertion warning): NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
rambyteenab.vhdl:16:9:#0ms:(report note): RAM_WIDTH = 0
%:
The failure is by virtue of RAM_BYTE_ENAB having a a default initialization of all 'U's which generates the numeric_std warning assertion in simulation. The OP should have encountered a similar warning during simulation as the only means of producing a zero through elaboration.
So, what about synthesis?
Historically IEEE Std 1076.6-2004 VHDL Register Transfer Level (RTL) Synthesis (withdrawn due to lack of vendor participation and age) for RAM_BYTE_ENAB told us:
8.4.3.1 Object declarations
b) Signal declarations
...
The initial value expression shall be ignored unless the declaration is in a package, where the declaration shall have an initial value expression.
which didn't allow for depending on the initial value, a practice supported generally in memory based FPGAs today. Some number of tool implementations for target device architectures not capable of passing initial values through lack of passing memory or ability to otherwise pull up or pull down nets still do not make use of initial values.
The reliance on initial values isn't possible in a portable fashion.

Answer 2

Constants should be known at synthesis time and cannot be derived from signals. For the RAM to be instantiated, its width needs to be known. So you should set it to a constant number e.g.
constant RAM_WIDTH : natural := 32;