FPGA VGA Controller for 8-bit computer

[BrianHG]

   I mean your code should look like:

Code: [Select]

always_comb begin
      CMD_waddr[1]       = (PORT_ADDR_SIZE)'(gpu_addr)       ; // Set the Z80 write address.
      CMD_wdata[1]       = (PORT_CACHE_BITS)'(gpu_wdata)      ; // Set the Z80 write data.
      CMD_wmask[1]      = (PORT_CACHE_BITS/8)'(1)           ; // 8 bit write data has only 1 write mask bit.     
      CMD_write_req[1]  =  gpu_wr_ena                         ;
 
      CMD_read_req[1]  =  gpu_rd_req ;
      CMD_raddr[1]      = (PORT_ADDR_SIZE)'(gpu_addr)       ; // Set the Z80 read address.

      gpu_rd_rdy          = CMD_read_ready[1] ;
      gpu_rData[7:0]    = 8'(CMD_read_data[1]) ;
end

This is direct wiring, no clock delay.

assign x = y ; on every line
instead of always_comb will also work.

[nockieboy]

Your current core needs 125 and 250MHz and this is the speed coming out of your Z80 bridge.  But, running the DDR3 at 400MHz means my IO ports are running at 100Mhz.  A slower speed.  To be 1:1 compatible, you need tyo run the ram at 250MHz in half mode, or 500MHz in quarter mode.

Ok, let's try the overclock method.
This now means that you need to remove your PLL in your GPU and use the following 2 clocks coming out of my design to replace them.

First change this line:

Code: [Select]

parameter int        CLK_IN_MULT             = 32,               // Multiply factor to generate the DDR MTPS speed divided by 2.
parameter int        CLK_IN_DIV              = 4,                // Divide factor.  When CLK_KHZ_IN is 25000,50000,75000,100000,125000,150000, use 2,4,6,8,10,12.to:

Code: [Select]

parameter int        CLK_IN_MULT             = 40,               // Multiply factor to generate the DDR MTPS speed divided by 2.
parameter int        CLK_IN_DIV              = 4,                // Divide factor.  When CLK_KHZ_IN is 25000,50000,75000,100000,125000,150000, use 2,4,6,8,10,12.
This will make the DDR3 run at 500MHz.

All done.

Disable your PLL in your GPU and now, these will be your clock signals:
DDR3_CLK      = 500MHz.
DDR3_CLK_50 = 250MHz.  -> This will new feed your GPU 'clk_2x'
DDR3_CLK_25 = 125MHz.  ->  This will new feed your GPU 'clk'
DDR3_CLK_25 = 125MHz.  ->  This will new feed your GPU 'clk_2x_phase' *** you may need to invert this one.
CLK_IN           = 50MHz    -> This will feed your GPU 'com_clk'

Okay, I've removed the altpll0 instance (b2v_inst17) from GPU.sv and added the clock outputs it produced as inputs on GPU.sv and wired as below:

Code: [Select]

) GPU_CORE (

   //.clk54m      ( MAX10_CLK1_50 ),
.clk         ( DDR3_CLK_25   ),
.clk_2x      ( DDR3_CLK_50   ),
.clk_2x_phase( !DDR3_CLK_25  ),
.com_clk     ( CLK_IN        ),

I'm sorry about the missing graphic view you are used to.  Beginning that way has made you unfamiliar with the module net names.

Oh don't apologise, it's just me finding it easier to look at an image with wires linking modules rather than blocks of HDL and trying to search for wire names between modules.  I see why we switched to HDL instead of design view - I loaded up the EP4CE10 project earlier to help my understanding and it took a full 20 seconds or so to open the GPU.bdf file.  I still feel you can't beat a visual representation, but it's personal preference I guess.

  I mean your code should look like:

Code: [Select]

always_comb begin
      CMD_waddr[1]       = (PORT_ADDR_SIZE)'(gpu_addr)       ; // Set the Z80 write address.
      CMD_wdata[1]       = (PORT_CACHE_BITS)'(gpu_wdata)      ; // Set the Z80 write data.
      CMD_wmask[1]      = (PORT_CACHE_BITS/8)'(1)           ; // 8 bit write data has only 1 write mask bit.     
      CMD_write_req[1]  =  gpu_wr_ena                         ;
 
      CMD_read_req[1]  =  gpu_rd_req ;
      CMD_raddr[1]      = (PORT_ADDR_SIZE)'(gpu_addr)       ; // Set the Z80 read address.

      gpu_rd_rdy          = CMD_read_ready[1] ;
      gpu_rData[7:0]    = 8'(CMD_read_data[1]) ;
end

This is direct wiring, no clock delay.

assign x = y ; on every line
instead of always_comb will also work.

No worries. Teams meeting in 10, so won't be able to do much more until this afternoon, but will take a look at this and passing through the appropriate connections from the Z80_bridge to the top level then.

[nockieboy]

Yep. There won't be any difference as far as I2S is concerned - just be aware that any 24-bit or higher DAC these days will take 32-bit data sample through I2S (64-bit data per stereo frame), with the lower unused bits ignored. Some (now less common) 16-bit DACs may only take 16-bit data sample/32-bit per frame, so regarding I2S, that would be your incompatibility here. But if you stick to 24-bit or higher DACs, then it will be basically plug and play as far as I2S is concerned.

Typically this doesn't matter because there is always quite a bit of "nothingness" at the tail end of each channel's sample value, so higher-resolution DAC will recognize these as trailing zeros.

Differences may be with how the chips are configured (hardware config via pins, software config via I2C or SPI...), the master clock, but those can be handled separately. As far as I remember, the PCM5102 (probably 5102A as the 5102 is now obsolete if I'm not mistaken) can generate the master clock internally from the I2S bit clock, so it's very easy to interface.

That stuff usually boils down to find a table in the datasheet which tells you what values you need to assign to config pins/config interface registers to get the mode and frequency you want. So it's a one-time task (unless you need to change these on the fly, which is quite rare) for a specific P/N.
The cool part is that some newer DACs (for example CS4344) will auto-detect sampling frequency, so that means less configuration hassle.

Yes, the PCM5102A can generate an internal master clock.  I'm happy interfacing the FPGA with the DAC and sorting out I2S (at least it sounds easy enough and there's HDL examples about), my only concern is matching the output from the YM2149 HDL module to a serial signal the DAC will accept.  I haven't really looked in any detail at this yet (it's a little further down the task list, after getting the GPU and DDR3 working how we want), but I'll need to go take a close look at the YM2149 HDL module and see what it outputs.

[nockieboy]

Okay, there's probably wiring errors and more things I need to do (I think I still need to do something with the DDR3 Controller wiring logic?) but it builds with no errors, which is a start.

Takes 3 min 32 seconds, uses 18,533 LEs and 10,582 registers.

Attached files for info.

[BrianHG]

Ok, really minor addition for the DDR3 controller, see the last 3 lines (just to makes things implicit):

Code: [Select]

assign   CMD_waddr[1]            = (PORT_ADDR_SIZE)'(gpu_addr)   ; // Set the Z80 write address.
assign   CMD_wdata[1]            = (PORT_CACHE_BITS)'(gpu_wdata) ; // Set the Z80 write data.
assign   CMD_wmask[1]            = (PORT_CACHE_BITS/8)'(1)       ; // 8 bit write data has only 1 write mask bit.     
assign   CMD_write_req[1]        = gpu_wr_ena                    ;
assign   CMD_read_req[1]         = gpu_rd_req                    ;
assign   CMD_raddr[1]            = (PORT_ADDR_SIZE)'(gpu_addr)   ; // Set the Z80 read address.
assign   gpu_rd_rdy              = CMD_read_ready[1]             ;
assign   gpu_rData               = 8'(CMD_read_data[1])          ;

assign   CMD_read_vector_in[1]   = 0 ; // When not in use, just set to 0.
assign   CMD_R_priority_boost[1] = 0 ; // When not in use, just set to 0.
assign   CMD_W_priority_boost[1] = 0 ; // When not in use, just set to 0.

Also, in GPU.sv, you will need to check lines:
274,312,291,292, 425,426
Remember, you still want to feed the Z80 -> mux geo writes (FPGA blockram and control registers will shadow the DDR3), but, the reads will exclusively come from the DDR3.

I know these modules IO ports are un-sorted due to the auto-generated nature of having Quartus generate the GPU.sv.  I think you should vertically sort and group each module's IOs so it is much easier to deal with.

IE, for the 'Z80_bridge_v2', group sort the IO into all the Z80 IOs (sort these too), then double space with a comment and group the GPU ram IO port, then double space and comment and add the geometry access port, then double space and comment and add the keyboard port, sound port...

Do the same for the data_mux_geo, space out and have first all of port a IOs, port B IOs, geo port IOs, gpu core ram IOs.

Reading and debugging will really help once this is done.
I noticed your keyboard isn't connected, how do you type?

(*My time might become very limited after next week, so, now is the time to get everything to work...)

[nockieboy]

Sorry for delay replying, have had a busy day.

Also, in GPU.sv, you will need to check lines:
274,312,291,292, 425,426
Remember, you still want to feed the Z80 -> mux geo writes (FPGA blockram and control registers will shadow the DDR3), but, the reads will exclusively come from the DDR3.

Okay, bit confused about all this.  Doesn't line 281 also need to be changed?  For some reason I'm having trouble with this - Z80_WR_data seems to be non-existent now (I've commented-out the only mention of it).  I'm worried I'm losing the thread of which wires went where and which I need to change and which need to be kept.  I think Z80_WR_data was a remnant from the EP4CE10 project.  Either way, I'm going to have to take a look at this with fresh eyes in the morning, I think. 

So to check my understanding, let's look at line 274.  Z80_rd_rdy signals to the Z80_bridge that data is ready from block RAM for the Z80 to read.  I need to replace this wire with p1_drdy from GPU_DECA_DDR3_top.sv?

I noticed your keyboard isn't connected, how do you type?

I use the serial console - it's quicker than messing around digging out the keyboard and plugging it in every time I have five minutes to work on it.  EDIT:  Plus, there's no PS2 connector on the DECA. 

[BrianHG]

My recommendation is to document as comments EXACTLY what each of these IO ports actually do and where they go:

Code: [Select]

Z80_bridge_v2  b2v_inst10(
   .reset             ( reset          ),
   .GPU_CLK           ( clk            ),
   .Z80_CLK           ( Z80_CLK        ),
   .Z80_M1n           ( Z80_M1         ),
   .Z80_MREQn         ( Z80_MREQ       ),
   .Z80_WRn           ( Z80_WR         ),
   .Z80_RDn           ( Z80_RD         ),
   .gpu_rd_rdy        ( Z80_rd_rdy     ),
   .sel_pclk          ( out3[7]        ),
   .sel_nclk          ( out3[6]        ),
   .PS2_RDY           ( PS2_DAT_RDY    ),
   .Z80_IORQn         ( Z80_IORQ       ),
   .Z80_IEI           ( IEI            ),
   .GEO_STAT_RD       ( geo_stat_rd    ),
   .gpu_rData         ( dat_to_Z80     ),
   .PS2_DAT           ( key_dat        ),
   .PS2_STATUS        ( DFF_inst33     ),
   .RD_PX_CTR         ( collision_rd   ),
   .WR_PX_CTR         ( collision_wr   ),
   .Z80_addr          ( Z80_ADDR       ),
   .Z80_wData         ( Z80_data       ),
   .Z80_245data_dir_r ( DIR_245        ),
   .Z80_rData_ena_r   ( data_en        ),
   .Z80_245_oe_r      ( OE_245         ),
   .gpu_wr_ena        ( gpu_wr_enable  ),
   .gpu_rd_req        ( gpu_rd_request ),
   .Z80_INT_REQ_r     ( Z80_INT_RQ     ),
   .Z80_WAIT          ( Z80_WAIT       ),
   .Z80_IEO_r         ( IEO            ),
   .EA_DIR_r          ( EA_DIR         ),
   .EA_OE_r           ( EA_OE          ),
   .SPKR_EN           ( SP_EN          ),
   .VIDEO_EN          ( video_en       ),
   .snd_data_tx       ( snd_data_tx    ),
   
   .GEO_WR_HI_STROBE ( send_geo_cmd    ),
   .WR_PX_CTR_STROBE ( wr_px_ctr_rs    ),
   .RD_PX_CTR_STROBE ( rd_px_ctr_rs    ),
   
   .GEO_STAT_WR      ( geo_stat_wr     ),
   .GEO_WR_HI        ( geo_cmd[15:8]   ),
   .GEO_WR_LO        ( geo_cmd[7:0]    ),
   .gpu_addr         ( gpu_addr        ),
   .gpu_wdata        ( gpu_wdata       ),
   .snd_data         ( snd_data        ),
   .Z80_rData_r      ( Z80_RD_data     )
);

Then sort and group them like I told you to in my lat post.  This should help you out.

Remember, you want the Z80 write to GPU ram to feed the DDR3 and the current MUX port.  But for the Z80 reads, you no longer need to activate the MUX port, but have the DDR3 respond to the read request and have the DDR3 send the response to the Z80 bridge.

Also, do the same for the:

Code: [Select]

data_mux_geo   b2v_inst25(
   .clk           ( clk            ),
   .reset         ( reset          ),
   .wr_ena_a      ( gpu_wr_enable  ),
   .rd_req_a      ( gpu_rd_request ),
   .wr_ena_b      ( 1'b0           ), // RS232_wr_ena
   .rd_req_b      ( 1'b0           ), // RS232_rd_req
   .geo_rd_req_a  ( geo_rd_req_a   ),
   .geo_rd_req_b  ( geo_rd_req_b   ),
   .geo_wr_ena    ( geo_wr_ena     ),
   .address_a     ( gpu_addr       ),
   .address_b     (                ), // RS232_addr
   .address_geo   ( geo_ram_addr   ),
   .data_in_a     ( gpu_wdata      ),
   .data_in_b     (                ), // RS232_wDat
   .data_in_geo   ( geo_wr_data    ),
   .gpu_data_in   ( h_rdat         ),
   .gpu_wr_ena    ( h_wena         ),
   .gpu_ena_16bit ( h_16bit        ),
   .gpu_rd_rdy_a  ( Z80_rd_rdy     ),
   .gpu_rd_rdy_b  ( 1'b0           ), // RS232_rd_rdy
   .geo_rd_rdy_a  ( geo_rdy_a      ),
   .geo_rd_rdy_b  ( geo_rdy_b      ),
   .geo_port_full ( geo_port_full  ),
   .data_out_a    ( dat_to_Z80     ),
   .data_out_b    (                ), // RS232_rDat
   .data_out_geo  ( geo_r_data     ),
   .gpu_address   ( h_addr         ),
   .gpu_data_out  ( h_wdat         )
);

Now, I want real explanations exactly like all the notes I have at every port inside my DDR3 source code.  And I want those ports sorted and bundled by function.  (Only sort vertically, you do not need to do the fancy 'tabs' which I have done because of the huge number of ports in my design)

[nockieboy]

See attached update to GPU.sv.  Have added comments for the data_mux_geo module and Z80_bridge, as well as possibly some others as I'm working my way through the entire module.

[BrianHG]

Ok, I re-did you Z80_bridge section.  Tell me if this will help you properly wire the DDR3 ram controller.
Sadly, the port names used could have been better chosen, but the way grouped the ports and simplified their descriptions should help.

If not, you may need to cleanly label a bit more from the Data_mux_geo.

Beginning on line 196, you basically need to focus on lines 240-250 :    // *** Z80 <-> GPU RAM Access ***

[nockieboy]

Okay, here's my first attempt at wiring up the DDR3_Controller as suggested.  The Z80's writes should be duplicated to both the DDR3_Controller AND block RAM, with reads only coming from the DDR3_Controller.

I've disconnected rd_req_a from data_mux_geo, so any read requests by the Z80 will be ignored by block RAM.

Lines 708-758 handle the connection to the DDR3_Controller.

[BrianHG]

Well?
Does it do anything?

When disabling an input port control, do not:

Code: [Select]

//.rd_req_a      ( gpu_rd_request ), // When HIGH, Z80_Bridge is signalling a valid address on address_a input and requesting a READ to the Z80.

Instead do this:

Code: [Select]

.rd_req_a      ( 1'b0 ), // When HIGH, Z80_Bridge is signalling a valid address on address_a input and requesting a READ to the Z80.

You want to be certain that the control is disabled and that for whatever reason, the default set for an undefined port may possibly be a 1 instead of a 0.

[BrianHG]

Lines 708-758 handle the connection to the DDR3_Controller.

The attached code is only 674 lines long...

[nockieboy]

Lines 708-758 handle the connection to the DDR3_Controller.

The attached code is only 674 lines long...

Yeah, not sure what happened but it seems I pasted the wrong code into the file attachment.  I've attached both gpu.sv and GPU_DECA_DDR3_top.sv to this post.  It's GPU_DECA_DDR3_top that has the changes to connect up the DDR3.  I've attached GPU.sv for info in case you need it to cross-reference any connections.

Well?
Does it do anything?

Don't know yet - I'd assumed there'd be a multitude of errors and changes required, so I haven't tested it.

When disabling an input port control, do not:

Code: [Select]

//.rd_req_a      ( gpu_rd_request ), // When HIGH, Z80_Bridge is signalling a valid address on address_a input and requesting a READ to the Z80.

Instead do this:

Code: [Select]

.rd_req_a      ( 1'b0 ), // When HIGH, Z80_Bridge is signalling a valid address on address_a input and requesting a READ to the Z80.

You want to be certain that the control is disabled and that for whatever reason, the default set for an undefined port may possibly be a 1 instead of a 0.

There's a line like that in the GPU.sv code, but immediately below it is the line you're pointing out that it should be.  I commented-out the first connection to .rd_req_a so that I could easily see what was connected to, if I needed to change it later.

[BrianHG]

Why do you have all that BS code from lines 709 to 758?

Why is it there?

What happened to the 'assign's, or, just placing the correct ' CMD_R/W_*** ' right inside the brackets  ' .gpu_*** ( CMD_R/W_*** ) ' of lines 507-517?

Why do you keep on complicating things beyond belief?

[nockieboy]

I forgot that the RS232 interface was crossing a clock domain but presumably the Z80_bridge doesn't, hence all the extra gubbins at the end of the file.

Attempt 2 attached.

Lines 508-509 are where the DDR3_Controller data out connects to the GPU.sv module.
Lines 513-517 are unchanged from the GPU, but...
...lines 458-465 connect the GPU to the DDR3_Controller for writes and read requests, allowing sharing of the lines with the existing block RAM via data_mux_geo.

[BrianHG]

Well, if you have lines 464 & 465, then, you may place the wires in lines 509-509.

Why didn't you declare wires for gpu_addr, gpu_wdata, gpu_wr_ena, & gpu_rd_req like you did for gpu_rd_rdy and gpu_rData at lines 455 & 456?

...lines 458-465 connect the GPU to the DDR3_Controller for writes and read requests, allowing sharing of the lines with the existing block RAM via data_mux_geo.

No, the sharing with the data_mux_geo happens inside the GPU.sv.
Inside GPU.sv, lines 52 isn't wired anywhere, and I didn't even need a compiler to tell me this. m You have a typo at line 162.


Get this working...

[nockieboy]

Why didn't you declare wires for gpu_addr, gpu_wdata, gpu_wr_ena, & gpu_rd_req like you did for gpu_rd_rdy and gpu_rData at lines 455 & 456?

Ah I missed those declarations.  The project compiled as well - I guess Quartus just inferred the connections as wires?

Inside GPU.sv, lines 52 isn't wired anywhere, and I didn't even need a compiler to tell me this. m You have a typo at line 162.

The typo is the cause for line 52 not going anywhere, then.  Are there any other connection issues?  I'll have a little more time tomorrow to test the project on the hardware.

[Wilksey]

I've not read the entire thread, at 110 pages i'd be here a while, but Grant has his pages here: http://searle.wales/ apologies if you already have this link.

[BrianHG]

I've not read the entire thread, at 110 pages i'd be here a while, but Grant has his pages here: http://searle.wales/ apologies if you already have this link.

Nockieboy would have been happy with Grant Searle's Z80 GFX board only up to around then end of his opening post [HINT] of this thread...

[BrianHG]

Why didn't you declare wires for gpu_addr, gpu_wdata, gpu_wr_ena, & gpu_rd_req like you did for gpu_rd_rdy and gpu_rData at lines 455 & 456?

Ah I missed those declarations.  The project compiled as well - I guess Quartus just inferred the connections as wires?

Inside GPU.sv, lines 52 isn't wired anywhere, and I didn't even need a compiler to tell me this. m You have a typo at line 162.

The typo is the cause for line 52 not going anywhere, then.  Are there any other connection issues?  I'll have a little more time tomorrow to test the project on the hardware.

Without a full project and Z80, I cannot tell you much more.
Check all Quartus warnings.
Do not let it infer  wires as it makes mistakes there when dealing with multiple bit wide wires.

Get past this as you need to deal with adding and testing the 'WAIT' next.
Then you will need to decide how to re-incorporate the geometry unit and handle / create a new MAGGIE architecture for the DDR3.
There is a ton of work needed to upgrade the 12bit coordinate system to 16bit and upgrade the 20 bit address system to at least 30bit if not 32bit.

[nockieboy]

Without a full project and Z80, I cannot tell you much more.

Check all Quartus warnings.

I'll attach the latest project shortly.  I'm just working through the Quartus warnings.  I've found this one which makes me wonder if there's a long-dormant mistake in the MAGGIE?

Warning (10036): Verilog HDL or VHDL warning at maggie.sv(69): object "inc_addr_x" assigned a value but never read

After checking the maggie.sv module - inc_addr_x is a 16-bit wire declared at the start of the module, with the first 4 bits assigned a value of hw_regs[X_SCALE][7:4], but that's the last time it's mentioned.  Shouldn't it be used here?

Code: [Select]

Line 176: if (font_y_pos == font_y_size) begin
Line 177:        ram_read_pointer_y   <= ram_read_pointer_y + (inc_addr_y[15:0] << (3 - pixel_16_bit));  // vertical increment display position in backup buffer
Line 178:        ram_read_pointer_x   <= ram_read_pointer_y + (inc_addr_y[15:0] << (3 - pixel_16_bit));  // vertical increment display position in current display address

[BrianHG]

I don't think so based on the comments.

What about the Z80 <-> DDR3 ?

[nockieboy]

Latest version of project attached.  Compiles successfully.  Was part-way through checking the warnings, so still have some more to check.

[BrianHG]

Is the DDR3 working?

[nockieboy]

Is the DDR3 working?

No - at boot up, I'm getting a blank screen with just the two HW trigger lines on the screen - so no screen setup information is getting to the GPU.  There's not even any image or ASCII text appearing on the screen either.

On the DECA, LED2-LED7 are illuminated.

EDIT:  2nd attempt, LED3-LED7 are illuminated.