Limitation using MemoryPkg
June 22, 2017 at 09:04 #1385Jorge TonfatMember
I am using OSVVM 2017.05 and I have the following limitation using MemoryPkg:
I defined an SRAM vhdl model using the MemoryPType. And my SRAM data width is 32 bits.
My problem is that when I am reading a memory position with a value that is outside the integer positive range (> 2147483647) , I get only ‘U’ as data because of the following code in MemoryPkg:
if ArrayPtrVar(BlockAddr)(WordAddr) >= 0 then
-- Get the Word from the Array
Data := to_slv(ArrayPtrVar(BlockAddr)(WordAddr), Data'length) ;
elsif ArrayPtrVar(BlockAddr)(WordAddr) = -1 then
-- X in Word, return all X
Data := (Data'range => 'X') ;
-- Location Uninitialized, return all X
Data := (Data'range => 'U') ;
end if ;
To solve this issue, can we just change the MemBlockType definition?
type MemBlockType is array (integer range <>) of integer ;
type MemBlockType is array (integer range <>) of real;
Thank you!June 26, 2017 at 01:25 #1388
replacing the integer with a real won’t solve the problem.
Instead, it makes it even worse.
The integer data type uses 32 bits (signed) so you have a numerical range of -2^31 to (2^31)-1.
The mantissa of the (32 bit) real data type is just 23 bits wide, which means it has a smaller numerical range (for integer use).
Once you increase the exponent, you are loosing LSBs of the mantissa.
So, while the memory range may grow, you are not able to adress each word in the higher adress regions.
My guess would be to use some unsigned type for the desired purpose.
With unsigned the number of usable adresses can be increased to ranges not yet imaginable for existing memories.
(e.g. can your simulator host computer adress some array of unsigned (2048 downto 0) memory?)
Also, the unsigned data type behaves almost like integer and is compatible (castable) to slv, so it might require less code changes.
But it needs to be checked, wether the conversion functions (e.g. to_integer/to_unsigned) are used, I doubt that they handle larger_than_integer unsigned types properly.
Have a nice simulation
EilertJune 28, 2017 at 01:41 #1391Jorge TonfatMember
Thank you Eilert!
Yes, you are right, changing to REAL will not solve the problem. To avoid troubles in this case, I just limited my pseudo-random generation to be bounded by the positive integer range. As you mention, maybe it is possible to change the data type to an unsigned type, but I have not tried.
JorgeJune 28, 2017 at 18:47 #1392Jim LewisMember
For the time being, you can use more than one memory model.
A past version used integer_vector instead of integer. This is something I intend to re-consider in the future. The problem is it adds complication and overhead to all models. This is something that needs to be considered. I am looking into using generics with the package to handle this and some other features I am considering. I am particularly interested in the VHDL-2017 generics on protected types.
The VHDL type REAL is a double (64 bits) – so it could handle the value but integer_vector would be a better solution.
JimJune 28, 2017 at 22:56 #1395August 16, 2017 at 16:18 #1400Jim LewisMember
In the 2008 standard it says:
An implementation shall choose a representation for all floating-point types except for universal_real that conforms either to IEEE Std 754-1985 or to IEEE Std 854-1987; in either case, a minimum representation size of 64 bits is required for this chosen representation.
I think this changed before 2008, perhaps in 2002.
- You must be logged in to reply to this topic.