2020-03-13

Long story short: I’ve just spent way too much debugging a problem that turned out simply to be an SDRAM chip’s CKE line not connected in the toplevel design file!

A while back I discovered the Next186_SoC FPGA core, by Nicolae Dumitrache. When I first learned of this excellent core’s existence I could’t find any ports to Altera devices – the main target device was a Nexys board that had DDR SDRAM, and porting the core to the boards in my possession (Altera FPGAs, single data rate SDRAM) was beyond my skill level at the time. A few months back, however, it was pointed out to me that the original author had ported the core to the Turbo Chameleon 64 V2 – but not the V1 hardware.

I set out to backport this great core to the older hardware, and – as so often happens – found myself wanting to build multiple targets from a single source tree.

I also found, quite quickly, that setting up an SD card for use with the core is a royal pain. Because extracting the size information from a non-high-capacity SD card is so absurdly convoluted, the core’s boot ROM only supports SDHC cards. It requires an 8k BIOS image to be written to the last 8k of the card – which is not an easy thing to arrange – and it requires a FAT16 boot partition on the card.

So began my quest to improve the core, by adding a new bootstrap module with an extra CPU (originally ZPU, but I’m in the process of replacing this with EightThirtyTwo) and floppy-disk image support and support for a wider range of SD cards.

The biggest problem I faced was that, while there’s plenty of logic elements left from the 25,000-odd available in the target devices, there’s next to no block RAM left, which makes debugging problems by way of SignalTap very difficult.

To address this problem, I’ve just bought a de10-lite devboard, which has a MAX10 FPGA with about 50,000 logic elements (drool!) but better yet, well over 1.6 million bits of block RAM – all using similar enough techology to the Cyclone III / Cylone 10LP chips that IP megafunctions translate directly. The memory blocks are even still M9Ks!

So I’ve ported the core to the de10-lite, hooked up an SD card module to the Arduino headers, and tried it out for the first time…

Nothing.

After checking many, many things, from the polarity of reset signals to timing constraints, I was pretty sure the problem was SD-RAM related – then it finally dawned on me: neither version of the Turbo Chameleon hardware connects the SDRAM chip’s CKE signal to the FPGA – there wasn’t a spare IO pin – so instead CKE is tied high. I’d neglected to account for this in my port!

So having tied the signal high in the toplevel design file, well…. OK – it still doesn’t fully work, but it now not works a lot less than it didn’t work before.