Perhaps a picture would do a better job explaining what happened ... The good news is that regressions are now passing (again) following a simple fix (S/W change only) to move the sample clock earlier.

Yeah, that's what they tell me ... I just don't know how you would go about guaranteeing deterministic behavior in this particular situation.

Today's bug: two simulators (XCelium, Icarus), same logic, one test case passes, one doesn't. Why? It's a race condition. The model sets its data on the same cycle as it gets sampled. One simulator samples the data before it gets set by the model, the other afterwards.

Sadly, this was a "working" IP. There was no time (or money ...) planned in the schedule for rebuilding critical components. Time had to be made, but that will push everything else a bit later. I was supposed to be working on a memory controller for another type of memory. Life happens.

Formally verifying the components involved required building proper interface property sets--to make sure any input assumptions were guaranteed by the prior component and so on. In the process, another bug was found whereby reads (or writes) crossing different devices might get merged. Likewise, reads might have accidentally merged requests across WRAP requests--turning WRAP requests of the H/W into hybrid WRAP requests--even though not all memories support hybrid wrap.

The read in question was an instruction cache read. The memory controller returned all zeros, which ... wasn't the right instruction, eventually leaving the CPU in an unscheduled loop. The engineer had to decode the VCD from the hung CPU, through the cache, to the bus, and so on into the memory controller. Full stack debug.

Then we connected it to a (still simulated) CPU. (A ZipCPU -- of course.) The memory controller failed. What happened? The read controller tried to aggressively merge a new request with the prior request. However, a write had taken place in the meantime that the read handler didn't know about. As a result of a bug in the read/write arbiter, the arbiter didn't force a new transaction, allowing the prior write to merge with the read. So, instead of reading, the memory was writing. Junk data was being returned to the read handler, and hence to the AXI bus master making the request.

Two key blocks are the downsizers. These are designed to downsize beats from the bus width to the memory width, while also aggressively merging transactions together to avoid the need to restart any memory transactions. Again, everything was working in the test bench.

Today's bug of the week is a story. It starts with a commercial memory controller (built by yours truly), that passes all of its simulation tests. Reads tested, writes tested, WRAP tested, Exclusive access checked, etc. Many, but not all components were formally verified.

I needed to make certain the IP wasn't in one of the two states listed. The proper boolean expression would've required &&, not ||. As written with ||, the condition will always pass--the FSM state can never equal both of the states its being checked against at once.

Just for context, r_transfer is the name of the state variable -- although the bug would still be a bug either way.

I can't say I've never made this mistake before Note that TFR_WRITE != TFR_TXPARITY ... otherwise this might've worked accidentally ...

Further, because this is intended to be an ASIC design, all cache accesses--both tag and memory--will be single port only, for area reduction purposes. That's just a sample of some sticky details.

One subtle reality, is that the two streams (read/write) of such a cache cannot be independent. If nothing else, they will need arbitration to access tag memory. This is in contrast to most of my AXI work, where I try to keep the read/write FSMs as independent as possible.

This weeks design puzzle has been to build an AXI cache: AXI in, AXI out with all WSTRB bits set. I've been a bit surprised at the requirements of such a controller, and the more I've dug into it, the more challenging and complex it becomes.

This stack exchange post has a good description of the problems with using AES-CTR for memory encryption. I love the included pictures. They tell the story well. crypto.stackexchange.com/que…

ROMs take space, but they can be placed on ASICs. It depends on your technology. ROMs that are small enough can be built out of logic. Yes, you can reset an internal RAM from a ROM. You can also use an external flash if necessary.

Three examples where memory reset is needed: 1) Security applications, where you have to guarantee no memory leakage, 2) Histogram accumulators, 3) GPS correlation accumulators. These aren't common examples, but they do happen.

It takes work--often a small FSM, coupled with a controller that holds READY low while running. I had to do this with my histogram generator.

Whoever thought AES-CTR could be used to secure memory ... is offering an expensive encryption that looks good but offers zero security.