FPGA VGA Controller for 8-bit computer

[nockieboy]

Another trick you could try for speeding up the transistor is to put a smallish capacitor across the base resistor.

Smallish as in 100nF or 100pf? Across the 1K base resistor?  How does that work?  Isn't that setting up some sort of RC oscillator? (Genuine questions, I have no idea!) 

Yes, I can confirm that fitting a 1k pullup to the WAIT line causes the system to lock up with the DECA/GPU attached, but not as long as it doesn't try to mess with the WAIT line.

Maybe you have some kind of logic error that's being masked when the wait state is unusually long? Could the FPGA be releasing the WAIT line too early, before it's actually ready for the Z80 to continue doing stuff?

I'm wondering if it could be a code or logic error, but there are no interrupts running, so no reason why the Z80 couldn't be held in WAIT for as long as I wanted.  I'm suspecting that it could be a false triggering of the HDL in the FPGA, thinking a valid memory read or write is occurring when it isn't - so WAIT is getting pulled low but not getting released at the end of the 'memory op' , causing the straight behaviour and flickering of the WAIT line that I'm seeing now when it happens.

Note that it's the FPGA making the Z80 wait - not the other way around - there's no actual requirement for the Z80 to wait at all, I'm just forcing WAIT states to be inserted for testing, and the Z80's WAIT line is asynchronous so it can be released at any time - the Z80 will pick up the high WAIT line on the next Tw cycle's falling clock edge.  I'm going to have to continue testing - what I really need is to somehow trigger SignalTap to capture some traces when the problem occurs, but that's like trying to find a needle in a haystack on the first attempt.

[nockieboy]

Okay, WAIT insertion is done.  It'll be a simple matter to refactor the HDL to allow the GPU to remove the WAIT state as soon as it's ready to progress the memory operation, but in the meantime it's using a counter to delay operation of the Z80 during a memory operation to GPU RAM.  Here's a memory op with no wait states:



It's stable, so long as I don't set too high a value on the WAIT counter, but works with no WAITs at all and then starts at a minimum of 2 WAIT states - this seems to be the minimum time it takes the 2N3904 to release the WAIT line on the Z80:



If I up the timer to 20 (GPU clock cycles), I get 6 WAIT states.  Bearing in mind each of these WAITs is 125 nanoseconds at the Z80's 8 MHz clock, that's 750 nanoseconds - I'm hoping that will be plenty of time for the GPU to interrogate the SDRAM and get (or set) a value from external RAM.  It does seem to be the upper limit for reliability - higher values tend to crash the system.



The issue with reliability previously was to do with WAITs not being applied in time for a write operation from the Z80 - it wasn't picking up the WAIT in time and was sometimes picking it up on the next memory op after the one triggering the WAIT, causing 'undocumented behaviour'.   

[BrianHG]

Many read and writes will be in time, so, no wait will be necessary.

The real problem is only with the reads.  When you do a read request, occasionally, if the ram controller just sent a refresh command, your read can take as long as 360ns+150ns+? when using the largest 8gb DDR3 ram chips, or 90ns+150ns+? for a 512mb DDR3 ram chips with the Z80's read channel priority set to max, or above all other channels (recommended).  At max priority, the reads will typically take 100ns to 150ns unless the read is a cache hit where the read will only take around 20ns or if the read is within the same activated page where the read will take around 50ns.  Since there is a nasty extended penalty when using the 'wait', you need to find out when is the latest you can issue a wait so that if a read can makes it back in time, you will not need to pulse the 'wait' line to the Z80.  It's also not that the ram want have your data within 750ns, it's that you really cant release the wait until the ram has delivered the read data, as in you cannot predict in advance and disable the wait early before the read acknowledge has come in.

Since the you will have a 2 word write cache and the Z80 is so slow, I doubt you will ever need a wait state during a write, however, for the writes, you will know in advance if that cache is full when you receive a write command.  It is also easy enough to increase the write cache size by a byte or 2 meaning the Z80 will not be able to out-pace the DDR3 no matter what the DDR3 may be doing elsewhere.

(Yes, smaller DDR3 ram chips refresh much faster than the larger ones.  Here is your selection:)

Code: [Select]

//                                512mb,    1gb,    2gb,    4gb,                 8gb   **** Refresh time for each size of DDR3 Ram.
localparam int  ttRFC   [0:8] = '{90000, 110000, 160000, 260000, 260000, 360000, 360000, 360000, 360000}; // minimum time in picoseconds
The DECA board right now has the 4gb chip, or 260ns.

[nockieboy]

Well I don't necessarily intend on using anything bigger than 512MB - not for an 8-bit system, anyway.  Anything more seems like a massive waste of silicon.  But given how it's cheaper to buy a 512KB chip these days than a 16KB one (if you can even find one), I guess it's just a matter of time before anything less than 4GB dries up completely.

Given the parameter you've provided for _ttRFC, it'll be easy enough to insert the appropriate number of WAIT states into a memory read if it's a cache miss.  In terms of the latest time to get WAIT pulled low, it's not long - it's the falling edge of T₂ (that being the second clock cycle of the memory operation).  I need to detect a stable address in the GPU's RAM range and MREQ going low to signify the start of a valid memory op - in the image below, that's the first vertical dotted line at time 0.  The Z80 samples the WAIT line on the falling edge of T₂ - the second vertical dotted line at time 6.  Each of those time steps is approximately 20ns - so it would appear I have a maximum of 120ns to get the WAIT line low enough that the Z80 will detect it as low on the falling edge of T₂.



Have attached latest z80_bridge_v2 for information.  Need to tidy it up a little, but hopefully there's no major issues with anything in it. 

[BrianHG]

You can try a Diodes inc mosfet 'DMN53D0LQ' in place of the 3904 as it's turn on is ~20ns, but it's turn off + fall is also around 30ns instead of having that 10x hold time of 200ns.

NXPs NX138AK mosfet is also good and it's also completely on on when the gate-source reaches 3v.

[BrianHG]

Well I don't necessarily intend on using anything bigger than 512MB - not for an 8-bit system, anyway.  Anything more seems like a massive waste of silicon.  But given how it's cheaper to buy a 512MB chip these days than a 64MB one (if you can even find one), I guess it's just a matter of time before anything less than 4GB dries up completely.

Anyways, you would also be using 2 of them in parallel.
512mb (64 megabytes) and 1gb are still in high circulation, also remember you are using x16 width.

So, your smallest system size will be 2x512mb, or 128 megabytes.

(The 2x chips is for memory speed for video, though, you can still do a lot with 1, but loose rendering speed with high res 32bit color screens.)

[BrianHG]

You can try a Diodes inc mosfet 'DMN53D0LQ' in place of the 3904 as it's turn on is ~20ns, but it's turn off + fall is also around 30ns instead of having that 10x hold time of 200ns.

NXPs NX138AK mosfet is also good and it's also completely on on when the gate-source reaches 3v.

The NXP mosfet is faster...
But we are talking just over 5ns faster.

However, they are drop-in replacements for the 3904 transistors and you can change the series base resistor to 0-100 ohm for top speed.


Diodes inc 'DMN2230UQ' is also good and there exist a lot of fast mosfets with will turn on really hard at 3v g-s.  Though I think your final solution may be a logic IC with open-drain output so you have a few outputs on 1 device at your disposal.

[nockieboy]

You can try a Diodes inc mosfet 'DMN53D0LQ' in place of the 3904 as it's turn on is ~20ns, but it's turn off + fall is also around 30ns instead of having that 10x hold time of 200ns.

NXPs NX138AK mosfet is also good and it's also completely on on when the gate-source reaches 3v.

The NXP mosfet is faster...
But we are talking just over 5ns faster.

However, they are drop-in replacements for the 3904 transistors and you can change the series base resistor to 0-100 ohm for top speed.


Diodes inc 'DMN2230UQ' is also good and there exist a lot of fast mosfets with will turn on really hard at 3v g-s.  Though I think your final solution may be a logic IC with open-drain output so you have a few outputs on 1 device at your disposal.

I'll get some of the NXP parts and the Diodes Inc ones in case one works and the other doesn't.  For a final solution, I'm looking to use something like the 74LVC07 to provide the open-drain outputs I require to pull various lines low, including WAIT.  It seems to be pretty responsive, with t_PZL and t_PLZ times in single-digit nanosecond ranges.  Hopefully it's appropriate for the task.

[BrianHG]

You can try a Diodes inc mosfet 'DMN53D0LQ' in place of the 3904 as it's turn on is ~20ns, but it's turn off + fall is also around 30ns instead of having that 10x hold time of 200ns.

NXPs NX138AK mosfet is also good and it's also completely on on when the gate-source reaches 3v.

The NXP mosfet is faster...
But we are talking just over 5ns faster.

However, they are drop-in replacements for the 3904 transistors and you can change the series base resistor to 0-100 ohm for top speed.


Diodes inc 'DMN2230UQ' is also good and there exist a lot of fast mosfets with will turn on really hard at 3v g-s.  Though I think your final solution may be a logic IC with open-drain output so you have a few outputs on 1 device at your disposal.

I'll get some of the NXP parts and the Diodes Inc ones in case one works and the other doesn't.  For a final solution, I'm looking to use something like the 74LVC07 to provide the open-drain outputs I require to pull various lines low, including WAIT.  It seems to be pretty responsive, with t_PZL and t_PLZ times in single-digit nanosecond ranges.  Hopefully it's appropriate for the task.

I would test to make sure, however, you would want to scope the output to ensure the 'pull-down' does indeed drop the bus signal below ~0.5v with that 4.7k pull-up.  Otherwise, you may meed to run 2 or 3 outputs in parallel to really clamp down the signal line as being a CMOS open drain output, it behaves differently than an open-collector TTL output.

My recommended mosfets have at least 10x the pull of the 50ma 74LVC07, so, you just need to make sure.

[nockieboy]

I would test to make sure, however, you would want to scope the output to ensure the 'pull-down' does indeed drop the bus signal below ~0.5v with that 4.7k pull-up.  Otherwise, you may meed to run 2 or 3 outputs in parallel to really clamp down the signal line as being a CMOS open drain output, it behaves differently than an open-collector TTL output.

My recommended mosfets have at least 10x the pull of the 50ma 74LVC07, so, you just need to make sure.

Some back-of-an-envelope maths indicates (if I'm doing it right - I'm using V=IR from my school days) about 1mA of current needs to be sunk on the WAIT line (using I=V/R, where V=5v and R=4.7Kohms).  I guess without knowing the capacitance of the physical trace connecting the open-drain output to the Z80's WAIT pin, there's no way to calculate rise/fall times?  It would probably help if I minimised the trace length to the system bus header on the PCB too.

[BrianHG]

I just finished a few improvements to the DDR3 controller.  Patched most of the main issues.  Tomorrow for me, later today for you, once I documented the changes, I will upload it to the DDR3 thread.  You should think about wiring the DDR3 directly to the Z80 bridge as a test.  However, in this state, the GPU wont be accessible, so only do this if you have access to a terminal mode to test the Z80 read and write to DDR3.

Let's see what you come up with for wiring the thing together.

[BrianHG]

V0.95 of the DDR3 controller has been released:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3621074/#msg3621074

[BrianHG]

          
  500MHz/1GTPS
          

@Nockieboy, please give this DECA board ellipse demo .sof programming file a test:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3630084/#msg3630084
I just want to make sure that this isn't a fluke which only works on my eval board...

[BrianHG]

Well, my DDR3 controller is now good enough to run at 300MHz on Altera's slowest speed grade -8, perfect for the cheapest Cyclone V GPU.

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

[BrianHG]

BrianHG_DDR3_Controller V1.00 has been released.
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3649396/#msg3649396

Sad news about Cyclone V, see here:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3649318/#msg3649318

[nockieboy]

That's an amazing piece of work, BrianHG, and one that's going to be appreciated by a LOT of people - well done and thank you. 

I haven't had any time at all to work on hobby projects since I last posted - hoping for some time next week to look at wiring the DDR3 controller up to the existing DECA GPU build, but was wondering about your C-V FMax results.  If they don't turn out to be a bug in the Quartus software (I'm guessing you don't have a C-V sitting around you can do a build test on to verify if it works or not) then I'm wondering if it's worth moving up to a C-V for my GPU at all, given that the reason for moving to a C-V was purely based on the internal RAM size which is a need that is now negated by the use of external DDR3 RAM?

Staying with a C-IV, but a larger one than the CE10 I'm using in my existing prototype GPU card, may be preferable given those FMax results if they're going to affect performance.  Alternatively, switching from Altera altogether may be preferable?  What do you think?

[BrianHG]

Staying with a C-IV, but a larger one than the CE10 I'm using in my existing prototype GPU card, may be preferable given those FMax results if they're going to affect performance.  Alternatively, switching from Altera altogether may be preferable?  What do you think?

Give me a week to fiddle with Lattice Diamond.
They supposedly upgraded to using Modelsim for simulation and my DDR3 code was designed to work on any FPGA with a dumb DDR IO port and a PLL where I can phase shift one of the PLL clock outputs.

I'll see what Intel says about the Cyclone V, but, don't get your hopes up there.  It's FPGA fabric is different from the earlier Cyclones and with a lower 1.1v core, but, identical cell nanometer node size, I bet it just might be a slower FPGA at certain tasks.  Or, since it is a newer 'fitter' within Quartus, it may just be programmed lousily by a different team.  I guess we will see.  It is too bad as the Cyclone V's PLL can do 712MHz officially and that means that with the internal HDMI serializer, there was a good shot of achieving true 1080p output.  Cyclone IV's PLL max was rated at 475 MHz and we made it to 540, IE 1080mbps.  (CV's 712 might have made it to 742.5, 1080p's official 1485mbps.)

[BrianHG]

Finally!!!!  (Damn javascript bug finally bypassed...)

My GitHub repository release:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller

[BrianHG]

Attached is the GPU Geometry testbench V1.0.

Here is the original v0.6 with instructions: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3465124/#msg3465124

Remember, after running a test script, the sent commands are stored in: 'GEO_tb_command_results.txt'
And the results are stored in the .bmp as requested in the executed 'GEO_tb_***.txt'.

A lot of work was put into this, you should be using it to verify bugs you may be having when programming the GPU itself.

[BrianHG]

Here you go Nockieboy:

https://github.com/BrianHGinc/GPU_GEOMETRY_Testbench

Don't forget to 'Fork' the repository into your repo listings.

[gcewing]

Another trick you could try for speeding up the transistor is to put a smallish capacitor across the base resistor.

Smallish as in 100nF or 100pf? Across the 1K base resistor?  How does that work?  Isn't that setting up some sort of RC oscillator? (Genuine questions, I have no idea!) 

Something about that size, yes. Depends on the details of the circuit, you'd have to try it to find out how much you need. It's not creating a feedback path, so it shouldn't make anything oscillate.

[nockieboy]

Quick question BrianHG - this is probably something we've covered before, but I've forgotten. 

I'm finishing off the last few bugs and glitches in the full-graphics display mode for CP/M and my DMI, and have discovered that blitting characters appear to use the inverse of the colours used when drawing shapes?  i.e. I'm drawing a rectangle to clear the screen in 1 bpp mode, which uses colour index 00 to clear to black.  However, blitting a character from the character table also uses colour index 00 to blit the character in as a white char on a black square (colour index 1 draws black on white).  This is with CP and PM off (blitter mode 1).  What have I forgotten that's causing this confusion? 

[BrianHG]

When blitting, you have the paste/draw color which does a flip/invert/bit-wise XOR of the source data.  In other words, blit paste with color 0 for output 0=0 and 1=1.  Also, you have the transparency color which also flips/inverts bits around.  And you also have transparency enable.  Disable the transparency and the color 0 and 1 both get piped through though to the screen, but the paste mask color transparency setting will still do it's first stage XOR invert color bits of the source data.

If it were replace color when selecting the paste color, then how do you manipulate multicolor blits where the source data has 16 or 256 colors?

[nockieboy]

Ah, that's it - I knew there'd be an explanation that I'd just plain forgotten about!   Thank you.

[BrianHG]

If you ever wanted to re-implement your line drawing engine with floating point (this means triangles as well as quads and ellipses which you can rotate), here is a key to providing different Bézier curves: