[Open SoC Debug] Queries Regarding GSoC and Open SoC
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
> > 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.
More information about the OpenSoCDebug