Dynamic memory allocation for random stimulus

Why OSVVM?ForumsVHDLDynamic memory allocation for random stimulus

This topic has 2 voices, contains 3 replies, and was last updated by Avatar of Louis Nugroho Louis Nugroho 650 days ago.

Viewing 4 posts - 1 through 4 (of 4 total)
Author Posts
Author Posts
August 18, 2015 at 00:41 #1025
Avatar of Louis Nugroho
Louis Nugroho

Hi,

I am a verification engineer and have been using OSVVM since a few months. I find it really useful and pretty practical.

Right now I am verifying an SPI design with a self-checking testbench, and have a problem with memory allocation for storing the random driver signals. Currently I am using VHDL Access variable and build a linked list with it, which seems very neat. The linked list built from the drivers will be checked in the comparator at the end of the simulation by comparing the driver’s list and the predictor’s list in no time.

But the problem is, in an Access variable, only 16-bit (65535) elements are supported. If I tried to allocate new memory after that, it will point back to the first location. Here is a simple example:

 

type data_type;
type data_list is access data_type;
type data_type is record
value: integer;
end record;

...

process

begin

data_list := new data_type;

while simulation = '1' loop
wait until rising_edge(clk);

value:= value+1;
data_list.value := value;

data_list.next_el:= new data_type;
data_list := data_list.next_el;

end loop;

end process;

 My question is, is there a way to “outsmart” this memory limit? Or is there a better, faster, more efficient way to store those stimulus, and at the same time flexible to be used in the comparator?

Thanks in advance.

 

Best regards,

Louis

August 18, 2015 at 08:23 #1028
Avatar of Jim Lewis
Jim Lewis

Hi Louis,
I suspect your concerns are tool specific, so you will want to report it as a bug to your simulator vendor. 

For this type of checking, I use a scoreboard.  Basically a driver puts the value it sent into the checkers scoreboard and when the checker receives a value, it checks it and the item is no longer stored.  Hence, there is no need to keep the information around any longer.

Jim

August 18, 2015 at 13:18 #1032
Avatar of Jim Lewis
Jim Lewis

Hi Louis,
I just ran some extended tests of MemoryPkg.  In the simulators I used it in, it did not show any signs of having issues at 16 bits.

The test walked across an address range of 2**30 in the memory model.  This requires an allocation of 2**20 blocks of memory, where each block has 2**10 integers.  First I wrote 2**20 random values into the memory (each in a different block), and then I read them back.  The data values were randomized.  The address always wrote to the first location in the memory block, so if there were any reuse of a previous pointer, then it would overwrite the previous value. 

Best Regards,
Jim

August 19, 2015 at 00:49 #1033
Avatar of Louis Nugroho
Louis Nugroho

Hi Jim,

Thanks for the response. I am currently using ModelSim PE10.3c. Yes, I think it is better to use the checkers scoreboard like you said. I will try it in the meantime, while I figure out if it’s a bug from the simulator.

 

Best Regards,

Louis

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.