Dynamic memory allocation for random stimulus

Why OSVVM™? Forums VHDL Dynamic memory allocation for random stimulus

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #1025


    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;




    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,


    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 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,


    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,


Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.