Over the past week I’ve been working on communicating with an SD Card using my custom SPI Controller. I’ve uncovered some bugs in the controller and begun having some success in communicating with the SD Card. A combination of unique SD Card behavior and a clock phasing bug meant I spent far too long debugging an unresponsive SD Card in the beginning stages of experimentation. Unlike a lot of the signal captures I’ve found online the SD Card I’m working with does not drive the DAT0 line high until it receives a valid CMD0 packet. My protocol analyzer was indicating that the packet I was sending out was a valid CMD0 yet nothing I did received any response from the SD Card. After lengthy debugging I looked closer at the serial data bus and found that my clock phasing was actually inverted. With the clock phasing fixed the SD Card now Drives high and responds with the expected idle response (0x01).
Aside from the bug fixes I’ve added the ability to trigger a single byte transfer from the SPI controller. This makes it much easier to prepare a data byte and send it out by removing the necessity to determine when the controller is going to poll the input bus. It’s still a bit cumbersome as I was unable to get my intended design to synthesize. I haven’t yet gotten a complete grasp on the details of the VHDL to hardware process which leads to some hiccups, but the code I have now is enough to establish communication. My current work is on another bug which is likely in the SPI Controller portion of my circuit. After receiving a card ready response (0x00) the MISO line turns into a 12kHz clock and the SD card loses synchronization.
The Serial Peripheral Interface (SPI) Bus is a full duplex synchronous serial communication standard. SPI is common in embedded applications due to it’s high throughput and relatively simple interface. This is a simple SPI controller implementation with an 8 bit word length and a single slave select line. Continue reading “FPGA: SPI Controller”
A video engineer, or really anybody who cares, would tell you that I’ve created a pretty inaccurate representation of the SMPTE color bar test pattern. As I’m not actually trying to calibrate any monitors I don’t fall into this category. I’ve modeled my test screen off of the Wikipedia description of SMPTE color bars. This project only generates a color simulation, ignoring the I and Q vectors, pluge pulse, and other underlying embedded signals. I’m satisfied with the results of this project and consider the original goal to be accomplished. Modifications to the code will most likely be required when it is integrated into the final NES project, but that is much farther down the road. The updated color generator code as well as a download link to the entire project are provided below. Continue reading “FPGA NES: VGA (Part 3)”
The heart of the VGA controller described in previous articles is a modified binary counter. The VHDL code provided below is a simple 4 bit counter with clock enable and reset inputs. The 4BitCounter_Test file provides a testbench to stimulate the counter and verify it’s operation.
A counter can also be implemented as an altium designer schematic, writing no VHDL, with little effort. In this case an 8 bit counter is used to simplify connection to the on board LEDs. A clock divider is used to create a 2 Hz clock signal to drive the counter. When uploaded to the FPGA board the LEDs will cycle indicating that the counter is working.
Both the VHDL files and designer schematic are available for download at the end of this post.
Previously a basic VGA controller was designed that had the capability to display a solid color across an entire computer monitor. This post builds on that design in an attempt to verify that the controller is able to correctly display more advanced patterns. In this example the code for the clock sub-circuit remained unchanged. However the color generator code was hacked up to create a moving 100 pixel horizontal and vertical bar. Color selection still works as before with the upper two bits now being used to enable or disable either bar. The animation of the bars works fairly well, however both bars are expected to be a solid color which is not the case as shown in the image below.
I’ve found the bug. It turns out I was not shutting off pixel color when the active pixel left the boundaries of the screen. The code has been modified with the changes from line 73-77. I believe the problem is related to the monitor expecting an absence of data during H-Blank. It looks as though the monitor may be setting the black level by averaging the voltages measured during H-Blank. A fade to black would occur with a persistent input signal if this were the case. This also explains why the vertical bar is unaffected.