Full-featured spec: RISC-V Debug Module Integration with ARM processor

[zhongho chen]

Hi,

This is a hypothetical question, but it is likely to happen.

Assuming my SoC has both RISC-V processors and ARM processors, how would I integrate debug debug subsystem?

Since ARM processors use CoreSight architecture, all debug components are using APB interface.

Is it possible to use APB interface as debug bus for RISC-V Debug Module?

Thanks

[Richard Herveille]

Hi,

If that's what you want, take a look at my lightweight debug spec. It uses MMIO instead of debug rom. It can be easily mapped into any address space. 

I currently use AHB for example. 

Richard

Sent from my iPad

--
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/4dc9e9fd-6db5-4b74-a50c-ff3bab3306ee%40groups.riscv.org.

[Tim Newsome]

As it stands right now you could make it work, but it's not convenient. The problem is that the Debug Bus is 34 bits wide, which is not supported by APB. The reason that it's 34 bits wide is to keep the JTAG Debug Transport Module efficient and simple.

In your scenario you could work around this by implementing a CoreSight Debug Transport module, which translates between 32-bit APB accesses and 34-bit Debug Bus accesses. The straightforward approach would be to keep a 34-bit register that CoreSight can access the lower 32 and upper 2 bits from.

A different solution might be to spec an optional 18-bit Debug Bus, which includes 16 data bits. It might take some fiddling to figure out the appropriate behavior for the currently specced 32 registers, but none of them should have side effects so it might "just work."

This is definitely an issue that could use some more thought, and at the least there ought to be a recommended way of solving this problem.

Gajinder Panesar from UltraSoC might have some better insight here. I know he's been looking at making their components (which use APB) with the Debug Module.

System overview for reference:

Tim

[Megan Wachs]

One thought...

The upper two bits are the Interrupt and Halt Notification bits (if I am ignoring the Serial interface). These bits could be accessed elsewhere in the lower 32 bits (e.g. reflect them in the CONTROL register at lower locations). Then the upper 2 bits would become optional, and using them is just an efficiency. In systems that don't implement them they get tied to conservative values. 

OpenOCD, etc would have to then implement two completely different protocols, so not sure how practical this suggestion is.

Megan

--

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/CAGDihenZD4zsApgT-PX%2B6j8dby8Le%3D2JWdS8S6CHKqrSQH41pA%40mail.gmail.com.

--

Megan A. Wachs

Engineer | SiFive, Inc 

300 Brannan St, Suite 403 

San Francisco, CA  94107 

me...@sifive.com

[Stefan Wallentowitz]

On 25.10.2016 19:32, Tim Newsome wrote:
> On Mon, Oct 24, 2016 at 7:35 PM, zhongho chen <zhong...@gmail.com
> <mailto:zhong...@gmail.com>> wrote:
>
> This is a hypothetical question, but it is likely to happen.
> Assuming my SoC has both RISC-V processors and ARM processors, how
> would I integrate debug debug subsystem?
> Since ARM processors use CoreSight architecture, all debug
> components are using APB interface.
> Is it possible to use APB interface as debug bus for RISC-V Debug
> Module?
>
>
> As it stands right now you could make it work, but it's not convenient.
> The problem is that the Debug Bus is 34 bits wide, which is not
> supported by APB. The reason that it's 34 bits wide is to keep the JTAG
> Debug Transport Module efficient and simple.
> In your scenario you could work around this by implementing a CoreSight
> Debug Transport module, which translates between 32-bit APB accesses and
> 34-bit Debug Bus accesses. The straightforward approach would be to keep
> a 34-bit register that CoreSight can access the lower 32 and upper 2
> bits from.

Just something that comes to my mind: Didn't the ARM debug spec also
specify a debug monitor approach similar to the one Tim proposes? Cannot
really find useful information from a quick search if I confuse it with
MIPS or if it is still there.

Cheers,
Stefan

[Tim Newsome]

On Tue, Oct 25, 2016 at 10:43 AM, Megan Wachs <me...@sifive.com> wrote:

The upper two bits are the Interrupt and Halt Notification bits (if I am ignoring the Serial interface). These bits could be accessed elsewhere in the lower 32 bits (e.g. reflect them in the CONTROL register at lower locations). Then the upper 2 bits would become optional, and using them is just an efficiency. In systems that don't implement them they get tied to conservative values. 

That's a really good idea.

OpenOCD, etc would have to then implement two completely different protocols, so not sure how practical this suggestion is.

Yes, but giving OpenOCD a CoreSight transport option is going to force most of it to be rewritten anyway.

Tim

 

Megan

On Tue, Oct 25, 2016 at 10:32 AM, Tim Newsome <t...@sifive.com> wrote:

On Mon, Oct 24, 2016 at 7:35 PM, zhongho chen <zhong...@gmail.com> wrote:

This is a hypothetical question, but it is likely to happen.

Assuming my SoC has both RISC-V processors and ARM processors, how would I integrate debug debug subsystem?

Since ARM processors use CoreSight architecture, all debug components are using APB interface.

Is it possible to use APB interface as debug bus for RISC-V Debug Module?

As it stands right now you could make it work, but it's not convenient. The problem is that the Debug Bus is 34 bits wide, which is not supported by APB. The reason that it's 34 bits wide is to keep the JTAG Debug Transport Module efficient and simple.

In your scenario you could work around this by implementing a CoreSight Debug Transport module, which translates between 32-bit APB accesses and 34-bit Debug Bus accesses. The straightforward approach would be to keep a 34-bit register that CoreSight can access the lower 32 and upper 2 bits from.

A different solution might be to spec an optional 18-bit Debug Bus, which includes 16 data bits. It might take some fiddling to figure out the appropriate behavior for the currently specced 32 registers, but none of them should have side effects so it might "just work."

This is definitely an issue that could use some more thought, and at the least there ought to be a recommended way of solving this problem.

Gajinder Panesar from UltraSoC might have some better insight here. I know he's been looking at making their components (which use APB) with the Debug Module.

System overview for reference:

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+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/CAGDihenZD4zsApgT-PX%2B6j8dby8Le%3D2JWdS8S6CHKqrSQH41pA%40mail.gmail.com.

[Gajinder Panesar]

Hello,

  It really isn't hypothetical.
  We have just such a system. In fact there will be systems with Ceva/MIPs/ARC/Xtensa and RISCVs.
  We do need to be core vendor neutral. So forcing something along the lines of CoreSight is not the way to go.

  Regards,

    Gadge

[zhongho chen]

Hi Tim,

Do you have quantitative comparison between 34-bit and 32-bit debug bus?

Users are only sensitive to few debug operations, such as load program.

Other debug operations are fine to have reasonable latency. 

Thanks,

Alex

Tim Newsome於 2016年10月26日星期三 UTC+8上午4時49分53秒寫道：

[Michael Chapman]

On 26/10/2016 02:58, zhongho chen wrote:

Hi Tim,

Do you have quantitative comparison between 34-bit and 32-bit debug bus?

Users are only sensitive to few debug operations, such as load program.

Other debug operations are fine to have reasonable latency.

This is not true. The latency is sometimes a big issue. This is particularly true for single stepping and users are very sensitive to this.
There is a (reasonable) expectation that single step is instantaneous.

When debugging with a RTOS in place and single stepping, for each step an awful lot of state is downloaded.
In particular, openOCD at gdb's request for task information will download the task control block from the RTOS (including most of the register state) for all tasks.

We have come across examples where a single step on windows with the standard driver takes several seconds which is unacceptable from a user perspective.

With a dumb USB <-> JTAG cable, which is most of the commonly available cables (they are based on a FTDI chip) and with the standard manufacturers driver on windows, this is painfully slow. It is a lot faster with libusb though.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/adf41e76-cfc4-4896-b6f8-a54cc163c2f9%40groups.riscv.org.

[Stefan Wallentowitz]

On 26.10.2016 10:57, Michael Chapman wrote:
>
>
> On 26/10/2016 02:58, zhongho chen wrote:
>> Hi Tim,
>>
>> Do you have quantitative comparison between 34-bit and 32-bit debug bus?
>> Users are only sensitive to few debug operations, such as load program.
>> Other debug operations are fine to have reasonable latency.
>
> This is not true. The latency is sometimes a big issue. This is
> particularly true for single stepping and users are very sensitive to this.
> There is a (reasonable) expectation that single step is instantaneous.

But isn't that just a few cycles on the chip? As I understood the
proposal there can be an adapter from 34 bit JTAG to a standardized 32
bit interface, right? So it won't be an extra host<->target cycle.

Cheers,
Stefan

[Gajinder Panesar]

Yes, this is my understanding too.

I think we should use a standard bus.

--
You received this message because you are subscribed to a topic in the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.riscv.org/d/topic/debug/gBmB06JlIYc/unsubscribe.
To unsubscribe from this group and all its topics, 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/644db082-8b7e-c5d1-64f8-bef42c43d8f5%40wallentowitz.de.

[Stefan Wallentowitz]

On 26.10.2016 13:45, Gajinder Panesar wrote:
> Yes, this is my understanding too.
> I think we should use a standard bus.

Hi all,

while in favor of a simple light weight debug interface (just because I
am not a run-control fan) I am really happy to see some convergence on
both specs, and a similar run control interface is a good start (will
comment on details in the respective thread).

As some of you know I am working on the Open SoC Debug project
(opensocdebug.org) and for me clear "standard" interfaces are very
important, and ideally those interfaces can be used in different
platforms including a slave bus interface..

To me that means I can hook it up easily, a unified interface for RISC-V
is of course beneficial, but not a must. Let me roughly my understanding
and suggestions on platform interfaces.

## MMIO slave interfaces:

- The debug monitor ("full-featured") approach defines the debug bus of
the the debug unit to be accessed by JTAG or any other transport. In our
case this transport is abstracted to and there is a simple debug
interconnect we hook a simple adapter (including CDC) to it.

- The memory-mapped debug unit ("light-weight") has an interface that
is somewhat derived from the "advanced debug system" used in OpenRISC.
We support it already, it is just the memory map that varies.

For the lowRISC project it would be generally an option supporting both
the debug monitor for the Rocket or BOOM cores and the mmio debug unit
potentially for the ri5cy cores. Of course generally a full
compatibility between both interfaces is desirable, but thats up to the
RISC-V Foundation Working Group of course.

An important aspect in that context is the possibility to discover the
interface at runtime. While more complex SoCs, such as those featuring
the Open SoC Debug infrastructure, have other means to know which
protocol each debug unit speaks, for simple embedded system a base MMIO
register describing the core, protocol, version etc. is very important.

## Trace interface

An interface for simple sampling of the core execution is necessary. In
my humble opinion it should be decoupled from the run control entirely
with respect to the basic interface. This still leaves room for
configuration of this trace interface from the debug monitor for
example, but from a platform perspective a simple pin interface with
valid signals for different events (retired instructions, register
write-back, predictor update, privilege level change, ..) is the most
flexible to use.

Generally it is of course better to define this interface at a higher
abstraction level, but that would pretty much harden the integration
with other platforms (which may use different trace packet formats etc.).

So in my opinion there should be a very basic pin-level interface
defined, with the potential future plan to define or decide for a
unified trace format (nexus 5001 is not really open imho).

Sorry for the lengthy mail.

Cheers,
Stefan

[Gajinder Panesar]

Hello all,

I largely agree with Stefan, both fully featured and light-wieght interfaces will need to exist. Where possible use existing standards, e.g. buses.
The trace should be decoupled from the run-control, but that doesn't mean you can have an implementation which has a block that does both. We should, for now describe the pin-level interface. This will allow for implementions which may have diifferent levels of compression for example.

Commercial systems will have mixtures of different cores, not just RISCV based ones, so we need to be mindful of that.

  Regards,

    Gadge

--
You received this message because you are subscribed to a topic in the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.riscv.org/d/topic/debug/gBmB06JlIYc/unsubscribe.
To unsubscribe from this group and all its topics, 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/84a19ea8-517c-bfa8-b043-fde57223c6d3%40wallentowitz.de.

[Tim Newsome]

On Tue, Oct 25, 2016 at 5:58 PM, zhongho chen <zhong...@gmail.com> wrote:

Do you have quantitative comparison between 34-bit and 32-bit debug bus?

I don't. There's a lot that goes on in real-world performance.

One is the number of bits scanned. Naively just changing all Debug Module registers to be 32 bits wide, the number of bits scanned would roughly double. Just eye balling it, there's probably some stuff that can be done to make the increase 10% or so. If you have awesome JTAG debug hardware, this is the dominating factor.

Another is the number of batches of scans that need to happen. That's basically the number of scans that you can do before the debugger has to actually look at the result. That should be unaffected by this change. If you're using a cheap USB JTAG adapter then this is the dominating factor (and OpenOCD has a bunch of code to optimize for this).

I think the upshot here is that the performance gains of a 34-bit wide bus are not that significant, and it sounds like there is real interest in being able to use a standard bus as the Debug Bus.

I'll spend some more time puzzling out the details, which will probably end up as an incompatible new version of the spec. (If so, I plan to keep OpenOCD backwards compatible for quite some time.)

As Stefan points out, compatibility could be achieved by adding extra adapter hardware, but it seems better to put that logic in software if we can.

 

Users are only sensitive to few debug operations, such as load program.

Other debug operations are fine to have reasonable latency. 

As Michael says, most operations matter. This is especially true when using a graphical IDE, which will want to update everything the user has a view open after every step. But that doesn't affect what I wrote above.

Tim

 

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/adf41e76-cfc4-4896-b6f8-a54cc163c2f9%40groups.riscv.org.