ao68000 - Wishbone 68000 core

It seems to me there is a problem executing BRA instruction. For example, if the instruction is 0x60FE, I expect next_pc = current_pc (i.e. next_pc = current_pc + 2 +0xffffffe), instead i see next_pc = current_pc-2.....

Type your text here

The Motorola M68000 Family Programmer's Reference Manual desribes the BRA instruction as follows:

" Description: Program execution continues at location (PC) + displacement. The program counter contains the address of the instruction word of the BRA instruction plus two. "

Please explain what do you mean by 'current_pc' ?

For the ao68000 current_pc is equal to the address of the BRA instruction plus 2 (exactly as in the Reference Manual), so for offset (-2) we have next_pc = current_pc - 2 = BRA instruction address.

I tested all opcodes from 0x6000 to 0x6100 and compared the results with the WinUAE M68000 software emulator and the results are identical.

Thank you for your interest.

I think the explanation is clear. I am closing this bug.

Hi I'm very sorry.. you are absolutely right.... Porting the project under Xilinx e Modelsim environment I misunderstood about mix of blocking and not blocking operator within the same statement (pc_valid generation).

Finally, I've another question for you. It seems to me that byte qualifier flags SEL_O3:0 does not work correctly during memory read operation (instructions fetch). I'll test in detail next days. Have you any information about? Regards Simone

Hello,

Mixing blocking and not blocking statements, perhaps is not very pretty but is handy..

I checked the SEL_O signal used by instruction fetch. There are two possibilities: SEL_O <= 4'b0011 or SEL_O <= 4'b1111.

4'b0011 is used when the pc address is not a multiple of 4. The system is big-endian, so: SEL_O3 indicates byte addresses 0,4,8,..., SEL_O2 indicates byte addresses 1,5,9,..., SEL_O1 indicates byte addresses 2,6,10,.., SEL_O0 indicates byte addresses 3,7,11,...

So SEL_O <= 4'b0011 selects a word from byte addresses: (2 + 4k) and (3 + 4k). It is a bit confusing that SEL_O3 selects a lower byte address than SEL_O0, but thats how it works.

Thank you for your tests. If you find a bug I will be very happy :)

Regards, Aleksander Osman.

I understand, but it seems to there is a problem fetching operand. I try to execute this code: @0 aaaaaaaa // (SP) @4 00000400 // (PC) @400 4e714e71 // (NOP) (NOP) @404 247c0000 // MOVEA.L #$00000800,A2 @408 080060fe

I see this wishbone access in order

address sel 400 1111 404 1111 408 0011 40c 0011 408 0011 40c 1111 410 1111 408 0011 40c 1111 410 1111 .........

So, i never see flag activation for 2 MSB of 0x408. If I strobe data read with SEL_I, I'll charge 32'h0000zzzz in register A2 (instead of 32'h00000800).

Take into account that if change the code, for example without NOP operation: @0 aaaaaaaa // (SP) @4 00000400 // (PC) @400 247c0000 // MOVEA.L #$00000800,A2 @404 080060fe

I see a different behaviour: address sel 400 1111 404 1111 408 0011 404 0011 408 1111 40c 1111 404 0011 408 1111 40c 1111 ............... so I fetch correctly the entire operand within register A2

Thank you very much for your valuable example.

You are absolutely right - there is a bug. The output SEL_O signal is invalid in the case you showed.

I commited a fix. I believe it solves the problem. Now all instruction fetches are with SEL_O <= 4'b1111, except one case when the prefetch is empty and the pc register has pc1:0 == 2'b10.

Thank you once more. Aleksander Osman.