You can create an integer generic on the instantiated component and pass it the loop control variable value.
Then your instance can use the generic value to distinguish itself from the other instances.
port(D,CLK,RESET : in std_ulogic;
Q : out std_ulogic);
for I in 0 to 3 generate
I'm not quite certain to understand what you are trying to do here. Maybe there is a bit of a XY problem in the first place. Nonetheless, I'll try to answer questions we have so far.
Strings are defined by standard as:
type STRING is array (POSITIVE range <>) of CHARACTER;
and positive is defined as:
subtype POSITIVE is INTEGER range 1 to INTEGER'...
My preference is to keep my synthesis code as simple as possible. So I keep error checks as independent as practical from my logic code. So I use choice number 2.
If I want error checks, I use an assert of the form (preferably concurrent, but in your case maybe sequential):
assert not (is_x(EXPECTED_ACK_STATE_MATCHED(i)) or is_x(EXPECTED_MSG_CODE_MATCHED(...
Rewriting in non-VHDL-2008 style (output port should become buffer, and add explicit level tests to std_logic signals)
entity Integrator is
port( Input : in integer;
Output : buffer integer := 0;
Sample : in std_logic; --clock enable
My money is on the problem existing somewhere in the hardware wrapper, but that's actually beside the point.
Your best bet in debugging is to view the exact values of the input and output and see how the design is responding. In comments you state that you are "unable to view the actual numbers in hardware" but I think this still can be done, and ...
Either of the ways you have written it is perfectly correct.
I don't believe that testing for values other than '0' or '1' is synthesizable in any devices I have ever used. So it doesn't make any difference with regard to synthesis and implementation.
Testing for things like 'U' or 'X" can be useful for debug in simulation. Its certainly not required, ...