@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?
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.
(WTF can you do with 88 layers?)
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
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!
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.
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?
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.
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.
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 ( ) );
inout [43:0] GPIO0_D,
inout [22:0] GPIO1_D,
input [21:0] GPIO0_D,
inout [29:22] GPIO0_D,
output [43:30] GPIO0_D
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]} )