FPGA VGA Controller for 8-bit computer

[nockieboy]

Okay, it's still not running (throwing an error loading design and pausing on line 10 of setup_z80.do), but there's only suppressible errors in the log, all relating to legacy IO ports that are no longer in the latest Bridgette (PS2 and sound ports):

# ** Error (suppressible): (vsim-3584) Z80_Bus_Interface_tb.sv(222): Module parameter 'IO_DATA' not found for override.
#    Time: 0 ps  Iteration: 0  Instance: /Z80_Bus_Interface_tb File: Z80_Bus_Interface_tb.sv
# ** Error (suppressible): (vsim-3584) Z80_Bus_Interface_tb.sv(222): Module parameter 'IO_STAT' not found for override.
#    Time: 0 ps  Iteration: 0  Instance: /Z80_Bus_Interface_tb File: Z80_Bus_Interface_tb.sv
# ** Error (suppressible): (vsim-3584) Z80_Bus_Interface_tb.sv(222): Module parameter 'SND_DUR' not found for override.
#    Time: 0 ps  Iteration: 0  Instance: /Z80_Bus_Interface_tb File: Z80_Bus_Interface_tb.sv
# ** Error (suppressible): (vsim-3584) Z80_Bus_Interface_tb.sv(222): Module parameter 'SND_OUT' not found for override.
#    Time: 0 ps  Iteration: 0  Instance: /Z80_Bus_Interface_tb File: Z80_Bus_Interface_tb.sv
# ** Error (suppressible): (vsim-3584) Z80_Bus_Interface_tb.sv(222): Module parameter 'SND_TON' not found for override.
#    Time: 0 ps  Iteration: 0  Instance: /Z80_Bus_Interface_tb File: Z80_Bus_Interface_tb.sv
# Error loading design

I've updated the _tb file include the updated IO port addresses and names and removed the legacy ports listed above.  ModelSim is now complaining about missing connections for ports:

# Loading work.Z80_Bus_Interface
# ** Warning: (vsim-2685) [TFMPC] - Too few port connections for 'Z80_BRIDGE'.  Expected 48, found 41.
#    Time: 0 ps  Iteration: 0  Instance: /Z80_Bus_Interface_tb/Z80_BRIDGE File: Z80_Bus_Interface_tb.sv Line: 225
# ** Error: (vsim-3063) Port 'READ_PORT_DATA' not found in the connected module (30th connection).
#    Time: 0 ps  Iteration: 0  Instance: /Z80_Bus_Interface_tb/Z80_BRIDGE File: Z80_Bus_Interface_tb.sv Line: 225
# ** Warning: (vsim-3722) Z80_Bus_Interface_tb.sv(225): [TFMPC] - Missing connection for port 'm_wb_adr_o'.
# ** Warning: (vsim-3722) Z80_Bus_Interface_tb.sv(225): [TFMPC] - Missing connection for port 'm_wb_dat_o'.
# ** Warning: (vsim-3722) Z80_Bus_Interface_tb.sv(225): [TFMPC] - Missing connection for port 'm_wb_dat_i'.
# ** Warning: (vsim-3722) Z80_Bus_Interface_tb.sv(225): [TFMPC] - Missing connection for port 'm_wb_sel_o'.
# ** Warning: (vsim-3722) Z80_Bus_Interface_tb.sv(225): [TFMPC] - Missing connection for port 'm_wb_we_o'.
# ** Warning: (vsim-3722) Z80_Bus_Interface_tb.sv(225): [TFMPC] - Missing connection for port 'm_wb_cyc_o'.
# ** Warning: (vsim-3722) Z80_Bus_Interface_tb.sv(225): [TFMPC] - Missing connection for port 'm_wb_stb_o'.
# ** Warning: (vsim-3722) Z80_Bus_Interface_tb.sv(225): [TFMPC] - Missing connection for port 'm_wb_ack_i'.
# Error loading design

I'll start adding these ports if that's the right way to go...?

[nockieboy]

Line 191 was most important as it must be logic, not a simple wire if you are using it inside an 'always_comb'.

Ah okay, I've updated Bridgette accordingly.  I guess Quartus was correcting this mistake itself during compilation as it's never thrown an error regarding this line, but ModelSim isn't so happy about it?

[BrianHG]

None of this would have been an issue if you placed the SD card stuff externally to the Z80 bridge, as it's own module in the GPU top hierarchy.

This way, we could have concentrated on the one tiny issue with the read-port function.

Line 191 was most important as it must be logic, not a simple wire if you are using it inside an 'always_comb'.

Ah okay, I've updated Bridgette accordingly.  I guess Quartus was correcting this mistake itself during compilation as it's never thrown an error regarding this line, but ModelSim isn't so happy about it?

Quartus was a little more forgiving with it's implementation of SystemVerilog.

[BrianHG]

Remember, we just wanted to fix the Z80 bridge.
Now, because you placed the SD card stuff in there, we will have a nightmare of a time getting this to simulate.

[nockieboy]

Remember, we just wanted to fix the Z80 bridge.
Now, because you placed the SD card stuff in there, we will have a nightmare of a time getting this to simulate.

It seemed like the logical thing to do at the time.   What's going to be easier?  Trying to get it to simulate as-is, or I go back and remove the Wishbone stuff from Bridgette?

[BrianHG]

All the signals your WB uses are located in the 4 port arrays:

Code: [Select]

   output logic [255:0] WRITE_PORT_STROBE          = 0 , // The bit   [port_number] in this 256 bit bus will pulse when the Z80 writes to that port number.
   output logic   [7:0] WRITE_PORT_DATA   [0:255]      , // The array [port_number] will hold the last written data to that port number.
   output logic [255:0] READ_PORT_STROBE           = 0 , // The bit   [port_number] in this 256 bit bus will pulse when the Z80 reads from that port number.

// Until the legacy ports are moved out, this port needs to be a wire inside this module exclusively.
//   input  wire    [7:0] READ_PORT_DATA    [0:255]      , // The array [port_number] will be sent to the Z80 during a port read so long as the read port
                                                         // number is within parameter READ_PORT_BEGIN and READ_PORT_END.
However, I guess for now you can add dummy signals for the WB IO ports.
In the _tb.sv files, just add the ports and tie the inputs to '0'.
This should be enough to get the sim to run.

[nockieboy]

Okay, that runs.  I've just created the extra WB ports and put a wire name in them, not connected to anything else.  Hopefully that's the right thing to do...?

[BrianHG]

ok, edit the 'Z80_cmd_stimulus.txt' and make it only read the 1 port replicating the bug.
And I'll be able to help fix the issue later tonight.

[nockieboy]

Latest testbench folder included.  Have updated the stimulus list to just write an address to SD_ADDR and then read from SD_DATA.  Here's the output:

[BrianHG]

1 note when making the modelsim .zip files: you do not need the sub-folders...

Ok, take update the new setup file and the waveforms I listed.

Here is a snapshot:


You will see I am now showing the read and write ports with their strobes which should be driving your wishbone interface.

The problem with the read strobe is that is appears at the same time we expect the read data to be valid.
This is no good if you wish to process something first before returning a read.

An example fix, this can still work if you execute your WB command when you do the write port setting the function so the results are ready by the time you perform the read.  This might solve your current problem.

However, working with your current control scheme, we can change the read port function a little.  Take a look at the position of the yellow cursor.  It is at that point we know that a read command has been sent and what the address is.  If we were to modify the Z80 bridge to send the strobe at that point and wait for an acknowledge before latching the result, maybe this might be a route to take.

What do you think?

[nockieboy]

The problem with the read strobe is that is appears at the same time we expect the read data to be valid.
This is no good if you wish to process something first before returning a read.

An example fix, this can still work if you execute your WB command when you do the write port setting the function so the results are ready by the time you perform the read.  This might solve your current problem.

Interesting idea.  The only issue (if I understand your suggestion correctly) is that the bridge doesn't know if it's going to be a read or a write op when the address is written (the host writes to the SD interface's registers as well as reading them). I'm assuming you mean fire off a WB read request when the address is first written, instead of waiting for the IO read to send the read request via WB?

However, working with your current control scheme, we can change the read port function a little.  Take a look at the position of the yellow cursor.  It is at that point we know that a read command has been sent and what the address is.  If we were to modify the Z80 bridge to send the strobe at that point and wait for an acknowledge before latching the result, maybe this might be a route to take.

What do you think?

I think this should work.   My only concern is that of completeness.  It will work for slightly delayed IO reads, but what about if/when a slower IO device is used?  Will the bridge be able to insert WAITs as required whilst it waits for the device's read ack?  That feature isn't needed for this particular case, though, I'm just thinking out loud.

[BrianHG]

Ok, step 1: Change the  parameter READ_PORT_CLK_POS to:

Code: [Select]

// Z80 bus timing settings.
   parameter bit [3:0]  READ_PORT_CLK_sPOS    = 0,     // Number of Z80_CLK cycles before the bus interface before the read strobe pulse outputs.
   parameter bit [3:0]  READ_PORT_CLK_aPOS    = 2,     // Number of Z80_CLK cycles before the bus interface read port data is returned.

Next break the read port into 2 parts:

Code: [Select]

            // ************************************************************
            // *** Read port
            // *** This will trigger once on the transition of Z80_CLK
            // *** position READ_PORT_CLK_sPOS.
            // ************************************************************
            end else if (z80_op_read_port && (Z80_CK_POS==READ_PORT_CLK_sPOS ) && zclk ) begin
       
                if (port_in_range) begin    // Only respond to a port read request if the read port is in range.

                    READ_PORT_STROBE[Z80_addr_r[7:0]] <= 1        ; // Generate the access strobe signal on the requested port number.

                end
       
            // ************************************************************
            // *** Read port
            // *** This will trigger once on the transition of Z80_CLK
            // *** position READ_PORT_CLK_aPOS, the acknowledge position for the read port.
            // ************************************************************
            end else if (z80_op_read_port && (Z80_CK_POS==READ_PORT_CLK_aPOS ) && zclk ) begin
       
                if (port_in_range) begin    // Only respond to a port read request if the read port is in range.

                    READ_PORT_ACK[Z80_addr_r[7:0]] <= 1        ; // Generate the acknowledge for debugging purposes.
                    Z80_fpga_data_out                 <= READ_PORT_DATA[Z80_addr_r[7:0]]; // send data to read port.
                    Z80_fpga_data_oe                  <= 1'b1     ; // set the FPGA Z80_data bidirectional IO port to output.
                    Z80_245data_dir                   <= data_out ; // Set the 245 to send data from the Z80 to the FPGA.
                    Z80_245_oe                        <= 1'b0     ; // Enable 245 OE.

                end
And further down, don't forget the:

Code: [Select]

                READ_PORT_ACK     <= 0 ; // Make sure that the generated strobes are only active for 1 clock.

Now, please get rid of that silly ' wb_RQ_READ <= 1'b1 ; // initiate a Wishbone RD' and properly assign it to the correct read strobe address.

Add the new ACK reg to the setup_Z80.do script file so you can see whats going on and upload the update.

What these additions wont do is supply a 'wait' state to the z80, but, you should see what is going on in the new waveform with the separate strobe and ack.

Once sim-ed, then tested on hardware, we will look at the signal-tap, then add the 'wait' capability.

[nockieboy]

Made those changes, plus a couple more to get the simulation to run.  Had to edit setup_z80.do to add the sPOS and aPOS values as READ_PORT_CLK_POS was no longer in use.  Had to tweak Z80_Bus_Interface_tb.sv to update the CLK_POS parameter to sPOS and aPOS.  Made the alterations to Z80_Bus_Interface.sv as suggested in your post.

Here's the new simulation result:

[BrianHG]

Good.  I'm deliberately leaving out the little things.

Now, your WB will see the first READ_PORT_STROBE[ x ].
As long as the matching READ_PORT_DATA[ x ] has the correct value before the READ_PORT_ACK[ x ] pulses, the Z80 will see the correct data.

Ok, proceed to the GPU hardware and test / signal-tap.

If everything is ok, then we will generate an optional 'wait' for the Z80 which will hold until you feed an acknowledge input.

[nockieboy]

Have just done a quick hardware test and it seems to be working perfectly based on my tests on the host.  I can read the SD interface registers and have access to the full 32-bit register.

I don't have time to set up SignalTap tonight (it's late here and I need sleep), but will get on it tomorrow when I have time.

Thanks!

[nockieboy]

Okay, SignalTap of a read to port 240 (reading SD interface register for the SD clock divider):

[BrianHG]

Ok, it's been a week.  Anything new to see?  Any new bugs found?

[nockieboy]

Ok, it's been a week.  Anything new to see?  Any new bugs found?

Nothing to report really.  Progress is slow due to time constraints (as always).  I've broken down the example C code in the interface project and translated that to Z80 assembly to successfully initialise the card down to obtaining CID, CSD data and RCA address from the SDHC card I'm using.  I'm currently working on reading a block of data from the SD card, but I'm not getting back the correct data expected from the SD card (and further down the chain it's not getting written to DDR3, correct or not).  This is likely to do with the poorly-documented SD interface HDL and something I'm doing wrong with its software setup as data is being read from the card, but is turning into a stream of zeros from the RX buffer or some other point in the interface, so I'm currently using SignalTap to probe and see what's going on.

[nockieboy]

Further to the above writing issues, I'm definitely getting no writes to GPU memory, as verified by my CP/M test program and the rs232_debugger.

I've extensively tested the SD interface with SignalTap and found data being read from the SD card and passed through to the DDR3/Wishbone interface module.  From there, it attempts to write the data to DDR3 - but nothing is actually getting written.

Below are two SignalTaps - the first is a working write from the Z80_Bridge, simply writing 0xAA to DDR3 memory at location 0x5001:



This second image shows the first two of 128 consecutive 32-bit writes to DDR3 memory from the DDR3/Wishbone interface, starting at address 0x5000:



I had written an AA55AA55 pattern to the first 16 bytes of GPU RAM from 0x5000 to 0x5010, so even with zeros being read from the SD card, that pattern should have been overwritten, but nothing is happening.  Is there an issue with the CMD_write_mask or something else going on?

I'm using port 5 for the SD/Wishbone interface to the DDR3 controller.  I've attached relevant modules in case they're of any use, but I suspect I've made a silly mistake somewhere.

[BrianHG]

How the mask works:
The write mask (each bit being equal to 8 bits of the data bus) needs to be high for a write to actually take place, for example: (32 bit data interface)

MASK = 4'bxxxx  DATA = 32'h11223344

So, the red mask bit X will enable a write on  the red data 11.
The mask green bit X will enable a write on the green data 22.
The mask blue bit X will enable a write on the blue data 33.
The mask purple bit X will enable a write on the purple data 44.

If there are no '1' in the mask during a write, nothing will make it to the DDR3.
You appear to be using it correctly as your mask is set to 4'hF, or, 4'b1111.

[BrianHG]

Your data bus width parameter is in error.  See what I made red...

parameter bit [8:0]  PORT_R_DATA_WIDTH [0:15] = '{  8,  8, 16, 16,128,128,128,128,128,128,128,128,128,128,128,128},
parameter bit [8:0]  PORT_W_DATA_WIDTH [0:15] = '{  8,  8, 16, 16,128,128,128,128,128,128,128,128,128,128,128,128},
                                                // Use 8,16,32,64,128, or 256 bits, maximum = 'PORT_CACHE_BITS'
                                                // As a precaution, this will prune/ignore unused data bits and write masks bits, however,
                                                // all the data ports will still be 'PORT_CACHE_BITS' bits and the write masks will be 'PORT_CACHE_WMASK' bits.
                                                // (a 'PORT_CACHE_BITS' bit wide data bus has 32 individual mask-able bytes (8 bit words))
                                                // For ports sizes below 'PORT_CACHE_BITS', the data is stored and received in Big Endian. 

However, with the 128 settings, only the first 4 bytes at address $5000 should have been filled with $00, while all the other bytes should have your original Z80 data.  Once you fix the 2 data bus width parameters, then all 16 bytes should change.

[BrianHG]

ALSO:  You need to assign 0's to the unused input ports on my DDR3 controller...

You did not assign these 2:
CMD_priority_boost[5], CMD_read_vector_in[5]

[nockieboy]

How the mask works:
The write mask (each bit being equal to 8 bits of the data bus) needs to be high for a write to actually take place, for example: (32 bit data interface)

MASK = 4'bxxxx  DATA = 32'h11223344

So, the red mask bit X will enable a write on  the red data 11.
The mask green bit X will enable a write on the green data 22.
The mask blue bit X will enable a write on the blue data 33.
The mask purple bit X will enable a write on the purple data 44.

If there are no '1' in the mask during a write, nothing will make it to the DDR3.
You appear to be using it correctly as your mask is set to 4'hF, or, 4'b1111.

Yes, that's my understanding of how it works - it's identical to the sel line in the Wishbone interface, which is handy.  It's not that, then!

Your data bus width parameter is in error.  See what I made red...

parameter bit [8:0]  PORT_R_DATA_WIDTH [0:15] = '{  8,  8, 16, 16,128,128,128,128,128,128,128,128,128,128,128,128},
parameter bit [8:0]  PORT_W_DATA_WIDTH [0:15] = '{  8,  8, 16, 16,128,128,128,128,128,128,128,128,128,128,128,128},
                                                // Use 8,16,32,64,128, or 256 bits, maximum = 'PORT_CACHE_BITS'
                                                // As a precaution, this will prune/ignore unused data bits and write masks bits, however,
                                                // all the data ports will still be 'PORT_CACHE_BITS' bits and the write masks will be 'PORT_CACHE_WMASK' bits.
                                                // (a 'PORT_CACHE_BITS' bit wide data bus has 32 individual mask-able bytes (8 bit words))
                                                // For ports sizes below 'PORT_CACHE_BITS', the data is stored and received in Big Endian. 

However, with the 128 settings, only the first 4 bytes at address $5000 should have been filled with $00, while all the other bytes should have your original Z80 data.  Once you fix the 2 data bus width parameters, then all 16 bytes should change.

Ah okay, so these red values should be 32 instead of 128 - the SD interface accesses the DDR3 controller via a 32-bit data bus - but as you've already identified, the first four bytes would still have been written okay thanks to the correct mask being used.

ALSO:  You need to assign 0's to the unused input ports on my DDR3 controller...

You did not assign these 2:
CMD_priority_boost[5], CMD_read_vector_in[5]

That seems to have fixed the memory writing issue - I knew it'd be something I'd missed somewhere - thanks.

It's writing data to GPU RAM now - on to the next issue; it's not writing what I expect it to write (I have a raw dump of the first 4 sectors on the SD card to compare against) - likely a problem with the SD interface setup! Onwards and upwards!

[nockieboy]

I've got another (small - hopefully) issue I've run into, which I think is being caused by the DDR3 memory caching... possibly.

To start testing SD block reads, I write 512 bytes (all 0xAA) to the SD RD/WR buffer in GPU RAM.  That way I can see if the data has been changed, as the SD seems to be reading a lot of 0x00s at the moment (with some other sporadic byte values, but that's not the issue).

I read the SD card's SCR register, which is 8 bytes of data relating to that SD card.  The result is written to the start of the SD buffer in GPU RAM directly via the SD interface's DMA and my Wishbone/DDR3 interface.

Now the issue - the register data is written to the GPU RAM; I can see it using the RS232_debugger.  However, when I try to read that data from the host, I'm getting the 0xAA's I've written (from the host before the SCR register read).  So what the host is reading doesn't match what the RS232_debugger is seeing.

This seems to me like an issue with the cache not updating and still presenting the host with the cached data instead of the new data written by the SD interface.  Do I need to do something to make the SD interface writes update the cache?  I seem to recall having this issue once before, but I can't find it in the thread history (not using the right search terms, obviously!)

[BrianHG]

Now the issue - the register data is written to the GPU RAM; I can see it using the RS232_debugger.  However, when I try to read that data from the host, I'm getting the 0xAA's I've written (from the host before the SCR register read).  So what the host is reading doesn't match what the RS232_debugger is seeing.

This seems to me like an issue with the cache not updating and still presenting the host with the cached data instead of the new data written by the SD interface.  Do I need to do something to make the SD interface writes update the cache?  I seem to recall having this issue once before, but I can't find it in the thread history (not using the right search terms, obviously!)

Ok, what seems to be happening is that the Z80 read cache is it's own on a different channel compared to the SD-Card's cache.  So, it doesn't know that something has been written into that address.

Try this fix:
Read any GPU memory location which is at least 16 bytes outside the read address you desire forcing the old read data in the DDR3 Z80's read cache to be dumped.
Now, read the address you actually want to read, now being on a different cache bank read address, this will now force a fetch direct from the DDR3.