<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, May 23, 2018 at 5:44 PM, Philipp Wagner <span dir="ltr"><<a href="mailto:philipp.wagner@tum.de" target="_blank">philipp.wagner@tum.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On 05/23/2018 10:36 AM, SHIVAM AGGARWAL wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 1.<br>
<br>
    *Register map for SPRs and GPRs in CDM-OR1K*:<span><br>
<br>
We can easily map 32-bit wide 32 GPRs as two 16-bit OSD specific registers in the module. We already have access to the debug unit for setting watchpoints/breakpoints.<br>
<br>
In GDB, there are commands like ‘info spr’ used to show the value of a SPR or group of SPRs and ‘spr’ to set the value of an individual SPR. There are about 12 groups (permitted upto 32) with some groups (1, 2 and 3) having 1000+ SPRs.<br>
<br>
<br>
We can assign address spaces 0x0200-0xffff (about 65023 registers) as module specific registers in CDM-OR1K. The space is enough to map each or1k register into OSD address space.<br>
</span></blockquote>
<br>
Could you list the full register map somewhere in a document (the list can contain groups, but should list all relevant register addresses and their mapping to OSD CDM register addresses). The du_addr_i signal is a 16 bit signal, given that we don't have full 16 bits available for register address in OSD (we can only start above 0x200) we need to make sure that we map all relevant parts of the or1k register space to OSD registers.<br></blockquote><div><br></div></span><div>Link:<br></div><div><a href="https://drive.google.com/open?id=15EVkp6ij-7tRm2m3mgQqwUAhHUYLOkxG" target="_blank">https://drive.google.com/open?<wbr>id=15EVkp6ij-<wbr>7tRm2m3mgQqwUAhHUYLOkxG</a><br></div><div>The pdf contains all the information about OR1K Register Set. Section 4.3 contains the list of all the Special Purpose registers. As per my understanding, we have to map each and every register (total 4665 SPRs + 32 GPRs) given in the description.  <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*Alternate solution*: Can we have certain dedicated read/write registers in the module?<span><br>
<br>
i.e instead of mapping each and every register, each time GDB asks for a specific SPR read/write, we can store its address in one of OSD register and data in two other registers. This information can be translated over system interface signals to the CPU core. But, for commands like ‘info spr’, we might need to store such information for all the SPRs.<br>
</span></blockquote>
<br>
That is possible, although very inefficient as you need multiple roundtrips for each access.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
      2. *System Interface signals*<span><br>
<br>
Currently, we have debug signals for the debug unit. The complete interface should work like this:<br>
<br>
<br>
Read operation:<br>
<br></span>
 1.<br>
<br>
    GDB commands Register read.<br>
<br>
 2.<span><br>
<br>
    OSD debug interconnect passes this request in the form of a register<br>
    read request debug packet to the module.<br>
    (<a href="https://opensocdebug.readthedocs.io/en/latest/02_spec/03_dataformats.html#register-read-request-type-sub-req-read-reg" rel="noreferrer" target="_blank">https://opensocdebug.readthed<wbr>ocs.io/en/latest/02_spec/03_da<wbr>taformats.html#register-read-<wbr>request-type-sub-req-read-reg</a>)<br>
<br></span>
 3.<span><br>
<br>
    CDM-OR1K acknowledges that request. du_we_i port goes low. (read<br>
    operation)<br>
<br></span>
 4.<span><br>
<br>
    OR1K reads data from that address into OSD registers. (du_dat_o port)<br>
<br></span>
 5.<span><br>
<br>
    Now CDM-OR1K passes this information to OSD debug interconnect in<br>
    the form of two reg read response packets.<br>
    (<a href="https://opensocdebug.readthedocs.io/en/latest/02_spec/03_dataformats.html#register-read-response-type-sub-resp-read-reg-success" rel="noreferrer" target="_blank">https://opensocdebug.readthed<wbr>ocs.io/en/latest/02_spec/03_da<wbr>taformats.html#register-read-<wbr>response-type-sub-resp-read-<wbr>reg-success</a>)<br>
</span></blockquote>
<br>
What do you mean by "two reg read response packets"? Every REQ_READ_REG_16 is answered by a single RESP_READ_REG_SUCCESS_16.<br>
<br>
If you want to split a 32 bit register into two 16 bit registers over OSD you need to have two REQ_READ_REG_16 and two RESP_READ_REG_SUCCESS_16 packets, i.e. two fully independent requests.  </blockquote><br></span></div><div class="gmail_quote">Okay understood. So when GDB asks for a read operation from (let's say) SPR at address 0x423 in the CPU core, internally we need to have two REQ_READ_REG_16 for the mapped OSD specific register. And then, there will be two RESP_READ_REG_SUCCESS_16 packets, i.e. two fully independent requests.  <br></div><div class="gmail_quote">Currently, this is accomplished using osd_regaccess_layer. <br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[Given that we seem to need a significant number of registers to be mapped, and the trouble of implementing the split of 32 bit registers into two 16 bit registers seems to be significant, I'm slowly thinking we should invest the time to finish the implementation of 32 bit register accesses through OSD. Let's revisit that topic once we have a clear understanding of the required register map, as discussed above.]<span><br></span></blockquote><div><br></div></span><div>I think that might be a good option. As per my understanding, we have to change Host Interface Module and osd_regaccess_layer on the hardware side. Please correct me if I am wrong. <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. I looked in the description of mor1kx to figure out the system interface for SPRs and GPRs. Can these signals be used for the system interface?<br>
<br>
<a href="https://github.com/openrisc/mor1kx/blob/a9a01c009ea2b24764973560fde4a9855f4ba95d/rtl/verilog/mor1kx_cpu.v#L157" rel="noreferrer" target="_blank">https://github.com/openrisc/mo<wbr>r1kx/blob/a9a01c009ea2b2476497<wbr>3560fde4a9855f4ba95d/rtl/veril<wbr>og/mor1kx_cpu.v#L157</a><br>
</blockquote>
><br>
> OR,<br>
> <a href="https://github.com/openrisc/mor1kx/blob/a9a01c009ea2b24764973560fde4a9855f4ba95d/rtl/verilog/mor1kx_bus_if_wb32.v#L28" rel="noreferrer" target="_blank">https://github.com/openrisc/mo<wbr>r1kx/blob/a9a01c009ea2b2476497<wbr>3560fde4a9855f4ba95d/rtl/veril<wbr>og/mor1kx_bus_if_wb32.v#L28</a><br>
><br>
> 2. Also since the system interface for SPRs will be different from that<br>
> of Debug unit, CDM-OR1K must also know a way to differentiate between<br>
> the two, right?<br>
<br></span>
No, you can (and should) only use signals which are available in the toplevel, i.e. here: <a href="https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx.v" rel="noreferrer" target="_blank">https://github.com/openrisc/mo<wbr>r1kx/blob/master/rtl/verilog/m<wbr>or1kx.v</a>. The du_* signals can access any register, including SPRs. (That's at least my understanding, Stafford can confirm.)<span class="m_-7994219454878333612HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div>Okay.  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="m_-7994219454878333612HOEnZb"><font color="#888888">
<br>
Philipp<br></font></span></blockquote><div> </div></span></div><span class="HOEnZb"><font color="#888888">- Shivam<br></font></span></div></div>
</div><br></div>