ModelSim "out of range" issue

[Altera_Forum]

I have the following code: 

  Library IEEE; use IEEE.Std_Logic_1164.all; use IEEE.numeric_std.all; use IEEE.Math_real.all ; ... WIDTH_DQ : natural := 9 ; X : in integer range -(2 ** (WIDTH_DQ - 1)) to 2 ** (WIDTH_DQ - 1) - 1 := 0 ; Y : in integer range -(2 ** (WIDTH_DQ - 1)) to 2 ** (WIDTH_DQ - 1) - 1 := 0 ; ... signal lxn : integer range -(2 ** (WIDTH_DQ - 1)) to 2 ** (WIDTH_DQ - 1) - 1 := 0 ; ... lxn <= X - Y / (2 ** RANK) ;  During RTL simulation at RANK = 2 in time X = 226 and Y = -113. I'd expect lxn to become 254 and well within range. But ModelSim tells:   --- Quote Start ---  # ** Fatal: (vsim-3421) Value 261 for lxn is out of range -256 to 255. # Time: 88 ns Iteration: 3 Process: /tp_cordic_vhd_tst/i1/genel(3)/regel/genpure/line__252 File: C:/qdesigns/bv5fpga/c-cam/bb/arithmetic/TP_cordic/cordicelement/cordicelement.vhd # Fatal error in Process line__252 at C:/qdesigns/bv5fpga/c-cam/bb/arithmetic/TP_cordic/cordicelement/cordicelement.vhd line 294   --- Quote End ---   It looks like ModelSim is taken the representation of -113 as 'unsigned' and added 1/4 of that giving a result of 261.  Any clues?

[Altera_Forum]

hmm, I do concur. What version of modelsim is it? have you tried a different version? 

 If you cant solve it - the mentor guys are very good with support.

[Altera_Forum]

10.0c 

And live is too short to try other versions. I already lost almost half a day on it. One would think this is pretty basic and already solved back in version 0.0.a  Apart from this bug I get plagued by the obscure "Fatal: Unexpected signal: 11." error on about every other project I try to simulate in RTL. So I revert to the Timimg Simulation as this always seems to work, be it a lot slower than RTL Simulation. I guess ModelSim has no problem with the .vho net-list QII generates as everything is nicely spelled out in there.  I still have to find the 'support' section on Mentor Graphics web-site ...

[Altera_Forum]

--- Quote Start ---   I still have to find the 'support' section on Mentor Graphics web-site ...  --- Quote End ---    http://supportnet.mentor.com/  If you can create a Modelsim design (source plus simulation script) that reproduces the problem, I can try a couple of Modelsim versions, including the SE subscription version.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   If you can create a Modelsim design (source plus simulation script) that reproduces the problem, I can try a couple of Modelsim versions, including the SE subscription version.   --- Quote End ---  I reproduced the problem with 10.0c Altera Starter Edition and the full edition. Tests failed with earlier versions of Modelsim, since you have conversion functions on the ports to components (which we discussed in an earlier thread - it requires creating intermediate signals).  I defined a subtype for your integer of limited range, and then added dummy qualifications around each argument and result of the operation, and the error was still generated.  Definitely looks like a bug.  I'd recommend trying to create a minimal example with just your subtype and whatever operation leads to the error, eg., have something as simple as z <= x + y; and ramp x and y until the error is triggered. Submit that file with a SR to Mentor and to Altera.  Cheers, Dave

[Altera_Forum]

Maybe it's just me, but since you didn't post the code that generates X and Y I'm not sure how the others were able to re-create the problem. In any case, my re-creation (full code posted below) works just fine, no errors reported, sim runs to completion. Modelsim 6.4c. 

 I suspect that in your simulation there may be a simulation delta delay between 'X' and 'Y' and that there is a delta cycle where X and Y do produce the value of 261. To verify I would suggest putting X, Y and lxn into a list window and observe there whether or not X and Y really are changing on the same delta cycle or not and whether or not X and Y are at values that would create the errent value at the time of the error.   Kevin Jennings    Library IEEE; use IEEE.Std_Logic_1164.all; use IEEE.numeric_std.all; use IEEE.Math_real.all ; entity foofoo is generic(WIDTH_DQ : natural := 9) ; port( X : in integer range -(2 ** (WIDTH_DQ - 1)) to 2 ** (WIDTH_DQ - 1) - 1 := 0 ; Y : in integer range -(2 ** (WIDTH_DQ - 1)) to 2 ** (WIDTH_DQ - 1) - 1 := 0 ); end foofoo; architecture rtl of foofoo is signal lxn : integer range -(2 ** (WIDTH_DQ - 1)) to 2 ** (WIDTH_DQ - 1) - 1 := 0 ; constant RANK: integer := 2; begin lxn <= X - Y / (2 ** RANK) ; end rtl; entity tb_foofoo is end tb_foofoo; architecture rtl of tb_foofoo is constant WIDTH_DQ: natural := 9; signal X: integer range -(2 ** (WIDTH_DQ - 1)) to 2 ** (WIDTH_DQ - 1) - 1 := 0; signal Y: integer range -(2 ** (WIDTH_DQ - 1)) to 2 ** (WIDTH_DQ - 1) - 1 := 0; begin process begin for x1 in 225 to 227 loop X <= x1; for y1 in -114 to -112 loop Y <= y1; wait for 10 ns; end loop; end loop; wait; end process; dut : entity work.foofoo generic map(WIDTH_DQ => WIDTH_DQ) port map( X => X, Y => Y); end rtl;

[Altera_Forum]

to Kevin: I didn't post the code as it is a work in progress, rather a lot, and proprietary. Now you say: 

  --- Quote Start ---  I suspect that in your simulation there may be a simulation delta delay between 'X' and 'Y' and that there is a delta cycle where X and Y do produce the value of 261. To verify I would suggest putting X, Y and lxn into a list window and observe there whether or not X and Y really are changing on the same delta cycle or not and whether or not X and Y are at values that would create the errent value at the time of the error.  --- Quote End ---    But why would I have to care about that. The simulator should handle my code or flag an error on compilation not on runtime. 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? I tried the list-thing (1st encounter) and in the list it shows 254 ... no sign of a 261 in miles ... 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 ;  to Dave:  --- Quote Start ---  Tests failed with earlier versions of Modelsim, since you have conversion functions on the ports to components (which we discussed in an earlier thread - it requires creating intermediate signals).  --- Quote End ---   Old habits die hard ... then again the latest released version should be better than an earlier one?   --- Quote Start ---  I defined a subtype for your integer of limited range, and then added dummy qualifications around each argument and result of the operation, and the error was still generated.   Definitely looks like a bug.   I'd recommend trying to create a minimal example with just your subtype and whatever operation leads to the error, eg., have something as simple as z <= x + y; and ramp x and y until the error is triggered. Submit that file with a SR to Mentor and to Altera.  --- Quote End ---   Kevin shows that the minimal example seems to work. I can file an SR to Altera, and I registered on supportnet.mentor.com but only got a 'guest' status.

[Altera_Forum]

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

[Altera_Forum]

--- Quote Start ---  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.  --- Quote End ---   You're quite right about the compilation itsel being no guarantuee, but in VHDL if you can compile without warnings, the chances are quite good. In this design the values of X,Yand Z will not go outside the boundaries by design. Now in this case X,Y and Z propagate through a number of registered stages. So even if X gets registered ad a different moment, inducing the 'dreaded' delta cycle we either have X being 0 or 226 and Y being either 0 or -113. No combination of either X + or - Y/4 or Y + or - X/4 goes outside the -256 to + 255 range? Second as it is a registered design only the value at the required setup time is of interest. I agree that if at that moment the value is out of range an error is warranted, before that time a warning would do. Although this is RTL simulation there is no notion of setup time and no delta (this being VHDL code)?   --- Quote Start ---  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 End ---   Am I correct that your testbench avoids a delta cycle as X and Y change at exactly the same moment? What will happen if you induce a delta cycle by delaying the change of e.g. Y?    --- Quote Start ---  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 End ---   I did put all stages in the list window and a saw nothing that would have generated the 261 value.  On my next 'try' I will add the report statement. I will then switch to Timing SImulation. As this design is heavily registered, most vital signals will be preserved and will allow a reasonably good inspection of the internals.

[Altera_Forum]

--- Quote Start ---  In this design the values of X,Yand Z will not go outside the boundaries by design.  --- Quote End ---   Designs need to be validated. Since your sim indicates that lxn is going outside of its defined range it suggest that things aren't quite right by design after all.     --- Quote Start ---  Now in this case X,Y and Z propagate through a number of registered stages. So even if X gets registered ad a different moment, inducing the 'dreaded' delta cycle we either have X being 0 or 226 and Y being either 0 or -113.  --- Quote End ---   That might all be true, but you haven't posted any code that shows how X and Y are actually generated so nobody else can really verify this (which is fine), but it means that suggestions can be offered for things for you to look at. What I haven't heard in return is whether you have verified in the list window that X and Y really are changing on the same simulation delta cycle, and while you stated that X = 226 and Y = -113 at the point of the failure, it's not clear what it was prior to that...     --- Quote Start ---  No combination of either X + or - Y/4 or Y + or - X/4 goes outside the -256 to + 255 range? Second as it is a registered design only the value at the required setup time is of interest. I agree that if at that moment the value is out of range an error is warranted, before that time a warning would do. Although this is RTL simulation there is no notion of setup time and no delta (this being VHDL code)?  --- Quote End ---   This has nothing to do with setup times. The error reported is "Value 261 for lxn is out of range -256 to 255" which simply means that the signal had a defined range and there was an attempt to assign a value that is outside of that range...that is an error.     --- Quote Start ---  Am I correct that your testbench avoids a delta cycle as X and Y change at exactly the same moment? What will happen if you induce a delta cycle by delaying the change of e.g. Y?  --- Quote End ---   Nothing...but that may not be the same sequence of X,Y pairs that you are simulating. Just prior to the X,Y that causes the failure there must have been a different X,Y pair. Perhaps the previous X and the current Y exist for one simulation delta cycle and that causes the error.      --- Quote Start ---    I did put all stages in the list window and a saw nothing that would have generated the 261 value.   --- Quote End ---   My question was do X and Y change on the exact same simulation delta cycle? Perhaps it would simply be better for you to run the simulation to the point of the failure and simply copy/paste the last few lines of the list window since we don't seem to be getting very far.     --- Quote Start ---  On my next 'try' I will add the report statement.  --- Quote End ---   That should produce useful information     --- Quote Start ---    I will then switch to Timing SImulation. As this design is heavily registered, most vital signals will be preserved and will allow a reasonably good inspection of the internals.    --- Quote End ---   The timing sim will produce nothing of value as it relates to this problem. The reason is that the timing sim is based on the synthesized logic which has no notion of integer range boundaries. If your design happens to overflow, the typical response is that the values will simply wrap around because arithmetic operators get transformed to boolean logic. Boolean logic does not have integer ranges so there can be no error of this type to report...regardless of what design it is.   Kevin Jennings

[Altera_Forum]

--- Quote Start ---  I reproduced the problem with 10.0c Altera Starter Edition and the full edition. Tests failed with earlier versions of Modelsim, since you have conversion functions on the ports to components (which we discussed in an earlier thread - it requires creating intermediate signals).   I defined a subtype for your integer of limited range, and then added dummy qualifications around each argument and result of the operation, and the error was still generated.   Definitely looks like a bug.   --- Quote End ---   Dave,   Out of curiousity, just what were you using for the design and the testbench when you say that you reproduced the problem?   Did you verify in the list window that X and Y are changing on the exact same simulation delta cycle? Your talk of conversion functions and intermediate signals suggests to me the strong possibility that by the time X and Y make it to the process that they are not precisely in sync which then raises the possibility that a 'previous' X and the new Y could cause the problem since, based solely on the defined ranges of the signals, it is possible for the computation to not be in range.   Kevin Jennings

[Altera_Forum]

Hi Kevin, 

  --- Quote Start ---    Out of curiousity, just what were you using for the design and the testbench when you say that you reproduced the problem?    --- Quote End ---    Josy sent me the design files via email, and I performed a quick sanity check to see whether Modelsim-SE generated the same error.    --- Quote Start ---    Did you verify in the list window that X and Y are changing on the exact same simulation delta cycle?   --- Quote End ---     Let me check ... (I'll fire up my machine with 10.0c on it and re-run the simulation) ...    --- Quote Start ---   Your talk of conversion functions and intermediate signals ...   --- Quote End ---    I looked into that to see whether there was some weird promotion to full integer going on, there wasn't.  Cheers, Dave

[Altera_Forum]

Hi Kevin and Josy, 

 I fired up the simulation again, and added the signals from within the design node generating the error.  The error is generated for a calculation  lxn <= X - dX;  Right at the time the simulation error is generated, X = 254 and dx = -7, so lxn will equal 254 - (-7) = 261.  Looks like an error in the logic, rather than a simulator bug.  Josy - you should be able to repeat what I just did.  Kevin - thanks for gnawing away at this :)  I've attached the list window for the signals at the design level where it fails.  Cheers, Dave

[Altera_Forum]

Hello Dave and Kevin, 

 thanks for working on this while I was sleeping ...  Dave, I had all my X and Y in a list window and did not see what you see. Maybe I had too many signals in the list window to see it clearly. I redo this all later tonight after finishing a few urgent issues on other parts in the project.  Kevin, advice well taken. I'll validate the ranges by doing some worst case sequences on paper (or script it). The design is a Cordic Machine. I just assumed that doubling the range, enough to handle the Cordic Gain of about 1.646 would have sufficed. I'll apologize later :)  Regards,  Josy

[Altera_Forum]

It's a feature of the simulator to detect overflows of range constrained signals. In synthesized logic, integer signals are represented by signed or unsigned bit vectors and will silently wrap around on overflow. 

 To achieve a consistent simulation in this regard, you need to do this: - set integer constraints equal to the range of the respective signed or unsigned number (you already did in your code) - add overflow handling or modulo operations (considering wrap around)  Or assure by design, that no overflow occurs.

[Altera_Forum]

--- Quote Start ---  It's a feature of the simulator to detect overflows of range constrained signals. In synthesized logic, integer signals are represented by signed or unsigned bit vectors and will silently wrap around on overflow.  To achieve a consistent simulation in this regard, you need to do this: - set integer constraints equal to the range of the respective signed or unsigned number (you already did in your code) - add overflow handling or modulo operations (considering wrap around)  Or assure by design, that no overflow occurs.  --- Quote End ---    Thank you Frank, but Kevin and Dave already did a good job explaining what happened.

[Altera_Forum]

While waiting on anther long simulation (because I have to run most of my simulations in Timing Simulation mode because my code tends to provoke the obscure "Fatal : Unexpected signal 11" error in RTL Simulation mode) I did a (the) calculation on my design: 

As the longest vector to rotate is either (127,127) or (127,-127) which has a length of sqrt(x^2 + y^2) or 179.6. This however gets multiplied by the Cording Gain of about 1.647 which gives : 295.8. And this takes one bit more than I catered for. So to Kevin: my sincerest apologies. Can't say that I didn't learn something, though! Thanks again to Kevin and Dave for the help.

[Altera_Forum]

Glad to hear that the problem has a solution. 

 I'm sure you are happy you took (are taking) the time to learn to use Modelsim. You would have had fun tracking this down in hardware.   The wrapped signal would have generated a glitch in your sinusoid that would have created some pretty ugly artifacts in your spectra :)  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  The wrapped signal would have generated a glitch in your sinusoid that would have created some pretty ugly artifacts in your spectra  --- Quote End ---   The exercise at hand is to find out whether a point in 8bit by 8bit plane is inside a 12-point polygon (concave or convex) centred around (128,128) . The first simulation (again in Timing mode) produced unexpected results, so I went a bit deeper and decided I had to re-simulate the Cordic Machine proper. Like you said learning ModelSim is definitely worth the (initial) effort. (I once spearheaded the demand to bring the QII internal simulator back, but I now repent ...)

[Altera_Forum]

--- Quote Start ---   I once spearheaded the demand to bring the QII internal simulator back, but I now repent ...  --- Quote End ---    Excellent, another convert :)  Cheers, Dave

[Altera_Forum]

You'll be telling us you write bus functional models next!