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?

Most electronics systems employ memory components either for storing executable software or for storing data, and therefore the availability of accurate memory models is fundamental to most functional verification strategies. Making these models available in proven, standards-based libraries is essential. This article describes the qualities you should look for in such models and introduces a new library that I feel delivers the most comprehensive solution of this kind and supports any type of simulation environment and all three of the industry-leading simulators.

Memory model requirements
For verification modelling purposes a memory device can be abstracted as a signal-level protocol interface to a storage array. The signal-level interface has to conform to the timing and behaviour of the memory protocol, which may be specified in an industry standard, such as the JEDEC JES79-3F standard for DDR3 or, in a specific case, it may be described in a device manufacturer's datasheet. How the storage array is implemented is not directly visible to the user, but for simulation models it is generally implemented using either a SystemVerilog data structure or an optimised C data structure.

Figure 1: Generic abstraction of a memory device model.

When a memory model is used in a testbench, it is instantiated as a component that is connected to a memory controller, which is either the design under test or part of the design under test. Accesses to the memory take place using the signals of the memory model's protocol front end, and data is transferred in and out of the model's storage array. The complexity of the front-end protocol varies by memory type, but it can involve concurrent transfers interacting with a memory state space using control and status registers. Getting decent performance from some types of memory, such as DDR, relies on the controller recognising certain types of data traffic and reorganising the memory accesses to optimise the access rate in and out of memory. This level of sophistication requires a hi-fidelity memory model not only to reproduce the complex behaviour and timing of a real memory device but also to determine whether the controller optimisations are effective.

The front door access to the memory over the protocol interface is mandatory for functional verification, but it does take time to transfer data in and out of the memory; therefore a backdoor interface is used to directly load or unload the memory storage array. The backdoor interface is typically used to load an executable software image in a memory model, or it may be used to load data content that is going to be manipulated by a hardware accelerator. The backdoor interface can also be used either to check memory content during a test or compare the memory data against a golden reference at the end of a test. A backdoor interface can also be coupled to a memory debugger to allow memory content to be interactively viewed and changed.

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