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?
Have you considered learning about using Quartus' Signal Tap?
Since the FPGA you are using has free ram, and space, you can use the built in logic analyzer and see what the Z80 bus is doing in real time.
Have you considered learning about using Quartus' Signal Tap?
Since the FPGA you are using has free ram, and space, you can use the built in logic analyzer and see what the Z80 bus is doing in real time.
Other vendors have something similar. Never used that though. Something I would expect it that it would tend to make routing more difficult - especially in complex, or congested designs - and thus, hinder Fmax. Do you have experience with this and can you confirm or OTOH tell me that it usually has very little impact?
Have you considered learning about using Quartus' Signal Tap?
Since the FPGA you are using has free ram, and space, you can use the built in logic analyzer and see what the Z80 bus is doing in real time.
"Is there anything faster than a 2N3904, I wonder? That 35ns delay is a killer."
Not to distract the signal tap, just a passing thought, how about the SN74LVC07A Hex Buffer and Driver With Open-Drain Outputs?
It has a propagation delay of around 4ns and can sink 24ma I believe.
It is a hex package and might replace all 6 3904's on on your pcb.
Curious, 55ns seems a bit of a short response time, don't know the Z80 though
I have a ver.0.95 of my DDR3 controller to get out tonight, then I can take a look at your code.
Also, what's the series resistor from the FPGA to the base of the 2N3904. A lower value means a faster turn on time. Using a small value like 220ohm will mean the 2N3904 will probably be on and pulling down within <10ns or even closer to 5ns. It's truly a fast little bugger capable of over 200MHz if you drive the base with enough current. If you are using 1k series resistor to the base, when driving a 3v logic at the other end, expect a 15-20ns delay.
I have a ver.0.95 of my DDR3 controller to get out tonight, then I can take a look at your code.
Also, what's the series resistor from the FPGA to the base of the 2N3904. A lower value means a faster turn on time. Using a small value like 220ohm will mean the 2N3904 will probably be on and pulling down within <10ns or even closer to 5ns. It's truly a fast little bugger capable of over 200MHz if you drive the base with enough current. If you are using 1k series resistor to the base, when driving a 3v logic at the other end, expect a 15-20ns delay.It's stuff like this that I miss. The transistor circuit was a cut 'n' paste from somewhere else - I think the series resistor was to prevent overloading the IO output of whatever was driving the transistor, but what you've said makes perfect sense now that I think about it.
Just look at the 2N3904 data sheet. I believe delay and rise time is 35ns+35ns if you drive the base with 1ma. 220 Ohm would drive the base with around 10ma. Don't go below 100Ohm as the IO on the FPGA might not like a constant ~20ma current.
What's the pull up resistor on the bus?
What's the pull up resistor on the bus?
On the Z80 side? There's a 10K pullup.
I've got a 10K pull-down on the FPGA signal line to the transistor as I didn't want the WAIT line to default to LOW all the time the FPGA was starting up.
Note that the 'turn-off' time of a 2N3904 my not be unavoidable. Though, in the past, our Z80 problems have been narrowed down and connected to code in the bridge.
You need to get the SignalTap going so you can trap what happens before a freeze event.
My guess is that you are applying a wait when there is a read or write of an op-cope elsewhere outside the address of the display GPU.
Can I see you latest code for driving the 'wait' line?
Can I see you latest code for driving the 'wait' line?If you have a spare TTL-3.3v input on your PCB-DECA board, try tying the bus side 'wait' to an input and add that input to the Signal tap so you can see when the 'wait' timing looks like after the 2N3904. This will show you if all those TW wait states are due to the buss signal, or due to internal Z80 processing.
You might also be able to use a series 100k resistor from the Z80 buss wait line to an input as 100k series wont load an input protection diode too much. But, you would probably have to shrink the 10k pull-up as that 100k would be equal to a pull-down to a 3.3v rail.
Can I see you latest code for driving the 'wait' line?
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.