Dynamic memory allocation for random stimulus
Why OSVVM™? › Forums › VHDL › Dynamic memory allocation for random stimulus
Tagged: VHDL Verification
- This topic has 3 replies, 2 voices, and was last updated 7 years, 9 months ago by Louis Nugroho.
August 18, 2015 at 00:41 #1025Louis NugrohoMember
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_list is access data_type;
type data_type is record
data_list := new data_type;
while simulation = '1' loop
wait until rising_edge(clk);
data_list.value := value;
data_list.next_el:= new data_type;
data_list := data_list.next_el;
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.
LouisAugust 18, 2015 at 08:23 #1028Jim LewisMember
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.
JimAugust 18, 2015 at 13:18 #1032Jim LewisMember
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.
JimAugust 19, 2015 at 00:49 #1033Louis NugrohoMember
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.
- You must be logged in to reply to this topic.