--- Quote Start ---
to Kevin: I didn't post the code as it is a work in progress, rather a lot, and proprietary. Now you say:
But why would I have to care about that. The simulator should handle my code or flag an error on compilation not on runtime.
--- Quote End ---
Just because something compiles doesn't mean that there will not be a runtime error. The ranges for X and Y and the function impliemented by lxn allow for lxn to be out of the range that you stated which implies there is the possibility for exactly the runtime error that you are seeing.
For that error to never occurs implies that the way that X and Y are generated in your system must operate in such a way that they never happen to hit the condition where the computation of lxn is ever out of range, even for a single simulation delta cycle.
Since you are seeing this error, the simplest explanation is that X and Y are in a state that is causing lxn to be out of range for at least one simulation delta cycle. Another explanation that you and others are pursuing is that it is a simulator bug. That may be the case, I'm offering an alternative explanation that is probably more likely since, as I think you mentioned, this behavior should work with version 0.0.a.
--- Quote Start ---
Your code very closely resembles what I have, but I did enclose the 'lxn <= ... ' inside a process. Also in you code lxn is not exported to the output?
--- Quote End ---
Since you didn't post your full code, I just put something together. I don't think it will matter whether or not lxn is an entity output or not. The only reason it's not is because the first run was simply to create code with no I/O and use the force statement to generate X and Y (which ran with no problem). The next step was to make the testbench which required the DUT to at least have inputs X and Y.
--- Quote Start ---
I tried the list-thing (1st encounter) and in the list it shows 254 ... no sign of a 261 in miles ...
--- Quote End ---
What I asked though was to look at the values of X and Y in the list window as well. Are they actually changing on the exact same simulation delta cycle?
--- Quote Start ---
So it will be the 'process'?
process( X , Y , Z , M )
begin
if (M = 0) then
if (Z < 0) then
lzn <= Z + ARCZ ;
lxn <= X + Y / (2 ** RANK) ;
lyn <= Y - X / (2 ** RANK) ;
else
...
end if ;
end if ;
end process ;
--- Quote End ---
Note that if X and Y change on different sim delta cycles then the process will trigger two times. In order to bolster your case (if it's a simulator bug) or get to the root of the problem (if it's a sim delta cycle thing) then you might want to add some old fashioned print statements right before the line of code that is failing:
report boolean'image(X'event) & LF &
boolean'image(Y'event) & LF &
boolean'image(Z'event) & LF &
boolean'image(M'event) & LF &
integer'image(X) & LF &
integer'image(Y) & LF &
integer'image(X) & LF &
integer'image(X + Y / (2 ** RANK));
Kevin Jennings
Honored Contributor
