FPGA VGA Controller for 8-bit computer

[BrianHG]

Ok, I'll take a look tonight.
Remember, you can always signal-tap your new port 6 with the wishbone interface.
I do no know anything about wishbone, so I hep it wont be too difficult.

[nockieboy]

I don't think Wishbone is all that complicated, to be honest - I was able to work out how to interface it without help, so it must be pretty simple.   I've yet to test it, though - and yes, I'll be making significant use of SignalTap.

I've spent my free time today designing and writing the Wishbone Master interface in the Z80_bridge module.  Haven't had a lot of time, but I'm just testing the I/O system I'm intending to use to get commands and values to the SD interface - will probably have it finished tomorrow, then I can start testing the whole setup.

[nockieboy]

Hmm.. bit stumped by this one:

Code: [Select]

reg [31:0] SD_ARGUMENT = 32'b0 ; // Value to RD/WR SD interface's 32-bit ARGUMENT register
reg [1:0]  ARG_PTR     = 2'b0  ; // 2-bit pointer to current byte in 32-bit SD_ARGUMENT
...
assign  READ_PORT_DATA[SD_ARGS]    = SD_ARGUMENT[((ARG_PTR+1)*8)-1:ARG_PTR*8] ;
So, the above code is a line from the Z80_Bridge module. SD_ARGS is an I/O port parameter (integer 245 to be exact).  SD_ARGUMENT is a register that holds a 32-bit value.  I want to return an 8-bit segment of that 32-bit value, depending on the value of ARG_PTR (which itself is a 2-bit register).  Depending on ARG_PTR's value, reading the SD_ARGS I/O port should return either the top MSB, top LSB, bottom MSB or bottom LSB of SD_ARGUMENT.

Compiling the above code results in this error:

Error (10734): Verilog HDL error at Z80_Bus_Interface.sv(213): ARG_PTR is not a constant

I suspect this is because I'm trying to assign a variable value to a wire and I'll probably need some more steps to switch between the four bytes in SD_ARGUMENT before assigning them to READ_PORT_DATA[SD_ARGS]??

EDIT:

Also, what am I doing wrong here?  This is a simple I/O port that can be read/written to, that modifies (or reads) the 2-bit ARG_PTR register mentioned above.

Code: [Select]

assign  ARG_PTR[1:0]     = WRITE_PORT_DATA  [SD_ARG_PTR][1:0] ;
...
assign  READ_PORT_DATA[SD_ARG_PTR] = '{ 6'b0, ARG_PTR[1:0] }      ;
I'm reading a zero value from it, which I guess is right as it should start at zero, but I'm unable to write a new value to it (or read the new value back - just getting zero back).

[BrianHG]

Ok, I finally have time.
You will need to send me the project.  I tried to add your previous .zip source and obviously, things are missing.

[nockieboy]

Ok, I finally have time.
You will need to send me the project.  I tried to add your previous .zip source and obviously, things are missing.

Yes, I was just asking for a brief glance at the module I'd written, hence I posted it and the Z80_Bridge in isolation, but things have moved on since then and I have a working (well, it compiles) interface between the Z80_Bridge and SD interface.

Z80_Bridge is modified to remove legacy PS2 ports and now has a developing Wishbone interface state machine at the bottom that I only got working and started looking at the SignalTap traces for this afternoon, so there's more work to be done with it to get it to a workable state communicating properly with the SD interface.

I seem to have broken the GPU MMU feature somehow, so I'll be looking into that.

[BrianHG]

  Great to see that you are coding HDL...

As frustrating as bugs are, I'm sure you'll get it working...

[nockieboy]

Just a quick update - I have the Wishbone interface working fine at the moment.  I'm currently testing the SD card interface itself from the host and trying to get an SD card initialised in 1-bit mode.  Once that's done and I can get a block read to execute, I'll be testing the Wishbone interface to the DDR3.

Does anyone have any experience with SD 1-bit and 4-bit initialisation?  It seems there's literally tons of information on how to set up an SPI interface to the SD card, but very little at all about the faster methods.

EDIT: That said, I've moved away from existing examples and now I'm using the Part1_Physical_Layer_Simplified_Specification_Ver8.00 document, so it's just a matter of time before I decode the flow charts and get it running.

[Ted/KC9LKE]

Hi Jonathan,

Not to detract from the current focus.
 
Sometime in the near future I plan to work with my DECA board on an unrelated project and it would be nice to have the same Z80 bus to level shifters, to DECA FPGA connections as this GPU project. It would save a ton of "wire up" time if I want to give the GPU a try.

Is there an updated, current, schematic on your GIT that I could follow?

I know time is hard to come by so no hurry.

Great job to all on the GPU project BTW!

Best / Ted   

[pcprogrammer]

Just a quick update - I have the Wishbone interface working fine at the moment.  I'm currently testing the SD card interface itself from the host and trying to get an SD card initialised in 1-bit mode.  Once that's done and I can get a block read to execute, I'll be testing the Wishbone interface to the DDR3.

Does anyone have any experience with SD 1-bit and 4-bit initialisation?  It seems there's literally tons of information on how to set up an SPI interface to the SD card, but very little at all about the faster methods.

EDIT: That said, I've moved away from existing examples and now I'm using the Part1_Physical_Layer_Simplified_Specification_Ver8.00 document, so it's just a matter of time before I decode the flow charts and get it running.

Take a look here https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_startup_from_sd_card/bl_sd_card_interface.c

It is C code for working with a SD card on the F1C100s.

I went through the same path to get SD cards working on the FNIRSI 1013D, so might save you some time. In the folder with the scope source there is also the FatFs code I used to get it working.

[nockieboy]

Hi Jonathan,

Not to detract from the current focus.
 
Sometime in the near future I plan to work with my DECA board on an unrelated project and it would be nice to have the same Z80 bus to level shifters, to DECA FPGA connections as this GPU project. It would save a ton of "wire up" time if I want to give the GPU a try.

Is there an updated, current, schematic on your GIT that I could follow?

I know time is hard to come by so no hurry.

Great job to all on the GPU project BTW!

Best / Ted

Hi Ted,

Nothing on the github repo in relation to the DECA interface, unfortunately.  I designed my DECA-uCOM interface card on EasyEDA - if you use that (or want to try learning it, it's easier than KiCAD) then I can probably work out how to share that project with you, but in the meantime here's the schematic PDF - hope it helps.  If you have any questions, you know how to get hold of me.

[Ted/KC9LKE]

Schematic form is perfect

Thanks!

[nockieboy]

SD interface progress update - I seem to have actually worked out how to initialise an SD card.   Special thanks to @pcprogrammer and his link to the FNIRSI_1013D firmware repo link.

I get the feeling this should be a lot easier than it is, but I'm working in SD-mode instead of SPI and using an OpenCore project that adds an extra layer of variables between the software and the SD card.

I'm now expanding the HDL in Bridgette to allow reads from the Wishbone interface, so I can allow the host Z80 to get data directly from the interface and SD card registers.  Up until now I've been using SignalTap to see what's going on with the SD interface's registers.

[nockieboy]

@BrianHG - have made some progress on reading SD interface registers via the Wishbone interface today, but am having to read the IO ports twice because the SD interface isn't responding with the register value in time for the Z80 before it reads the IO port value.

How do I need to go about adding WAIT states to IO port reads? (current Bridgette attached).

[BrianHG]

I'll look at it tonight...

[nockieboy]

I'll look at it tonight...

Thank you.  Here's a SignalTap trace showing some of the timings.  The 32-bit register, wb_DATA_IN, is where the requested register value is loaded into on a successful read over the Wishbone interface.  This can then be read by the host via two I/O ports, one to read the data a byte at a time and the other as a pointer to the byte in the wb_DATA_IN word.

A read is performed by setting the address of the desired register using I/O port 242, then reading I/O port 240 to get the byte pointed to by port 249.  The SD interface and Wishbone bus are fast enough that the register value is retrieved and wb_DATA_IN should be set within the Z80's I/O cycle, ready for it to be read, but there's a full Z80 clock cycle delay between the I/O cycle starting (z80_op_read_port going HIGH in the trace) and the Wishbone read request (wb_RQ_READ) going HIGH.  Maybe there's room to speed this up and not have to insert any WAIT states?

[BrianHG]

Ok, our problem here is the current Z80 code delivers you a read port pulse, simultaneously latching the read data on that exact pulse where it is obvious the data isn't yet ready.

What you want is not a delay due to interrupt, but a delivery of the read port port address when the command is received, which is actually already available on the first Z80 clock, and have the return data sampled before it is actually needed to be send to the z80 on clock position number 3.  The wishbone interface appears to be way faster than the Z80, so this actually isn't a problem.  We just need to capture the read data later at the right time.  See your code on lines 486,487, and 494 which does the same as line 486.

However, we want to fix this properly and include the potential for a super fast Z80 in case we ever go to a Z80 FPGA core which can operate in the 100MHz region.

Step #1, take the above Z80 code and stuff it into my Z80 bridge interface Modelsim simulator and let's perform the Z80 code port read/write and see the waveform.  Provide the new Z80 bridge simulator here so we can modify the code to make the bridge provide with a read in advance and then wait before line 487/488 are driven.

Helping you here will ensure in the future you know how to either use the Z80 bridge properly, or how to properly modify it to your liking.

[nockieboy]

The latest testbench version for the Z80 interface I have is v15.  It might take me some work to upgrade it to the current v16 GPU setup, but I'll see what I can do.

[BrianHG]

The latest testbench version for the Z80 interface I have is v15.  It might take me some work to upgrade it to the current v16 GPU setup, but I'll see what I can do.

Funny, the Z80 bridge testbench has nothing but the Z80 bridge in it plus the _tb file.
You do not need the DDR3 or SD card HDL.  Just the Z80 bridge so you may do development work on the code for the ports.
How can that possibly take so long?
There is no GPU.
There is no DDR3.

[nockieboy]

The latest testbench version for the Z80 interface I have is v15.  It might take me some work to upgrade it to the current v16 GPU setup, but I'll see what I can do.

Funny, the Z80 bridge testbench has nothing but the Z80 bridge in it plus the _tb file.
You do not need the DDR3 or SD card HDL.  Just the Z80 bridge so you may do development work on the code for the ports.
How can that possibly take so long?
There is no GPU.
There is no DDR3.

I guess because I'm not familiar with the _tb version of the Z80 bridge.  When I wrote that last message, I'd just run the new Z80_bridge and v15 Z80_bridge_tb through a file comparison and saw the number of changes needed to be made.   Maybe it won't take so long, but I've got to add in the Wishbone ports and I'm not that confident messing with ModelSim yet.

[BrianHG]

Just copy over the Z80 bridge.v file.
All you wan it the bare bone Z80 bridge I made for you.
No wishbone.
No ddr3 version.
No gpu version.

You can simulate the wishbone response.
And just add the nets to the waveform.

[nockieboy]

Just copy over the Z80 bridge.v file.
All you wan it the bare bone Z80 bridge I made for you.
No wishbone.
No ddr3 version.
No gpu version.

You can simulate the wishbone response.
And just add the nets to the waveform.

Ah, okay, that makes life easier.  I was thinking I'd have to tweak the Z80_Bus_Interface_tb.sv file to include all the changes in the Z80_Bus_Interface.sv file.

Running 'do setup_z80.do' throws errors in the always_comb section of the new Bridgette, like this one:

# ** Error: Z80_Bus_Interface.sv(251): (vlog-2110) Illegal reference to net "READ_PORT_DATA".

Uncommenting line 286 in Z80_Bus_Interface_tb.sv doesn't stop the errors.

EDIT: Have also modified READ_PORT_END and upped it from 249 to 251 to account for the additional IO ports in use.

[BrianHG]

  I said not to use the enhanced overblown DDR3 test version.
All you want is the version with 6 files for the entire z80 tb.

there should be 2 .do files,
a z80_xxx.sv and z80_xxx_tb.sv files
and an ascii .txt script file to send simulated Z80 buss commands.

All we want to do is play with the read port function.

[BrianHG]

Ok, lets work with what you provided.

[nockieboy]

I said not to use the enhanced overblown DDR3 test version.
All you want is the version with 6 files for the entire z80 tb.

there should be 2 .do files,
a z80_xxx.sv and z80_xxx_tb.sv files
and an ascii .txt script file to send simulated Z80 buss commands.

All we want to do is play with the read port function.

Oops, sorry.  I guess that'll be 'Z80_Interface_TB' in the test folder then. 

[BrianHG]

Ok, you need to change lines 188 through 215 to this:

Code: [Select]

// ***************************************************************************************************

// until the legacy ports are removed, this needs to be a wire outside the IO ports.
logic    [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

// TODO:
// 1) Wishbone Master SD interface
// 2) Interrupt handling for keyboard data
//
// *******************************************************************************************************
//
// ********************** Settings and IO ports for features *********************************************
//
// *******************************************************************************************************
//
//reg        PS2_prev   = 1'b0        ;
//reg [12:0] port_dly    = 13'b0 ; // Port delay pipeline delays data output on an IO port read
reg [7:0]  GPU_MMU_LO  = 8'b0   ; // Lower 8-bits of the upper 12-bits of the DDR3 address bus
reg [7:0]  GPU_MMU_HI  = 8'b0   ; // Upper 4-bits of the upper 12-bits of the DDR3 address bus
wire  [7:0]  SD_ADDRESS  = 8'b0   ; // SD register being addressed
wire  [31:0] SD_COMMAND  = 32'b0  ; // Value to RD/WR SD interface's 32-bit COMMAND register
reg [31:0] SD_ARGUMENT = 32'b0  ; // Value to RD/WR SD interface's 32-bit ARGUMENT register
reg [7:0]  ARG_PTR     = 8'b0   ; // 2-bit pointer to current byte in 32-bit SD_ARGUMENT
reg [2:0]  wb_STATE    = 3'b000 ; // Wishbone transceiver state machine register
reg        wb_RQ_SEND  = 1'b0   ; // Wishbone write request flag
reg        wb_RQ_READ  = 1'b0   ; // Wishbone read request flag
reg        wb_DAT_RDY  = 1'b0   ; // Data ready flag
reg [31:0] wb_DATA_IN  = 32'b0  ; // Data latch for incoming Wishbone data

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