A typical SOC consists of multiple interfaces that can access the memories within the design. When we are verifying such a design, we need to ensure that the memory accesses by various interfaces do not overlap, resulting in data integrity loss.

When verifying with System Verilog based verification environments involving multiple interfaces, we need to provide concise constraints on the stimulus to make sure that these accesses do not overlap and result in loss of data integrity.

Verification engineers typically had to spend a lot of time debugging the applied constraints, and such a form of constraining led to under constraining of the stimulus, which is a very risky path to walk on.

With the introduction of UVM based singleton memory manager, this task became much more implementation friendly with the availability of the memory management classes provided by UVM. But still these new verification components were not designed specifically for the development of environments involving multiple masters. The ‘Easy memory manager’ we have developed here maximizes the use of the existing UVM methods and also provides easier memory accesses between multiple masters.

What is the UVM memory manager?

There are very scarce resources available regarding the uvm_mem_mam class, so it would be understandable if the readers do not have much knowledge about its functionality. Before moving on to the features provided by the memory manager, we would like to offer a brief idea regarding the functionality of the default UVM memory manager.

There are four classes associated with memory management in UVM. They are mentioned below -

• uvm_mem_mam_cfg – It allows us to choose the number of bytes and the start and end offset to be managed by the manager.
• uvm_mem_mgr – It is to be initiated by the static/dynamic entity which wishes to allocate the memory.
• uvm_mem_alloc_policy – It can also be used to control the start and end offset of the manager and to also constrain these variables as per our requirement.
• uvm_mem_region – These represent the regions that are to be allocated by the memory manager. The regions contain the start offset and the number of bytes to be allocated by the manager.

Now that we have a brief idea regarding the operation of the default memory manager and the classes associated with memory management in UVM, let us see what we have added over this existing functionality in our memory manager.

Features supported

The ‘Easy memory manager’ supports the following set of features that makes it possible to be reused among various projects:

• The entire memory is divided into three dimensions of memory, master, and the regions allocated with allocation and release of regions on these three dimensions being supported.
• Divide the memories into virtual regions.
• Runtime allocation and release of regions.
• Non overlapping allocation for multiple masters.
• Allocating regions by providing the physical address of the region to be allocated and the number of bytes.
• Chunks of memory can be reserved so that any masters cannot access it.
• Debugging mechanisms that provide detailed information about the regions that have been allocated.
• Create memories based on the input from the .xls file.
• The top register block and the manager is configurable by script.
• Plug and play so it can be directly used in any existing UVM environment.

Architecture

This section depicts the structure of the memory manager and the environment where the ‘Easy memory manager’ will be introduced. The manager consists of the top uvm_reg_block, which contains the individual memories (E.g. – Flash, JTAG, SRAM, etc.). The individual memories are created as per the data provided in the .xls file. The individual memory class configurations are fully customizable as per the project requirements. In a similar fashion we can configure the top memory via the script’s command line options. The manager is a singleton so there will be no data duplication.

Figure 1 Environment using Easy memory manager

Figure 2 Allocation and deallocation of memory regions using Easy memory manager

                             Table 1 List of methods within the manager

Here we have shown a scenario of how the ‘Easy memory manager’ will be used in a multi-master scenario. The memory is being accessed by two masters, one of SPI and another of Ethernet which are executing their own test sequences. In the example, you can observe how the unique numbers provided by masters while accessing memories makes the handling of regions in the test cases more controllable to the user. Also, the user need not know about the structure of the memory in the RAL model. He can simply provide the physical address and the manager is smart enough to reserve the region as per the address.

        Figure 3 Interaction of masters with the manager when reserving/releasing regions

1. Initially, the entire range of memory is available and the SPI master requests for two regions so that it can start its sequences on these regions.
2. Similarly, the Ethernet master has also requested three regions. The Ethernet master’s and the SPI master’s regions will be differentiated by the master number that is passed as an argument by the master while allocating.
3. The SPI master has finished its sequences and releases the two regions it had allocated by specifying its unique master number while calling the release function.
4. The Ethernet master now wishes to access the region previously allocated to the SPI master. So it will request these regions by specifying a physical address.
5. The sequences of Ethernet have completed, and it will release the regions it had requested.

Steps of integration

                                                    Figure 4 Steps of integration

• Provide input to XLS– Write the data in the appropriate format in the .xls file to create the individual memories.
• Generate memories and reg_block via script– Run the script with the appropriate command-line options. If command-line options not provided, then the default options are used.
• Take manager’s instance in environment – The memories and manager will be created as per the data provided in the .xls file and the command-line options. Create an object instance of the manager in the component where you want to access the manager.
• Get the handle of manager – The manager’s instance will need to get the handle of the manager since it is a singleton. The manager consists of a method that returns the singleton handle.
• Access methods via handle– The manager’s methods can be accessed by use of the manager’s handle.

The ‘Easy memory manager’ is generic in nature and can be used in any existing UVM based verification environments. The manager package is easily configurable and can be extended into any project-specific environments without any changes in the internal code.

At eInfochips, we have used this memory manager in the system, subsystem, and IP level environments and achieved expected results. We have validated this component using QuestaSim and NCSim simulators.

About the Author

Siddharth Nair is working as a ASIC Verification Engineer with eInfochips, an Arrow Company. He is proficient in SV and UVM based functional verification and experienced in formal verification. He has also worked in IP/subsystem/SOC level verification environments.