FPGA VGA Controller for 8-bit computer

[nockieboy]

@Nockieboy, looking at your PONG video above, it looks like you are getting an impossible interlace artifact.  Do you actually see that in person, or is it just your video camera recording?

Nope, not getting any artefacts on screen?  It's most probably the video recording, scan rates not matching up, something like that.

[BrianHG]

I'm talking about this 'zippery' artifact during the motion of the ball.  I assume it's not there in real life, correct?

[nockieboy]

No, that's definitely an artefact caused by my camera - or the video encoding/conversion. 

[BrianHG]

All software DDR3 controller update....

16 read, 16 write ports with smart cache, configurable priority encoding and data width per port done.
4096x2160 screen scrolling on a 1080p 32bit color out HDMI with geometry test drawing program done.
Auto DDR3 PLL calibration finally done.

  !!!400MHz with data integrity!!!   With a +/- 3 PLL tuning step valid data window.

Yes, Altera/Intel's software DDR3 solution is only rated at 300MHz.  Not even the minimum 303MHz rated by the DDR3 spec.
It also only has a single read and write port.

It's Altera's hardware dependent PHY which has multiport and runs at 400MHz.

Things left to do:
Upgrade my software FIFOs in my multiport module as they currently have a bottleneck of 125MHz because of the way they are written.
Improve the cross clock domain boundary as the DDR3 sequencer sends commands to the DDR3 CK clock domain.  (The solution I'm looking at might get the DDR3 running at 500MHz on a -6, but definitely working at >300MHz on a -8, even on old Cyclone III & IV.)
The goal for the above 2 is at least 300MHz allowing for a 'Full Rate' controller where as if you want the 400MHz (officially overclocking Altera's IOs), you will probably need to run it at 'Half Rate', or 'Quarter Rate'.

Without the Multiport module, IE, directly communicating with my DDR3 controller, 1 read & 1 write port, the controller consumes just under 3K logic gates for a 16bit DDR3 ram chip.  And it is smart, keeps banks open and aware when you access across banks, it will keep banks open if it can, only close and open individual banks as it needs to.

I should be ready to post the source next week.


Since your video output on the final board will be limited to 720p@60hz, or 1080p@30hz, and you will have 2 DDR3 16 bit ram chips, here is what the maximum video layers you can produce at the following bit depths:

Color depth ->  1080p@60Hz, 720p@60hz/1080p@30hz,  480p@60hz
32bit                4                , 8                                 ,   22
16bit                8                , 16                               ,   44
8bit                 16               , 32                               ,   88    (WTF can you do with 88 layers?)

This does not include the additional 15 layers you get with the core ram's 128kb memory.

Anyways, @nockieboy, make sure your DECA board works and you can at least output the HDMI test program by sending it just the .sof file in the deca example source code demos.  I will be providing a DDR3 demo .sof file in a few days.

[Ted/KC9LKE]

Brian,

Which version of Quartus Prime Lite would be the one to use with the DECA board and this project?
I read your caveat on the DECA thread about opening the examples with newer versions of Quartus and them being changed and wont work then with an older Quartus version afterwards.
If I have it correct.
I am ok with that, as I will use a copy of the DECA examples.

Thanks

Ted

[nockieboy]

All software DDR3 controller update....

16 read, 16 write ports with smart cache, configurable priority encoding and data width per port done.
4096x2160 screen scrolling on a 1080p 32bit color out HDMI with geometry test drawing program done.
Auto DDR3 PLL calibration finally done.

  !!!400MHz with data integrity!!!   With a +/- 3 PLL tuning step valid data window.

...

Since your video output on the final board will be limited to 720p@60hz, or 1080p@30hz, and you will have 2 DDR3 16 bit ram chips, here is what the maximum video layers you can produce at the following bit depths:

Color depth ->  1080p@60Hz, 720p@60hz/1080p@30hz,  480p@60hz
32bit                4                , 8                                 ,   22
16bit                8                , 16                               ,   44
8bit                 16               , 32                               ,   88    (WTF can you do with 88 layers?)

This does not include the additional 15 layers you get with the core ram's 128kb memory.

Anyways, @nockieboy, make sure your DECA board works and you can at least output the HDMI test program by sending it just the .sof file in the deca example source code demos.  I will be providing a DDR3 demo .sof file in a few days.

Err... Wow! 

I've yet to test my uCOM/DECA interface, I've had no time at all to do anything recently other than build the interface card when the PCBs arrived.  As soon as I get a chance, I'll get the HDMI test program uploaded and check it and start making in-roads into porting the GPU project onto the DECA to test the interface with the uCOM.

(WTF can you do with 88 layers?)

Err... 88 sprites?  Some a-m-a-z-i-n-g parallax scrolling that knocks Shadow of the Beast into a cocked, Gouraud-shaded hat?  The mind boggles, but I'm sure someone out there could find a use for it!

[BrianHG]

Brian,

Which version of Quartus Prime Lite would be the one to use with the DECA board and this project?
I read your caveat on the DECA thread about opening the examples with newer versions of Quartus and them being changed and wont work then with an older Quartus version afterwards.
If I have it correct.
I am ok with that, as I will use a copy of the DECA examples.

Thanks

Ted

The code I release should compile in DECA's original version 15 as well as the latest version 20.  I have both versions of Quartus installed.  My code should work in Quartus V13 as well for support of older Cyclone III.

[BrianHG]

  Make that 450MHz / 900mtps 

Though, the FPGA is being overclocked...

500Mhz completely fails to do anything.  Though, an older Cyclone IV might work as their core is ever so slightly faster and we already successfully got a CycloneIV to output 1080mbps with my posted HDMI transmitter core.

[BrianHG]

Err... 88 sprites?  Some a-m-a-z-i-n-g parallax scrolling that knocks Shadow of the Beast into a cocked, Gouraud-shaded hat?  The mind boggles, but I'm sure someone out there could find a use for it!

If it were small sprites, yes you have enough gates to do it.  But, since your sprites are actually over-window screen sized layers, you might chew up a good number of gates superimposing 88x256 color layers.  Though, this FPGA is kinda big compared to your 10k gate CIV board.

Also, you only have 16 read ports.  Though, you can multiplex a few read ports to multiply their number by, say 4 each for 480p.  If you use 10 ports to draw the screen, multiply those by 4 and you will have 40x 8bit or 16bit layers from the DDR3 on a 480p display.

[nockieboy]

I now have a working HDMI test output on the DECA whilst it's plugged into the uCOM, so next step is to port the GPU project over and wire it up properly so it works with the uCOM and replaces the dedicated GPU card.  Then, get the HDMI output working.  Maybe some progress on this next week. 

[NorthGuy]

Make that 450MHz / 900mtps 

Good Job!

[nockieboy]

Make that 450MHz / 900mtps 

Though, the FPGA is being overclocked...

500Mhz completely fails to do anything.  Though, an older Cyclone IV might work as their core is ever so slightly faster and we already successfully got a CycloneIV to output 1080mbps with my posted HDMI transmitter core.

Sorry, missed this with my previous reply.  That's some serious performance out of a system that isn't specced to do more than 300MHz - well done!  Will there be any issues transferring that performance to a Cyclone V?  (I know currently we're using the MAX10 as the new testbed, but I'm assuming you're still working 'within' the specs of the CV?)

[BrianHG]

Make that 450MHz / 900mtps 

Though, the FPGA is being overclocked...

500Mhz completely fails to do anything.  Though, an older Cyclone IV might work as their core is ever so slightly faster and we already successfully got a CycloneIV to output 1080mbps with my posted HDMI transmitter core.

Sorry, missed this with my previous reply.  That's some serious performance out of a system that isn't specced to do more than 300MHz - well done!  Will there be any issues transferring that performance to a Cyclone V?

Well, if you are using the -8, you will safely achieve the 300MHz mark.  The DECA board has a -6.  The Cyclone V should pretty much match the MAX10.  The number of layers I quoted was for running the ram at 300MHz, though, 400MHz would give you a additional nice margin.  Do not expect the -8 to achieve 450MHz and my multi-port module may also become a bottleneck unless you disable a number of the features which make it really smart.  Though, I'm coding right now trying to fix that.

[nockieboy]

Make that 450MHz / 900mtps 

Though, the FPGA is being overclocked...

500Mhz completely fails to do anything.  Though, an older Cyclone IV might work as their core is ever so slightly faster and we already successfully got a CycloneIV to output 1080mbps with my posted HDMI transmitter core.

Sorry, missed this with my previous reply.  That's some serious performance out of a system that isn't specced to do more than 300MHz - well done!  Will there be any issues transferring that performance to a Cyclone V?

Well, if you are using the -8, you will safely achieve the 300MHz mark.  The DECA board has a -6.  The Cyclone V should pretty much match the MAX10.  The number of layers I quoted was for running the ram at 300MHz, though, 400MHz would give you a additional nice margin.  Do not expect the -8 to achieve 450MHz and my multi-port module may also become a bottleneck unless you disable a number of the features which make it really smart.  Though, I'm coding right now trying to fix that.

Availability of 5CEBA2s seems to have dropped through the floor with LCSC. Might have to hunt around for an alternative supplier when the time comes and, if I'm going to be spending 'big bucks' on a supplier like Mouser, may as well go for the -6 variant.

I've got some 'practice' test boards coming from JLCPCB so I can perfect my QFN-56 soldering skills and nail down my USB keyboard interface design.  I'm opting for an RP2040 microcontroller to handle the USB port, after finding the MAX3421E a bit too complex and low-level for my HDL skillset.  The RP2040 is massive overkill, but it's cheap (and newly available), without too many supporting components.  Plus I could off-load the PS/2 management to it if I decide to retain the PS/2 port (certainly not definite, but a nice-to-have if I have the room).

I may have asked this question before - but what would be the preferred interconnect between the RP2040 and the FPGA?  I could use I²C, SPI or UART and I've listed them in my order of preference, I guess.  Part of the reason for mentioning all this is that perhaps people may have ideas of alternative uses I could put the RP2040 (and it's 2MB flash memory) to use, other than just to manage the USB port for keyboard/mouse peripherals...?  It's highly flexible, easily programmable and the limit really is what I wire its GPIOs to on the final board.

[BrianHG]

For those who bought the MAX 10 DECA board, I have a graphics test demo here:
https://www.eevblog.com/forum/fpga/arrow-deca-max-10-board-for-$37/msg3600487/#msg3600487

[BrianHG]

Patched functioning version of the DDR3 demo found here:

https://www.eevblog.com/forum/fpga/arrow-deca-max-10-board-for-$37/msg3601248/#msg3601248

Just some house cleaning work needed on the code and I will release the source...

[nockieboy]

I've set up the pin assignments for the GPU project on the DECA board, have left out the PS/2, serial debug interface, R, G and B outputs and VGA signals for the moment as I just want to test if it will work with the uCOM without crashing it and respond to memory access.

I've also imported the pin assignments from the HDMI_TX DECA demo project, so that the MAX10 is set up with all the usual pin assignments specific to the DECA board, like clock inputs, switches, buttons, LEDs and other peripherals.  As a result there's two node names assigned to some pins - i.e. I've got all the Z80_ADDR[] nodes assigned to pins on the MAX10 that are also assigned to GPIO_D[] node names because of the DECA pin assignment import.  I'm assuming that won't cause any issues and I could use either node name in the project without issue, as long as there's no conflict in direction or I/O standard (i.e. trying to set a GPIO pin to output when it's already being used as an input for a Z80 address line)?

[BrianHG]

All you need to use is the 'ASSIGN' verilog command.  The GPIOs should be a 3.3v IO pin.

IE: Addr inputs:

assign Z80_addr[21:0] = GPIO0_D[40:20] ;

to send data out:

assign  GPIO0_D[10] = Z80_245data_dir_r ;

For IOs, here is what you do, to send data out with an output enable:  (IE, when Z80_rData_ena_r is high, the Z80_rData_r is sent out, otherwise it is in HI-z state.)

assign GPIO0_D[7:0] = Z80_rData_ena_r ? Z80_rData_r : 8'bzzzzzzzz ;

And take data back in...
assign Z80_wData = GPIO0_D[7:0] ;

You can assign wire-by-wire if you need to because of PCB routing.

The pins should already be assigned as 'INOUT'...

You can always clean up your Z80 bridge verilog code to make the Z80 data bus an INOUT as well and handle the tristate inside the Z80 bridge code.  Then, instead of assign, you would just tie the correct 'GPIO0_D[x:x]' straight to the Z80_bridge port module.

[nockieboy]

All you need to use is the 'ASSIGN' verilog command.  The GPIOs should be a 3.3v IO pin.

IE: Addr inputs:

assign Z80_addr[21:0] = GPIO0_D[40:20] ;

to send data out:

assign  GPIO0_D[10] = Z80_245data_dir_r ;

For IOs, here is what you do, to send data out with an output enable:  (IE, when Z80_rData_ena_r is high, the Z80_rData_r is sent out, otherwise it is in HI-z state.)

assign GPIO0_D[7:0] = Z80_rData_ena_r ? Z80_rData_r : 8'bzzzzzzzz ;

And take data back in...
assign Z80_wData = GPIO0_D[7:0] ;

You can assign wire-by-wire if you need to because of PCB routing.

Oh, so what I've done is wrong?  I've assigned all the GPU node names to the appropriate FPGA pins to match the GPIO they should be connected up to? 

Can I put these assigns in a separate .sv file in the project or do they need to go into the relevant module where the nodes names are used?

The pins should already be assigned as 'INOUT'...

They don't seem to be?

You can always clean up your Z80 bridge verilog code to make the Z80 data bus an INOUT as well and handle the tristate inside the Z80 bridge code.  Then, instead of assign, you would just tie the correct 'GPIO0_D[x:x]' straight to the Z80_bridge port module.

  So I could remove the tri-state module from the design and connect the Z80_WR_data[7..0] bidir pins directly to the Z80_bridge?  Not sure what that should look like?  Need an input and an output from the Z80_bridge module and would only have one set of bidir pins?

Project attached if it helps to view the pin assignments.

[BrianHG]

Before starting, open your GPU_EP4CE10 and from the GPU.bdf, make a GPU.v to replace it.
Actually, cancel that.  You will need a GPU.sv since it has an array 'GPU_HW_REGS_BUS' and Altera skips that net name everywhere since it isn't supported in an old verilog .v.  I've attached an untested .sv I made.  Use that file.  You should try to clean it up once you basic GPU is working.

Now, for the DECA board, copy the project 'DECA_HDMI_TX', rename and take a look at file HDMI_TX.v.

Rename it to GPU_TOP.sv.
Rename in the 'module HDMI_TX' to 'module GPU_TOP'.
Set that file to top hierarchy.

Inside there, place an intimation of your GPU.sv #(.parametersnames(),.,.,...) GPU_CORE (.GPUIOS,.,.,...) ;

Wire all the IO.  Also, the Z80_data is already combined here into a tristate INOUT port, so you do not need to do what I said in the last post.

Most of the GPUIOs can be tied directly to the DECA's IO labeled in GPU_TOP.sv which was once HDMI_TX.sv.

Include my attached GPU.sv source file plus all the other .sv source files you have & add them to the project. 

If you are still having trouble, then I will look at your source code.


Once working, you will need to go through the my GPU.sv, look at your original GPU.bdf and rename all the 'SYNTHESIZED_WIRE_#'s to something more sensible.

[BrianHG]

This is the code you place in GPU_TOP.sv which was the HDMI_TX.v:

Code: [Select]

GPU #(
    .HW_REGS     ( 9  )
) GPU_CORE (
.clk54m      (    ),
.uart_rxd    (    ),
.Z80_CLK     (    ),
.Z80_M1      (    ),
.Z80_MREQ    (    ),
.Z80_WR      (    ),
.Z80_RD      (    ),
.Z80_IORQ    (    ),
.IEI         (    ),
.Z80_RST     (    ),
.RESET_PIN   (    ),
.Z80_ADDR    (    ),
.hs          (    ),
.vs          (    ),
.uart_txd    (    ),
.LED_txd     (    ),
.LED_rdx     (    ),
.vde         (    ),
.pixel_clk   (    ),
.Z80_INT_RQ  (    ),
.IEO         (    ),
.SPEAKER     (    ),
.EA_DIR      (    ),
.EA_OE       (    ),
.STATUS_LED  (    ),
.DIR_245     (    ),
.OE_245      (    ),
.PS2_CLK     (    ),
.PS2_DAT     (    ),
.b           (    ),
.g           (    ),
.r           (    ),
.Z80_data    (    )  );

Just place in the correct IO pins inside the empty brackets...
Also, vertically sort and organize the IOs by section and priority...

[BrianHG]

Just use the attached file, here you go:
Edit the net names in the brackets located on line 439.

You will want to pass the core ram size parameters to the top of the module GPU.sv and pass them to the top of GPU_TOP.sv where I left room right at the top of the file as well as the number of layers.

[nockieboy]

Okay, I think I'm following what you've said to do.  I've just copied the HDMI_TX project, inserted your GPU_TOP.sv file and set it as the top-level design entity, then copied all the .sv, .v, .MIF files and the SDC1.sdc file from the GPU project into the new project.  So I guess all the pin assignments will remain the same as specified by the DECA example project I've hijacked, I just need to wire up the node names in GPU_CORE  in GPU_TOP.sv to the appropriate DECA board IO names.

One question, though - GPU_TOP.sv specifies all GPIO0_D and GPIO1_D IOs as bidirectional INOUTs.  I assume it won't be an issue if I specify certain GPIOx_Ds as inputs or outputs - is there a cleaner way to do that other than just 'breaking out' the lines...

Code: [Select]

    inout             [43:0]        GPIO0_D,
    inout             [22:0]        GPIO1_D,
... and doing something like this:

Code: [Select]

    input             [21:0]        GPIO0_D,
    inout             [29:22]       GPIO0_D,
    output            [43:30]       GPIO0_D
(for example)?

[BrianHG]

Do not change the DECA definitions.  INOUT is either direction.  If you tie a pin, even part of a port, to an output, it will be changed into an output.  If you tie it to an input, it will become an input.

Yes, at line 439, just place in the correct partial buss name from 'GPIO0_D[x:y]'.

Also, if the bus is broken up on the connector, you can use as an example:

Code: [Select]

Unbroken bus:
.Z80_data    (  GPIO0_D[15:8]  )

Broken bus due to wiring Example A:

.Z80_data    (  {GPIO0_D[15:12],GPIO0_D[3:0]} )

Example B:

.Z80_data    (  {GPIO0_D[20],GPIO0_D[29],GPIO0_D[15],GPIO0_D[7],GPIO0_D[6],GPIO0_D[2],GPIO0_D[30],GPIO0_D[21]} )


[nockieboy]

I'm assuming it's okay to leave assignments empty where there is no connection required?

I'm getting an error when I try to compile:

Error (10228): Verilog HDL error at altpll0.v(39): module "altpll0" cannot be declared more than once

The HDMI_TX project that I've used as the 'donor' for the new GPU project obviously has a PLL module in it, but if nothing's referring to it (i.e. in GPU_TOP or GPU.sv) then will the compiler still try to build it, or am I barking up the wrong tree?

Project attached for info.