Limitation using MemoryPkg

[Jorge Tonfat]

Hi!

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') ;

      else 

       -- Location Uninitialized, return all X

        Data := (Data'range => 'U') ;

      end if ;

To solve this issue, can we just change the MemBlockType definition?

From:

type MemBlockType    is array (integer range <>) of integer ;

To:

type MemBlockType    is array (integer range <>) of real;

Thank you!

[Eilert Backhus]

Hi Jorge,

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

   Eilert

[Jorge Tonfat]

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.

Best regards,

Jorge

[Jim Lewis]

Hi Jorge,

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.

Best Regards,

Jim

[Eilert Backhus]

[Jim Lewis]

Hi Eilert,
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.

Best Regards,
Jim

[Jim Lewis]

Hi Jorge,
I just came across this again. This issue was addressed in release 2022.08. MemoryPkg now supports data words of any width. A couple of different implementations of MemoryPkg are provided via generic instances). The instance MemoryPkg (and MemoryPkg_X) stores data and X/U’s. The instance MemoryPkg_NoX stores only data and X’s are mapped to 0.

[Author]

Posts