FPGA VGA Controller for 8-bit computer

[BrianHG]

Quartus lpm_fifo setup for feeding the geometry_xy_plotter input:

Here, your 16 bit output port will feed the lpm_fifo  data.
Your chosen high or low output port data strobe will be tied to the lpm_fifo wrreq.
(You will decide which output port byte you want to feed first, even or odd, and use the second one's data strobe to tie to the lpm_fifo's wrreq).
You will also tie the lpm_fifo's 'almost_full' output to a chosen bit in one of the 4 input ports.  Before sending data to the lpm_fifo unit for the geometry unit, test this bit to make sure you arent writing into a full fifo.

The lpm_fifo data out 'q' should go to the geometry_xy_plotter cmd_data.
The lpm_fifo's output empty should be INVERTED and && the geometry units load_cmd, also && with !draw_busy then fed into the geometry unit's cmd_rdy input and it should also feed the lpm_fifo's rdreq input.

The lpm_fifo sclr should be tied to the reset signal.

[BrianHG]

Here, I vastly simplified the LPM_FIFO so you may insert it directly into the geometry_xy_plotter.sv

Code: [Select]

scfifo scfifo_component (
              .sclr        (rst),                   // reset input
              .clock       (clk),                   // system clock
              .wrreq       (fifo_cmd_rdy),          // connect this to the 'strobe' on the selected high.low Z80 bus output port.
              .data        (fifo_cmd_in),           // connect this to the 16 bit output port on the Z80 bus.
              .almost_full (fifo_cmd_busy),         // send to a selected bit on the Z80 status read port

              .empty       (fifo_cmd_rdy_n),         // remember, when low, the FIFO has commands for the geometry unit to process
              .rdreq       (load_cmd && !draw_busy), // connect to the listed inputs.
              .q           (geo_cmd_data),           // to geometry_xy_plotter cmd_data input.
              .full        ()                        // optional, unused
              );
     defparam
          scfifo_component.add_ram_output_register = "ON",
          scfifo_component.almost_full_value = 510,
          scfifo_component.intended_device_family = "Cyclone III",
          scfifo_component.lpm_hint = "RAM_BLOCK_TYPE=M9K",
          scfifo_component.lpm_numwords = 512,
          scfifo_component.lpm_showahead = "ON",
          scfifo_component.lpm_type = "scfifo",
          scfifo_component.lpm_width = 16,
          scfifo_component.lpm_widthu = 9,
          scfifo_component.overflow_checking = "ON",
          scfifo_component.underflow_checking = "ON",
          scfifo_component.use_eab = "ON";

Remember, now your geometry modules inputs drive the fifo directly.  The the fifo outputs will drive the rest of the geometry unit.  You will need to make an additional output for the 'fifo_cmd_busy' to tell the Z80 that it has to wait before adding instructions.

fifo_cmd_rdy_n will need to be inverted and && with (load_cmd && !draw_busy) before being sent to the geometry units internal 'cmd_ready'.

[BrianHG]

Ok, here comes the pixel_writer.sv

Now, you will need the command inputs:
clk, reset,
cmd_in[39:0], cmd_rdy which come from the 3 word fifo's data out and fifo_not_empty.

Command outputs:
next_cmd which drives the 3 word fifo's shift_out

Next you will need these memory access port IO which feeds the data_mux_geo I prepared for you.
Inputs:
rd_data_in[15:0]  this gets wired to the data_out_geo[15:0] on the  data_mux_geo
rd_data_rdy_a  this gets wired to the geo_rd_rdy_a on the  data_mux_geo
rd_data_rdy_b  this gets wired to the geo_rd_rdy_b on the  data_mux_geo
ram_mux_busy   this gets wired to the geo_port_full on the data_mux_geo

Outputs:
rd_req_a  this gets wired to the geo_rd_req_a on the  data_mux_geo
rd_req_b  this gets wired to the geo_rd_req_b on the  data_mux_geo
wr_ena    this gets wired to the geo_wr_ena on the  data_mux_geo
ram_addr[19:0]  this gets wired to the address_geo on the data_mux_geo
ram_wr_data[15:0] this gets wired to the data_in_geo on the data_mux_geo

Collision saturation counters IO:
outputs:
collision_rd[7:0]  this feeds 1 read port on the Z80_bridge_v2
collision_wr[7:0]  this feeds a second read port on the Z80_bridge_v2
inputs:
collision_rd_rst, collision_wr_rst - these 2 inputs will be connected to their associated read port's read strobe so they will be automatically cleared after they have been read.

The collision counter will count up to 255, and stop on 255.  This is what is meant by a saturation counter.

When reading a pixel (copy pixel), it will be checked if that address has already been read, if not, the appropriate rd_req_a will be sent out.  When the data comes in by the rd_data_rdy_a, the 16 bit word will be held and the new addressed for that cached 16bit word will be updated.  This is done so if a read of the same address is done again, no rd_req_a is required, we already have the data.  Remember to hold the color setting(an optional read transparency function), sub-pixel address and bits_per_pixel setting as they are needed to convert the read pixel to a value for the paste write pixel.

When any write pixel is done, first the ram address needs to be read into it's own 16 bit word cache (if necessary) just like the read pixel except you will use the rd_req_b channel.  (Makes the latching of read data easy to separate between the 2 different read destinations)  Once you have the valid data in the write pixel's read cache, you will then edit the correct bits depending on the type of pixel write and then do a 'wr_ena'.  (Basically the wr_ena is being held off until the 2 16 bit word caches have valid read data)  Plus, if the write address = the current copy_pixel read_address cache's 16 bit word, you will simultaneously copy the 16 bit write data (just the changes bits) into the copy_pixel read cache's 16 bit word.

Now, it's all in the edit.  This is where you look at you settings, bits per pixel & pixel types, and transparency settings and decide what to change the write pixel 16bit data to when sending out the wr_ena.
This will depend on color setting, write bits per pixel and sub-pixel offset.
Also, depending on transparency settings with copy pixel, and source data, you may edit the write pixel data, or just skip the write.

Also remember, when doing a copy & paste from a low color bitmap like 2 colors, to a high bitmap, like 256 colors, you should multiply the supplied 8 bit color value with the write-paste command's read lower color source pixel.  This way, you can paint a 2 color image, like a B&W paint brush image of a circle, to any new color you like.  Using the mask feature means you can do accelerated painting of low color images to the screen with more colors with a new color choice, with optional color 0 transparency (paste 'mask' feature).  Masked out pixels during a paste-mask will not add or count to the write pixel collision counter.

Remember, though rare, it is still possible to fill the data_mux_geo's fifo, so when reading and writing bytes, you may need to pause based on the ram_mux_busy input.

As for the collision counters, the read collision counts if the read data does not equal the set read color.
As for the write pixel collision, it increments if a pixel writes over a non-0 color pixel.  Remember that a write does not take place from a copy source if that source has a transparent color on it's read pixel.

(I would clearly simulate this one module in it's own project)

A little more to come....

[BrianHG]

Last (after triangle fill and ellipse/ellipse fill), adding an X/Y block copy function to the geometry_xy_plotter.

This will copy a rectangular block from source A to destination B with all the fancy features listed in the pixel writer.

Running the copy command will do just that with the optional transparency mask settings and destination color multiplier.

This code should have it's own defined arrays so you will be able to update and replace the line and ellipse function write pixel with a trigger of the copy command using the write pixel coordinates to set the destination B coordinates so that you may paint lines and ellipses with a stored brush such as a 2 bit color circle.  This way, you can make thick lines and thick circles.  Extended example, angular shaded lines stored in the copy's source would generate a shadow effect on drawn lines and ellipses.

[nockieboy]

Whoah steady tiger, I'm still trying to get the pixel_address_generator finished. 

Also, what's the 'target_bit'?
In the comb section, you can make it:
target_bit = x[3:0];

Is that all that's required for it?

Are these outputs...

Code: [Select]

    output logic[3:0]  memory_rw_bit_size,
    output logic[3:0]  memory_rw_bit_offset
...unnecessary or will I need to pass the extra information here:

Now I just need to move bit 0 of the address_offset into target_byte, take the remainder and place that in target_bit, then zero the last bit of address_offset?

...into those two outputs?

At the moment, I don't seem to be doing anything with the lost bits (the remainder) when I right-shift the address_offsets by LUT_bits_to_shift?  Unleeeesss... oh - that'll be because target_bit is being set by the raw x[3:0] value?

Just so I'm on the same page, the target_byte and target_bit that I spoke about in my quote above - these are both handled by target_bit[3:0] in the code?

Wouldn't it be better to change this:

Code: [Select]

target_bit      = x[3:0]         ;
... to this :

Code: [Select]

target_bit      = draw_cmd[3:0];
I guess it won't make much difference in the HDL, but seems to cut out the 'middle man' as x[] is derived from draw_cmd[] anyway?

Make sure this module works and now begin the pixel writer.

You make it sound so easy.

[BrianHG]

Ok, you are curently telling the pixel writer the:

pixel_cmd[27:24] <= dest_bits_per_pixel[3:0]; 

This tells the pixel writer that a pixel is:
1 bit wide,
2 bits wide,
4 bits wide,
8 bits wide, or
16 bits wide.

Now, to work, the pixel writer needs a second bit of information.  Remember when we set the video source or destination to 1 bit per pixel, the:
( y * dest_rast_width[15:0] + x ) << 1 ) >> LUT_bits_to_shift[dest_bits_per_pixel[3:0]]
is effectively divided by 16 (since we are eventually muting bit 0 in the address).

Now, since the address stays the same for every 16 pixels when in 1 bit pixel mode, we need to sub-shifts to the right bit position every 16 coordinates on the X/Y axis when in that 1 bit per pixel mode.  The pixel writer still needs that sub-position location which shifts by 1 every 1 pixels while the provided address stays the same for every 16 pixels.

This is the:
pixel_cmd[23:20] <= target_bit;  (You actually need 2 of them, a dest & srce target bit)

When in 1 bit mode, the pixel writer/reader will concentrate on the first 4 bits of the X coordinate which was lost from the address generator which was divided by 16 meaning:

dest_target_bit[3:0] = ( y * dest_rast_width[15:0] + x ) && 4'b1111;
srce_target_bit[3:0] = ( y * srce_rast_width[15:0] + x ) && 4'b1111;

Now, if x=0, the pixel writer knows to edit bits 15 in 1 bit mode.
Now, if x=1, the pixel writer knows to edit bits 14 in 1 bit mode.
Now, if x=2, the pixel writer knows to edit bits 13 in 1 bit mode.
Now, if x=3, the pixel writer knows to edit bits 12 in 1 bit mode.
Now, if x=4, the pixel writer knows to edit bits 11 in 1 bit mode.

In 2 bit mode, the pixel write knows to pay attention to the bottom 3 bits of the srce/dest_target_bit[3:0].
Now, if x=0, the pixel writer knows to edit bits 15..14 in 2 bit mode.
Now, if x=1, the pixel writer knows to edit bits 13..12 in 2 bit mode.
Now, if x=2, the pixel writer knows to edit bits 11..10 in 2 bit mode.
Now, if x=3, the pixel writer knows to edit bits 9..8 in 2 bit mode.
Now, if x=4, the pixel writer knows to edit bits 7..6 in 2 bit mode.

In 4 bit mode, the pixel write knows to pay attention to the bottom 2 bits of the srce/dest_target_bit[3:0].
Now, if x=0, the pixel writer knows to edit bits 15..12 in 4 bit mode.
Now, if x=1, the pixel writer knows to edit bits 11..8 in 4 bit mode.
Now, if x=2, the pixel writer knows to edit bits 7..4 in 4 bit mode.
Now, if x=3, the pixel writer knows to edit bits 3..0 in 4 bit mode.
Now, if x=4, the pixel writer knows to edit bits 15..12 in 4 bit mode.  (remember, only the bottom 2 bits of x is used)

In 8 bit mode, the pixel write knows to pay attention to the bottom 1 bit of the srce/dest_target_bit[3:0].
Now, if x=0, the pixel writer knows to edit bits 15..8 in 8 bit mode.
Now, if x=1, the pixel writer knows to edit bits 7..0 in 8 bit mode.
Now, if x=2, the pixel writer knows to edit bits 15..8 in 8 bit mode.
Now, if x=3, the pixel writer knows to edit bits 7..0 in 8 bit mode.
Now, if x=4, the pixel writer knows to edit bits 15..8 in 8 bit mode.

In 16 bit mode, the pixel write knows to ignore the srce/dest_target_bit[3:0].
Now, if x=0, the pixel writer knows to edit all bits 15..0 in 16 bit mode.
Now, if x=1, the pixel writer knows to edit all bits 15..0 in 16 bit mode.

You've sort of done this before.  Take a look at your 'bart.v' source code. It has:
colour_mode_in[2:0], similar to srce/dest_bits_per_pixel[3:0] with different values.
The difference is that it works using only the bottom 3 bits of the X coordinate, and in it works it's way toward bit x[2] as the bits per pixel increases.

With our pixel writer, we we work toward the bottom of the X coordinate bit, down to bit X[0] when we go up to 8 bit color and ignoring the srce/dest_target_bit all together when operating in 16 bit mode.


Like this: (beginning of lines 109, get rid of line 107)

Code: [Select]

    dest_base_address_offset = ( ( y * dest_rast_width[15:0] + x ) << 1 ) >> LUT_bits_to_shift[dest_bits_per_pixel[3:0]] ;
    srce_base_address_offset = ( ( y * srce_rast_width[15:0] + x ) << 1 ) >> LUT_bits_to_shift[srce_bits_per_pixel[3:0]] ;
    dest_target_bit[3:0] = ( y * dest_rast_width[15:0] + x ) && 4'b1111;
    srce_target_bit[3:0] = ( y * srce_rast_width[15:0] + x ) && 4'b1111;


[nockieboy]

Aha, thanks for the clarification.   Now that last missing piece is in, it's making a lot more sense to me as it correlates 1:1 with the algorithm outlined in my earlier post.

I've removed these outputs as you haven't confirmed they're needed and, as far as I understand it all, they're not needed anyway.

Code: [Select]

    output logic[3:0]  memory_rw_bit_size,  // ***** ARE THESE NEEDED ANYMORE? *****
    output logic[3:0]  memory_rw_bit_offset // ***** ARE THESE NEEDED ANYMORE? *****

Okay, so the attached code for the pixel_address_generator (PAGE or PAGET I guess, if we're naming everything Amiga-style) should be the complete article.

I'll get started on simulating next.

[BrianHG]

Sorry, my little booboo...

    dest_target_bit[3:0]     = ( y * dest_rast_width[15:0] + x ) && 4'b1111 ;
    srce_target_bit[3:0]     = ( y * srce_rast_width[15:0] + x ) && 4'b1111 ;

I had 3 1's, not the proper 4...
looks finished...

Hurry up, tomorrow may be my last day.

[BrianHG]

Code: [Select]

    output logic[3:0]  memory_rw_bit_size,  // ***** ARE THESE NEEDED ANYMORE? *****
    output logic[3:0]  memory_rw_bit_offset // ***** ARE THESE NEEDED ANYMORE? *****


No, they are not needed anymore.

[nockieboy]

Ironically I'd noticed the mistake in your post, but forgot to correct it when I updated the code! 

I'm running on pure coffee at the moment, so these tests may be a bit 'spray n pray'. 

Quick question - how do I get the Vector Waveform to simulate longer than 1000ns?  Can't seem to find an option that changes it - have tried Assignments/Settings/Simulator Settings/Simulation Period - End Simulation at:  but it doesn't seem to make a difference to the length of the .vwf file.

[BrianHG]

Open the .vwf. Then just
Go to 'Edit / End Time' in the normal 'Edit' menu.

Any signals you have already drawn will just repeat.
Only go around 10x as the longer you make it, the more time to simulate.
Also, once you have an initial .vwf, go to 'Assignment sertings / Simulator Settings '
and change 'Timing Simulation' to 'functional simulation'.

To get access to adding/removing IO pin labels, you may need to initially do a compile first.

[nockieboy]

Hmm.. okay, here's my test project.  I've connected up the pixel_address_generator in the schematic, I've compiled the whole project, then generated a functional simulation netlist before going to geo3.vwf and trying to add signals.

I can only seem to find signals relating to the geometry_xy_plotter. 

Oh, hang on - I need output pins for the pixel_cmd bus? D'oh!

[BrianHG]

You can change the parameter LUT_bits_to_shift to a localparam as it will not be something you would adjust...
Finish the simulation with output pins and see the results after setting the new bitmap controls.
You really jumped the gun....
I would generate output pins decomposing the address generator's output data into:
cmd ready
cmd function[3..0]
address[19..0]
color[7..0]
bits per pixel[3..0]
bit offset[3..0]

[BrianHG]

also include the intermediary output between the geometry_xy_plotter and address generator so you may see what's getting passed through.  This may be done with signal tap, you do not necessarily need output pins unless Quartus has simplified out you module's signal names.

[nockieboy]

Okay, I've got as far as setting up the test environment - I just need to work out the commands to send to the geometry plotter and insert them into the .vwf.

This is about all I can manage today, work calls - will have to come back to it tomorrow morning now.   

[nockieboy]

Think there's a problem with the above project setup.  I'm not getting any draw commands out of the geo_plotter. 

[BrianHG]

You were missing an important input pin:


Right ow you have an FMAX problem reaching only 60MHz in the address generator, however continue your verification work.
I'll upload a 2 stage piped address generator tonight which will get it up to 125MHz.

It that we are asking the cyclone to calculate (y*width+x)>>shifted + base_address all in a single clock.
Piping means breaking this down into 2 steps meaning the output will be delayed by 1 clock.  Doing this means all the address generator's cmd outputs which are assigned in a single clock need to be delayed by an additional clock.  I'm sure this will be puzzling as the command input will need to pipe along in 2 stages as well.

I doubt such piping will be necessary in the pixel_writer as all it needs to do is manipulate a 16bit word with a bunch of small conditions attached.

[BrianHG]

Geometry_xy_plotter, line 369.  I had to add this:

Code: [Select]

        end else   draw_cmd_tx <= 1'b0;    // stop transmit output command function//  end of (geo_run) flag
Without ending the draw_cmd_tx, after sending 'CMD_OUT_DSTRWDTH', the output went on indefinately.

Also in your current address generator, lines 72-79:

Code: [Select]

// CMD_OUT:
// bit 3 = COLOUR (HIGH for colour data included, LOW for none)
// bit 2 = WRITE bit (HIGH for WR, LOW for RD)
// bit 1 = TRANSPARENT bit (HIGH for transparent mask, LOW for none, ignored if bit 35 is LOW)
// bit 0 = READ/MODIFY/WRITE (ignored if bit 2 is LOW)
localparam CMD_OUT_WRITE_PIXEL_COLOUR   = 4'b1100 ;
localparam CMD_OUT_WRITE_PIXEL_MASK     = 4'b1110 ;
localparam CMD_OUT_READ_PIXEL           = 4'b0000 ;
3 commands? And read pixel is command 0, usually reserved for nop.
Read the '           case (aux_cmd_in)' at line 132.
Each command has it's own pixel write function.  It's in the actual CMD_IN_PX??.

Here, this is better:

Code: [Select]

// CMD_OUT:
localparam CMD_OUT_NOP           = 0;
localparam CMD_OUT_PXWRI         = 1;
localparam CMD_OUT_PXWRI_M       = 2;
localparam CMD_OUT_PXPASTE       = 3;
localparam CMD_OUT_PXPASTE_M     = 4;
localparam CMD_OUT_PXCOPY        = 6;

Ok, I fixed up a few other things and cleaned up the order of the formulas for better reading and it will give me some leg room to optimize the FMAX.
Here is the latest sim:


Also, I've attached the latest simulation complete project with both updated source codes.  The only issue is that the compiled FMAX is 70MHz, but we require 125MHz.  I'll improve the FMAX in a few hours.

[BrianHG]

Ok, here you go:


As you see, the output of the address generator is now delayed by 2 clocks instead of the usual 1 clock.

With this change, the FMAX has reached 134MHz, good enough for your 125MHz core.

I've attached the new simulation test bench with the new source code changes.

[BrianHG]

You are just missing the 'scfifo   scfifo_component' at the beginning of the geometry_xy_plotter command input.

Time to make the pixel_writer.
Do not attach it to the geometry project, make a whole new Quartus simulation project to develop it, all by itself.  It has so few commands and IO to check all on it's own.

Also, remember when adding the new Z80 input and output ports, you have a full simulation test bench ready which I made you last time to verify the new ports work and the single clock 'strobe' output for each port when they are accessed.

[BrianHG]

Oooops, a little bug in some of the commands in the new address_generator.
Some of the second sequence clocked ( s2_ ) functions were getting their data from the first clock stage.
No difference on the above simulation as these functions were never called.

You also didn't properly pass these commands to the pixel_writer.

The new FMAX limit of 134MHz is now restricted by logic inside the geometry_xy_plotter.
(I updated the simulation test bench Quartus project above...)

[nockieboy]

Latest geometry_xy_plotter attached, with scfifo added and (hopefully) wired in correctly.

EDIT: Also added the geo_pixel_writer file - currently only consists of module declaration and I/O as you've specified.  Hopefully all correct so far.

[BrianHG]

Latest geometry_xy_plotter attached, with scfifo added and (hopefully) wired in correctly.

Well, does it simulate.  (I think not as it doesn't compile)
It should still simulate when running through a FIFO inside.

Also, this line:

Code: [Select]

    .sclr        (rst),                    // reset input
Do you have a 'rst' input wire?  It should be called 'reset'.

Code: [Select]

    .wrreq       (fifo_cmd_rdy),           // connect this to the 'strobe' on the selected high.low Z80 bus output port.
' _rdy ', not ' _ready '  ?

You also need these 2 before the FIFO:

Code: [Select]

logic [15:0] cmd_data;
logic        fifo_cmd_rdy_n;
I've added the ' !fifo_cmd_rdy_n ' to this line in the fifo:

Code: [Select]

    .rdreq       (load_cmd && !draw_busy && !fifo_cmd_rdy_n), // connect to the listed inputs.
It's just another check to prevent a read if the fifo is empty.

Ok, I've made the changes & it finally simulates properly.  Your geometry_xy_plotter now has a 510 word instruction cache which you might never be able to fill up with a slow 8 MHz Z80 unless all you are doing is non-stop 16bit color full screen copy & fills.

Don't forget to generate and update symbol in your simulation + if you want, add the 'fifo_cmd_busy' output which you could never make it go high in simulation unless it is deliberate.

(LOL, I like there's a 3 clock delay from the first loaded instruction until the geometry_xy_plotter sees and executes it.  If we used my FIFO_3/7word_0_latency FIFO, the execute would have been executed just as immediate as if it wasn't in the circuit.)

[BrianHG]

EDIT: Also added the geo_pixel_writer file - currently only consists of module declaration and I/O as you've specified.  Hopefully all correct so far.

So far perfect...

[nockieboy]

Well, does it simulate.  (I think not as it doesn't compile)
It should still simulate when running through a FIFO inside.

Ah well done, yes there were a few cut 'n' paste errors in the FIFO instantiation. 

Ok, I've made the changes & it finally simulates properly.  Your geometry_xy_plotter now has a 510 word instruction cache which you might never be able to fill up with a slow 8 MHz Z80 unless all you are doing is non-stop 16bit color full screen copy & fills.

Yes, simulating just fine here too.    I really can't think of any situations where I'm going to be filling the FIFO - I can't see FMV or the need to hypnotise the user cropping up any time soon! 

(LOL, I like there's a 3 clock delay from the first loaded instruction until the geometry_xy_plotter sees and executes it.  If we used my FIFO_3/7word_0_latency FIFO, the execute would have been executed just as immediate as if it wasn't in the circuit.)

Is the sc_FIFO up to the task then?  Would using your zero-latency FIFO be overkill?

I'm going to work on the rest of your posts above as quickly as I can, but I just don't have the time to sit down and work on it all in continuous blocks of time.  I'm certainly not going to get any more done before tomorrow.   I'll keep plugging away at it over the next month and might post questions here as I hit blocks, but won't expect any responses during August.  Thanks for all the help so far!