Fwd: [Open SoC Debug] GSoC project to improve soft-CPU debugging in LiteX + MiSoC

[SHIVAM AGGARWAL]

Hi,

I talked to the OSD folk and that's what they advised me. I think the proposed implementation seems reasonable and can be used for the project. Please provide your valuable feedback.

Thanks

Shivam Aggarwal

---------- Forwarded message ----------
From: Philipp Wagner <philipp...@tum.de>
Date: Wed, Mar 21, 2018 at 2:27 AM
Subject: Re: [Open SoC Debug] GSoC project to improve soft-CPU debugging in LiteX + MiSoC
To: openso...@lists.librecores.org


Hi Shivam,

Am 19.03.2018 um 16:09 schrieb SHIVAM AGGARWAL:
> Currently, I am working with Timvideos.us and researching about this
> issue #issue 39 <https://github.com/timvideos/getting-started/issues/39>
> to create a generic debug system for soft CPU cores(or1k, lm32, risc-v)
> and a GDB server as a part of GSOC project.

Sounds good!
> I looked at some emails from
> the last year's archives at OpenSOC. Tim introduced the project on the
> mailing list
> <https://lists.librecores.org/pipermail/opensocdebug/2017-March/000024.html>
> and some constructive discussion was carried out. A rough outline of how
> the project could be implemented was also discussed:
> https://docs.google.com/drawings/d/1AmjG0FFkTv_wLnw1iKEqU-Do72TsChtH6hlmAS98At8/edit
> <https://docs.google.com/drawings/d/1AmjG0FFkTv_wLnw1iKEqU-Do72TsChtH6hlmAS98At8/edit>

That's a good drawing. It's not fully correct any more w.r.t. the
changes we've recently made in OSD, but the general idea holds. (If the
time comes we can discuss in more detail how a fully accurate picture
would look like.)

> My current progress:
>
> 1. I have thoroughly read about JTAG, OpenOCD, adv_dbg_sys implemented
> by opencores.
>
> 2. I also read the documentation of OpenSOC and in the process of
> setting up the development environment for the same.
>
> 3. Initially, I propose to tackle the project using the architecture
> implementation of adv_dbg_sys but OpenSOC seems to be a better alternative.
>
>
> I am quite interested in the project and would like to implement the
> project as a part of this year's GSOC. I believe a lot of things are
> already implemented as a part of OpenSOC project and can be used in this
> project. It would be great if someone could provide a rough outline of
> the project and guide me for the same.
>
>
> Looking forward to your valuable suggestions for the project.

The picture you've shared already shows some of the main areas which
need work to integrate OSD with LiteX/MiSoC. Please bear in mind that
I'm not overly familiar with LiteX/MiSoC, please make sure to
double-check with someone more knowledgable for these things before
taking things for granted :-)

- The main work will most likely be the work on adding run-control
debugging to OSD. This means on the hardware side the CDM module, and on
the software side the GDB server bridge. For some of these modules, we
have (outdated) drafts laying around, but essentially it's a start from
scratch -- which shouldn't be too frightening, as all accesses done by
GDB are register reads/writes. Depending on the CPU you're targeting the
hardware and software implementations will look different, and also the
existing code you can re-use. My experience is mainly with the mor1kx
cores, I haven't looked to closely at the lm32 cores. RISC-V has a
rather recently standardized run-control debug interface, which is,
however significantly different from what mor1kx has.

- The second area of work is the off-chip transport. In OSD we typically
use GLIP, a FIFO-based off-chip transport. That's the easiest way
forward, sine it's known to work. If you want to re-use existing
off-chip communication infrastructure of LiteX/MiSoC you'd need to put a
bit of work into that as well. On the hardware side, you'd need to
provide anything which acts like a FIFO. On the host (software) side you
can either extend write a new gateway implementation which feeds the
received data into the system. Or you can extend GLIP, as the picture
shows. (Note that we've changed the structure of the host software a bit
recently and GLIP is not encapsulated inside the opensocdebug daemon any
more, but living side by side. This makes it easier to write new
host-device gateways.)


To summarize, the easiest path forward would be:

- Target mor1kx CPU cores.
- Use the existing GLIP off-chip interface unchanged.
- Focus on the run-control hardware and software parts.

Depending on the time budget you can either have a look at re-using
existing off-chip communication infrastructure, or at supporting more
CPU types.


For GSoC, I'm willing to co-mentor this project with someone from
timvideos/LiteX/MiSoC. If all of that sounds reasonable to you, please
start by drafting a proposal. It probably will help to have a video call
when you're done with a first draft to see where misunderstandings
happened and what can be improved.

Please let me know how you want to proceed.

Best,

Philipp
_______________________________________________
OpenSoCDebug mailing list
OpenSo...@lists.librecores.org
https://lists.librecores.org/listinfo/opensocdebug

[SHIVAM AGGARWAL]

Hi Philip,

Thanks for the prompt reply.

I discussed the proposed solution with Tim in last two days and he is quite satisfied with the proposed implementation details.

So, a rough outline to tackle the project would be:

1. To add support for run-control debugging in OSD.

2. To add OSD into LITEX firmware using existing off-communication tool i.e. GLIP.

3. If everything works fine, then to figure out some alternative for GLIP.  

Few queries:

 1. I looked at the documentation of or1k and figured out the debug registers. So, as part of the software side i.e. GDB server bridge, I am supposed to read and write from the registers. Now, how will CDM module work?

- The second area of work is the off-chip transport. In OSD we typically
use GLIP, a FIFO-based off-chip transport. That's the easiest way
forward, sine it's known to work. If you want to re-use existing
off-chip communication infrastructure of LiteX/MiSoC you'd need to put a
bit of work into that as well. On the hardware side, you'd need to
provide anything which acts like a FIFO. On the host (software) side you
can either extend write a new gateway implementation which feeds the
received data into the system. Or you can extend GLIP, as the picture
shows. (Note that we've changed the structure of the host software a bit
recently and GLIP is not encapsulated inside the opensocdebug daemon any
more, but living side by side. This makes it easier to write new
host-device gateways.)

2. As far as I understand, GLIP is used for transferring data from host to target using FIFO mechanism. Is that correct?

3. There are modules like OSD Host Interface Module and OSD interconnect debug. Do I need to study these blocks for the project? It would be very helpful if you can guide as to which modules to target for the project proposal.

To summarize, the easiest path forward would be:

- Target mor1kx CPU cores.
- Use the existing GLIP off-chip interface unchanged.
- Focus on the run-control hardware and software parts.

Depending on the time budget you can either have a look at re-using
existing off-chip communication infrastructure, or at supporting more
CPU types.


For GSoC, I'm willing to co-mentor this project with someone from
timvideos/LiteX/MiSoC. If all of that sounds reasonable to you, please
start by drafting a proposal. It probably will help to have a video call
when you're done with a first draft to see where misunderstandings
happened and what can be improved.

Please let me know how you want to proceed.

Best,

Philipp
_______________________________________________
OpenSoCDebug mailing list
OpenSo...@lists.librecores.org
https://lists.librecores.org/listinfo/opensocdebug

Thanks
Shivam Aggarwal

[SHIVAM AGGARWAL]

Some corrections.

I looked at the project description at the website. I figured out that two important points:

In order to support these operations from GDB, the goal of this project is to create
(a) hardware extensions in SystemVerilog, which allow reading control registers from a CPU (these are used to set breakpoints and halt/continue the CPU), which I suppose is CDM module.
and (b) create a gdbserver implementation inside our Open SoC Debug software implementation which GDB can connect to.

Now, what exactly is a hardware extension and is it possible to code these hardware extensions in Verilog?

 

- The second area of work is the off-chip transport. In OSD we typically
use GLIP, a FIFO-based off-chip transport. That's the easiest way
forward, sine it's known to work. If you want to re-use existing
off-chip communication infrastructure of LiteX/MiSoC you'd need to put a
bit of work into that as well. On the hardware side, you'd need to
provide anything which acts like a FIFO. On the host (software) side you
can either extend write a new gateway implementation which feeds the
received data into the system. Or you can extend GLIP, as the picture
shows. (Note that we've changed the structure of the host software a bit
recently and GLIP is not encapsulated inside the opensocdebug daemon any
more, but living side by side. This makes it easier to write new
host-device gateways.)

2. As far as I understand, GLIP is used for transferring data from host to target using FIFO mechanism. Is that correct?

3. There are modules like OSD Host Interface Module and OSD interconnect debug. Do I need to study these blocks for the project? It would be very helpful if you can guide as to which modules to target for the project proposal.

The OSD documentation gives information about each module. But, since I am not changing anything on this side do I need detailed knowledge of each module for the project?

To summarize, the easiest path forward would be:

- Target mor1kx CPU cores.
- Use the existing GLIP off-chip interface unchanged.
- Focus on the run-control hardware and software parts.

Depending on the time budget you can either have a look at re-using
existing off-chip communication infrastructure, or at supporting more
CPU types.


For GSoC, I'm willing to co-mentor this project with someone from
timvideos/LiteX/MiSoC. If all of that sounds reasonable to you, please
start by drafting a proposal. It probably will help to have a video call
when you're done with a first draft to see where misunderstandings
happened and what can be improved.

Please let me know how you want to proceed.

Best,

Philipp
_______________________________________________
OpenSoCDebug mailing list
OpenSo...@lists.librecores.org
https://lists.librecores.org/listinfo/opensocdebug

Thanks
Shivam Aggarwal

Thanks

Shivam Aggarwal

[Philipp Wagner]

The (more or less only) job of the CDM module is to play "register
access translator". In OSD we already have the notion of register
accesses to debug modules, e.g. to query the type of debug module.

For the CDM module to work you need two things:
1) Specify the register map: probably you'll map the debugging registers
of the mor1kx CPU somewhere to the 16 bit address space of OSD registers.

2) Copy an existing debug module and make use of the osd_regaccess
Verilog module to forward the register accesses to the debug ports of
the mor1kx core.

3) (And that's possibly a bit more tricky.) Even though we specify
register accesses of other word width than 16 bit, only 16 bit are
currently used. In some places the implementation is generic enough to
handle wider register data width, in others it isn't. So you'll need to
go through the data path between the debug modules and the hardware to
see where things need to be changed to support 32 bit word width. (Or,
of course, map a 32 bit mor1kx debug register to two 16 bit OSD
registers, as a workaround if we run into roadblocks.)

Relevant documentation:

- https://opensocdebug.readthedocs.io/en/latest/02_spec/03_dataformats.html
- https://opensocdebug.readthedocs.io/en/latest/02_spec/04_api.html

>> - The second area of work is the off-chip transport. In OSD we typically
>> use GLIP, a FIFO-based off-chip transport. That's the easiest way
>> forward, sine it's known to work. If you want to re-use existing
>> off-chip communication infrastructure of LiteX/MiSoC you'd need to put a
>> bit of work into that as well. On the hardware side, you'd need to
>> provide anything which acts like a FIFO. On the host (software) side you
>> can either extend write a new gateway implementation which feeds the
>> received data into the system. Or you can extend GLIP, as the picture
>> shows. (Note that we've changed the structure of the host software a bit
>> recently and GLIP is not encapsulated inside the opensocdebug daemon any
>> more, but living side by side. This makes it easier to write new
>> host-device gateways.)
>>
>
> 2. As far as I understand, GLIP is used for transferring data from host to
> target using FIFO mechanism. Is that correct?

yes, where "FIFO" is essentially the API on the HDL side and on the
software side.

- General logic description (hardware):
http://www.glip.io/group__logicif.html
- Example HW interface:
https://github.com/TUM-LIS/glip/blob/master/src/backend_cypressfx3/logic/verilog/glip_cypressfx3_toplevel.sv#L59
- SW: glip_read()
http://www.glip.io/group__communication.html#ga2e5385d600d1df1263517b1879cddaaf
& friends

> 3. There are modules like OSD Host Interface Module and OSD interconnect
> debug. Do I need to study these blocks for the project? It would be very
> helpful if you can guide as to which modules to target for the project
> proposal.

No, these modules are "infrastructure" and you can (most likely) take
them as they are.


Best,

Philipp