OpenCores

IORQn in IAck Cycle

Back to bugtracker overview.

Information:
Type :: BUG
Status :: OPENED
Assigned to :: Goran, Devic

Description:
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.

Comments:

Devic, Goran Dec 14, 2018
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!
Ivy, Richard Dec 12, 2018
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, pla[74], or pla[56] or, perhaps, setM1 is being set within multiple "IF" blocks ... but the evaluation is incomplete at this point too.
Ivy, Richard Dec 11, 2018
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.
Devic, Goran Dec 10, 2018
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.
Devic, Goran Dec 9, 2018
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.
Devic, Goran Dec 9, 2018
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.
Devic, Goran Dec 9, 2018
The nIORQ is clearly lagging behind a few cycles. This must be a consequence of a recent change. Investigating...
Devic, Goran Dec 9, 2018
The nIORQ is clearly lagging behind a few cycles. This must be a consequence of a recent change. Investigating...

Post a comment:
Login to post comments!

Back to bugtracker overview.

© copyright 1999-2019 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.