Recognise this screen? It’s a little distorted, but it’s getting there!
I managed to create the ‘hardware shim’ that would allow the Verilog RTL to run on my new DE10-Nano. This is the first output from the RTL image. A few problems, but promising!
More to come….!
2017-05-08 Update
I managed to fix the problems with the image above. As expected, I’d broken the golden rule of FPGA development, only use registered data. That is, it’s OK to use combinational logic to create the data for output, but only use result of the combinational logic on a leading or trailing clock edge.
For example, this code was causing the errors above:
assign r = (en) ? ((pixels[pixel_pointer]) ? 8'hf8 : 8'h0) : 8'd0;
Pixels is an 8 bit register holding the pixel data, pixel pointer is a 3 wire bus counting up 0-7 and around again. In theory this would work (under simulation), but in practice the three wires of the bus may not all change at the same time and cause mis-counts, causing the bus to show odd sequences such as 011 to 111 to 100. I’ve written about this previously in my article on the need for Gray Codes.
Instead of a multiplexer (as above), I’m using a shift register to get the data out:
always @(negedge clk_i)
if ( pixel_x[2:0] == 3'd0 )
pixels <= {
...calculate pixel data...
};
else
pixels <= {pixels[1:7],1'b0}; // Shift out
// Combinational logic OK here as pixel data is registered
assign r = (en) ? ((pixels[0]) ? 8'hf8 : 8'h0) : 8'd0;
// HDMI clocks the value of the R/B/G signals on posedge of clk_i
This fixed the problem of the parallel busses counting incorrectly, but caused the display to shift across by 8 pixels as the pixel data took the time of 8 pixels to clock through the pipeline. I shifted the start of calculation to 8 pixels before the data enable (DE) HDMI signal, so by the time of the first pixel for the HDMI image, it was ready and out on the RGB data bus.
Here’s the new CPC2 image (no surprises).
Intelligent Toasters 