FPGA VGA Controller for 8-bit computer

[nockieboy]

I've updated the PS/2 interface to the Verilog-only version.  Have tweaked the original code a bit to get it sending break codes in the format I need for the Z80_bridge, and to cope with CTRL-C codes and CAPS LOCK.  Otherwise it's a pretty comprehensive module.

I've also stripped out some project files that are no longer used (including the old PS/2 VHDL stuff).

Compilation reports the following now:

• Total logic elements: 83%
• Total memory bits: 81%
• Fmax summary: clk[0] - 125.99 MHz, clk[1] - 266.31 MHz, clk[2] - 116.16 MHz

I have a couple of questions on the project so far:

• Fmax has dropped again (see red above) - any tips/advice on how to find bottlenecks?
• The pixel collision counters - why are they 8-bit and are they for detecting sprite collisions and/or something else?

EDIT:  Okay, I've got Fmax back up to 133.21 MHz for clk[0] by adding a FF between the status output of the PS/2 module and the input of the Z80_bridge. Woot. 

[BrianHG]

I have a couple of questions on the project so far:

• Fmax has dropped again (see red above) - any tips/advice on how to find bottlenecks?
• The pixel collision counters - why are they 8-bit and are they for detecting sprite collisions and/or something else?

1. Give me a sec.  For now, those figures are functional.  (YOU MODIFIED THE COMPILER SETTINGS...)

2a. I can switch them down to 1 bit (no collision, or yes, a hit) like a normal 8 bit computer if you like.
2b. We can also remove these collision counters completely since 8 bit computers since cant detect collisions when writing pixels in the first place. They have player missile and sprite collision detectors.  We have yet to add any collision detectors to the MAGGIE layers.  These are different.  Each layer will have a 16 bit register where each bit, 0 through total layer number which will go from 0 to 1 depending on a collision with each associated layer's pixel set to that bit#.  Once again, if you do not like this, we can make each layer have only a single bit collision detector telling you if it collided with anything at all like any 8 bit computer or Amiga.

[nockieboy]

I have a couple of questions on the project so far:

• Fmax has dropped again (see red above) - any tips/advice on how to find bottlenecks?
• The pixel collision counters - why are they 8-bit and are they for detecting sprite collisions and/or something else?

1. Give me a sec.  For now, those figures are functional.  (YOU MODIFIED THE COMPILER SETTINGS...)

Hmmm.. maybe - I added in the CYCLONE II setting you'd mentioned.  Anyway, as per my edit in my previous post, I've got Fmax back up to 133 MHz now. 

2a. I can switch them down to 1 bit (no collision, or yes, a hit) like a normal 8 bit computer if you like.
2b. We can also remove these collision counters completely since 8 bit computers since cant detect collisions when writing pixels in the first place. They have player missile and sprite collision detectors.  We have yet to add any collision detectors to the MAGGIE layers.  These are different.  Each layer will have a 16 bit register where each bit, 0 through total layer number which will go from 0 to 1 depending on a collision with each associated layer's pixel set to that bit#.  Once again, if you do not like this, we can make each layer have only a single bit collision detector telling you if it collided with anything at all like any 8 bit computer or Amiga.

I have no preference, really. I'll go with whatever you think is best.    They sound handy - I was just asking as I wasn't sure if they were for detecting sprite collisions or something else that I couldn't grasp. 

[BrianHG]

Here is the updated .zip.
Don't worry about how close the FMAX is, everything is set to area and you still have good clearance for the geometry unit with is the most mathematically intense part of your entire design.

I also patched the address generator back a revision as a simple 2 layer carry buffer was better than a FIFO.

The running plot line example I asked you for was to be able to send as many different line commands as possible.  The z80 is 8 bit, so, to send as many different x&y coordinates as possible, a simple add, 5 different add figures, 1 for each coordinate and 1 for a different color would plot a lot of different lines very quickly compared to generating 5 different random numbers for each line drawn.  This test would at least get you close to the speed of drawing geometry from cpu ram.

[BrianHG]

I have no preference, really. I'll go with whatever you think is best.    They sound handy - I was just asking as I wasn't sure if they were for detecting sprite collisions or something else that I couldn't grasp. 

Well, going down to a 1 bit collision counter will save 14 registers and a few gates on the FPGA.

The sprite collision detector needs to be done in the 'palette_mixer.sv' since that module receives all the different pixel layers in parallel before it chooses which dot from which layer ends up being the final pixel shown.

[nockieboy]

Here is the updated .zip.
Don't worry about how close the FMAX is, everything is set to area and you still have good clearance for the geometry unit with is the most mathematically intense part of your entire design.

I also patched the address generator back a revision as a simple 2 layer carry buffer was better than a FIFO.

Runs fine.  I've updated the Z80_bridge and ps2_keyboard_interface with some changes I'd made today, so here's the latest project files at the end of the post.

The running plot line example I asked you for was to be able to send as many different line commands as possible.  The z80 is 8 bit, so, to send as many different x&y coordinates as possible, a simple add, 5 different add figures, 1 for each coordinate and 1 for a different color would plot a lot of different lines very quickly compared to generating 5 different random numbers for each line drawn.  This test would at least get you close to the speed of drawing geometry from cpu ram.

Okay, well I can give this a shot tomorrow perhaps.  I really need to start looking at these triangle and circle functions too. 

[BrianHG]

The 2 key settings to get the FMAX to the top for this design:  This increases the the design back to 84% utilization.

[BrianHG]

Ready to go on the filled triangle.
Tell me what you have learned so far on the triangle.

[nockieboy]

Ready to go on the filled triangle.
Tell me what you have learned so far on the triangle.

Setup is key.  Three line generators operate on three sets of coordinates in the registers X[0]Y[0] to X[2]Y[2].  The three lines need to be ordered vertically in the registers so that register set

• (0) contains the longest vertical line,
• (1) contains the first line to finish (vertically), and
• (2) contains the last line which gets drawn after line (1) is finished and connects line(0) with line(1).

There's some extra drawing to ensure lines meet and there's no empty pixels at the edges.

 

[BrianHG]

Take a look at the basic code and recount the line generators.
There are a few tricks buried in this.

Separate out the steps involved in setting up and running each of the line generators.
Remember, we don't want to just add more and more line generators to our design, we the minimum necessary, meaning, even when calling a simple line, box, or box fill, we want to use the exact line generators as the filled triangle, is only the order and setup in which we run those few line generators.  Logic space is at a premium here.

Yes, even when we get to the ellipse, it will be an addition to one of the line generators which will have a adapted arc radius, or, drawing a triangle with 1 rounded face, 4 of them rotated 90 degrees from each other with the inner face line just not drawn.

[nockieboy]

Take a look at the basic code and recount the line generators.

D'oh.  There's only two.  One is re-used for the third line. 

Separate out the steps involved in setting up and running each of the line generators.

1) Order the lines so that the two line generators run on the first and third lines, with one line stopping and that line generator then drawing the second line.
2) Each line is setup by calculating its bounding box's width and height
3) Signs are calculated for the stepping increments according to the direction of the line
4) Key values are assigned to magic, errd and is_done to allow the line generator to run
5) Line generators are run, filling in horizontal raster lines between the two lines being drawn if fill mode is on

[BrianHG]

Take a look at the basic code and recount the line generators.

D'oh.  There's only two.  One is re-used for the third line. 

Separate out the steps involved in setting up and running each of the line generators.

1) Order the lines so that the two line generators run on the first and third lines, with one line stopping and that line generator then drawing the second line.
2) Each line is setup by calculating its bounding box's width and height
3) Signs are calculated for the stepping increments according to the direction of the line
4) Key values are assigned to magic, errd and is_done to allow the line generator to run
5) Line generators are run, filling in horizontal raster lines between the two lines being drawn if fill mode is on

Step #1 is more like the first linegen is the tallest vertical line.
Line #2 begins by touching the top of line #1.
Increment a Y pixel at a time for each line.
If there is empty space, draw a line (will be the linegen3 engine) between the X coordinates of linegen #1 and #2.
Loop around until lingen2 ends, the reset linegen2 with the lat 2 points on the triangle.

Currently, we have a dumb linegen3, but, we might as well replace it with a normal smart one.

Ok, what you said is ok, but, what we want is the order of operations before we start drawing, IE the setup, and what instructions to send to the linegens.

This organization step is important as with a variable setup and control, our triple linegen engine with the right setup controls will also replace our single linegen as well as out box, box-fill, 4 point polygon & fill, + ellipse.

[BrianHG]

I'm working on setting up your IO timing rules.  It's a mess as some buses cross IO banks and is f---ng things up.  I need to know what output pins you have set the led_rxd and led_txd.

When going to a higher pin count FPGA, you will need to read the datasheet and choose the IOs wisely, otherwise you wont get anywhere near good performance with external ram without a crap load of carry chains destroying the read-turn-around times.  And carry chains will not work if you have IO on opposite sides of the FPGA silicon or use the any one of the 4 slower IO banks out of the 8.

My biggest headache is with 4 IO which are dual purpose pins as they have also the ability to be a 'VREF' input, there are 4 of them.

[BrianHG]

Ok, this one took all day.  (Poor documentation from Altera/Intel)

I've setup your timing constraints.  To do so, I had to add additional delay pipe chains in the Z80 bridge, video out and a few other places, however now, Quartus is respecting the IO timings, core clock frequency & the Fast IO assignments now appear to function correctly.

It should now compile quickly & achieve the timing requirements filling the FPGA to only 76%.

If it were'nt for those 4 IOs on the vref pins, all your outputs would be within 300ps of each other.  Those 4 IOs are 1.3 ns slower than your slowest output.  Though, your DAC clk output is the fastest output at 25MHz.
Inputs are tight too except for the PS2 keyboard interface which wasn't engineered for speed.

I also changes the DAC CLK output to a synthesized 25MHz clock generated from the sync generators /5 of the 125MHz clk.

You'll need to test everything.  On my side, my DAC on my scaler wasn't designed to operate down to 25MHz, so I have a shaded bar on the left hand side of the screen.  Make sure you do not see this.

Let me know if everything works.

[nockieboy]

I'm working on setting up your IO timing rules.  It's a mess as some buses cross IO banks and is f---ng things up.  I need to know what output pins you have set the led_rxd and led_txd.

Uh, looks like their pin assignments got lost with the project going back and forth over the last couple of days.  I'm actually not using them - may as well remove the output pins. 

When going to a higher pin count FPGA, you will need to read the datasheet and choose the IOs wisely, otherwise you wont get anywhere near good performance with external ram without a crap load of carry chains destroying the read-turn-around times.  And carry chains will not work if you have IO on opposite sides of the FPGA silicon or use the any one of the 4 slower IO banks out of the 8.

I'm hoping I might have a little more flexibility in choosing which IOs to use in a BGA setup - or they'll all be as hard to route as each other - as the QFP package I'm using is fairly restrictive in terms of choice of IO pin due to their position on the package and what's physically near it on the PCB.

My biggest headache is with 4 IO which are dual purpose pins as they have also the ability to be a 'VREF' input, there are 4 of them.

Well I'm open to suggestions for the BGA iteration of the board.  I should steer clear of dual-purpose pins, then?

[nockieboy]

Ok, this one took all day.  (Poor documentation from Altera/Intel)

I've setup your timing constraints.  To do so, I had to add additional delay pipe chains in the Z80 bridge, video out and a few other places, however now, Quartus is respecting the IO timings, core clock frequency & the Fast IO assignments now appear to function correctly.

It should now compile quickly & achieve the timing requirements filling the FPGA to only 76%.

If it were'nt for those 4 IOs on the vref pins, all your outputs would be within 300ps of each other.  Those 4 IOs are 1.3 ns slower than your slowest output.  Though, your DAC clk output is the fastest output at 25MHz.

I'm not going to cry over 1.3ns unless it causes issues later, but this design has outgrown the EP4CE10 a lot faster than I thought it would - it really does appear that BGA is the way to go.

I had a look around at various packages and models in the Cyclone range last night.  I had pretty much decided on the EP4CE22F17 as the next step - though I'm wondering if the jump straight to an EP4CE40 might be worth it.  That's an FBGA-484 package, though - perhaps that should wait until I've developed some skill with the FBGA-256 first.

I guess I was just wondering what's in the ball-park of realistic home-DIY soldering (and PCB design)?  Is an FBGA-484 too much?  Then there's the Cyclone V range.  The smallest one appears to have over 150 KB of RAM and 40% lower power usage, and I can get it in FBGA-256 (5CEBA4F17 - https://uk.rs-online.com/web/p/fpgas/8303565/).

Talking of power usage, I've fitted a heatsink over the 1.2V regulator now.  It's still almost too hot to touch, but it makes me feel happier. 

You'll need to test everything.  On my side, my DAC on my scaler wasn't designed to operate down to 25MHz, so I have a shaded bar on the left hand side of the screen.  Make sure you do not see this.

Let me know if everything works.

It all works with no anomalies or glitching. None of the tests have thrown up issues, there's no shaded bar down the side of the screen, it all looks good. 

[BrianHG]

I had a look around at various packages and models in the Cyclone range last night.  I had pretty much decided on the EP4CE22F17 as the next step - though I'm wondering if the jump straight to an EP4CE40 might be worth it.  That's an FBGA-484 package, though - perhaps that should wait until I've developed some skill with the FBGA-256 first.

Before jumping to really expensive FPGAs, look at this post here:

https://www.eevblog.com/forum/fpga/quartus-prime-18-1-cant-fit-design-in-device/msg3178780/#msg3178780

A little research might reveal what you are getting at what price.

I'm not going to cry over 1.3ns unless it causes issues later, but this design has outgrown the EP4CE10 a lot faster than I thought it would - it really does appear that BGA is the way to go.

No problem on this design as everything is slower than 40ns for VGA out, 125ns/2 for Z80_CLK.  But if you want 250MHz DDR ram, IE 500mtps, that 1.2ns on 1 or 2 specific pins in each IO bank would potentially be disastrous.  Or not using the dedicated PLL CLK & CLKn output pins to drive the memories CLK inputs.

[BrianHG]

Ok, lets see your triple line drawing engine.

[nockieboy]

Ok, lets see your triple line drawing engine.

Hmmm well, my first question in writing this function is that as it uses two line drawing engines, how best do I utilise the existing line-drawing engine in the geometry_xy_plotter module?   Do I need to create it as a sub-module and instantiate it for use in the triangle function, or can I somehow re-use the existing function?

Code: [Select]

4'd1 : begin    // draw line from (x[0],y[0]) to (x[1],y[1])
 
case (geo_sub_func1)    // during the draw line, we have multiple sub-functions to call 1 at a time

4'd0 : begin

errd            <= dx + dy;
geo_sub_func1   <= 4'd1;                 // set line sub-function to plot line.

end // geo_sub_func1 = 0 - setup for plot line

4'd1 : begin

draw_cmd_func        <= CMD_OUT_PXWRI[3:0]; // Set up command to pixel plotter to write a pixel,
draw_cmd_data_color  <= geo_color;          // ... in geo_colour,
draw_cmd_data_word_Y <= geo_y ;             // ... at Y-coordinate,
draw_cmd_data_word_X <= geo_x ;             // ... and X-coordinate.

if ( ( geo_x >= 0 && geo_x <= max_x ) && (geo_y>=0 && geo_y<=max_y) )
draw_cmd_tx     <= 1'b1;            // send command if geo_X&Y are within valid drawing area
else
draw_cmd_tx     <= 1'b0;            // otherwise turn off draw command

if ( geo_x == x[1] && geo_y == y[1] ) geo_shape <= 4'd0;   // last pixel - step to last sub_func1 stage, allowing time for this pixel to be written
// On the next clock, end the drawing-line function
 
// increment x,y position
if ( ( errd << 1 ) > dy ) begin

  geo_x   <= geo_x + geo_xdir;
 
  if ( ( ( errd << 1 ) + dy ) < dx ) begin
 
geo_y   <= geo_y + geo_ydir ;
errd    <= errd + dx + dy   ;

  end else begin
 
errd    <= errd + dy   ;

  end
 
end else if ( ( errd << 1 ) < dx ) begin
  errd    <= errd  + dx       ;
  geo_y   <= geo_y + geo_ydir ;                           
end

end // geo_sub_func1 = 1 - plot line

endcase // sub functions of draw line
 
end // geo_shape - draw line

[BrianHG]

Ok, lets see your triple line drawing engine.

Hmmm well, my first question in writing this function is that as it uses two line drawing engines, how best do I utilise the existing line-drawing engine in the geometry_xy_plotter module?   Do I need to create it as a sub-module and instantiate it for use in the triangle function, or can I somehow re-use the existing function?

Code: [Select]

4'd1 : begin    // draw line from (x[0],y[0]) to (x[1],y[1])
 
case (geo_sub_func1)    // during the draw line, we have multiple sub-functions to call 1 at a time

4'd0 : begin

errd            <= dx + dy;
geo_sub_func1   <= 4'd1;                 // set line sub-function to plot line.

end // geo_sub_func1 = 0 - setup for plot line

4'd1 : begin

draw_cmd_func        <= CMD_OUT_PXWRI[3:0]; // Set up command to pixel plotter to write a pixel,
draw_cmd_data_color  <= geo_color;          // ... in geo_colour,
draw_cmd_data_word_Y <= geo_y ;             // ... at Y-coordinate,
draw_cmd_data_word_X <= geo_x ;             // ... and X-coordinate.

if ( ( geo_x >= 0 && geo_x <= max_x ) && (geo_y>=0 && geo_y<=max_y) )
draw_cmd_tx     <= 1'b1;            // send command if geo_X&Y are within valid drawing area
else
draw_cmd_tx     <= 1'b0;            // otherwise turn off draw command

if ( geo_x == x[1] && geo_y == y[1] ) geo_shape <= 4'd0;   // last pixel - step to last sub_func1 stage, allowing time for this pixel to be written
// On the next clock, end the drawing-line function
 
// increment x,y position
if ( ( errd << 1 ) > dy ) begin

  geo_x   <= geo_x + geo_xdir;
 
  if ( ( ( errd << 1 ) + dy ) < dx ) begin
 
geo_y   <= geo_y + geo_ydir ;
errd    <= errd + dx + dy   ;

  end else begin
 
errd    <= errd + dy   ;

  end
 
end else if ( ( errd << 1 ) < dx ) begin
  errd    <= errd  + dx       ;
  geo_y   <= geo_y + geo_ydir ;                           
end

end // geo_sub_func1 = 1 - plot line

endcase // sub functions of draw line
 
end // geo_shape - draw line

You can:
A) Make 1 module which runs on arrays.
B) Copy and paste the line to make 3 of them.
C) Make a new module which you can call 3 times.

Before all this, there is some mathematical prep work which needs to be taken care of.  One big part and FMAX killer is determining which arrays have equal X, or Y coordinates.  What are the array groups order from low to high on the Y  axis and also X axis.  Prep up these flags creating a status array so you know which line functions draw what and in what order.  Remember, you have 4 sets of coordinated to compare.  This should all be prepared in advance before the draw command is even being given since the any and all X&Y coordinates are being sent in advance of the draw command.

[BrianHG]

I am talking about you making a module which takes in X[0..3] or Y[0..3] and returns all the point which are equal, greater than and less than in 3 arrays which can easily be checked/used to select which lingen should be used (IE: if all X & Y coordinates on the 3 vertices are equal, no lingen will be used, just draw a point), each of those linegen's source and destination X[?]&Y[?] coordinates and select whether to add or subtract the x&y counter (x&y dir) in each linegen module's arithmetic.

[BrianHG]

I guess I was just wondering what's in the ball-park of realistic home-DIY soldering (and PCB design)?  Is an FBGA-484 too much?  Then there's the Cyclone V range.  The smallest one appears to have over 150 KB of RAM and 40% lower power usage, and I can get it in FBGA-256 (5CEBA4F17 - https://uk.rs-online.com/web/p/fpgas/8303565/).

The '5CEBA2F17C8N' may actually be identical to the 5CEBA4F17 just like the EP4CE6 is identical to the EP4CE10...

[nockieboy]

I am talking about you making a module which takes in X[0..3] or Y[0..3] and returns all the point which are equal, greater than and less than in 3 arrays which can easily be checked/used to select which lingen should be used (IE: if all X & Y coordinates on the 3 vertices are equal, no lingen will be used, just draw a point), each of those linegen's source and destination X[?]&Y[?] coordinates and select whether to add or subtract the x&y counter (x&y dir) in each linegen module's arithmetic.

Hmm.. well, this is what I've got at the moment.  It's taken straight from the FreeBasic geo program to set up the order of lines to be drawn.  It's not what you're asking for though, by the looks of it.  It doesn't do the sign (x & y dir) yet, but I'm not sure I'm on the right path anway..... it sounds like you want a module that returns three arrays - equal, greater than and less than - with the coordinates ordered accordingly and a sign flag for the use of another module?

[nockieboy]

I guess I was just wondering what's in the ball-park of realistic home-DIY soldering (and PCB design)?  Is an FBGA-484 too much?  Then there's the Cyclone V range.  The smallest one appears to have over 150 KB of RAM and 40% lower power usage, and I can get it in FBGA-256 (5CEBA4F17 - https://uk.rs-online.com/web/p/fpgas/8303565/).

The '5CEBA2F17C8N' may actually be identical to the 5CEBA4F17 just like the EP4CE6 is identical to the EP4CE10...

Right, so let me get this straight - the EP4CE6 and EP4CE10 are physically identical - it's the Quartus software that artificially limits the capabilities of the CE6 chip?  Potentially the only difference in the chips is the model identifier or some fuse setting? Interesting.

[BrianHG]

Potentially the only difference in the chips is the model identifier or some fuse setting? Interesting.

No fuse identifier.  Didn't you not see the jtag scan of the chip in the last post.  Quartus could not tell whether the installed FPGA it was scanning was an EP4CE10, or a EP4CE6.  Look at the picture in the last post.  In fact, it also couldn't tell in that same FPGA was a CycloneIII EP3C5 or EP3C10.