Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

Modelsim: Interpretation of numbers in wave window

Altera_Forum
Honored Contributor II
5,384 Views

Hello all! 

 I've encountered a problem that absolutely baffles me. It's regarding the radix interpretation in the Sim/Wave window. I've checked that the binary number is correct, 64-bit fixed with 32 bits decimals.  When displayed with fixed#32#binary#signed everything is correct but when displayed with fixed#32#decimal#signed it shows nonsense (see picture attached).  The bit sequence is: 00000000000000000000000000000000 . 00101110000000000000000000000000  in binary rep. it's showed correctly but decimal shows ~7.7e8 instead of the correct 0.1796875. Signed, unsigned makes no difference.  Anybody that knows what error I'm doing here?  Thanks in advance! BR/ eleteria

0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
2,901 Views

Hi eleteria, 

 

The given bit sequence “00000000000000000000000000000000 . 00101110000000000000000000000000” represents fraction in binary so you should check “float32” option in Radix. 

 

 

Let me know if this has helped resolve the issue you are facing or if you need any further assistance. 

 

Best Regards 

Vikas Jathar  

Intel Customer Support – Engineering 

(Under Contract to Intel)
0 Kudos
Altera_Forum
Honored Contributor II
2,901 Views

Hello!  

 

First of all, thanks for your effort and interest in replying!  

 

The 64 bit sequence is a fixed fractional number, not a float number. I.e. the 32 first bits represents the number and the 32 last (LSB ) represents the fractional part, 1/2 and below.  

But the most amazing thing regarding this, is that if I do the same with a 32 bit, with 16 bit integer, 16 fractional bits, then everything works perfectly.  

 

The 32-bit sequence: 0000000000000000 . 0000000100000000 i.e. 1/128 = 0.0078125 is showed correctly with radix fixed#16#decimal#signed. (signed/unsigned does not matter, it works correctly) 

 

See attached image. 

 

This is nothing short of mind blowing to me, I simply can't understand it.
0 Kudos
Altera_Forum
Honored Contributor II
2,901 Views

Anybody that has any idea here? 

My test development has pretty much come to a halt. 

I guess this is just a bump. :)
0 Kudos
Altera_Forum
Honored Contributor II
2,901 Views

After a thorough investigation, this is simply a bug in Modelsim. Just replying for other users future knowledge.

0 Kudos
Altera_Forum
Honored Contributor II
2,901 Views

 

--- Quote Start ---  

After a thorough investigation, this is simply a bug in Modelsim. Just replying for other users future knowledge. 

--- Quote End ---  

 

 

Though late but I think there is trivial misunderstanding of terminology.  

It looks like Modelsim means by decimal as signed (without decimal point), unsigned as unsigned(without decimal point) and fixed point for binary with decimal point defintion. Thus your above  

value is viewed without decimal point unless you choose fixed point. For signed/unsigned it ignores decimal point entered for fixed point.
0 Kudos
Altera_Forum
Honored Contributor II
2,901 Views

 

--- Quote Start ---  

Though late but I think there is trivial misunderstanding of terminology.  

It looks like Modelsim means by decimal as signed (without decimal point), unsigned as unsigned(without decimal point) and fixed point for binary with decimal point defintion. Thus your above  

value is viewed without decimal point unless you choose fixed point. For signed/unsigned it ignores decimal point entered for fixed point. 

--- Quote End ---  

 

 

I'm sorry, but please read through my previous posts more carefully.  

For every even bit length <64 it works. Given the fact that I also have 15+ year experience in programming I can easily say that this is a bug. Classical index out of bounds error. 

Regarding decimal, that is how it's presented in the wave window. Signed/unsigned doesn't matter at all. 

 

This is already concluded to be a bug in the Xilinx forum. Thanks for your interest though.
0 Kudos
Reply