At long last, the final build of the CPC is finished, tested and working!
Assembly of the new board was pretty uneventful. I followed my usual process of dry assembly on a spare board, solder pasting with a stainless steel stencil, rapidly transferring the components from the dry board to the pasted board followed by a session in the IR oven. Continue reading
With the world in lockdown, you’d think there’s plenty of time for hobbies. Somehow, it’s been 4 months since my last post – time flies in a crisis! I’ll admit that I’ve been somewhat lax in working on the CPC2, but with the project so close to completion, I need to re-commit to finishing this 5-year project! Today’s post is about my CPC Bluetooth joystick!
Christmas holidays are over and with it, my loooong days testing the CPC2.3 board are also over. So before I go back to work, here’s the current state of the CPC2. Spoiler: It’s GREAT!
The application used for testing is copyright Firebird and Telecomsoft.
So the next build of the CPC2 is done. I recorded the process with a time-lapse camera because it’s hard to make a 7 hour build entertaining. Each second of video is 30 seconds of assembly time, so this 7-hour build ended up at 7m19s of timelapse, after cutting out the cursing and head-scratching. See if you can spot my hands start to shake at the 2-hour mark of trying to precisely place the sub-millimetre components and enjoy.
The CPC disk operations are working! The video below shows the CPC loading a disk image from the eMMC, saving new files and unloading the disk image back to the eMMC. The image on the right is the UART console, which is also used to issue the mount and unmount commands (via ‘m’ and ‘u’ commands).
This post talks about HyperRAM, what it is, how to interface to it and how to improve the performance of high-speed parallel interfaces.
HyperRAM is described well by Cypress. It is essentially a double data rate RAM with a compact 12-line interface that masks the underlying technology of a DDR SDRAM. It can provide 333MB/s of data transfer in short bursts. Data is transferred on both edges of the clock, and the narrow bus makes it ideal for microprocessors or pin-constrained FPGAs. Continue reading
Another update and another dead end. In an attempt to add the much-needed storage mentioned in my last post, I managed to damage the board so that the JTAG connection stopped working. I added the EPCQ configuration flash chip to the board, only to find that I’d wired the data in and data out back to front and the flash can’t be read from the FPGA. I looked at direct access through the ASMI connection, but I couldn’t get this working. I guess it doesn’t expect the chip to be wired in ‘backwards’! In a futile recovery attempt, I tried to solder in the spare 16G eMMC card, but managed to short out the power pins again. Upon desoldering the eMMC, I must have damaged something because the JTAG connection stopped working. The chip could still be programmed through the supervisor connection on the fast-passive-parallel port, so it was not extensively damaged, but the JTAG connection was pretty essential to efficient RTL development. For now the board is relegated to the ‘post-project-review’ bin. Developing the hardware, RTL and software all in parallel creates too much inefficiency. So I decided to use this board to finish the development, the Terasic Cyclone V GX Starter:
Time for a quick update. I’ve integrated the SDRAM controller, the byte cache, and created some logic to map some of the SDRAM address space to the CPC ROM enable line. I also created some logic to allow the support CPU to push data into the SDRAM. This means that the support CPU can alter the ROM configuration of the CPC2 based on a user-set configuration.
To test the set-up, I created an example ROM that when booted by the CPC, it copies itself to address 0x4000, then dumps 64 bytes of memory at 0x4000. This will test the SDRAM controller, the cache and the cache replacement algorithm. Here’s the output.
Following a summary of the timing closure challenges in my last post, here’s a few more lessons learned from the process of trying to get my SDRAM and DMA controller to run at their fastest possible speed.
A lot of my timing closure process involved changing the RTL code and checking the effect on the timing. It’s a slow and laborious process, so here’s a list of my findings so you can save the hours of compilation time that it took me to test these.
Hello CPC fans! Has it really been 4 months since my last post? How time flies. Thanks to codepainters for the prompt to get going on my next post, and for reminding me that there are readers following the progress of this project.
I spent the first 3 months of this year refining the caching SDRAM controller and chasing timing closure issues. The SDRAM controller and it’s byte cache worked absolutely fine in simulation but failed to work reliably when I put the design in silicon at high speed. The sort of random and unpredictable behaviour I saw is usually indicative of timing issues, (especially when it worked at lower speeds), so I turned my attention to the timing reports from Quartus. This was new ground for me. I knew that IO timing was something that I should pay attention to, but until today my designs generally ran at sub 50MHz speeds where there’s enough timing slack to not notice the issues. However, on every design I’ve ever produced, at least one or two of the Timequest reports were in red, meaning that there were timing violations and hidden problems waiting to rear up when I least wanted them to. Continue reading
Intelligent Toasters 