number of hw breakpoints?

[Liviu Ionescu]

Does anyone remember what were the reasons behind the decision to have only two hw breakpoints in the current E31/E51 chips? 

Thank you,

Liviu

[kr...@berkeley.edu]

Hi Liviu,

>>>>> On Sat, 26 Aug 2017 15:10:42 -0700 (PDT), Liviu Ionescu <i...@livius.net> said:

| Does anyone remember what were the reasons behind the decision to have only two
| hw breakpoints in the current E31/E51 chips? 

This is really a SiFive question as opposed to a generic RISC-V debug
question. The E31 and E51 are standard softcores, not chips. The
choice reflects a tradeoff between core size and functionality, based
on customer interactions. Other versions of the cores have been
requested with greater or fewer hardware breakpoints.


Krste


| Thank you,


| Liviu


| --
| 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/
| b6505247-47ab-41cd-a761-0117a4bb527c%40groups.riscv.org.

[Liviu Ionescu]

> On 27 Aug 2017, at 23:40, kr...@berkeley.edu wrote:
>
>
> | Does anyone remember what were the reasons behind the decision to have only two
> | hw breakpoints in the current E31/E51 chips?
>
> This is really a SiFive question as opposed to a generic RISC-V debug
> question.

ah, ok, sorry for misplacing the question.

> ... a tradeoff between core size and functionality, based

> on customer interactions. Other versions of the cores have been
> requested with greater or fewer hardware breakpoints.

fewer? for cores that are never expected to run a debug session, probably, but for cores that are expected to run even a simple GDB session, 2 are already below the reasonable limit. :-(

any idea what would be the incremental increase in core size (in % of transistors, or die size, or whatever) for an increase of 2 -> 4 hw breakpoints for a chip like Freedom E310?


regards,

Liviu

[Krste Asanovic]

> On Aug 27, 2017, at 1:54 PM, Liviu Ionescu <i...@livius.net> wrote:
>
>> ... a tradeoff between core size and functionality, based
>> on customer interactions. Other versions of the cores have been
>> requested with greater or fewer hardware breakpoints.
>
> fewer? for cores that are never expected to run a debug session, probably, but for cores that are expected to run even a simple GDB session, 2 are already below the reasonable limit. :-(

Right, some products don’t want debug capability at all.

If the code is in SRAM, you can use software breakpoints too.

> any idea what would be the incremental increase in core size (in % of transistors, or die size, or whatever) for an increase of 2 -> 4 hw breakpoints for a chip like Freedom E310?

Not off hand, and it depends a lot on exact core configuration, but probably not more than 1% area in the overall core complex with an E31 core. There is a power cost too. The Freedom debug unit design supports a large number of hardware breakpoints. It’s just a per-product design decision trading off debug needs with area and power.

Krste

[Liviu Ionescu]

> On 28 Aug 2017, at 08:23, Krste Asanovic <kr...@berkeley.edu> wrote:
>
> If the code is in SRAM, you can use software breakpoints too.

for application class devices with lots of RAM that's probably enough, but for a Freedom E310, with 16 kB of RAM, soft breakpoints are not very useful.

>
> ... probably not more than 1% area in the overall core complex with an E31 core. There is a power cost too. The Freedom debug unit design supports a large number of hardware breakpoints.

ok, thank you, I expected so. 1% of the core probably means less than %0.5 for the entire chip, including peripherals and memory and everything.

as for power cost, is the debug subsystem always on? isn't it possible to power it down when the chip is not in a debug session?

> It’s just a per-product design decision trading off debug needs with area and power.

yes, in this case, I would say a poor design decision.

for bare-metal devices, which are expected to run from flash, 2 HW breakpoint are not enough.

to me many of the architecture design decisions seem to match only the needs of unix class devices, and ignore the needs of bare-metal embedded applications. which is a pity...


regards,

Liviu

[kr...@berkeley.edu]

>>>>> On Mon, 28 Aug 2017 10:12:28 +0300, Liviu Ionescu <i...@livius.net> said:

|| On 28 Aug 2017, at 08:23, Krste Asanovic <kr...@berkeley.edu>
|| wrote: If the code is in SRAM, you can use software breakpoints
|| too.

| for application class devices with lots of RAM that's probably
| enough, but for a Freedom E310, with 16 kB of RAM, soft breakpoints
| are not very useful.

|| ... probably not more than 1% area in the overall core complex with
|| an E31 core. There is a power cost too. The Freedom debug unit
|| design supports a large number of hardware breakpoints.

| ok, thank you, I expected so. 1% of the core probably means less
| than %0.5 for the entire chip, including peripherals and memory and
| everything.

| as for power cost, is the debug subsystem always on? isn't it
| possible to power it down when the chip is not in a debug session?

Clock and data gating is possible to reduce switching power somewhat,
but power gating for leakage reduction would probably add too much
area/complexity overhead.

|| It’s just a per-product design decision trading off debug needs with area and power.
| yes, in this case, I would say a poor design decision. for
| bare-metal devices, which are expected to run from flash, 2 HW
| breakpoint are not enough.

How many do you think is enough?

| to me many of the architecture design decisions seem to match only
| the needs of unix class devices, and ignore the needs of bare-metal
| embedded applications. which is a pity...

As I said previously, the design supports more breakpoints. The FE310
part is clearly not a Unix-class device, and was meant as a base
platform for Freedom SoC development. Other FE standard parts will
have different numbers of breakpoints, and you can have as many HW
breakpoints as you want when you order your own Freedom SoC.

Krste

| regards,

| Liviu

[Liviu Ionescu]

> On 28 Aug 2017, at 12:10, kr...@berkeley.edu wrote:
>
>
> How many do you think is enough?

for devices running from flash, which expect active debugging during development, 8 would be preferred, with 4 probably a minimum.

and 3-4 data watches would be helpful, although I don't know how well they are supported by the current specs & development tools.

> ... you can have as many HW

> breakpoints as you want when you order your own Freedom SoC.

aaaa... right, when I'll grow up and order my first Freedom SoC I'll definitely remember this. :-)

but for the moment I'm working with SiFive to design the software framework to be used for bare-metal devices (Eclipse plug-ins, tools, project templates, etc, part of the GNU MCU Eclipse project, https://gnu-mcu-eclipse.github.io/arch/riscv/); while working on the project templates I had to do lots of builds and lots of debugging, which turned to be quite a struggle :-(

as it seems, the HiFive1 board was designed for the Arduino ecosystem, without debugging in mind, probably by Unix gurus, used with unlimited software breakpoints.

hopefully further designs of bare-metal chips will also consider the needs of those who really write embedded software.


regards,

Liviu

[Tim Newsome]

On Mon, Aug 28, 2017 at 2:32 AM, Liviu Ionescu <i...@livius.net> wrote:

and 3-4 data watches would be helpful, although I don't know how well they are supported by the current specs & development tools.

The current spec allows for all manner of hardware triggers, including data watchpoints (value, address, or both).

The current OpenOCD/SiFive implementation supports triggering on reads/writes/executes at specific addresses. The SiFive cores implement a bit more as well, but OpenOCD does not.

Tim 

[Liviu Ionescu]

> On 28 Aug 2017, at 21:10, Tim Newsome <t...@sifive.com> wrote:
>
> ... all manner of hardware triggers, including data watchpoints (value, address, or both).

>
> The current OpenOCD/SiFive implementation supports triggering on reads/writes/executes at specific addresses.

great!

I'll add testing this to my TODO list.

thank you, Tim

Liviu