Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Memory/Storage

Examining memory models

Posted: 04 Jan 2016 ?? ?Print Version ?Bookmark and Share

Keywords:verification? SystemVerilog? DDR3? memory protocol? interface?

As well as providing this useful front and back door functionality, other capabilities are required to enhance the usability of the memory model for verification. The memory model should provide a means of checking that the memory protocol is being followed and flagging errors as they occur. This is usually supported by the use of assertions that are fired when an error occurs, making it easier to get to the root cause of the problem. The memory model should provide a functional coverage monitor that tracks the different ways in which the protocol has been used. This can be used to check that a memory controller has been thoroughly verified, or to understand which modes of protocol operation have not been tested. Support for debugging the memory protocol is also important in order to efficiently trace the source of a bug.

Mentor memory library
Mentor Graphics recently introduced a new and comprehensive memory verification IP library aimed at addressing the growing need for accurate memory simulation models. The newly released Mentor memory model library contains twenty five of the most commonly used memory types. Through configuration, the library supports thousands of models based on memory devices, and users are able to create their own configurations, allowing an almost infinite number of models to be supported.

Table 1: Memory model types currently supported by the Mentor memory library.

All of the models available in the library can be used either as a stand-alone memory model or as a UVM agent, supporting any type of simulation environment. The models are qualified on all of the three main EDA simulation platformsQuesta from Mentor Graphics, Incisive from Cadence, and VCS from Synopsys.

The memory models are packaged as SystemVerilog modules with a pin-out corresponding to the modelled memory type. This allows them to be instantiated as components in a design netlist or in the top level of a test harness. The models respond to the signal-level protocol for front-door accesses and provide a back-door API that is common across the library.

The models provide full functionality and timing accuracy for each type of memory model. This includes optional functional mode settings and support of advanced operations, such as training and levelling, which is used to fine-tune the response of high-speed protocol interfaces, such as DDR4.

The timing and behaviour of the models are highly configurable allowing them to be tuned to take on the personality of real memory devices. Each memory module has a MANUFACTURER and a PART_NUMBER parameter that allows you to specify which device the model should behave like. These parameters are used at the beginning of a simulation to set up the appropriate configuration options within the model. The value of these part number parameters can be changed as a simulator command line option. This makes it possible to change the part modelled without having to recompile the design and testbench, which is useful for checking that a second source component will work in a system design.

The memory models are supported by the Mentor VIP configuration GUI, which allows you to either instantiate a specific memory component model in a testbench created by the GUI or create a configuration file that can be loaded by the memory component. The GUI gives you access to all of the configuration options available for a specific memory type, including timing parameters. This allows you to create your own variant of a memory model to explore specific corner cases. The path to the configuration file generated by the GUI is another parameter of the memory module and, if specified, overrides the MANUFACTURER and PART_NUMBER configurations.

Figure 2: Memory model block diagram.

The models have an API so you can reconfigure them during a simulation. The API allows either a new device part number to be specified or a different configuration file to be used. Almost any change can be made to the model using this approach. However, you must make sure that any change in behaviour occurs at a reasonable place in the test, and you must be aware that the model may require re-initialisation or training, depending on the extent of the reconfiguration.

Memory models have other module-level parameters that provide optional verification features. A functional coverage monitor for the memory protocol is activated using the ENABLE_FUNC_COV parameter. A memory transaction logger is turned on using the ENABLE _TXN_LOG parameter. The memory transaction logger either writes to the simulator transcript or to a specified log file, with the output being useful for tracing memory-level simulation activity.

?First Page?Previous Page 1???2???3?Next Page?Last Page

Article Comments - Examining memory models
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top