This week, I’ve been testing a CI/CD pipeline. This has been my opportunity to shake the screws and kick the tires on what should become a new verification product shortly. I thought that a good design to check might be my SDIO project. It has roughly all the pieces in place, and so makes sense for an automated testing pipeline. This weekend, the CI project engineer shared with me: It’s literally the first time I get to know a good hardware project needs such many verifications and testings! There’s even a real SD card simulation model and RW test… After reminiscing about this for a bit, I t ..read more

I’ve come across two approaches to video synchronization. The first, used by a lot of the Xilinx IP I’ve come across, is to hold the video pipeline in reset until everything is ready and then release the resets (in the right and proper order) to get the design started. If something goes wrong, however, there’s no room for recovery. The second approach is the approach I like to use, which is to build video components that are inherently “stable”: 1) if they ever lose synchronization, they will naturally work their way back into synchronization, and 2) once synchronized they will not get out of ..read more

Ever had one of those problems where you were stuck for weeks? It’s not supposed to happen, but … it does. Let me tell you about the Kimos story so far. What is Kimos? Kimos is the name of one of the current open source projects I’m working on. The project is officially named the “Kintex-7 Memory controller, Open Source toolchain”, but the team shortened that to “KiMOS” and I’ve gotten to the point where I just call it “Kimos” (pronounced KEE-mos). The goals of the project are twofold. Test an Open Source DDR3 SDRAM memory controller. This includes both performance testing, and performance c ..read more

It should come as no surprise that a blog with no advertisements has never paid my bills–at least not directly. I blog for fun, and to some extent for rubber duck debugging. As I learn new concepts, I enjoy sharing them here. Going through the rigor to write about a topic also helps to make sure I understand the topic as well. Why are there no advertisements? For two reasons. First, because I’m not doing this to make money. Second, because because I want more control over any advertising from this site than most advertisers want to provide. Perhaps some day the site will be supported by advert ..read more

Fig 1. The KlusterLab board used for the 10Gb Ethernet Switch testing I’ve now been working with Symbiotic EDA and PCB Arts on a 10Gb Ethernet switch project for NetIdee for some time. Indeed, I’ve discussed this project several times on the blog. I first brought it up in the context of building a Virtual Packet FIFO. The topic then came up again during two articles on building an SDIO (SD-Card) controller: first when discussing how to build a Verilog test bench for it, and then again when discussing what bugs managed to slip past the verification, which then had to be caught in hardware ..read more

This post is the second post regarding my new SDIO/eMMC controller. The SDIO protocol is commonly used on SD cards, and the eMMC protocol for eMMC chips. The two protocols are so similar that, when using this controller, they will differ in software only. Today’s bottom line is that, although the controller is still quite new and only barely silicon proven, this week I had the chance to formally verify the receive portion of the controller and so I thought I might write about what took place. My goal will be to answer the question of whether this extra step of doing formal verification was wor ..read more

Fig 1. The KlusterLab board One of my current projects is to test and bring up a 10Gb Ethernet test board. The board has been fondly named the “KlusterLab”, because of all of the various interfaces present on it. Among those interfaces are an SD port and an eMMC port. Now, how shall I verify their functionality? Building an SDIO/eMMC Controller My first round of testing the SD port used my SPI-based SD card controller, SDSPI. Using that controller, the card responded in much the way I expected, save that the first sector of the card wasn’t what FATFS was expecting. Since this is simply bo ..read more

It’s time to announce a new version of the ZipCPU: ZipCPU v3.0! For reference, here’s how the ZipCPU’s development has taken place over the years: ZipCPU v0.1 Way back in the beginning, the ZipCPU had four bit opcodes and only 16x16-bit multiplies. It truly had a very limited instruction set. That said, the instruction set design was too limited to be very functional. This original instruction set didn’t even last a half a year. ZipCPU v1.0 The ZipCPU, v1.0, had 32-bit bytes and no octet level access. If you wanted to read or write an octet (8bit value) in memory, you needed to read a 32b word ..read more

I first came across virtual packet FIFOs in a SONAR project by necessity. The SONAR device’s only means of communicating with the outside world was via Gb Ethernet. There was no UART and no JTAG. Everything went over Ethernet. Collected data went over Ethernet. Device control was over Ethernet. Debugging had to be done over Ethernet. FPGA reconfiguration and all software updates had to go over Ethernet. Last of all, the CPU needed to talk to the outside world over Ethernet. This was where I first came up with the idea of a virtual packet FIFO. Fig 1. A Virtual Packets FIFO The idea came f ..read more

Central to the motivation behind the development of the ZipCPU is the concept of a System within a Chip (SwiC). As I’m now preparing the ZipCPU for a version 3.0 release, it’s worth revisiting this concept to see what it means and then to compare that with how the ZipCPU has been used in practice. Fig 1. A SwiC consists of a small CPU within a chip I have defined a SwiC to be a small soft-core CPU within a chip, but specifically where the CPU is neither the purpose of the chip nor the main application within it. Key to this definition is the requirement that the purpose of the chip is not ..read more