Products > Test Equipment
HP Logic Analyzer Inverse Assemblers
gslick:
Here are some sample Z80 waveforms I captured with Timing Zoom enabled so that both state and timing samples are available.
With the Slave Clock set to both the rising and falling edges of the CPU Clock, in the Opcode Fetch waveform sample the relevant Slave Clock edge is the rising edge of the CPU clock at the marker position T3-H, just prior to the Master Clock at the rising edge of LMREQ at the marker position MREQ-H.
With the Slave Clock set to both the rising and falling edges of the CPU Clock, in the Memory Read waveform sample the relevant Slave Clock edge is the falling edge of the CPU clock at the marker position T3-L, just prior to the Master Clock at the rising edge of LMREQ at the marker position MREQ-H.
If the Slave Clock was set to only the rising edge or only the falling edge of the CPU Clock, the timing margin to capture valid state data could be reduced by half of a clock period, which could possibly be an issue if the access times of devices in the target system were near the timing margin limits.
Zilog databook timing diagrams came from here:
http://www.bitsavers.org/components/zilog/z80/03-0029-01_Z80_CPU_Technical_Manual_1977.pdf
MarkL:
The opcode fetch is a faster cycle than a regular memory fetch. Below is the opcode fetch timing cycle without the wait states. The first byte of the instruction is sampled by the CPU on the second rising edge of PHI after /MREQ falls. In rough numbers, this allows 1.5 clock periods for access time.
A memory data read is sampled by the CPU on the second falling edge of PHI after /MREQ falls, allowing it roughly 2 clock cycles for access time.
Since the opcodes and operands necessarily share the same physical memory in the Z80 architecture, they therefore have the same access speed requirements. The system must be designed to support the higher speed of the opcode fetch cycle.
So, LA slave sampling on the rising edge of PHI, with only 1.5 cycles of access time, should always work for memory. I suppose it's possible that a Z80 system could be designed with slower memory that is only for data and never instructions, but I've never seen that.
However, in the case of an I/O read, the cycle time is roughly 2.5 cycles, and starts on a rising edge of PHI, which is later in phase than an opcode or memory cycle. See I/O timing below (the "Tw" in the diagram is an automatically inserted wait state). If the LA slave was sampling only on the rising edge of PHI, the peripheral read would have only 2 cycles to settle. Giving it an extra half cycle to settle is probably not going to make a difference since peripheral registers, etc. are generally much faster to access than memory, but it would be wrong to assume this is always the case.
I think I'm convinced sampling on both edges of PHI is the right thing.
MarkL:
One interesting thing in my timing capture is that the address lines start changing before the rising edge of /MREQ. When using /MREQ * /IORQ as the only clock, which I tried first, it created nonsensical results in the state capture. This is what led me to look at PHI to do the slave latch capture.
However, in your timing digram, the address lines are stable for at least 80ns (MemRead) to 200ns (OpFetch), leaving plenty of time to use /MREQ * /IORQ in master mode as the only clock (no slave).
With your previous analysis of buffer delays in the Z80 Interface Module:
https://www.eevblog.com/forum/testgear/older-logic-analyzer-question/msg2525412/#msg2525412
I'm not sure how this would have ever worked for me, since /MREQ * /IORQ would occur even later because of the buffer delays.
One difference in my system is that I'm using a Zilog Z80H, which is the 8MHz variant (in contrast to the standard part speed of 4MHz). It's not beyond reason that the external bus interface in the chip was modified for the higher speed and behaves a little differently. The Z80H was introduced in 1982 (wikipedia), perhaps after the Interface Module was released?
At any rate, it doesn't change the approach to use master/slave clocking, or clocking on both edges of PHI. In fact, it's required in my case. Just thought it was interesting.
Hamster:
This is great stuff ! Love it.. I have two large driving arcades leaving and going to setup a proper station so i can test things out and dig in and help.
gslick:
--- Quote from: MarkL on March 19, 2024, 02:23:31 pm ---One interesting thing in my timing capture is that the address lines start changing before the rising edge of /MREQ. When using /MREQ * /IORQ as the only clock, which I tried first, it created nonsensical results in the state capture. This is what led me to look at PHI to do the slave latch capture.
However, in your timing digram, the address lines are stable for at least 80ns (MemRead) to 200ns (OpFetch), leaving plenty of time to use /MREQ * /IORQ in master mode as the only clock (no slave).
With your previous analysis of buffer delays in the Z80 Interface Module:
https://www.eevblog.com/forum/testgear/older-logic-analyzer-question/msg2525412/#msg2525412
I'm not sure how this would have ever worked for me, since /MREQ * /IORQ would occur even later because of the buffer delays.
--- End quote ---
From https://www.eevblog.com/forum/testgear/older-logic-analyzer-question/msg2525412/#msg2525412
Once through a 74LS240 Inverting Octal Buffer and Line Driver:
PIN 19 /MREQ CLOCK J
Once through a 74LS240 Inverting Octal Buffer and Line Driver:
PIN 20 /IORQ CLOCK K
Twice through a 74LS240 Inverting Octal Buffer and Line Driver:
PIN 20 /IORQ STAT BIT 1
Three times through a 74LS240 Inverting Octal Buffer and Line Driver:
PIN 22 /WR STAT BIT 0
One result of that is that the /WR signal as used for a STAT bit should be delayed by two gate propagation delay periods relative to the /MREQ and /IOREQ signals as used for the J and K clocks.
Delaying the /WR signal before it is sampled at the /MREQ and /IOREQ signal edges as used for the J and K clocks when using the 10300B Z80 preprocessor might be important if the /WR signal transition at the CPU pin can occur before the /MREQ signal transition at the CPU pin.
That appears to be occurring in the trace that I previously acquired when I scrolled forward to a memory write cycle. The rising edge of the /WR signal appears to occur around 3.25ns before the rising edge of the /MREQ signal (with the Timing Zoom sampling resolution of 250ps).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version