[Open SoC Debug] Queries Regarding GSoC and Open SoC

Philipp Wagner philipp.wagner at tum.de
Fri Mar 9 16:56:06 CET 2018


On 03/09/2018 03:03 PM, Anant Sharma wrote:
> On Mon, Feb 26, 2018 at 1:33 AM, Philipp Wagner <philipp.wagner at tum.de 
> <mailto:philipp.wagner at tum.de>> wrote:
>  >
>  > Hi Anant,
>  >
>  > great to hear that you were successful!
>  >
>  > Am 25.02.2018 um 19:00 schrieb Anant Sharma:
>  > > I have set up my environment and ready to go. I faced a little problem
>  > > because my system couldn't find or1k-elf-gcc, but I kind of fixed 
> it. (I
>  > > don't think there's anything wrong with the python script).
>  >
>  > Did you source the setup_prebuilt.sh script which comes as part of the
>  > prebuilts?
>  >
>  > > Also, went
>  > > through the examples of the Verilator. I am all set. What can I do 
> next?
>  >
>  > Great. By trying out OpTiMSoC you saw the hardware in which the
>  > run-control debug/GDB support should be integrated.
>  >
>  > Now is a good time to look at the other side: how GDB actually talks to
>  > a processor. That part is in fact easier than one might guess: the
>  > processor core simply provides an interface with special-purpose
>  > registers. By reading and writing these registers the CPU can be
>  > stopped, breakpoints can be set, etc. The documentation for this
>  > functionality is part of the OR1k architecture specification
>  > (https://github.com/openrisc/doc/blob/master/openrisc-arch-1.2-rev0.pdf,
>  > Chapter 11).
>  >
>  > To access the registers mentioned in the or1k specification the mor1kx
>  > CPU core has dedicated ports. You can find them here:
>  > https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx.v#L139
>  > (starting with "du_").
> 
> When I want to edit the stuff that is going into mor1kx i.e. all the 
> ports which
> start with "du_", from the mor1kx_module.sv <http://mor1kx_module.sv> 
> file, I will actually be dealing with
> the following ports.
> 
> input         dbg_stall_i, // External Stall Input
> input         dbg_ewt_i, // External Watchpoint Trigger Input
> output [3:0]  dbg_lss_o, // External Load/Store Unit Status
> output [1:0]  dbg_is_o, // External Insn Fetch Status
> output [10:0] dbg_wp_o, // Watchpoints Outputs
> output        dbg_bp_o, // Breakpoint Output


> input         dbg_stb_i, // External Address/Data Strobe
> input         dbg_we_i, // External Write Enable
> input [31:0]  dbg_adr_i, // External Address Input
> input [31:0]  dbg_dat_i, // External Data Input
> output [31:0] dbg_dat_o, // External Data Output
> output        dbg_ack_o, // External Data Acknowledge (not WB compatible)

These signals are the read/write ports for the debug registers.

> These ports are linked to the instantiated ports of mor1kx which start 
> with "du_"
> 
> Now I have 2 problems when I try to do the above.
> 
> 1. I can't figure out what values should I put into what ports to get 
> the result that
> i am looking for. Is there anywhere where the procedure is documented? 
> The pdf
> of or1kx architecture specification just talks about the registers but 
> nothing about
> these ports.

In the list of signals you find the read/write ports of the registers. 
I'm sure you'll find an internet resource on how to do standard 
reads/writes of registers over such ports, its very basic to all 
hardware designs (not only digital hardware).

> 
> 2. If I do figure out the data I have to put in the ports, I will have 
> to create registers
> which will be given values from inside an 'always' block which will in 
> turn be triggered
> when the CPU resets. The gtkwave can visualize the dbg_bp_o for me but 
> it cannot
> visualize registers inside mor1kx_module.sv <http://mor1kx_module.sv>

The registers the spec talks about are not necessarily registers as seen 
in Verilog. Instead, they are "storage spaces" which have a given 
address and can be read and written.

Philipp


More information about the OpenSoCDebug mailing list