You can tune a piano, but you can’t tune a cache without help

Once upon a time, designing a product with a first generation SoC on board, we were trying to use two different I/O peripherals simultaneously. Seemed simple enough, but things just flat out didn’t work. After days spent on RTFM (re-reading the fine manual), we found ourselves at the absolute last resort: ask our FAE.

After about a week, he brought back the answer from the corporate team responsible for the chip design: “Oh, you want to do those two things AT THE SAME TIME? That won’t work. It’s not documented, but it won’t work.” Sigh. Functionality verified, but performance under all use conditions obviously not.

My PTSD-induced flashback was provided courtesy of a recent conversation with Patrick Sheridan, senior staff product marketing manager at Synopsys, when we were discussing why protocol analysis is important in the system architecture and verification process – not just during the design of compliant IP blocks – and what to look for in performance verification of an SoC design.

The unnamed SoC in my opening happened to be non-ARM-based, but the scenario applies to any shared-bus design, especially advanced multicore designs. Without careful pre-silicon verification, there can be surprises for the unsuspecting system designer just trying to get the thing to do what the documentation says it does. The issues we see today aren’t usually as readily observed as mutual exclusivity, and what likely was an attempt to preclude the actual problem from showing up in a much harder-to-detect fashion.

The types of issues we are talking about aren’t functional violations of AMBA protocol – almost any reputable IP block vendor or design team can clobber those defects before they show up at integration. Things start cropping up when more blocks performing more transactions are combined. I asked Sheridan what kinds of problems they find with the Discovery Protocol Analyzer, and he gave one answer: cache coherency.

If I had a dollar for every cache-non-coherent conversation I’ve had over the course of my career, I’d be riding a bike somewhere on the side of a mountain instead of looking out my window at my plants wilting in 100-degree weather in Phoenix while I’m writing this. Those familiar with caching know there are two things worse than not using cache. The first is sustaining a stream of rapid-fire cache misses, which kick off a lot of cycles updating the data wherever it has been copied, and the resulting wait for things to catch up. The second and worse scenario is one or more locations blithely running off with the bad data, before the system has a chance to update it, due to being out of sync for some timing reason.

The AXI Coherency Extensions, or ACE, form the protocol which needs to be checked under duress to mitigate caching issues. Combining Discovery Verification IP with the Discovery Protocol Analyzer provides an easy way for a verification team to generate traffic and check performance without a whole lot of additional effort. Alternatively, a team would have to embark on complex simulation scenarios, or worse yet timing budget computations in a spreadsheet, to find possible faults.

By using a reference platform with pre-configured masters and slaves and built-in checking sequences, achieving the needed coverage is straightforward. With protocol-aware analysis capability, root causes of problems can be found looking at individual transactions, pins, or waveforms. Verification engineers can quickly run scenarios and spot interactions causing cache-coherency problems, and customize the SystemVerilog for their environment.

For more insight, watch for an upcoming article in the Synopsys Advanced Verification Bulletin, Issue 2, 2013 authored by Neil Mullinger titled “Achieving Performance Verification of ARM-Processor-based SoCs.” Mullinger will also be speaking at @50thDAC on Wednesday, June 5, in the ARM Connected Community Pavilion at 9:40am.

lang: en_US