Dumitrache, Nicolae

NextZ80

1. NMI sticky (SNMI) is not correctly implemented. Currently, NMI signal should be active until FNMI is activated, but FNMI is internal signal and cannot be analyzed by external modules. Moreover, one-clock NMI signals may be ignored. Fix is simple: just replace condition `(SNMI & !FNMI)` by `((NMI|SNMI) & !FNMI)` and add `SNMI <= 0;` to the if body.
2. No NMI acknowledge. Regarding to Zilog Z80 specification NMI acknowledge cycle is looks like generic memory read, so MREQ should be activated on first NMI processing stage.
3. NextZ80 jumps to address 0x00 instead of 0x66 after NMI accepting. I cannot understand why it happens.

NMI not work

I have added support for eZ80 instructions to your core (all instructions which works in Z80 mode of eZ80). Processor works perfectly (without any bugs for instructions which I use). Basically I start my changes on 7th SVN revision of your project. Later I backport all your later changes.
There is fixed bug with R register which was kept unchanged while processor executing HALT instruction (original Z80 executes HALT instruction as infinite NOP instruction, so R changes each 4 clocks).
Sources you may download from here: https://yadi.sk/d/417xl6Gn5fE0LQ

Support eZ80 intructions in Z80 mode.

Hi Nicolae,

I think there is the same bug for DJNZ.
M1 is high when fetching displacement for DNJZ.
Can you have a look ?

Thanks.

Thierry

M1 and DJNZ

When executing 4 bytes instructions : DD/FD + CB + index + instruction
M1 is high during DD/FD + CB : ok
but M1 is high during instruction (byte 4) : it is not the normal z80 behaviour (compared to to TV80).

Thank for your help.

M1 and index+CB

When executin the JP (HL) instruction during a simulation, the CPU reads the opcode and the PC is not updated, so it stucks reading again the JP (HL) opcode from the same address, stalling the CPU if no interrupts are triggered.

While tracking down this bug, I noticed that although register mux_rdor had the right value (the current value from HL) for some reason, that value wasn't propaged to register ALU160 even when signal ALU160_sel had also the right value (0). Line #127 of NextZ80Reg.v should assign the current value of mux_rdor to ALU160 according to the current value of ALU160_sel, and therefore, input D0 to ALU16 should be the right value, making ADDR to be also the right value. None of this happened.

Then I noticed the combinatorial always block located from line #123 in NextZ80Reg.v that assigns values to several of such said signals. Comb always use blocking assignments so the order of such do matter.

The first sentences of this always block are:
	always @* begin
		DIN = DINW_SEL ? {DI, DI} : ALU8OUT;
		ALU80 = REG_WSEL[0] ? rdow[7:0] : rdow[15:8];
		ALU81 = REG_RSEL[0] ? mux_rdor[7:0] : mux_rdor[15:8];
		ALU160 = ALU160_sel ? pc : mux_rdor;

The last one is that causes the issue. ALU160 is assigned with the current value of pc or mux_rdor depending on the value of ALU160_sel. The problem is that mux_rdor is not yet assigned a value. This is done later inside this always block. As order matter, the value of mux_rdor assigned to ALU160 is the one before the new assignment. In synthesis this bug get unnoticed because synthesizers can infer the right order based upon real dependencies between RHS and LHS parts of assignments.

In order for simulation to work correctly, the assignments inside the always block must be reordered so the ones that rely on variables which also get a value in a different assignment in the same always block, should be written after them. Another option is to break the always block into various always blocks so each one of them models a simpler combinational circuit with no interdependent assignments inside it. This is the approach I've taken. So, the always block starting from line #123 at NextZ80Reg.v ...

always @* begin
    DIN = DINW_SEL ? {DI, DI} : ALU8OUT;
    ALU80 = REG_WSEL[0] ? rdow[7:0] : rdow[15:8];
    ALU81 = REG_RSEL[0] ? mux_rdor[7:0] : mux_rdor[15:8];
    ALU160 = ALU160_sel ? pc : mux_rdor;

    case({REG_WSEL[3], DO_SEL})
        0: DO = ALU80;
        1: DO = th;
        2: DO = FLAGS;
        3: DO = ALU8OUT[7:0];
        4: DO = pc[15:8];
        5: DO = pc[7:0];
        6: DO = sp[15:8];
        7: DO = sp[7:0];
    endcase
    case({ALU16OP == 4, REG_RSEL[3:0]})
        5'b01001, 5'b11001: mux_rdor = {rdor[15:8], r};
        5'b01010, 5'b01011: mux_rdor = sp;
        5'b01100, 5'b01101, 5'b11100, 5'b11101: mux_rdor = {8'b0, CONST};
        default: mux_rdor = rdor;
    endcase
end

Becomes a series of always, like this:

always @* begin
    DIN = DINW_SEL ? {DI, DI} : ALU8OUT;
    ALU80 = REG_WSEL[0] ? rdow[7:0] : rdow[15:8];
    ALU81 = REG_RSEL[0] ? mux_rdor[7:0] : mux_rdor[15:8];
    ALU160 = ALU160_sel ? pc : mux_rdor;
end

always @* begin
    case({REG_WSEL[3], DO_SEL})
        0: DO = ALU80;
        1: DO = th;
        2: DO = FLAGS;
        3: DO = ALU8OUT[7:0];
        4: DO = pc[15:8];
        5: DO = pc[7:0];
        6: DO = sp[15:8];
        7: DO = sp[7:0];
    endcase
end

always @* begin
    case({ALU16OP == 4, REG_RSEL[3:0]})
        5'b01001, 5'b11001: mux_rdor = {rdor[15:8], r};
        5'b01010, 5'b01011: mux_rdor = sp;
        5'b01100, 5'b01101, 5'b11100, 5'b11101: mux_rdor = {8'b0, CONST};
        default: mux_rdor = rdor;
    endcase
end

which fixed my issue.

Instruction JP (HL) stalls the CPU

Simulation of instructions POP HL and POP BC shows that SP is incremented only once. The issue seems to be caused by this code, located at line #643 of NextZ80CPU.v

REG_WSEL = {1'b0, FETCH[5:4], 1'bx};

In other instructions, bit 0 of REG_WSEL is used to select hi or low order byte of the destination register depending on the stage cycle of the instruction. Changing that line with this:

REG_WSEL = {1'b0, FETCH[5:4], ~STAGE[0]};

fixed the issue for me.

POP instruction doesn't update SP properly

Good day!

I´m experiencing issues with CALL instruction. SP register (latch register as defined in line 71 of NextZ80Reg.v) contains 0xFF56. The CALL instruction is located at 0x128B. Return address is hence 0x128E. After reading the destination call address, I can see two write cycles, but the address to write to is 0xFFFF (for both writes). After that, SP register has the value 0xFFFF (instead of 0xFF54 as it should be).

I've tracked the offending behaviour down to a specific case statement in NextZ80Reg.v which assigns a value to mux_rdor. This case statement needs proper values, but you supply values with "x" bits, which is not acceptable. I´ve temporarily fixed it by changing the case into a casex statement, but I'm well aware that casex should be avoided by all means.

I guess all your "x" bits should be "?" bits instead, and use casez instead of casex when applicable.

I'm using iSIM with ISE 14.7 . The design uses the same WAIT pattern that you use for your example app.

CALL instruction doesn´t seem to properly store PC

I tried a simulation with Aldec's Active-HDL v9.3. If I assert and de-assert RESET, the simulation hangs with M1 & MEMRQ asserted and ADDR="xxxx". Without RESET it seems to run normally. Any suggestions?

Simulation fails after reset

I try run code:
      ld bc,00130h
      ini
after this operation BC=00030h, AF=00002h. Zero flag is not set!!! I check it in the simulator.
As I see, in ZEXDOC/ZEXALL tests for ini/inir and outi/otir are not present. So it is possible that all of them are buggy.

Browse

NextZ80