Test cases for SLT(I), SLTU(I)

[Samuel Falvo II]

Can someone please confirm if the following code fragment produces the
indicated results? I've run into a bug in my Verilog and I want to
make sure I'm writing a good testbench case for it:

addi x1, x0, -1
slti x2, x1, 1
jalr x0, 0(x2)
; instruction fetch should happen at address 1, not address 0.
; If your CPU traps misaligned accesses, then mbadaddr should equal 1.

and

addi x1, x0, -1
addi x2, x0, 1
slt x3, x1, x2
jalr x0, 0(x3)
; instruction fetch should happen at address 0, not address 1.

Thanks!

--
Samuel A. Falvo II

[Andrew Waterman]

JALR ignores the LSB of the effective address, so both should jump to address 0.  If you don't have the C extension, you can trigger a misaligned fetch exception by causing bit 1 of the effective address to be set. If you do have C, it's not possible to generate that exception at all.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3Dsomz4JH28s3LLZJvEZWTza7SUPTxTHQvTgBC%3Dupokr6gVA%40mail.gmail.com.

[Samuel Falvo II]

On Sat, Nov 26, 2016 at 11:25 AM, Andrew Waterman <and...@sifive.com> wrote:
> JALR ignores the LSB of the effective address, so both should jump to
> address 0. If you don't have the C extension, you can trigger a misaligned
> fetch exception by causing bit 1 of the effective address to be set. If you
> do have C, it's not possible to generate that exception at all.

Thanks for the clarification. This is logic that the external I-port
bus bridge would likely encapsulate for the time being, though future
CPU revisions will likely incorporate more of this logic as a matter
of course. :)

[David Horner]

Not sure what your objective is, but
the Set Less Than test could be modified slightly to resolve to different JALR addresses by providing an odd offset.

(Unlike branches the JALR does not scale the immediate value by 2)


The suggested revision may be more of a JALR validation test than SLT:

 
addi    x1, x0, -1
slti    x2, x1, 1

jalr    x0, 1(x2)
; instruction fetch should happen at address 2, not address 0.
; If your CPU traps misaligned accesses, then mbadaddr should equal 2.

and

addi    x1, x0, -1
addi    x2, x0, 1
slt     x3, x1, x2

jalr    x0, 1(x3)
; instruction fetch should happen at address 0, not address 2.

On Saturday, 26 November 2016 10:

[Samuel Falvo II]

On Sun, Nov 27, 2016 at 7:46 AM, David Horner <ds2h...@gmail.com> wrote:
> Not sure what your objective is, but

To detect the output of the ALU when executing these instructions.

> the Set Less Than test could be modified slightly to resolve to different
> JALR addresses by providing an odd offset.

This isn't necessary in my particular design as my bus architecture
exposes all 64 bits of the address.

I was more interested in making sure my interpretation/register
ordering were correct with respect to those instructions.

[David Horner]

The JALR with odd immediate is an anomaly that continues to be problematic, so I again suggest it be a Non-Standard Extension.

JALR - potential hazard and suggestion that JALR with odd immediate be NSE.

[Samuel Falvo II]

On Sun, Nov 27, 2016 at 12:49 PM, David Horner <ds2h...@gmail.com> wrote:
> The JALR with odd immediate is an anomaly that continues to be problematic,
> so I again suggest it be a Non-Standard Extension.

Can you provide a quantitative demonstration of how this is a problem?

In my CPU design, I expose all address bits for the purposes of
running the test benches and making sure the guts of the circuit are
behaving as expected. It also gives the implementor/integrator the
power to decide whether or not he wants a standards-compliant
implementation (where IADR[0] is ignored) or not (where IADR[0] feeds
back to a signal that generates an alignment trap).

Similar design decisions have been made with respect to the D-port of
the processor as well. For instance, the KCP53000 core can execute a
"ld x1, 1(x0)" instruction in one of three ways, depending on how the
core is integrated into the larger circuit:

1) It can generate an alignment trap by detecting an odd address being
used with a 64-bit transfer,
2) It can implement the required state-machine to implement hardware
assist to load a 64-bit quantity starting at address 1, or,
3) It can ignore low address bits and treat addresses 0, 1, 2, 3, 4,
5, 6, and 7 as address 0; 8, 9, 10, 11, 12, 13, 14, and 15 as address
8; and so on.