VHDL integer causing RTL and Gate level simulation difference

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.

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

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.

--- Quote Start ---

Our turbo decoder design can pass the RTL simulations, but not the gate level. We have to deposit '0's to all the flops before we can pass gate level simulation. When the chip comes back in our lab, we see some tests passes, but not others. Some chips passes all tests consistently, but others not. If we run some tests first, then other tests starts to pass as well.

--- Quote End ---

Are you talking about FPGA or ASICs?. As previously explained, FPGA registers have a defined POR state which determines the behaviour in gate level simulation.

It should be noticed however that the problems brought up by asynchronous reset can also affect power-on reset if the design clock is already present during reset. In this case, explicite reset logic and a reset synchronizer are required.

--- Quote Start ---

Uninitialized integers get assigned the value -2^(N-1), where N is the number of bits in the integer. (At least under VHDL).

--- Quote End ---

This is only true in functional simulation and for unconstrained or signed integers. Integers are synthesized either as signed or unsigned in gate level logic, depending on the range and initialized to all zero by default.

--- Quote Start ---

This is why I want to get rid of all INTEGERs so that I can have a consistently simulation between RTL and GATE. I can capture all my bugs in RTL simulation only.

--- Quote End ---

The described problems in gate level behaviour have unlikely to do with integer usage.

--- Quote Start ---

integers get value '0' at power on in RTL simulation, while it gets unknown value in real chip.

--- Quote End ---

Uninitialized integers get assigned the value -2^(N-1), where N is the number of bits in the integer. (At least under VHDL).

--- Quote Start ---

This is why I want to get rid of all INTEGERs so that I can have a consistently simulation between RTL and GATE. I can capture all my bugs in RTL simulation only.

--- Quote End ---

I could have sworn one of the first things you're supposed to learn when writing HDL, is to never use integers. That is why there are signed and unsigned types ... of course, that kind of advice does not help when you inherit code ...

Cheers,

Dave

OK. Here is what we observed in our lab.

Our turbo decoder design can pass the RTL simulations, but not the gate level. We have to deposit '0's to all the flops before we can pass gate level simulation. When the chip comes back in our lab, we see some tests passes, but not others. Some chips passes all tests consistently, but others not. If we run some tests first, then other tests starts to pass as well.

All of these observations made us think there is initialization issues in our design. Since we decided not to do reset to all of our flops unless required. There is lots of flops not having known reset value at power on.

My task is to figure our what needs to be reset in this design. Since there is lots of integers used in the design, such as index to arrays and integers get value '0' at power on in RTL simulation, while it gets unknown value in real chip. This, I think, made RTL simulation hides lot of potential bugs in our design.

This is why I want to get rid of all INTEGERs so that I can have a consistently simulation between RTL and GATE. I can capture all my bugs in RTL simulation only.