FPGA VGA Controller for 8-bit computer

[BrianHG]

Also, in the new Z80_bus_interface, change line 349 from:

Code: [Select]

  if ( (z80_read_memory_1s || z80_read_opcode_1s) && mem_in_bank && memrange[2:0] == 3'b111 ) begin  // *** START OF Z80 READ OP FROM GPU RAM ***
to:

Code: [Select]

  if ( (z80_read_memory_1s) && mem_in_bank && memrange[2:0] == 3'b111 ) begin  // *** START OF Z80 READ OP FROM GPU RAM ***
Dont forget to read my previous post on the previous page.

[nockieboy]

It doesn't like those settings either.  I've made both changes and all I'm getting is a blank screen.  The debugger and Z80 both agree on the contents of GPU RAM page 0 and it looks all good, just the cache miss read errors at the start of each row for the Z80.

Sometimes after a reset I see the two HW trigger lines (as previously) but without any fragment of a screen display in the top-left corner.

The default RAM contents screen looks like this at power-up:

[BrianHG]

It doesn't like those settings either.  I've made both changes and all I'm getting is a blank screen.  The debugger and Z80 both agree on the contents of GPU RAM page 0 and it looks all good, just the cache miss read errors at the start of each row for the Z80.

Sometimes after a reset I see the two HW trigger lines (as previously) but without any fragment of a screen display in the top-left corner.

The default RAM contents screen looks like this at power-up:

Are you saying that with no Z80 access at all, the video looks like that?
On my unit, I get the B&W Z80 image with the top right logo in blue and 10 layer text.

[nockieboy]

No, that's the display I get immediately after writing a new binary to the FPGA completes.  Normally, I get the B&W Z80 image and colour text.  Every time I reset the system, I get either a black screen or - occasionally - the two yellow lines of the HW triggers.

I'm just getting a black screen when the Z80 completes the GPU initialisation.

[BrianHG]

   And I though it was the Z80 bridge, so I did a whole bunch of things which might be for nothing...
Try this one...


Dont forget to move the debugger IO pins...

[nockieboy]

Aaaand that seems to work perfectly.

[BrianHG]

Ok, in GPU.sv, on line 265, switch the parameter USE_Z80_CLK to 0, and grab a read and write signal tap.

If that works, then I will add my 'wait' algorithm.

[nockieboy]

No issues with that change.  Here's a RD op:



And here's a WR op:

[BrianHG]

Ok, give this one a try.
I've added 'reset' support and trimmed a few delays.
Provide a signaltap read capture please.

If it still works, I'll add the 'wait' next, then trim the remaining fat.

(ARRGGG what did you do with your 'wait' code???  Getting rid of it all.)

[nockieboy]

Okay, well the display is still working so writes to GPU RAM are presumably still working okay, but reading from DDR3 RAM by the Z80 results in page 0 being displayed as all 0x7Es, so there's a timing issue.

The Signal Tap output below was from the Z80 attempting to read C000 - byte 0 in page 0.  The returned value should have been 0x00, but instead was 0x1A.

[BrianHG]

Ok, I missed setting the data output.

Question:  How do you get the upper addresses above A[ 15 ] ?

Without hardware, doing this right is a pain.
I'm throwing together a ModelSim TB for the Z80.

I would have liked to separate the Z80 bridge into 3 pieces.

1. Handle the Z80 bus, with a mem & port R&W IO plus interrupt.  (This handle the bus phy)
2. mem addr R&W to DDR3/GPU.  (Basically address range filter.)
3. port R&W (Basically your multiple ports, but maybe not even needed as this might be part/inside of your IO peripherals)

We have been reading the Z80 datasheet wrong.  Every read/write with the 'TW' cycle in the data sheet isn't actually there unless we we actually apply a 'wait'.  This does not count the 'TWA' in the port read.  All our mem reads have been on the edge of valid since I thought we had 1 more clock cycle.  Looking at the Signaltap, and counting the CLK, I see this now.  Also, it explains our read port problem from way back as we would return the port data too early because of TWA, but the FPGA would return the port data instantly.

[nockieboy]

Ok, I missed setting the data output.

Question:  How do you get the upper addresses above A[ 15 ] ?

EA14-EA21 are all generated by the hardware MMU that sits on the memory card - a couple of 74LS670s basically, although I plan on replacing these (increasingly hard-to-find) chips with an internal MMU in the FPGA.  The control hardware is already in place on the interface card (EA_dir pin and signal in HDL can change the FPGA from reading the extended address bus to setting it - I just need to remove/disable the hardware MMU to do this, which I was planning to do as a future task whilst also making the MMU mappings readable).

Without hardware, doing this right is a pain.
I'm throwing together a ModelSim TB for the Z80.

I've not had a lot of luck building another set of cards for some reason and hadn't gone back to problem-solve or start another set for well over a year, but recently I've been seriously thinking about building a second system to send over to you - it's the least I can do to say thanks for all this work, if nothing else.  Expect a PM at some point over the next few weeks asking for a postal address.

We have been reading the Z80 datasheet wrong.  Every read/write with the 'TW' cycle in the data sheet isn't actually there unless we we actually apply a 'wait'.  This does not count the 'TWA' in the port read.  All our mem reads have been on the edge of valid since I thought we had 1 more clock cycle.  Looking at the Signaltap, and counting the CLK, I see this now.  Also, it explains our read port problem from way back as we would return the port data too early because of TWA, but the FPGA would return the port data instantly.

I hadn't noticed as I'm still a noob at reading these traces and understanding what the heck is going on in the HDL.  That would explain a lot actually.  Yes, the Z80 inserts a WAIT state into every IO op to give the peripheral time to get its ducks in line and pull WAIT low if it needs to, but there's no such consideration for memory devices.  Even though the Z80 is a slow 8-bit processor from the late '70s, it still places some strict demands on timings.

[DiTBho]

Why do you use a MMU with a z80 CPU? and for what?

[nockieboy]

Why do you use a MMU with a z80 CPU?

The Z80 has a 16-bit address bus, so it can only address up to 64KB of memory.  My MMU expands the 16-bit address bus to 22 bits, allowing the Z80 to access up to 4MB of memory by treating the original 64KB that it can address as four 16KB 'areas'.  Each one of those areas can be swapped with, or mapped to, any 16KB 'bank' in the 4MB physical address space.

...and for what?

To allow CP/M 3 to run, for starters - it uses extra memory for program space and so on.  With the MMU, I can map the first 16KB of GPU RAM into the Z80's logical memory space (the 64KB it can address) and allow software on the Z80 to access the GPU, for example.  By swapping in the correct 16KB banks, the Z80 has access to the entire GPU RAM even though it's not part of the Z80's memory in any way.  I can also give it access to the megabytes of storage on the DDR3 chip/s on the GPU card by the same process.

[BrianHG]

OK, I got Modelsim to do a Z80 read an write memory by the datasheet numbers.

OMG, how on earth do they expect up to get that wait out in time if the time between the 'RD' going low and the setup time required to pull wait low is only ~10ns.  Unless you pre-emptively drive the 'wait', you cannot guarantee you will make it in time even with an FPGA.  At least the timing snapshotd you sent me using SignalTap doesn't look as bad/tight, though we still need to decide to get the 'wait' out within 2-3 125MHz clocks of deciding if a read needs to take place.  Though the datasheets are worst case scenario, we would have to get the 'wait' out within 1 clock.

I have to add read/write port, read instruction op-code and make the Z80 simulator respond to the 'WAIT'.

Then I can see and clean up the Z80_bus_interface.
Then I can tie it to my DDR3 controller simulator and see full true round-trip access and timing.

First, some sleep time, then I finish up tonight.

[BrianHG]

Ok, here is the beta Modelsim Z80 buss simulator.

// Instructions:
//
// Open ModelSim 20.x
// Select ' File / Change Directory ' -> 'Z80_Interface_TB'
//
// In transcript, type:
// do setup_z80.do
//
// Every time you edit code or ascii script and you want to re-run the simulation, type:
// do run_z80.do
//
// Ascii file 'Z80_cmd_stimulus.txt' allows you to enter Z80 commands to be simulated.
//

If it simulates to your liking, it appears to read and write memory ok, then copy the 'Z80_Bus_Interface.sv' source to you GPU folder and test, plus grab a Signaltap of 2 read requests, 1 cached and 1 uncached, + 1 write.

If everything is ok, I'll finish-up and add the 'wait' tonight.

[nockieboy]

Well, from what I can tell the timings look okay on ModelSim (though it's late here and I've had a looong evening).  However, testing on the hardware hasn't gone well at all.  Screen setup corruption and random 'snow' on the screen - see attachment.

I don't have time to do Signal Tap traces tonight, but will get them done ASAP when I'm back tomorrow afternoon, unless you know what the issue is of course.

[BrianHG]

Strange.  I haven't changed the 'Z80_bus_interface' since the last time except putting in the missing read-data return.
Yes, all I have done was make the ModelSim xxx_tb, in the bus interface, I only commented in 1 line.
Could you check the RS232 debugger to see if the Z80 is writing to ram correctly.

This might be an issue with with the 'reset'.
Try J-Tag programming the board a few times, IE, hard reset to see what happens.

This might be a stability issue.  In that case, I might try making a change in the .sdc file to help things.
Because of the way we are using the PLL, there are a few things in the CLK[4] domain which are being ignored from the 'CLK_IN' 50 MHZ domain.  Or, it's that pesky 'clk_2x_phase' where we used to have a special PLL tap feeding it to guarantee error free power-up.  I might need to make a special PLL for the DDR3 to include that output, or, go back to using 2 PLLs.

[BrianHG]

Ok, I changed my .sdc file and I got the static red center box junk.

Though the DDR3 reads and writes correctly, it is the FPGA core block ram and and registers which are not receiving the proper written values.  And this bug exists even when writing bytes with the RS232 debugger, so, it will be the same is the Z80 writes bytes.  It is not a problem with the Z80_bus_interface.

LOL, the DDR3 is working flawless, but the older core memory contents is messing up.
Because of the error, the problem is in the geo_mux module, or 4 port memory driver which is running at 250MHz linked to the 125MHz clock zones.

Now that I can replicate the problem, I can hunt down a temp fix as the geo_mux and method of driving the old core ram & control regs is about to become completely obsolete.

[BrianHG]

Ok, replace these 2, gpu.sv and GPU_DECA_DDR3.sdc files.
I think it should solve the build stability.

It's a sorry pain we have to deal with this as the new design bypasses this old main section which relies on the entire core ram running at 2x core speed so we may achieve 4 simultaneous ports.

The new design should be easier except for the 4 palettes which will require a single m9k block read port running at 300MHz.
However, this is easier to achieve than the equivalent 128k running at 250mhz.  (larger ram blocks and the address steering eats up the FMAX.)

If your monitor will display 48Hz, you can also try running the compiling core to the proper 400Mhz.  Only 3 signals in the GPU core red at 85C model.  This is part of the earlier mentioned GPU 250MHz blockram.  But you can be assured that the DDR3 is 100% in the black timing wise.

[BrianHG]

Z80 wait rubbish.

Looking at the attached photo:


You can see the grey highlighted RD signal.  Once that drops, then I know a read is taking place.
The red box which highlights the 'Z80_wait_sh' is the time the FPGA code needs to drive the wait and hold it driven for at least that amount of time to guarantee a 'WAIT' takes place.  The red box is positioned with the time of the FPGA IO round trip taken into consideration assuming that your open-drain IC takes less than 5ns to pull the Z80_WAIT low.

As you can see, with a fast 20MHz Z80 running at 8MHz, I have a huge amount of time to decide to and drive the 'WAIT'.  But with a 8MHz Z80, that time is in the negative.  If the FPGA and your open-drain IC was infinite in speed, you would have +5ns to begin driving the 'WAIT'.  (This is assuming that there are no timing errors in the data sheet as my Z80 sim uses those figures to generate the ModelSim waveform.)

Lets see what happens with the new code I will have ready in a few hours.
First, test and measure the new code I sent in 1 post above fixing the red box.

[nockieboy]

Ok, replace these 2, gpu.sv and GPU_DECA_DDR3.sdc files.
I think it should solve the build stability.

It's a sorry pain we have to deal with this as the new design bypasses this old main section which relies on the entire core ram running at 2x core speed so we may achieve 4 simultaneous ports.

The new design should be easier except for the 4 palettes which will require a single m9k block read port running at 300MHz.
However, this is easier to achieve than the equivalent 128k running at 250mhz.  (larger ram blocks and the address steering eats up the FMAX.)

If your monitor will display 48Hz, you can also try running the compiling core to the proper 400Mhz.  Only 3 signals in the GPU core red at 85C model.  This is part of the earlier mentioned GPU 250MHz blockram.  But you can be assured that the DDR3 is 100% in the black timing wise.

Have just tested these two files in the five minutes spare I've got before I head out, and can confirm a clean, stable image.

Haven't tried the core at 400 MHz yet - might have time later today.

[gcewing]

OMG, how on earth do they expect up to get that wait out in time if the time between the 'RD' going low and the setup time required to pull wait low is only ~10ns.

Where do you get that from? The Z80 timing diagram I'm looking at has RD going low in the middle of T1 and WAIT being sampled in the middle of T2. At 8MHz that gives you 125ns.

Are you perhaps looking at an I/O cycle diagram and imagining the TW cycle not being there? Note that RD goes low at different times for memory and I/O cycles.

[BrianHG]

Here is the diagram for a read data:


You can see the the RD falls tc(13)ns after the fall of clock cycle T1. (Clock cycle names in both ModelSim waveform and datasheet.)
You can also see that the setup time for the 'WAIT' signal mus be driven tc(17)ns prior to the fall clock cycle T2.
You can also see that we must hold the 'WAIT' signal for at least tc(18)ns after the fall of clock cycle T2.

Code: [Select]

// Timings found in Zilog Z8400/Z84C00 NMOS/CMOS Z80 CPU Product Specification data sheet.
//                                      4 MHz,  6 MHz,  8 MHz, 10 MHz, 20 MHz
localparam  int  tc13       [0:4] = '{  95000,  80000,  70000,  65000,  40000}; // TdCf(RDf)  - Time in picoseconds
localparam  int  tc17       [0:4] = '{  70000,  60000,  50000,  20000,   7500}; // TsWAIT(Cf)
localparam  int  tc18       [0:4] = '{  10000,  10000,  10000,  10000,  10000}; // ThWAIT(Cf)

Now, to be sure I don't have a typo, here is the snapshot of Zilog's Z80 datasheet timings.


Did I make a mistake in my code's parameter's worst case timings as given to me by the Z80 datasheet?

In the Modelsim waveform, the 'red box' 'Z80_wait_sh' sample window is shifted left by 10ns which covers the FPGA output delay + LVCT opendrain buffer which pulls-down the 'WAIT' line.  This allows me to see if my bus interface's output is early enough to still meet the timing by the time it reaches the Z80 bus as ModelSim's IO view is infinite in speed / IE has no delay.

[BrianHG]

Look at the 3 arrows, at the fall of T1 in the simulation, until Z80_RD, it does measure 70ns just like my setting in my code and data sheet.


The setup time for the 'WAIT' is also correct except shifted to the left by 10ns.