FPGA VGA Controller for 8-bit computer

[nockieboy]

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.

No, haven't verified that yet.  The buffers are powered by the 3.3v supply from the DECA board, though.  Is the IO voltage specified in the Pin Manager in Quartus, or should I be checking elsewhere?

The Pin Manager shows all the GPIOs set to 3.3-V LVTTL.

[BrianHG]

Quartus actually doesn't care.  Changing any pin IO voltages or buffer type there only effects the pins reported FMAX and potentially slightly skew the input threshold trigger point.  And any IO type chosen will run circles around a Z80's 8MHz.  It's how it's VCCIO is wired on the DECA board and I was curious.  I know on my side that if it were actually 2.5v, it would have no effect on the connected RS232-USB dongle I'm using as it's RXD input threshold is around 1v.

Driving 3.3v into a 2.5v IO pin wont do damage as the difference is 0.8v, though the over-voltage limit is 0.7v, the series resistance of the CMOS logic gates feeding the MAX10 input right at the top 3.3v just wont have enough current to really do anything.  You would be driving the input protection diodes with probably < 1 ma.

[nockieboy]

I'm going to have to dig the oscilloscope out, and/or the logic analyser, to be sure I guess. 

All I can say is that the DECA is clearly able to drive the OE pins high on the 245 buffers, and/or the DIR pins on same, as I'm able to get the uCOM to the bootstrap menu now.  Unfortunately it's locking up when I try to switch to the DMI, but that's probably something to do with the DMI starting up (although it worked fine without a GPU or DECA attached previously).

I need some more time to plod through this step-by-step and see where the issue is, but have made some progress today.

[nockieboy]

I've almost got the DECA working with the uCOM now, the only issue I'm facing is that bit 3 on the data bus seems to be permanently high when reading from the DECA, and no writes are possible.  When I read a 16K bank of RAM from the GPU, all returned bytes have bit 3 set, whether they should have or not.  Writing to GPU RAM isn't working at all - the values aren't changed when read back.

The bit 3 issue could be a damaged 245 data buffer.  There's no issue with the data bus on the uCOM side - everything else is running without fault on the Z80, so it seems either the 245 buffer is faulty, there's a short on the DECA side of the 245 buffer, or the DECA GPIO (GPIO1_D[15]) isn't working as expected.

I can't build another DECA interface board just yet (I'm lacking the key 46-pin Beaglebone headers), so I'll conduct some more tests for shorts and see if I can replace the data buffer without damaging the PCB. 

[BrianHG]

Time to get out that DVM continuity tester.
Test for shorts on the PCB.
Also, go over the schematic.

[BrianHG]

My DDR3 controller is now available here:

https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3606415/#msg3606415

[nockieboy]

My DDR3 controller is now available here:

https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3606415/#msg3606415

I don't think I'm making an overstatement if I say how blown away I am at the level of complexity and work that has gone into that piece of work.  I think it'd take me a university course and ten years of working in the industry to understand all of the considerations and technicalities you're accounting for in that project.  Mind. Blown. 

And a massive 'thank you'. 

In other news, I've sorted the D3 HIGH issue.  I was prepping to remove the LVC245 that was buffering the data bus when I just had the mad impulse to drag the soldering iron over the pins on the 5V side, as the DQ3 pin looked a little poorly connected.  That seems to have fixed the issue.    Though I'm not sure why a poor connection would result in consistent HIGHs on the line. 

Now the uCOM is reading from the GPU on the DECA perfectly, I just need to sort out why it won't write data to the GPU.  Give me another day or two and hopefully I'll have that nailed down, then I can sort out the HDMI output (which should just be messing with Quartus) and we can get started with testing the DDR3 controller. 

[nockieboy]

Write problem almost sorted.  I'd assigned Z80_WR to the wrong GPIO (the WR output instead of the WR input!) 

I can now write to the GPU RAM, but I can only write 0xFF.  Whatever I write to GPU RAM, it looks like it's writing 0xFF instead of the value I'm sending.   Bearing in mind that the uCOM can read the GPU's RAM with no issues or faults, it doesn't appear to be an issue reading the written data back, it appears that the GPU is taking the written value as 0xFF and nothing else.  Any ideas what could cause this?

I'll go check the DATA 245 buffer again, in case there's an issue with the DIR line (the DATA 245 seems to have caused me all my problems so far). 

EDIT:  I'm just wondering if this bit of HDL could be the cause of the problem?  Lines 305-312 in GPU.sv:

Code: [Select]

assign Z80_WR_data[7] = data_en ? Z80_RD_data[7] : 1'bz;
assign Z80_WR_data[6] = data_en ? Z80_RD_data[6] : 1'bz;
assign Z80_WR_data[5] = data_en ? Z80_RD_data[5] : 1'bz;
assign Z80_WR_data[4] = data_en ? Z80_RD_data[4] : 1'bz;
assign Z80_WR_data[3] = data_en ? Z80_RD_data[3] : 1'bz;
assign Z80_WR_data[2] = data_en ? Z80_RD_data[2] : 1'bz;
assign Z80_WR_data[1] = data_en ? Z80_RD_data[1] : 1'bz;
assign Z80_WR_data[0] = data_en ? Z80_RD_data[0] : 1'bz;
I'm just trying to work out exactly what's going on here to ascertain if this is the cause of the problem.  Would certainly explain the 0xFF's being written to GPU RAM if there's an issue with data_en... 

[nockieboy]

Ah, BrianHG - going to need your input on this one as the HDL is confusing me more than a schematic would do.

It looks (to my untrained eye) that the code I pasted above is the cause of the problem.  data_en is being used to determine if the data written to GPU RAM is the data written by the Z80, or a HIGH-Z bus?  But it looks as though there's an issue with how the data buses are wired up in GPU.sv or GPU_TOP.sv - I can't figure out if data is coming or going to GPU.sv, but it looks as though there could be a typo in the way the READ or WRITE data bus is being assigned in GPU.sv?  If you have a second later, could you confirm for me that it is wired correctly in the GPU.sv?

I'll keep plugging away at it, but I'm struggling to understand what's going on.  This is why I always liked the schematic top-level file. 

[BrianHG]

EDIT:  I'm just wondering if this bit of HDL could be the cause of the problem?  Lines 305-312 in GPU.sv:

Code: [Select]

assign Z80_WR_data[7] = data_en ? Z80_RD_data[7] : 1'bz;
assign Z80_WR_data[6] = data_en ? Z80_RD_data[6] : 1'bz;
assign Z80_WR_data[5] = data_en ? Z80_RD_data[5] : 1'bz;
assign Z80_WR_data[4] = data_en ? Z80_RD_data[4] : 1'bz;
assign Z80_WR_data[3] = data_en ? Z80_RD_data[3] : 1'bz;
assign Z80_WR_data[2] = data_en ? Z80_RD_data[2] : 1'bz;
assign Z80_WR_data[1] = data_en ? Z80_RD_data[1] : 1'bz;
assign Z80_WR_data[0] = data_en ? Z80_RD_data[0] : 1'bz;
I'm just trying to work out exactly what's going on here to ascertain if this is the cause of the problem.  Would certainly explain the 0xFF's being written to GPU RAM if there's an issue with data_en... 

Ok, what's going on here is if the signal 'data_en' is low, then the wires 'Z80_WR_data[ x ]' will be tristate.

If 'data_en' is high, then the wires 'Z80_WR_data[ x ]' will output the 'Z80_RD_data[ x ]'.

This means the the 'Z80_WR_data[ x ]' should be sent directly to your FPGA IO pins.

Now, to write data, this means you need to send the IO pins to the Z80 bridge,,,, wait

This does sound fishy as the line should really read:

Code: [Select]

assign Z80_data[7] = data_en ? Z80_RD_data[7] : 1'bz;
assign Z80_data[6] = data_en ? Z80_RD_data[6] : 1'bz;
assign Z80_data[5] = data_en ? Z80_RD_data[5] : 1'bz;
assign Z80_data[4] = data_en ? Z80_RD_data[4] : 1'bz;
assign Z80_data[3] = data_en ? Z80_RD_data[3] : 1'bz;
assign Z80_data[2] = data_en ? Z80_RD_data[2] : 1'bz;
assign Z80_data[1] = data_en ? Z80_RD_data[1] : 1'bz;
assign Z80_data[0] = data_en ? Z80_RD_data[0] : 1'bz;

Or, make your life easier:

Code: [Select]

assign Z80_data = data_en ? Z80_RD_data : 8'bzzzzzzzz;
And for the other direction,

However, you will need to kill line 684:

Code: [Select]

assign Z80_data = Z80_WR_data;
And change line 243 in 'Z80_bridge_v2.sv' from:

Code: [Select]

.Z80_wData(Z80_WR_data),to:

Code: [Select]

.Z80_wData(Z80_data),This ties the Z80_data pins directly to your 'Z80_bridge_v2.sv' Z80 data input.

Remember, the GPU.sv I gave you was generated automatically by Quartus from the original GPU.bdf, hence the reason I said you need to go through it, compare it to your original .bdf and relable some of the wires to make more sense.

[BrianHG]

Yes, a lot of the coding on the GPU wasn't organized to be viewed strictly from text source code.

IE, the Z80 bridge should directly drive the Z80 io pins and should have handled the tristate internally.

If you look at my HDMI DDR3 example, it reads much easier than this Quartus auto-generated GPU.sv.

I made it so even you can follow it.

[nockieboy]

I made it so even you can follow it.

Gee, thanks. 

[nockieboy]

Or, make your life easier:

Code: [Select]

assign Z80_data = data_en ? Z80_RD_data : 8'bzzzzzzzz;
And for the other direction,

However, you will need to kill line 684:

Code: [Select]

assign Z80_data = Z80_WR_data;

Sorry, what should go for 'the other direction'?

Shouldn't it be something like this?

Code: [Select]

assign Z80_data = data_en ? Z80_RD_data : Z80_WR_data;


[BrianHG]

No, Z80 data pins must be set to a value, or HI-z so that those pins become an input.

The 'Z80_data[ x ]' are the IO pins.  Reading this wire will always tell you the number whether it is an input of output.

This is why this one is tied to the read data in on the Z80 bridge.

Now, when you say 'Z80_data[ x ]' = [something], if that something isn't a 'z', it becomes an output.

So my code changes I recommended are correct.

Quartus made the booboo of making the output pins = to the assigned 'Z80_WR_data[ x ]' which was correct.  But, there was no way to reverse send the data from the Z80 IO pins when set to 'z'  back into the bridge unless the original line '684' was a bi-directional assign.  If that assign is bi-directional, then there was nothing wrong with the original code and we need to look for the error elsewhere.

Question: are you able to write valid changes to the control registers, IE screen position offset, zoom size.  These are logic registers and are not part of the core memory.  Do the settings take effect properly, yet read 'FF'?

[BrianHG]

Does the RS232 debugger work?
Can you read and write valid data there?
This will at least tell you the core ram is receiving and writing valid data internally.

As for the Z80 receiving 'FF' writes, usually in tristate, the inputs on the FPGA have a weak pull-up, so, if the 245's is set to the wrong direction, or the245's  OE is disabled, you will always write all 'FF'.

[nockieboy]

No, Z80 data pins must be set to a value, or HI-z so that those pins become an input.

The 'Z80_data[ x ]' are the IO pins.  Reading this wire will always tell you the number whether it is an input of output.

This is why this one is tied to the read data in on the Z80 bridge.

Now, when you say 'Z80_data[ x ]' = [something], if that something isn't a 'z', it becomes an output.

So my code changes I recommended are correct.

Quartus made the booboo of making the output pins = to the assigned 'Z80_WR_data[ x ]' which was correct.  But, there was no way to reverse send the data from the Z80 IO pins when set to 'z'  back into the bridge unless the original line '684' was a bi-directional assign.  If that assign is bi-directional, then there was nothing wrong with the original code and we need to look for the error elsewhere.

Okay, so just to confirm my understanding of the required changes:

I change all the previous assigns:

Code: [Select]

assign Z80_WR_data[7] = data_en ? Z80_RD_data[7] : 1'bz;
assign Z80_WR_data[6] = data_en ? Z80_RD_data[6] : 1'bz;
assign Z80_WR_data[5] = data_en ? Z80_RD_data[5] : 1'bz;
assign Z80_WR_data[4] = data_en ? Z80_RD_data[4] : 1'bz;
assign Z80_WR_data[3] = data_en ? Z80_RD_data[3] : 1'bz;
assign Z80_WR_data[2] = data_en ? Z80_RD_data[2] : 1'bz;
assign Z80_WR_data[1] = data_en ? Z80_RD_data[1] : 1'bz;
assign Z80_WR_data[0] = data_en ? Z80_RD_data[0] : 1'bz;

to this:

Code: [Select]

assign Z80_data = data_en ? Z80_RD_data : 8'bzzzzzzzz;
And the remove line 684:

Code: [Select]

assign Z80_data = Z80_WR_data;
And change line 243 to:

Code: [Select]

.Z80_wData(Z80_data),
Seems to make sense.

Question: are you able to write valid changes to the control registers, IE screen position offset, zoom size.  These are logic registers and are not part of the core memory.  Do the settings take effect properly, yet read 'FF'?

It seems ALL writes were passed through as 0xFF.  I confirmed that the block of code I originally identified was the problem by changing some of the values from 1'bz to 1'b0 so that instead of 0xFF, 0XD7 would be written instead and - lo and behold - the uCOM was reading back 0xD7 all over the place where it had written to. 

Does the RS232 debugger work?
Can you read and write valid data there?
This will at least tell you the core ram is receiving and writing valid data internally.

I haven't gotten that far with debugging, I'm fairly sure I've found the issue.  I'm just in the process of compiling and testing the code changes you've suggested now.

[BrianHG]

As for the Z80 receiving 'FF' writes, usually in tristate, the inputs on the FPGA have a weak pull-up, so, if the 245's is set to the wrong direction, or the245's  OE is disabled, you will always write all 'FF'.

[nockieboy]

Those code changes fixed the issue.  The uCOM is able to read and write GPU RAM with no issues now. 

Might have some time to start on converting the video output to use the HDMI connector on the DECA.  Without the schematic overview, this might cause me to be a little more confused than usual. 

I guess all the components needed are already in the project, as it's a hijacked HDMI_TX project.  I just need to wire up the RGB outputs from the pixel pipeline into the HDMI inputs somewhere on the HDMI_TX components.  Will have more time to look at this tomorrow. 

[BrianHG]

Man, the HDMI is the easiest part.
I already left the I2C config in there to power up the HDMI IC.
Just connect the IOs to your module.

Look at my DDR3 1080p output demo to see which IO drive the IC.

[nockieboy]

Look at my DDR3 1080p output demo to see which IO drive the IC.

Did you post the full project for that?    I've only seen the .sof files?

[BrianHG]

Look at my DDR3 1080p output demo to see which IO drive the IC.

Did you post the full project for that?    I've only seen the .sof files?

Uhh, did you download my DDR3 project on my DDR3 thread.
There are full projects there, 4 of them + 2 additional source directories.
My instructions tell you which folders you can open in Quartus as a project.
Then go to the top file in the project and look.

[nockieboy]

Uhh, did you download my DDR3 project on my DDR3 thread.
There are full projects there, 4 of them + 2 additional source directories.
My instructions tell you which folders you can open in Quartus as a project.
Then go to the top file in the project and look.

Ah, no.  I was hunting back in this thread and the Arrow DECA thread. 

[nockieboy]

Okay, the DECA GPU is working as expected with full access to the GPU memory for the host and a good, stable HDMI output (note: I've returned the I2C_HDMI_Config.v setting to HDMI from DVI).  The whole setup is infinitely more stable than the mess of wires I had previously bridging the old EasyFPGA EP4CE10 board via converters/buffers to the uCOM when developing the VGA output!

Next step is to test the WAIT signal and see if the GPU can stall the Z80 for time during memory reads and writes. 

[BrianHG]

Does your Z80 system have a clock/timing chip somewhere on it?

IE, can you test/time the speed of your reads?

This way, if we artificially enter a read delay with wait, can you tell is the performance slows down.

What I am thinking is during read cycle, add a timer/counter to delay placing the correct data on the Z80 output bus holding the wait and see if you can still read correct data.

[nockieboy]

Does your Z80 system have a clock/timing chip somewhere on it?

IE, can you test/time the speed of your reads?

This way, if we artificially enter a read delay with wait, can you tell is the performance slows down.

What I am thinking is during read cycle, add a timer/counter to delay placing the correct data on the Z80 output bus holding the wait and see if you can still read correct data.

It does - a Z80 CTC - but I'm wondering if it would be much easier to just add a constant delay in the GPU before returning any data, then up that delay until it becomes a noticeable slowdown when reading a 256-byte block of GPU RAM, for example?