Memories … Light the Corners of My Verification Space

With due apologies to Barbra Streisand, the topic of today’s blog post is the verification of SoC memories and memory subsystems. Once upon a time, memories were considered just about the easiest design structure to verify. A simple automated test doing “walking 1s” and “walking 0s” supplemented by some random reads and write to random addresses with random data seemed to be good enough.

“Can it be that it was all so simple then? Or has time re-written every line?” Actually, it really was that simple back then. But a lot of changes in memory subsystems have come along to complicate matters: memory regions, caches, multi-processor designs, shared memory, complex memory maps, etc. Verification of memories today is much more challenging, with many corner cases to be exercised, but it’s an essential part of the overall SoC verification effort.

Just adding a cache to a single memory increases the verification process. Tests must be written to ensure that the cache lines appropriately retain read results from main memory while updating main memory after a write operation. Adding additional embedded processors that share the same memory space complicates things further. One processor might read from a memory location whose most recent value is in another processor’s cache.

“Misty water-colored memories of the way we were.” Cache coherence is critical in multiprocessor systems. Outdated “misty” copies of data will cause huge problems. Any read from any processor to any memory location must return the value most recently written to that location. Next, consider adding multiple memories, some perhaps with multiple regions. Each memory has attached to it some sort of memory controller, some of which might have multiple channels.

Memory controllers contain some buffering in order to optimize memory accesses. The data in these buffers must be taken into account as part of the coherency scheme. On top of all the other complications, the processors in the system might not share the same global memory map. Processors may have private, non-cached memory regions. Even a shared memory location might not appear at the same address in the memory map of each processor:

There are several reasons why memory maps may differ from processor to processor in the same SoC. In this example, the audio processor has a smaller address space than the main CPU and so cannot possibly have the same address map. In addition, both the audio processor and the security processor have their own memory regions located at the start of memory to facilitate SoC-level reuse of code developed for the processors in standalone applications.

“Scattered pictures, of the smiles we left behind.” So the data in the SoC may be quite scattered indeed, between multiple regions of multiple memories, multiple levels of caches, memory controller buffers, and different addresses depending upon which embedded processor is accessing the data. This all adds significantly to the hardware complexity and presents a huge challenge to verification engineers trying to write tests to run on the embedded processors in the SoC.

“Memories … may be beautiful and yet, what’s too painful to remember, we simply choose to forget.” Forgetting is not an option in the memory subsystem of the SoC. It must work perfectly under all corner-case conditions, which means that these same conditions must be thoroughly verified before the chip is fabricated. Exercising the corner cases is statistically unlikely from a constrained-random testbench and very difficult with hand-written C tests.

Fortunately, there is an alternative. The multi-threaded, multi-processor, self-verifying C test cases generated by Breker’s TrekSoC and TrekSoC-Si products are very effective at verifying complex memory subsystems. The test case generator has access to the memory organization, memory maps, and other details of the SoC architecture. All the nasty details are handled automatically in the process of generating the code to run on the embedded processors.

For example, producer-consumer scenarios get complicated when the two agents do not share the same address map. If the producer writes its data to one address while the consumer must access a different address to read the same data, the generator handles this automatically when producing the test case. The user does not need to track any of this complexity. Because the generator exercises the corner cases for memory access, the test cases do an excellent job of verifying the memory subsystem.

We can be nostalgic and remember “the way we were” when memories were simple, but a smart SoC verification team knows that much more is needed today. The automated solution provided by TrekSoC and TrekSoC-Si verifies memories thoroughly from system-level modeling through simulation, acceleration, emulation, FPGA prototypes, and even actual silicon. No other method verifies cache coherency, multiple address maps, and other advanced memory features nearly as well.

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Breker, buffer, cache, coherency, constrained-random, emulation, functional verification, graph, memories, memory map, scenario model, streisand, system coverage, TrekSoC, TrekSoC-Si

This entry was posted on Tuesday, December 17th, 2013 at 12:42 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.