FPGA VGA Controller for 8-bit computer

[BrianHG]

See photo...

[BrianHG]

Don't forget to remove the old HDMI_TX.v from your project as well.

Also, in the GPU_TOP.sv file, rename to module name from

GPU_top

to

GPU_TOP

[nockieboy]

That sorted it, thanks. 

I'm now getting complaints about the part-select direction being opposite from prefix index direction.  This is an issue with wiring the Z80_ADDR and Z80_data buses.  The bit order is opposite to the GPIOx_D[] index direction:

Code: [Select]

.Z80_ADDR    ( {GPIO0_D[14:21], GPIO0_D[26:31], GPIO0_D[34:41]} ),

.Z80_data    ( GPIO1_D[11:18] ),

Am I going to have to specify each bit individually?

[BrianHG]

Yup, if it is backwards, name them individually...

There is another way out, but is it worth the 2 for loops and another temporary logic array.

[nockieboy]

Yup, if it is backwards, name them individually...

There is another way out, but is it worth the 2 for loops and another temporary logic array.

Probably not... I've already named them individually.

Okay, the project nearly builds, but the fitter is throwing a... fit... complaining about illegal location assignments.  Here's a sample (there's over a hundred of these - one for every node I'm guessing):

Error (171016): Can't place node "HDMI_TX_D[11]" -- illegal location assignment PIN_C15

EDIT:  This doesn't look good, either:



EDIT 2:  Ah... it's compiling for a smaller FPGA by default for the demo project. 

[BrianHG]

Wrong MAX10, you do not have an 08, you have a 50... -6.

This guy:

set_global_assignment -name DEVICE 10M50DAF484C6GES
set_global_assignment -name DEVICE_FILTER_PACKAGE FBGA
set_global_assignment -name DEVICE_FILTER_PIN_COUNT 484
set_global_assignment -name DEVICE_FILTER_SPEED_GRADE 6
set_global_assignment -name INTERNAL_FLASH_UPDATE_MODE "SINGLE IMAGE WITH ERAM"

Close the project, edit the .qsf file with notepad, change to my lines above, then re-open the project.

This happens when you click on Change FPGA because the original .qsf had a 'DEVICE_FILTER_SPEED_GRADE' set to 7 when that FPGA no longer exists, so Quartus shoved you on the smallest MAX10 by default.  Placing a 6 on that line solves that problem.

[nockieboy]

The fitter is named appropriately, it seems.  It's complaining about this now:

Error (169008): Can't turn on open-drain option for differential I/O pin DDR3_DQS_p[0]
Error (169008): Can't turn on open-drain option for differential I/O pin DDR3_DQS_p[1]
Error (169008): Can't turn on open-drain option for differential I/O pin DDR3_DQS_n[0]
Error (169008): Can't turn on open-drain option for differential I/O pin DDR3_DQS_n[1]

[BrianHG]

The fitter is named appropriately, it seems.  It's complaining about this now:

Error (169008): Can't turn on open-drain option for differential I/O pin DDR3_DQS_p[0]
Error (169008): Can't turn on open-drain option for differential I/O pin DDR3_DQS_p[1]
Error (169008): Can't turn on open-drain option for differential I/O pin DDR3_DQS_n[0]
Error (169008): Can't turn on open-drain option for differential I/O pin DDR3_DQS_n[1]

For now, just comment out those 2 lines in my DDR3 code.
Don't forget to erase the ' , ' on the line before.

You will also need to comment out the DDR3_CK_p/n.


Now it should compile.

[nockieboy]

Now it should compile.

It sure does.    I'll update you later when I get a chance to test the project on the hardware. 

[nockieboy]

Oh, the only thing I haven't done is pass the core ram size parameters through to GPU.sv.  Though it looks like that's being done anyway from the flow summary, as it's using 344,159 memory bits (21%).  Once it's working, will be nice to increase that so I can do a full-screen 640x480 mode, even if it's only for testing. 

[BrianHG]

Oh, the only thing I haven't done is pass the core ram size parameters through to GPU.sv.  Though it looks like that's being done anyway from the flow summary, as it's using 344,159 memory bits (21%).  Once it's working, will be nice to increase that so I can do a full-screen 640x480 mode, even if it's only for testing. 

In the Assignment settings, Advanced Compile synthesis settings, turn 'OFF' the auto-ram replacement and auto-shift register replacement.  This will leave you with the maximum available ramto allocate for the GPU screen.

[nockieboy]

It seems I have more available RAM in the FPGA than I can address in the gpu_RAM module / altsyncram module.  I've tried setting the video RAM to 96K, but this results in 48K per 'side' in the altsyncram which requires more than 15 address lines.

I'm a little hesitant to just wade into the vid_osd_generator.sv module and up the address lanes to 16, as there's likely to be many more places I'll need to make that change and probably some knock-on effects I haven't even considered yet.  Any advice?

[BrianHG]

I could have sworn we made room for 20 bit addressing, 1 megabyte...
Also, the addressing for the ram is 16 bit.
I would need to look at the design...

[BrianHG]

Funny, everywhere, I see:

host_addr[19:0]
h_addr[19..0]
geo_ram_addr[19..0]
RS232_addr[19..0]
output logic [19:0] gpu_addr
output logic [19:0] gpu_address,
input  logic [19:0] address_geo,
input logic [19:0] address_a,
input logic [19:0] address_b,
input [19:0] addr_in[14:0],
output reg [19:0] addr_out[14:0],
input  [19:0]  addr_host_in,

Do I need to go on?

Where on earth did you see a 16 bit limit?
Everything here has a 1 megabyte 20 bit limit.

[nockieboy]

Current project attached.

Where on earth did you see a 16 bit limit?

vid_osd_generator:

Code: [Select]

output wire [15:0] host_rd_data,
I think that's it (as in I think that's the issue?), but there may be others?

These are the errors I'm getting:

Error (272006): Insufficient address lines in altsyncram megafunction design -- 48640 memory words in side A specified but total number of address lines is 15
Error (272006): Insufficient address lines in altsyncram megafunction design -- 48640 memory words in side B specified but total number of address lines is 15
Error (287078): Assertion error: The current megafunction is configured for use with the clear box feature and cannot be used when the clear box feature is disabled
Error (12152): Can't elaborate user hierarchy "GPU:GPU_CORE|vid_osd_generator:b2v_inst9|sixteen_port_gpu_ram:gpu_RAM|gpu_quad_port_ram:gpu_RAM|gpu_dual_port_ram_INTEL:dual_port|altsyncram:altsyncram_component"

[BrianHG]

Did you adjust all these parameters in the 'vid_osd_generator.sv'?

Code: [Select]

parameter PIPE_DELAY = 11;                // This parameter selects the number of pixel clocks to delay the VDE and sync outputs.  Only use 2 through 9.
parameter HW_REGS_SIZE  = 9;              // default size for hardware register bus - set by HW_REGS parameter in design view
parameter ADDR_SIZE     = 15; // 15 = 32KB, 16 = 64KB etc
parameter NUM_WORDS     = 24576; // Video RAM up to 5FFFh (default for EP4CE6)
parameter NUM_LAYERS    = 7;              // This parameter defines the number of MAGGIE graphics layers.
parameter PALETTE_ADDR  = (2 ** ADDR_SIZE) - 1024 ;   // Base address where host Z80 may access the palette memory, usually located in the last 1024 bytes of addressable memory
parameter GPU_RAM_MIF   = "GPU_MIF.mif" ; // MIF file for the main GPU ram.

Namely the parameter ADDR_SIZE ?

Take a look at lines 652 to 658 in GPU.sv.

Code: [Select]

);
defparam b2v_inst9.ADDR_SIZE = 16;
defparam b2v_inst9.GPU_RAM_MIF = "GPU_MIF_CE10_10M.mif";
defparam b2v_inst9.HW_REGS_SIZE = HW_REGS;
defparam b2v_inst9.NUM_LAYERS = 5;
defparam b2v_inst9.NUM_WORDS = 40960;
defparam b2v_inst9.PALETTE_ADDR = 40960;
defparam b2v_inst9.PIPE_DELAY = 11;
It's set to 16, so your max is 64k.
Dont forget to set the num_words and place the palette above or equal to the num_words.

[nockieboy]

Did you adjust all these parameters in the 'vid_osd_generator.sv'?

Code: [Select]

parameter PIPE_DELAY = 11;                // This parameter selects the number of pixel clocks to delay the VDE and sync outputs.  Only use 2 through 9.
parameter HW_REGS_SIZE  = 9;              // default size for hardware register bus - set by HW_REGS parameter in design view
parameter ADDR_SIZE     = 15; // 15 = 32KB, 16 = 64KB etc
parameter NUM_WORDS     = 24576; // Video RAM up to 5FFFh (default for EP4CE6)
parameter NUM_LAYERS    = 7;              // This parameter defines the number of MAGGIE graphics layers.
parameter PALETTE_ADDR  = (2 ** ADDR_SIZE) - 1024 ;   // Base address where host Z80 may access the palette memory, usually located in the last 1024 bytes of addressable memory
parameter GPU_RAM_MIF   = "GPU_MIF.mif" ; // MIF file for the main GPU ram.

Namely the parameter ADDR_SIZE ?

Ah, how did I miss that?   Yes, it compiles now. With 96KB set aside for video RAM for 640x480 with 4 colours, it's still only using 47% of the MAX10's memory.  It should manage 640x480 with 16 colours easily.

Dont forget to set the num_words and place the palette above or equal to the num_words.

Yeah, I've added a couple of parameters to GPU_TOP.sv:

Code: [Select]

parameter int        GPU_MEMORY              = 98304,            // Defines total video RAM in the FPGA, including 1KB palette
                                                                 // For EP4CE10, use 41984
parameter int        NUM_MAGGIES             = 9,                // Number of MAGGIE layers available to GPU
GPU_MEMORY is a quick and easy way to set the total memory to use in the FPGA.  GPU.sv subtracts 1024 bytes from that figure to set the maximum video RAM and specify the start of the palette.

It's late here, so I'll start testing the hardware tomorrow.

[BrianHG]

I guess you can update your pong game to hires, some color & maybe a nice hires font.

[BrianHG]

Current project attached.

Where on earth did you see a 16 bit limit?

vid_osd_generator:

Code: [Select]

output wire [15:0] host_rd_data,
I think that's it (as in I think that's the issue?), but there may be others?

That's DATA, not address.  We have a 16bit data bus in the GPU's ram.  This is why you can generate a 16bit true color display.

[nockieboy]

That's DATA, not address.  We have a 16bit data bus in the GPU's ram.  This is why you can generate a 16bit true color display.

Yes, I know, as soon as I saw your post about the ADDR_SIZE parameter, I realised my mistake. 

On a slight tangent, is there an easy, simple way to upload the GPU project to the DECA's CFM?  It would make my testing of the uCOM/DECA interface vastly easier if the DECA ran the GPU project at power-on, rather than having to write it directly to the FPGA via JTAG every time it is reset or power-cycled.

The manual talks about compressed images and dual-boot shenanigans.  Doesn't help that I'm trying to read it whilst taking part in a Teams meeting.

[BrianHG]

In the programmer, click on the .sof file.
Click on change file.
Select the .pof file instead.
Check the program-configure 'CFM0'
And, go...

When developing with the FPGA, the .sof is better as you are not wasting Write erase cycles.
When you get a code you want to continuously reboot from, then use the .pof file.

[BrianHG]

There is a tiny flat SMD switch hidden under the DECA board to select whether you power up from CFM0, or CFM1.
So, you can have 2 different power-up programs in the DECA board.

[nockieboy]

In the programmer, click on the .sof file.
Click on change file.
Select the .pof file instead.
Check the program-configure 'CFM0'
And, go...

When developing with the FPGA, the .sof is better as you are not wasting Write erase cycles.
When you get a code you want to continuously reboot from, then use the .pof file.

Oh jeez, it's that easy!    Thanks. 

[nockieboy]

Okay, can I just check something?

I need to set some of the GPIOs to specific values in GPU_TOP.sv - namely the direction and output-enables for the various bus buffers.  Only the EA and DATA buffers are actually controlled by the GPU currently, I need to set the rest to values compatible with interfacing to the uCOM.  No matter what I do at the moment, if I power up the DECA and the uCOM together, it locks up and I get no output on the serial console (although the DECA indicates it's running the GPU without issues).

I've checked and double-checked that I'm assigning the correct GPIOs to the right uCOM signals, taking into account the Backbone connectors on the DECA and the routing on the DECA/uCOM interface card.

This is what I'm doing in GPU_TOP.sv - outside of any module instantiations:

Code: [Select]

always @( posedge MAX10_CLK1_50 ) begin

LED[6] <= 1; // Turn the LEDs off that aren't being used
LED[5] <= 0;
LED[4] <= 1;
LED[3] <= 1;
LED[2] <= 1;
LED[1] <= 1;
LED[0] <= 1;

end

// Set default values for Address Bus buffers
assign   GPIO0_D[23] = 1; // EA_DIR
assign   GPIO0_D[22] = 1; // EA_OE
assign   GPIO1_D[20] = 0; // DIR_245
assign   GPIO1_D[19] = 1; // OE_245
assign GPIO0_D[32] = 1; // HI_OE - LOW to enable
assign GPIO0_D[33] = 1; // HI_DIR - HIGH for A>B direction (to FPGA)
assign GPIO0_D[42] = 1; // LO_OE - LOW to enable
assign GPIO0_D[43] = 1; // LO_DIR - HIGH for A>B direction (to FPGA)
// Set default values for unused Control Bus Outputs
assign GPIO0_D[8]  = 0; // WAIT output
assign GPIO0_D[9]  = 0; // WR output
assign GPIO0_D[10] = 0; // M_REQ output
assign GPIO0_D[11] = 0; // RD output
assign GPIO0_D[12] = 0; // BUS_REQ output
assign GPIO0_D[13] = 0; // IO_REQ output
The LEDs are not illuminated apart from LED5 and LED7 (which is wired to the STATUS_LED output in the GPU module), as expected.

I'm just trying to work out what's wrong with the bus interface currently.  The uCOM boots fine if the DECA isn't powered, but if it is then I get nothing on the serial console.  So I've modified GPU_TOP.sv slightly to disable ALL the bus buffers and set the DATA direction to the DECA, and turn off all the transistors driving the 5V control lines for WAIT, WR, M_REQ, RD, BUS_REQ and IO_REQ so they SHOULD be floating at the DECA interface (actually pulled high thanks to the pullups on the CPU card).  I've attached GPU_TOP.sv for info - I'm assuming that I'm assigning values to the GPIOs correctly as per the code above?

If not, that would explain why the uCOM is locking up when the DECA has power.

Otherwise, I'm going to have to dig the logic analyser out and hunt down a wall-wart power supply for the DECA (I guess there's a chance there's not enough juice getting to the system via one shared USB lead).

UPDATE:  Have got the uCOM booting up to the start menu.  Just need to do some work to get to the DMI (my custom monitor) so I can start testing the GPU.  Still not 100% yet, but getting there.  Interestingly, I've not changed anything except wired the Z80_CLK and Z80_RST GPIOs to the GPU module.  Am going to continue adding connections step-by-step. 

[BrianHG]

I'm curious, did you verify that the IO are producing 3.0-3.3v out.  If they are 2.5v out, you may need to lower the 3.3v voltage regulator on your PCB just in case.

UPDATE:  Have got the uCOM booting up to the start menu.  Just need to do some work to get to the DMI (my custom monitor) so I can start testing the GPU.  Still not 100% yet, but getting there.  Interestingly, I've not changed anything except wired the Z80_CLK and Z80_RST GPIOs to the GPU module.  Am going to continue adding connections step-by-step. 

Yes, not wiring the Z80 CLK and reset would freeze up your data bus.