As promised in Part 27, I’ve finished a new build of the CPC2 hardware. Here are the board layouts as rendered by OshPark , and if you’re interested, I’ve shared the project.

Following my post on baking double sided boards, I created this board with components on the back also. This will present some challenges for assembly, but it was necessary to use a double sided format to keep the board roughly the same dimensions as the previous build. In fact this build was half an inch, smaller in length, being just 3″ x 1.5″ (76mm x 38mm) instead of 3.5″ x 1.5″ of the previous build. This reduction in size is despite adding a large eMMC chip, a large USB2 chip, a FPGA config flash chip and a ESP-WROOM32 Bluetooth/WiFi board.

I have yet to update the block diagram, but this tiny board now has all of the capabilities originally envisioned for it. Despite the squeeze on space, I decided to keep the MRAM and the Atmel SHA204A as this will be useful for true random number generation or encryption, such as HTTPS negotiation. I added a LOT of bypass capacitors for stability on the bottom later (see this article on best practice for this), and two extra power regulators for separate supply to both the ESP and the USB2 chip. I’m expecting that these additions will stabilise the FPGA under load, as well as assisting the video chip with stable HDMI output. In addition, I worked hard to deliver impedance matching for the TMDS video lines as described in a prior post. This involved keeping the lines as short as possible, expanding the width to 11mil, and placing a ground plane under the transmission lines.

Sharp eyed readers may also note that I turned each chip on its side to provide easier access to FPGA pins, avoid complicated routing and ensure all logic for each high speed device is only delivered out of one side of the FPGA. This should help timing issues where logic is routed to different sides of the chip. The SDRAM is exclusive serviced from the top side of the FPGA and the HDMI is services exclusively by the bottom side of the chip. Slower speed signals are routed to each side or mixed locations.

Here are the schematics. I’ve tried to avoid big changes to the schematic, because it was fairly successful in the last build. There is the obvious addition to the Microchip USB2 chip and the ESP-WROOM-32 after my testing on the Adafruit HUZZAH32 board.

I’ve added additional clocks to the FPGA, such as the 12MHz clock used for the USB2 as well as routing the 50MHz clock to two separate pins, to allow me to easily use two separate PLLs in the FPGA, giving me the essential 3.072MHz clock for the HDMI 48KHz audio. It wasn’t possible to synthesize 3.072MHz from the power-of-two PLL set up for the other parts of the design. While we’re on the subject of clocks, the USB2 chip provides a 60MHz clock for the USB data bus, so this needed to be connected to one of the global clock pins.

The addition of the FPGA config flash means that the FPGA should boot much quicker without relying on the Atmel SAM4 chip for it’s bitstream image. This meant that I could connect the eMMC chip directly to the FPGA for performance, as the SAM4 supervisor no longer requires access to the system storage. However, I still kept the 8-bit parallel interface from the SAM4 supervisor to allow rapid prototyping. This will continue to allow downloads of the system image via USB for testing. Once the image is correct, it can be uploaded into the FPGA config flash.

You may think this limits the FPGA to a single image per board, but this is not so. The Cyclone V FPGA has self-reconfiguration options. It loads the ‘factory’ image, that can then run logic to select a second image to be loaded after a self-reset. It’s for this reason that I kept the MRAM. I envision the boot process looking something like this:

• Board power-up
• Atmel SAM4S chip initializes all lines and enables the Flash memory
• It strobes the nConfig line to start initialization
• The FPGA loads in the default image from flash and starts operation
• The default image reads the MRAM as some sort of “bios settings” (in PC terms)
• The logic then selects the appropriate location in the FPGA config flash and self-resets
• The FPGA then loads the selected image and starts real operation

In this way, it will still be possible to have multiple images on the device. The FPGA config that I selected is a 256Mb/32MiB device, allowing potentially 16 images to be stored. As Bill Gates famously said once, “that should be enough for anybody!”.

As mentioned already, I replaced the raw flash with an eMMC chip. This removes the requirement for management of the flash, and simply presents an interface similar to an SDCard. It’s directly connected to the FPGA and so has the potential to run at it’s full speed of 45MiB/s if required. The flash will provide storage for the CPC, as well as recording the ROM images.

I’ve added JTAG connections on the bottom of the board for the FPGA (there were test points previously), the SAM4 and the ESP-WROOM-32. I don’t know if I’ll need this yet, but it’s a zero cost if I decide not to add the connector. I could probably have daisy chained the JTAG connections for the FPGA and the ESP, but I thought, why risk it with untested hardware? (For that reason, I decided not to share the 12MHz clock between SAM4, FPGA and USB2.

Bootstrapping

If anyone decides to build a copy of the CPC2, it will still be programmable without the JTAG connections and without specialist hardware. This was a core principle of the project that I did not want to drop. If the pin headers were soldered on, then the board would not neatly fit a case.

How it works is that the Atmel SAM4 chip has a factory ROM that will allow it to run a programming mode when the onboard Flash is empty. Using the SAM-BA software, an image can be uploaded to the SAM4 flash. This image would be the CPC2 monitor program, and as you know from the screenshots in Part 20, that the monitor program allows an upload of an FPGA image over the USB connection. That image would be a dummy image to facilitate an upload of a default/factory image to the flash. Once that’s flashed in, then the rest of the config is handled by that functionality through the USB port.

Order is placed

I’ve ordered my three boards from OshPark, and ordered my stencil from OshStencils. Given the tight tolerances and repeated use of these, I ordered the stainless steel stencils.

Within 24 hours, I got an email from OshStencils that my stencil had been dispatched! Wow. The boards from OshPark take a little longer as they are added to a panel shared with a bunch of other people (which is why the cost is so low). They also emailed me within 24 hours advising that the board is assigned to a panel, meaning I know roughly when the board design goes to the fabrication plant.

I’m hoping this is the final build. It’s been a long journey, over two years in design and five years in planning/dreaming! If you want to take a look at the boards at OshPark, click the link below. I’ll be placing the order with Mouser for the components soon, and they also allow cart sharing, so I’ll also publish the bill-of-materials (BOM).

Post script for Terry Pratchett

It is with some sadness that I recently heard that one of my favorite authors died, not so recently. Terry Pratchett was the author of the Discworld series that I read from my teenage years. Two interesting facts relevant to this post are that Pratchett started his writing on an Amstrad CPC computer, and one of his books, the Colour of Magic was made into an Amstrad CPC adventure game! (Wikipedia doesn’t agree it was available for Amstrad, but I still own it on tape!). Sir Pratchett died in March 2015, and a curious (but not surprising) request from the author was that his final work was destroyed. By steamroller. Sir Terry, my Fedora is off to you, you brought so much to us all.

Last Post <====> Next Post