- 3D printing
- Aeon Dashboard
- CNC Machine 4
- Eagle libraries
- Eagle search
- Lighting Lego
- Making PCBs
- Two layer PCBs
- USB Switch 2
- USB Switch 3
- Microchip PIC
- Source code
In preparation for the write, I had a look at the timing - the read operation was taking twice as long as it needed to (it was reading in 50MHz, whereas it should be able to read at 100MHz). This would give me much more write bandwidth.
So, I did a bit of playing with the system, generating a video and a memory clock. Unfortunately, due to an unknown timing issue, I found that the memory clock had to be under 80MHz, and also the video clock an integer multiple of the memory clock.
As a result, the main clock is now 150MHz, with the memory reads taking two clock cycles (75MHz), and the video using three clock cycles (50MHz).
I was initially powering it from the Spartan 3E development kit - but I wanted it to have a separate power board, with a processor on it. For testing, I went for a PIC18F4620 (it's a very well featured chip, and runs at a resonable speed). For my car dashboard, it'll be replaced by an ARM.
This is a simple board with the PIC, and a 3.3V power supply on it. I also put some switches and status LEDs on it, in case I need something other than the display to tell me something's going on.
Using the real display
Instead of using my main 24" monitor, I got the monitor I wanted to use (or rather the type of monitor I was aiming at) - a 10" automotive display running at 800x600. I plugged in the VGA cable, and turned it on.
Out of range was the message that appeared. Damn - the 50MHz speed was too fast. A quick reprogramming of the chip to use a 40MHz video clock (and 80MHz memory clock - faster, yay!) made it work, albeit at a lower refresh rate (it should be 72Hz):
This display also has a slight blurry bit - this can be changed by adjusting the 'clock' setting, but this is what the automatic setting decided.
I've got an SPI bus to connect to a microcontroller (the FPGA will be a slave), but that would slow down the communication to the display. As a result, I decided that I needed a two-tier system, with an embedded processor on the FPGA to take the SPI commands and interpret them for display.
After a long think about it, and a bit of research, I went for the Xilinx PicoBlaze processor - this wouldn't allow me to implement a full display, but it would be able to do some simple things. What I'd like to do is for it to perform the following commands:
- Set current colour
- Fill rectangle
- Outline rectangle
- Draw bit pattern
- Draw byte sequence
- Plot pixel (although that could be a small rectangle)
- Draw horizontal and vertical line
If there's enough instructions left (only 1K is available), then maybe an arbitrary draw line instruction too.
Writing to the display
To test the PicoBlaze integration, I wrote some very simple code to just repeatedly write to the screen with an incrementing colour (which increments each frame filled).
This code looks like this:
addr0 EQU sC addr1 EQU sD addr2 EQU sE colour EQU sF lowaddr DSOUT $01 midaddr DSOUT $02 highaddr DSOUT $04 ocolour DSOUT $08 begin: DINT LOAD colour, $00 outerloop: LOAD addr0, $00 LOAD addr1, $00 LOAD addr2, $00 loop: OUT addr0, lowaddr OUT addr1, midaddr OUT addr2, highaddr OUT colour, ocolour ADD addr0, $01 ADDC addr1, $00 ADDC addr2, $00 COMP addr1, $53 JUMP NZ, loop COMP addr2, $07 JUMP NZ, loop ADD colour, $01 JUMP outerloop
I've used individual bits for the output port ID to signify the address it's writing to, and also the colour data. This very much simplifies the internal wiring.
I then did a fair amount of simulation to iron out little problems to do with the write buffer (I didn't have a way to test it), and then gave it a whirl. I was very pleased and surprised to see the screen change colour in the way that I had expected:
Current FPGA utilisation
In order to see if I can use an XC3S50A-144 for the 16-bit version, I'm keeping an eye on the utilisation figures. They currently stand at:
- Occupied slices: 382
- DCMs: 2
- RAMB16BWEs: 4
The XC3S50A has:
- Slices: 704
- DCMs: 2
- RAMB16BWEs: 3
The last one is a bit concerning - I could change the SPI FIFO to a slice-based FIFO, but that would end up using more slices. Luckily the FIFO doesn't need to be that big, since I've done a bit of cleverness that allows the controlling CPU to determine if it's full without issuing a write sequence (it's a zero-bit write).