Triggers on instruction opcdes

[Mark Hill]

Could someone clarify the RV Debug Architecture for me when triggers are set on instruction opcodes (using mcontrol.[match=0, select=1]) in a machine with compressed instruction support.

My expectation is that if I'm looking for a match on a 32-bit instruction I would place the full 32-bit opcode (including specific values for operand fields) in tdata2, and that tor a 16-bit instruction I would place the full 16-bit opcode in tdata2[15:0]; with the upper bits either being ignored or perhaps requiring zero-extension.

However, when I looked at the spike model  it looks like all matching is done on 16bit values, so tdata2 must contain a zero-extended 16-bit value (or it will never match anything) and will trigger if either the top or the bottom of a 32-bit opcode matches:

https://github.com/riscv/riscv-isa-sim/blob/d48f107dba6a96fb827cb47fdf290261feadeb35/riscv/mmu.h

This does not sound right to me (or perhaps I've misread the code).

Thanks

[Tim Newsome]

This is definitely underspecified. I don’t think opcode matching has really been tested in spike, so I wouldn’t take it as an authority.

The core problem is that we have to specify some bits for the remainder on RV32 when setting an opcode trigger for a compressed instruction. The same problem exists on RV64 for all instructions. The interface doesn’t support ignoring bits (short of using a second trigger to add a mask, which seems pretty wasteful for this common case). We could extend with 0, but I’m worried that adding 0 to a compressed instruction might match a valid 32-bit instruction. Safest seems to be to say that the high bits must be filled in with c.nop instructions (16’h1). How does that sound?

Tim

​

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/0fea5c0e-640f-4702-bff7-ba0ea0db1ae3%40groups.riscv.org.

[Mark Hill]

Thanks for the reply. I don’t think there is an issue with false hits on 32bit opcodes because they all have bits[1:0]=3 and all 16-bit opcodes have bits[1:0]!=3. So the operation could be specified as only checking bits [31:16] if bits[1:0] of tdata2=3, or alternatively, zero extended without risking a false match.

There’s also the related issue of matches on sub-word loads and stores (signed and unsigned) which it would be good to clarify.

Mark

[Tim Newsome]

The general solution involves adding an access size to match triggers.

Currently mcontrol has 6 bits set aside for action, which is more than needed. (5 actions are defined.) We could easily take 2 bits from the action field, and use them to encode access size of 8, 16, 32, or 48 bits. (Instructions can be 48 bits.) Sizes greater than 32 can only happen on harts with XLEN at least 64. In that case the mcontrol register has 32 unused bits. We can take 2 more of those, to also encode sizes 64, 80, 96, 112, 128.

A different way of encoding this, is to take just 1 bit from mcontrol. If that bit is 0, then the size is MXLEN. If the bit is 1, then the size is less than MXLEN, and the actual size is encoded in the top bits of tdata2. This has the benefit that it's completely backwards compatible, but is a more convoluted encoding.

What do you think?

Tim

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/3e1180b2-388a-498c-9e16-66cad153e49e%40groups.riscv.org.

[bruce.ableidinger]

My take on opcode triggers is to have a match value along with a mask value. The value and mask are combined to allow triggering on categories of opcodes, not just strictly on one value. It also then supports 16-bit opcodes of compressed instructions - the user sets up two triggers: the first one has the opcode value in [31:16] and a mask of 0x0000FFFF (0 means care, 1 means don't care) and the second trigger with the opcode value in [15:0] and a mask of 0xFFFF0000.

--- Bruce

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.

To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/3e1180b2-388a-498c-9e16-66cad153e49e%40groups.riscv.org.

[Tim Newsome]

Masks are flexible, but take a lot of bits to store. We currently support masks by chaining two triggers together, but for the common case of setting a trigger on an RV16 instructions, or an 8-bit data load, it feels pretty wasteful to have to use a second trigger to do that.

Tim

On Mon, Jul 9, 2018 at 3:23 PM, bruce.ableidinger <bruce.ab...@gmail.com> wrote:

My take on opcode triggers is to have a match value along with a mask value.  The value and mask are combined to allow triggering on categories of opcodes, not just strictly on one value.  It also then supports 16-bit opcodes of compressed instructions - the user sets up two triggers: the first one has the opcode value in [31:16] and a mask of 0x0000FFFF (0 means care, 1 means don't care) and the second trigger with the opcode value in [15:0] and a mask of 0xFFFF0000. 

--- Bruce

-----Original Message-----
From: Mark Hill <mark....@gmail.com>
Sent: Sunday, July 8, 2018 1:38 PM
To: RISC-V Debug Group <de...@groups.riscv.org>
Subject: Re: [debug] Triggers on instruction opcdes

Thanks for the reply. I don’t think there is an issue with false hits on 32bit opcodes because they all have bits[1:0]=3 and all 16-bit opcodes have bits[1:0]!=3. So the operation could be specified as only checking bits [31:16] if bits[1:0] of tdata2=3, or alternatively, zero extended without risking a false match.

There’s also the related issue of matches on sub-word loads and stores (signed and unsigned) which it would be good to clarify.

Mark

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

[Mark Hill]

I think I prefer your first proposal Tim. It’s neat and regular and I don’t think you need to worry too much about legacy yet. I’m more concerned about eliminating ambiguity in the spec to avoid future implementations diverging and complicating the development and maintenance of shared tools.

Mark

[Tim Newsome]

OK. I've written up a pull request for that proposal here: https://github.com/riscv/riscv-debug-spec/pull/310

Tim

On Wed, Jul 11, 2018 at 3:03 AM, Mark Hill <mark....@gmail.com> wrote:

I think I prefer your first proposal Tim. It’s neat and regular and I don’t think you need to worry too much about legacy yet. I’m more concerned about eliminating ambiguity in the spec to avoid future implementations diverging and complicating the development and maintenance of shared tools.

Mark

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/6b361cba-caf1-48ff-9fb2-7451341c4082%40groups.riscv.org.

[mark...@gmail.com]

Hi Tim,

The spec says that these “will result in the same load happening again when the debugger lets the hart run”. Does that mean that the gpr will have also been updated prior to entry to debugger, or is the result of the first load thrown away and gpr is only updated at restart. 

Mark

[Tim Newsome]

Quoting a little more context, from the definition of the timing bit in mcontrol:

0: The action for this trigger will be taken just be-
fore the instruction that triggered it is executed,
but after all preceding instructions are are com-
mitted.
...
Data load triggers with timing of 0 will result in

the same load happening again when the debugger

lets the hart run.

With timing=0, the trigger fires before the instruction is executed, meaning the GPR is not yet updated.

Tim

On Tue, Sep 11, 2018 at 7:26 AM, <mark...@gmail.com> wrote:

Hi Tim,

The spec says that these “will result in the same load happening again when the debugger lets the hart run”. Does that mean that the gpr will have also been updated prior to entry to debugger, or is the result of the first load thrown away and gpr is only updated at restart. 

Mark

On 9 Jul 2018, at 23:14, Tim Newsome <t...@sifive.com> wrote:

The general solution involves adding an access size to match triggers.

Currently mcontrol has 6 bits set aside for action, which is more than needed. (5 actions are defined.) We could easily take 2 bits from the action field, and use them to encode access size of 8, 16, 32, or 48 bits. (Instructions can be 48 bits.) Sizes greater than 32 can only happen on harts with XLEN at least 64. In that case the mcontrol register has 32 unused bits. We can take 2 more of those, to also encode sizes 64, 80, 96, 112, 128.

A different way of encoding this, is to take just 1 bit from mcontrol. If that bit is 0, then the size is MXLEN. If the bit is 1, then the size is less than MXLEN, and the actual size is encoded in the top bits of tdata2. This has the benefit that it's completely backwards compatible, but is a more convoluted encoding.

What do you think?

Tim

On Sun, Jul 8, 2018 at 1:38 PM, Mark Hill <mark....@gmail.com> wrote:

Thanks for the reply. I don’t think there is an issue with false hits on 32bit opcodes because they all have bits[1:0]=3 and all 16-bit opcodes have bits[1:0]!=3. So the operation could be specified as only checking bits [31:16] if bits[1:0] of tdata2=3, or alternatively, zero extended without risking a false match.

There’s also the related issue of matches on sub-word loads and stores (signed and unsigned) which it would be good to clarify.

Mark

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.

To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.