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?

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.

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

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

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

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;

ModelSim "out of range" issue | Altera Community

21 Replies

Altera_Forum
Honored Contributor
14 years ago
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
Honored Contributor
14 years ago
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
Honored Contributor
14 years ago
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
Honored Contributor
14 years ago
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
Honored Contributor
14 years ago
--- 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
Honored Contributor
14 years ago
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
Honored Contributor
14 years ago
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
Honored Contributor
14 years ago
--- 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
Honored Contributor
14 years ago
--- 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
Honored Contributor
14 years ago
You'll be telling us you write bus functional models next!

Forum Discussion

ModelSim "out of range" issue

21 Replies

Recent Discussions

Unable to find questa_fe license file

No access to the Self Service Licensing Center (SSLC)

recovery timing issue

Duplicate_hierarchy_depth / duplicate_register

Unable to download Quartus