craig@craigjb.com
Githubhttps://github.com/craigjb Twitterhttps://twitter.com/craig_jbishop

Zynq Bare-Metal Blinky


I recently scored a couple of XC7Z035s on Ebay from a chip seller in China! These are huge chips! The XC7Z010 on my Digilent Zybo dev-board has 28K logic cells and 240 KB of block RAM, while the XC7Z035 has 275K logic cells and 2 MB of block RAM (“logic cell” is a hazy term, but 275K is a lot!). So I’m excited to design a board for them, probably the forever-ongoing project, Gameslab. The prices to fab PCBs with 6 or even 8 layers keep dropping so fast, there isn’t an excuse now! JLCPCB even offers 6 layers with an impedance controlled stackup ($150 estimate for a 150x100mm board)! So, anyway, I’m excited to get back into FPGA stuff, so I’ve re-downloaded all the tools and set them up on a new virtual machine. To make sure I’ve got everything working, I thought a bare-metal blinking LED program would be a good place to start. This will ensure the cable drivers are installed, the ARM toolchain is setup, and that the JTAG download works. Essentially, I would use this same program to do the first test on a new board with a Zynq part.

Continue reading
Zynq Bare-Metal Blinky

FPGA Game Boy Part 5: Direct & indirect load instructions


So far, the SlabBoy CPU can perform arithmetic operations and load 8-bit immediate values. Neither of these operations require accessing memory at an address other than the program counter (PC). In this post I’ll quickly implement the register-to-register load instructions, and then go on to implementing indirect addressing. Even though the indirect addressing will only support addressing by register HL for now, it fills gaps in the major 8-bit arithmetic and load instruction groups implemented so far. If you’re just starting reading about the Slab Boy here, I recommend reading this post since I skip a lot of the detailed commands and surrounding code here.

Continue reading
FPGA Game Boy Part 5: Direct & indirect load instructions

FPGA Game Boy Part 4: Loading immediate values and halting the CPU


It’s been a little while, but in the last post I showed my SpinalHDL implementation of the Z80-ish ALU, part of the Game Boy’s LR35902 CPU. We could compile and run a program with NOP, INC, DEC, etc. However, because the microcode doesn’t support load instructions yet, building complex values is a bit difficult. In this post, I’m going to briefly show how I added the 8-bit LR35902 load-immediate instructions and the halt instruction to make simulating the CPU more friendly.

Continue reading
FPGA Game Boy Part 4: Loading immediate values and halting the CPU

FPGA Game Boy Part 3: ALU and some microcode


In the last post, I showed the test bench that loads an assembled Game Boy binary program, and we looked at the waveform output showing that the instruction fetch cycle worked. However, the instruction itself didn’t do anything. This time, I’m going to work on implementing the basic register-to-register arithmetic instructions, which are some of the simplest out of the whole instruction set. First, the CPU needs an ALU before it can execute arithmetic instructions. Then, it needs an instruction decoder to turn the op codes into the right control signals.

Continue reading
FPGA Game Boy Part 3: ALU and some microcode

FPGA Game Boy Part 2: CPU Scaffolding and test bench


In the last post, I started talking about the internal cycles of the LR35902 CPU. In this post, I’d like to start implementing some instructions. Building a CPU RTL description is a large task, so it’d be crazy to try to implement everything all at once. Instead, I’m thinking of starting with the easy arithmetic instructions and then iterating from there. To make testing quick, I want to use an existing Game Boy assembler, feed the output binary into the test bench’s program memory somehow, and then run that program in the simulator. So first, I’m going to setup a new SpinalHDL project and build the basic instruction fetch state machine. Next, I’ll setup a test bench to visualize what’s happening. Finally, I’ll use the RGBDS assembler to create a program binary and load it into the test bench.

Continue reading
FPGA Game Boy Part 2: CPU Scaffolding and test bench

FPGA Game Boy Part 1: SpinalHDL and Z80-ish T-Cycles


For a long time now, I’ve wanted to build some hardware emulators of older game consoles on an FPGA. In fact, that was one of the reasons I started designing a handheld game console, the Gameslab, based on the Xilinx Zynq FPGA+ARM combo. Eventually, I envision the Gameslab ARM CPU running an OS that allows you to pick a game, and each game can include custom hardware that is also loaded with the software. For example, one game could run on the ARM CPUs and include some custom graphics hardware on the FPGA fabric for fast rendering of terrain. Or, like the case I want to work on today, the game could load a whole game system into the FPGA fabric. Of course, there will be some trickery involved, and I’ve already started poking around some things, like Linux device tree overlays. However, today I want to start working on something more fun, a HW Game Boy emulator in the FPGA fabric, called the SlabBoy :)

Continue reading
FPGA Game Boy Part 1: SpinalHDL and Z80-ish T-Cycles

Reverse engineering away an annoying pop-up


I recently started using an app called Be Focused Pro for focusing using the Pomodoro technique to focus a bit better. The free version of the app has ads and some pop-ups, so I paid $5 for the pro version to remove the ads. Afterward, I was unhappy to discover the app still persisted in annoying its pro users. Periodically, when you enter a 5-minute break, the app triggers a pop-up notification asking to rate the app in the AppStore. While normally I would just find another app, I actually really like this one’s user interface (and I already paid $5 for it). So instead, I decided to hack away the annoying pop-up and have the app I want.

Continue reading
Reverse engineering away an annoying pop-up

Atlys FPGA reset shenanigans


I’ve been playing around the last few days building a Microblaze processor system on the Digilent Atlys Spartan 6 board. I think my end goal is to boot Linux on it–but for now I’ll settle for booting Das U-Boot. It’s definitely been an interesting journey, since I decided against using the Xilinx-specific git repositories for everything, and instead I used mainline checkouts wherever possible. In another post I’ll go through the hell it took to compile a working GCC with Glibc for little-endian Microblaze. But, in this post I wanted to point out something a little more devious.

Continue reading
Atlys FPGA reset shenanigans

Gameslab high-level design


I finally decided I might as well make an overall block diagram of the Gameslab system. I was working on changing the design schematics and realized I forgot a couple things. So, I made this block diagram to use as a checklist–makes sure I don’t forget pieces. It also helped to figure out which peripherals would connect to the Zynq PS versus the PL. For example, the LCD touch controller was originally connected to PS I2C pins, but the PL has to be enabled to use the LCD anyway. So, it made more sense to route the touch screen I2C bus through the EMIO.

Continue reading
Gameslab high-level design

Basic IBIS simulation with eispice


While working on the DDR3 interface of the re-imagined Gameslab, I wanted to do some simple sanity checks for signal integrity. Since I don’t really want to pay >$1000 for two PCBs with controlled impedance and a custom stackup, I just wanted to verify my cheap boards from PCB-POOL would work at all. PCB POOL lists the stackup for 6-layer boards on their site, so I plugged these specs into a trace impedance calculator. My best option so far looks like routing the high-speed DDR traces on the inner layers with a reference ground plane above each signal layer. I calculated the impedance at ~63 Ω. Since DDR3 has 34 Ω driver and typically 40 Ω transmission lines, I wanted to at least do a sanity check simulation.

Continue reading
Basic IBIS simulation with eispice

Copyright © 2017 Craig J Bishop