--- Quote Start ---
I have a general question regarding the use of integers in VHDL.
If I have a lot of Array defined, we have to use integer as its index when accessing the arrays. However, when the index is converted from std_logic_vectors, it masked away the 'X' values, which masked my signal initiailization problem. Can anybody please let me know how to avoid this problem?
When running simulation, I have the following warning:
# ** Warning: NUMERIC_STD.TO_INTEGER: metavalue deteced, returning 0
--- Quote End ---
Actually, the simulator didn't mask the problem, you ignored the reporting. As you can see from the message that you posted you ignored what was reported presumably since it was 'just' a warning. You can set the simulator to stop on warnings as well as errors.
Having said that though, making use of the message that was reported can be problematic since at t=0 you can likely have a ton of such messages reporting similar warnings, so usually the better solution will be more task specific as mentioned below...
--- Quote Start ---
The code example is below:
SIGNAL a : ARRAY (INTEGER 0 TO 15) of STD_LOGIC_VECTOR(5 DOWNTO 0);
SIGNAL b : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL c : STD_LOGIC_VECTOR(5 DOWNTO 0);
c <= a(TO_INTEGER(UNSIGNED(b));
--- Quote End ---
To be able to flag the problem you're seeing with this example you can create your own assertion. Let's say that you want to ignore problems at t=0 but otherwise report when 'b' has unknown values in them. The following assertion will do the trick:
assert (t=0 ns) or (b = to_unsigned(to_integer(unsigned(b)), b'length))
report "OOPS! Unknown value detected on 'b'" severity ERROR;
This will create an error rather than a warning but it won't bother with things when t=0. One caveat though is that if the bits in b get set to an unknown value at t=0, and b never changes after that then the above assertion won't catch it either because it only does the check when there is a change on 'b'.
Lastly, a way to work around it is to give b an initial value like this
SIGNAL b : STD_LOGIC_VECTOR(3 DOWNTO 0) := (others => '0');
The problem with this approach is that it might not reflect what the real hardware is doing for initializations in which case you've simply punted the problem downstream. Instead of being able to catch the problem in simulation, you now will think everything is good, but when you build the real hardware it is working differently.
Kevin Jennings
Honored Contributor
