Hi all:
As previously mentioned on this e-mail list, I have forked the or1ksim
Test Suite in order to reorganise it so that orbuild can run it not only
against or1ksim, but against Verilog simulations too.
I realised today that instruction l.extws is not working as expected.
I'm still in the first development stages, so I might have made some
silly mistake, but as I'm not getting any further I have decided to ask
for help here.
According to the specification, l.extws should just copy one register to
another on 32-bit processors. On 64-bit processors it should also extend
the sign bit, but that does not apply to the current implementation in
ORPSoC V2.
Test case OR1KSIM/testsuite/test-code-or1k/ext/ext.S contains the
following line:
CHECK_MOVE(l.extws, 0x7fffffff)
That produces the right results under or1ksim, that is, it prints
0x7fffffff before and after executing the instruction. However,
when running on the ORPSoC V2 Verilog model, it prints 0x7fffffff before
the instruction and 0xffffffff afterwards.
I've tracked this issue down to this excerpt in file
ORPSOCV2/rtl/verilog/or1200/or1200_alu.v :
`ifdef OR1200_IMPL_ALU_EXT
always @(alu_op or alu_op2 or a) begin
casez (alu_op2)
`OR1200_EXTHBOP_HS : extended = {{16{a[15]}},a[15:0]};
`OR1200_EXTHBOP_BS : extended = {{24{a[7]}},a[7:0]};
`OR1200_EXTHBOP_HZ : extended = {16'd0,a[15:0]};
`OR1200_EXTHBOP_BZ : extended = {24'd0,a[7:0]};
default: extended = a; // Used for l.extw instructions
endcase // casez (alu_op2)
end
`endif
According to the spec, instruction l.extws has opcode 0x0 and opcode
0xd. After adding $display traces, I'm getting alu_op = 0x0d and alu_op2
= 0x0 at that point, which makes sense. However, the case statement only
checks alu_op2, and not alu_op, so it does not go down the "default:"
path, but it takes the OR1200_EXTHBOP_HS path. That's probably the
reason why the results differ. I wonder if alu_op2 should actually be
alu_op there.
I'm not familiar with those instructions or the Verilog implementation.
Can someone help here?
I've looked again at the spec, and instructions l.extws and l.extwz seem
unnecessary on 32-bit implementations. If you want to copy a register
you can just issue a "l.ori Rdest, Rsource, 0". Is that right?
Thanks,
rdiez
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc