A-Z80 CPU

Overall I am impressed with the A-Z80 core but it seems that the Processor does not drive IORQn low during the IAck Cycle.

I am running the A-Z80 on a Xilinx UltraScale+ in the Xilinx Vivado 18.2 tool ... so far, I am working only with simulations ...I have found that the A-Z80 does not respond as expected during the Interrupt Request / Interrupt Acknowledge Cycle as specified in the Z80 CPU User Manual (UM008011-0816 Page 13 Figure 9).

Per the User Manual, IORQn should be driven low for 1.5 clock cycles starting 2.5 clocks into the cycle. It does not.

I have tried it using my Z80 Assembly Program and with the Hello_World program provided with the core. The default interrupt mode in the supplied Hello_Word is IM2 but I tried it with IM0 and IM1 as well by modifying Hello_World and IORQ never responded as expected in the IAck Cycle.

IORQn does appear to respond appropriately in Port I/O Cycles.

To verify file integrity, I re-downloaded a fresh copy of the core and had the same problem.

In my program I write to an address that causes external logic to generate an INTn but when simulating Hello_World I forced INTn low ... the processor responded with what appeared to be an Interrupt Acknowledge Cycle except that IORQn did not go low.

The nIORQ is clearly lagging behind a few cycles. This must be a consequence of a recent change. Investigating...

The nIORQ is clearly lagging behind a few cycles. This must be a consequence of a recent change. Investigating...

Confirmed that the issue does not happen when I remove the latest change (Titled, "Correctly latch IO RW wait request") Besides reverting it, I need to find a correct fix for that last issue and test it better.

Confirmed that the issue does not happen when I remove the latest change (Titled, "Correctly latch IO RW wait request") Besides reverting it, I need to find a correct fix for that last issue and test it better.

Uploaded a fix to this issue: it was caused by my ad hoc connecting an unconnected flop enable line as part of a previous fix. That ENA should have stayed unconnected (always enabled).

Tested on a simulation that reproduced the requester's failure. With this fix, the simulation (and the behavior of nIORQ pin) continues as expected.

Hi Goran. Thanks for working on this. In my simulation the Interrupt Acknowledge cycle does work fine to completion but on the very next rising clock edge the M1_n signal goes into an unknown state, no valid address in placed on the bus, and, of course, the processor simulation then crashes. If I don't see a response or fix by my start of business on 12/12, then I will start trying to track it down. It is possible that another engineer I am working with, Sam Sangregory, may also post in this thread.

Update 12/12 - I tracked the problem to the "setM1" signal in exec_matrix.vh. Within there it seems to relate to invalid (unknown) values on use_ixiy, pla74, or pla56 or, perhaps, setM1 is being set within multiple "IF" blocks ... but the evaluation is incomplete at this point too.

Richard, I was simulating using (Altera Quartus) Modelsim since the project is already setup with it. I could try using the Xilinx sim, although I am not as familiar with it as I am with Altera toolset. It could help me if you could upload somewhere a zip of your project that is already setup to run the simulation. I'd like to repro using the same setup. Thanks!