Zip CPU

FPGA design engineer and blogger, placing particular emphasis on test and formal verification

[Zip CPU @zipcpu]

Wow, lots of new twitter followers just joined. Welcome! Just to give you an opportunity to get to know me and the ZipCPU blog, here's a bit about me and what you can expect here: https://t.co/8ES2DjR5za Again, welcome!

[Zip CPU @zipcpu]

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.

[Zip CPU @zipcpu]

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.

[Zip CPU @zipcpu]

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.

[Zip CPU @zipcpu]

@Burito_Joe 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.

[Zip CPU @zipcpu]

I can't say I've never made this mistake before

Note that TFR_WRITE != TFR_TXPARITY ... otherwise this might've worked accidentally ...

[Zip CPU @zipcpu]

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

[Zip CPU @zipcpu]

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.

[Zip CPU @zipcpu]

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.

[Zip CPU @zipcpu]

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.

[Zip CPU @zipcpu]

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.

https://t.co/WFlPkpxEKO

[Zip CPU @zipcpu]

@TheRetroHQ 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.

[Zip CPU @zipcpu]

One of the differences between ASIC and FPGA design is the initial statement. ASICs don't support them. To build IP that works across technologies, I've had to be very careful where, when, and how I use such statements. In many cases, I've had to remove them over time when my FPGA designs later become ASIC designs.

[IC Freely 🇨🇦 @intothefloyd]

@zipcpu They don't, as long as you define their initial state in register declaration to avoid X's in simulation, and of course to get the initial state that you want, whether 0 or 1.

[Zip CPU @zipcpu]

@bradipao @samsoniuk @ASiDesigner 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.

[Zip CPU @zipcpu]

@samsoniuk @ASiDesigner 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.

[Zip CPU @zipcpu]

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

[Zip CPU @zipcpu]

Sure, I get it.

There is one other issue to be aware of: If you get rid of the all internal reset, in favor of an initial statement, then the only way to reset the design will be a full reconfiguring of the FPGA. That's a design choice. Is it what you want?

Practically, that's what I used to do. I argued for it often. Then I came across issues with hardware that required resets. (The CPU hit a bug and needs to be reset, but I don't want to reset the whole system, the I2C system locked up, etc.) Resets within the design, even partial ones, can be quite valuable.

[Zip CPU @zipcpu]

In the end, I just had to swallow my pride, say, "Yes, sir! That's a good catch. I'll fix it right away," and then go on with generating a new release.

Yes, I knew the first release would've worked, but no one wanted to take that chance on simple trust.

[Zip CPU @zipcpu]

Arguably, the impact of any initial statements within a design on tainting any simulation results is a very real and valid threat to verifying any would-be ASIC IP, so I get their point.