CDM specification content and structure

[shivmgg]

To start with the specification of CDM, I have mapped each 32 bit wide debug register of or1k to two 16 bit wide OSD debug registers. The register access request made by the GDB can be transferred using osd_regaccess_layer. Issue #7 can be resolved by this PR.

[shivmgg]

I have updated the specification as per request. Regarding read-register request, I don't think there is any register which will change its value in between. I will read about the registers more in the meantime.

[imphil]

Asked via mail on the addressing scheme:

Sorry, but I didn't get what you meant here. Currently, the debug registers spans from 0x0200 - 0x02D3. Now, we need some space after address 0x0200, so should I shift all the registers to 0x0401-0x0449 (Total debug registers: 24) ? Also, what will be those CDM-specific registers?

Right now the debug registers span from 0x0200 until 0x203, and then continue at 0x280. I don't see a reason for this gap.

What I mean is this: look up what register address e.g. the DVR0 register has in OpenRISC. Use the same value with some offset in our register set. Example: Assuming DVR0 has address 2. Then the debug register for the DVR0 register could be 0x404 (LSB) and 0x405 (MSB), according to the rule debug register = or1k_register * 2 + 0x400. Other rules could make sense as well, whatever gives you enough room in the register map.

[shivmgg]

1. Thanks for the clarification. In or1k architecture, a 16-bit SPR (Special Purpose Register) address is made of 5-bit group index (bits 15-11) and 11-bit register index (bits 10-0). https://github.com/openrisc/mor1kx/blob/a9a01c009ea2b24764973560fde4a9855f4ba95d/rtl/verilog/mor1kx-sprs.v#L95 Debug Registers belong to the Group 6. So, the mapping will be easier.
2. Regarding connections between module, gdb and other components, we can use this image: https://docs.google.com/document/d/12q9Xkt0eTBFQzIyHR0LxKVAttDApImSXfVL2hRo7rRI/edit?usp=sharing I will make this picture more centric to CDM module.

[shivmgg]

I have made few more changes to the specification. I think we just need to refine the description of index.rst Regarding the big picture view, the following links provide a clear picture of the working, connections: https://opensocdebug.readthedocs.io/en/latest/01_overview/getting_started/index.html#run-control-debug https://opensocdebug.readthedocs.io/en/latest/01_overview/getting_started/index.html#osd-for-run-control-debugging I am not very sure if repeating these things will be a good idea or not.

[imphil]

I think we just need to refine the description of index.rst Regarding the big picture view, the following links provide a clear picture of the working, connections: https://opensocdebug.readthedocs.io/en/latest/01_overview/getting_started/index.html#run-control-debug https://opensocdebug.readthedocs.io/en/latest/01_overview/getting_started/index.html#osd-for-run-control-debugging I am not very sure if repeating these things will be a good idea or not.

Not repeating, but mentioning relevant parts of it in the introduction of the OR1k-CDM module will make its description stronger. So please add a figure and associated description of the actors and components relevant to this module to the description. You don't need to focus (or possibly even mention) intermediate components like the HIM, but make sure that people get an end-to-end picture of how gdb ultimately talks to a target.

[imphil]

It seems we're getting very close now, please take another look at the comments I've posted.

[imphil]

I have now rebased and merged this to master (8de1d8fb3da2abf78bd4498cebe80e3b99d7089d). I don't think all discussions have been fully resolved, especially https://github.com/opensocdebug/osd-doc/pull/8#discussion_r188586617 could hit us again. But let's see how the implementation turns out to be and then we can always go back to the spec and refine it.