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 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));

The problem is brought up with uninialized std_logic and derived types, that have a default value of 'U' in functional simulation and '0' in real hardware. Add '0' initializers to the definition of register signals or add an explicite reset initialization to achieve consistent simulation.

--- 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

Thanks very much for the reply. My problem is exactly 'B' gets an unknown value in the design. In RTL simulation, the good 'C' values corresponding to address 0 gets used; while in Gate level simulation, the unknown 'C' gets used. When there is tons of such logic in your design and we don't do reset our flops as a general principle, it is very hard to catch which one causes the problem in gate level simulation if it is not duplicate-able in RTL simulation. In general, we don't want to give an initial value to a variable since it is ignored by the synthesize tools. What we want is to have an exact RTL simulation to avoid debugging problem using gate level simulation.

--- Quote Start --- In general, we don't want to give an initial value to a variable since it is ignored by the synthesize tools. --- Quote End --- What makes you say that? FPGAs configure from bit-streams, and those bitstreams define the register states at power-on. Most devices power-up with registers set to 0, but if you initialize a signal to 1, the synthesis tool will use 'not gate pushback' to invert the input and output to the register, so as far as your logic is concerned, the register powers up to your initialized value of 1. Cheers, Dave

--- Quote Start --- Thanks very much for the reply. My problem is exactly 'B' gets an unknown value in the design. In RTL simulation, the good 'C' values corresponding to address 0 gets used; while in Gate level simulation, the unknown 'C' gets used. When there is tons of such logic in your design and we don't do reset our flops as a general principle, it is very hard to catch which one causes the problem in gate level simulation if it is not duplicate-able in RTL simulation. In general, we don't want to give an initial value to a variable since it is ignored by the synthesize tools. What we want is to have an exact RTL simulation to avoid debugging problem using gate level simulation. --- Quote End --- What this points to then is that you may need to be writing a better testbench. The signal 'c' eventually has some effect on the overall design and it being stuck at the value contained in a(0) should have caused some output to not be correct at some point...but it can only be determined to be incorrect if you take the time to write a testbench that generates stimulus sufficient to exercise the signals and that actually checks the outputs to verify that they are correct. The time it takes to write testbenches will pay off dividends over the entire lifecycle of the code as it changes over time. However, even when you do take that time things will get missed because it can take roughly as much time to write a testbench as it does to do the design. But it can also take just a small bit of time to get a testbench that covers a lot without much effort. The value judgment comes in as to where to draw the line about where you think you've tested this enough because there will never be an end to tests that you could've written. As you've already noticed running gate level simulations are painfully slow. Many experienced designers do not run them as a simple matter of course since there time is more effectively spent elsewhere. As I mentioned in the first post, one can sometimes also write self-checking right into the design itself. It's more limited then testbench testing but has the advantage of being usable in any testbench. Kevin Jennings

VHDL integer causing RTL and Gate level simulation difference

15 Replies

Altera_Forum
Honored Contributor
13 years ago
I am talking about ASICs.
Altera_Forum
Honored Contributor
13 years ago
Anybody know how to avoid INTEGERs when access arrays? I really this can mask out a lot of bugs during simulations because it doesn't allow 'X'.

Unless we make sure there is no 'X' exist in our design, this is always a risk to use.
Altera_Forum
Honored Contributor
13 years ago
'X' values in gate level simulation are really indicating undetermined values, e.g. due to a timing violation. That's not a problem of using integers, it's in the hardware.
Altera_Forum
Honored Contributor
13 years ago
--- Quote Start ---
Anybody know how to avoid INTEGERs when access arrays?
--- Quote End ---
Use conversion operators that output an integer.

For example;

type rddata_mux_t is array (0 to 7) of std_logic_vector(31 downto 0); signal rddata_mux : rddata_mux_t; signal rddata_sel : std_logic_vector(2 downto 0); rddata_mux(0) <= .... rddata_mux(1) <= .... rddata <= rddata_mux(to_integer(unsigned(rddata_sel)));
Or as Tricky comments, define a range restricted integer for rddata_sel. However, as you note, you cannot see an 'X' in that case, so using std_logic is a little more general.

Cheers,
Dave
Altera_Forum
Honored Contributor
13 years ago
zhujianbinc,
you can't avoid using integers to access arrays.

That said, that kind of RTL vs post-synthesis inconsistency is in no way limited to use of integers.
In fact, at least when you're using integers you get warnings like those from the RTL simulation. Other cases may be dead silent.

a <= b when c = '0' else d;

Consider than a, b, c and d are all std_logic and think of how the code behaves when b = 1', c = 'X' and d = '0' .
In RTL, a will be '0'; in post-synthesis it will be 'X'.

Anyway, you can try and make RTL and post-synthesis simulations match better by coding the handling of "X" explicitly when needed.
For example, replace
c <= a(TO_INTEGER(UNSIGNED(b));

with
c <= a(TO_INTEGER(UNSIGNED(b)) when not is_x(b) else (others => 'X');

It will synthesize the same, but you'll get XX when b has an X.

PS: This is an Altera forum, people assume you're talking about (Altera) FPGAs here. If you're going to ask about something else, please start by making it crystal clear.

Forum Discussion

VHDL integer causing RTL and Gate level simulation difference

15 Replies

Recent Discussions

Avalon-ST configuration with Agilex 3 fails

JTAG Chain Broken on Agilex 7-I Dev Kit

Question

Quartus Prime Pro 25.1 fatal error during fitter: Windows "Efficiency mode" required

Will serialization factor of 6 in LVDS serdes IP be supported in the future on Agilex5?