Integrating the GNU Debugger with Cycle Accurate Models

First and foremost this application note draws on techniques described in Embecosm Application Notes 3-6 [7] [8] [9] [10]. These should be used as the primary source of additional information.

Verilator has its own website (www.veripool.org), providing guidance for downloading, installing and using the tool. In particular this application note should be read in conjunction with the Verilator user guide.

SystemC is defined by IEEE standard 1666, and the standardization documents are the ultimate reference. The SystemC standard [14] is a free PDF download (a novelty for the IEEE). The open source reference implementation from OSCI includes an introductory tutorial.

JTAG is also an IEEE standard (1149.1), and the standardization document is the ultimate reference. Unlike the SystemC standard, the JTAG standard [16] costs money. The Texas Instruments JTAG primer [15] is a useful free alternative.

The main user guide for GDB [21] provides a great deal of context about how GDB is intended to work. The GDB Internals document [12] is essential reading before and during any porting exercise. It is not complete, nor is it always up to date, but it provides the first place to look for explanation of what a particular function does.

The files making up the examples used in this application noted are comprehensively commented, and can be processed with Doxygen [23]. Each class, member and method's behavior, parameters and return value is described.

There is a wealth of material to support both SystemC and JTAG on the Internet.

The Open SystemC Initiative (OSCI) provides an open source reference implementation of the SystemC library, which includes tutorial material in its documentation directory. These may be accessed from the OSCI website (www.systemc.org).

OSCI also provide a number of public mailing lists. The help forum and the community forum are of particular relevance. Subscription is through the OSCI website (see above).

The main GDB website is at sourceware.org/gdb/. It is supplemented by the less formal GDB Wiki at sourceware.org/gdb/wiki/.

The GDB developer community communicate through the GDB mailing lists and using IRC chat. These are always good places to find solutions to problems.

The main mailing list for discussion is gdb@sourceware.org, although for detailed understanding, the patches mailing list, gdb-patches@sourceware.org is useful. See the main GDB website for details of subscribing to these mailing lists.

IRC is on channel #gdb on irc.freenode.net.

There is some variation in the level of detail shown with specific modeling techniques. For example cycle accurate models generated by ARC VTOC from Verilog RTL will show the value of every state holding register in the model on each clock edge, and any asynchronous signal edge. Hand-written cycle accurate models within ARM SoC Designer will typically only show the state on the active edge of the clock cycle, and that state will be restricted to the external ports and defined internal registers.

Most cycle accurate models follow 2-state, zero delay synthesis semantics. In this way they are closer to the behavior of the actual chip than traditional 4-state event-driven simulation. However there is no absolute reason why cycle-accurate models could not follow 4-state simulation semantics.

Some cycle accurate models are written by hand—for example the cycle accurate models supplied by ARM for their processor cores. However the great majority of cycle accurate models are generated automatically from Verilog or VHDL RTL. There are two commercial products (ARC VTOC and Carbon Design Systems ModelStudio) and one free open source product (Verilator).

These models typically follow 2-state, zero delay, synthesizable semantics. Embecosm Application Note 6 High Performance SoC Modeling with Verilator: A Tutorial for Cycle Accurate SystemC Model Creation and Optimization [10] describes how to created a Verilator SystemC model of ORPSoC which simulates at up to 130kHz on a standard Linux PC.

All these tools generate models in C/C++. However SystemC is becoming increasingly popular, and is generated by all the tools as well. However the reference OSCI SystemC simulator carries a serious performance penalty, and in all cases the model is a SystemC wrapper for the top level ports around a plain C/C++ model.

The performance penalty of SystemC wrappers should be a consideration when generating cycle accurate models. Performance can be particularly adversely affected by any ports of wider than 64-bits. The reference SystemC simulator has a very low-performance implementation of such ports.

ORPSoC is a complete SoC based on the OpenRISC 1000. It combines the processor with SRAM, flash memory and a range of peripherals as shown in Figure 2.1.

Figure 2.1.  The OpenRISC Reference Platform System-on-Chip (ORPSoC).

The full design is around 150k gates + memories. It runs on standard Altera and Xilinx FPGA boards and is also available commercially from Flextronics.

The public interface to this class is as follows:

The RSP packet cannot be represented as a simple string, since binary packets may contain null (string terminator) characters. Instead the packet is represented as a character buffer and separate length field. However by convention the character buffer is also null-terminated, allowing non-binary packets to be printed out for debugging purposes. The public interface to this class is as follows:

The OpenRISC 1000 debug unit uses a 4-bit JTAG instruction register. It adds two additional instructions, CHAIN_SELECT (binary 0011) and DEBUG (binary 1000).

All data registers have a cyclic redundancy check (CRC) field as their final (most significant) 8-bits, calculated on the remaining bits. The CRC used is the 8-bit ATM Header Error Correction [3], using the irreducible polynomial x⁸ + x² + x + 1. This is capable of detecting all single and double bit errors in the data register and single burst errors of up to 8 bits.

So the usual sequence of operations is as follows:

The RISC_DEBUG Debug Chain

The RISC_DEBUG chain uses a 73-bit data register as shown in Figure 4.5.

Figure 4.5.  RISC_DEBUG JTAG data register format

The first 32 bits (SPR) specify the SPR to be accessed. Bit 32 (W) is set if the value is to be written. Bits 33-64 (Data) form the value to be written (if W is set) or the value read when the result is shifted out. The final 8 bits (65-72) are the CRC.

The CPU logic is fast enough that the data field can be set during a single JTAG capture-shift-update operation.

The REGISTER Debug Chain

The REGISTER chain uses a 46-bit data register as shown in Figure 4.6.

Figure 4.6.  REGISTER JTAG data register format

The first 5 bits (Reg) specify the CPU control register to be accessed. Bit 5 (W) is set if the value is to be written. Bits 6-37 (Data) form the value to be written (if W is set) or the value read when the result is shifted out. The final 8 bits (38-45) are the CRC.

The CPU logic is fast enough that the data field can be set during a single JTAG capture-shift-update operation.

The OpenRISC 1000 Debug Unit defines 6 CPU control registers:

• MODER (binary 00000), TSEL (binary 00001), QSEL (binary 00010), SSEL (binary 00011) and RECSEL (binary 10000). These registers control hardware trace, if that functionality is implemented. They are not described further here.

• RISCOP (binary 00100). The bits in this register control the CPU. Bit 0 is the reset bit. If written to 1, the CPU will be reset. Bit 1 is the stall bit. The value read indicates whether the CPU is stalled. The CPU can be stalled by writing 1 to this bit and unstalled by reading 0 from this bit.

  	Caution
  	Remember that accessing a JTAG register takes hundreds of system clock cycles. It is quite possible to unstall the processor and for the processor to have stalled again (perhaps due to hardware single step, or an adjacent breakpoint) before the register is next read. This can cause confusion, with "unstalling" appearing to have no effect. A VCD trace always clarifies what is happening.

	Note
	The Mohor Debug Unit has no support for trace and the value of the Reg field is ignored. All accesses are for the RISCOP register.

The WISHBONE Debug Chain

The WISHBONE chain uses a 73-bit data register as shown in Figure 4.7.

Figure 4.7.  WISHBONE JTAG data register format

The first 32 bits (Address) specify the memory address to be accessed. Bit 32 (W) is set if the value is to be written. Bits 33-64 (Data) form the value to be written (if W is set) or the value read when the result is shifted out. The final 8 bits (65-72) are the CRC.

The Wishbone memory interface may not be able to set the data field during a single JTAG capture-shift-update operation. This is particularly the case with slow memory. This can be solved either by using the PAUSE-DR state of the JTAG TAP state machine, or by performing two reads, one immediately after the other.

This class is a SystemC module (i.e. it has sc_module as a base class).

The Debug Unit functions work by queuing instances of TapAction sub-classes on a queue (FIFO) connected to the JTAG interface (class JtagSC). This allows the debug unit to read and write the various JTAG registers. In each case the debug unit waits (using the SystemC wait function) for notification that the action is complete before proceeding. The full interface is described in Embecosm Application Note 5 Using JTAG with SystemC: Implementation of a Cycle Accurate Interface [9].

The Debug Unit caches the current value of the debug chain. This means it can avoid selecting the chain for a debug action, where it is unchanged from the previous action.

The public interface to DebugUnitSC is as follows:

The OpenRISC 1000 provides for up to 2¹⁶ Special Purpose Registers (SPRs). These are frequently accessed to implement debugging commands, yet do not change when the CPU is stalled (but see the issue concerning the Next Program counter in Section 4.6.1).

In practice only a few SPRs are used repeatedly. It makes sense to cache the SPRs in a simple closed hash table. SprCache represents the cache as three private C++ arrays. The Boolean array sprIsvalid indicates whether than entry is valid, the sprKeyNum array holds the SPR value for which this entry is valid and sprValue holds the corresponding cached value. Clearing the cache is a matter of setting all entries in sprIsValid to false using memset.

A key feature is that the Next Program Counter (NPC) must always be cached (see Section 4.6.1). The cache will reject attempts to write once it is 70% full (so caching remains efficient). However a flag may be used to force caching beyond this point. This is safe, because it is only ever used for one register, the NPC

The use of SprCache within the Debug Unit is discussed in the chapter on optimization (Section 5.2).

The public interface to SprCache is as follows:

It also make sense to cache memory accesses when the CPU is stalled. The same locations are repeatedly accessed as the stack is analyzed.

It is not generally feasible (nor efficient) to cache all of memory. Instead a small hash table is used. In this case the hash table is represented by three private arrays, each of the same size (specified in the constructor and dynamically allocated). tabIsValid is a Boolean array indicating if the corresponding hash table slot is in use. tabKeyAddr holds the memory address being used to key a particular hash table slot. tabValue holds the associated cached value. The hash table can be cleared by using memset to set all the elements of tabIsValid to false.

The hash table provides for no retry function if a lookup clashes. The new key address replaces any existing entry. In practice clashes are very unlikely, so this makes lookup efficient.

The use of MemCache within the Debug Unit is discussed in the chapter on optimization (Section 5.2).

The public interface to MemCache is as follows:

The public interface to the GdbServerSC class is its constructor and destructor. The constructor arguments include the start and end address of Flash memory, the port on which RSP TCP/IP connections will be accepted and a pointer to the JTAG FIFO for TAP actions.

The constructor instantiates a new instance of RspConnection to handle the RSP TCP/IP interface (see Section 4.2) and a new instance of DebugUnitSC to model the interface to the OpenRISC 1000 Debug Unit and drive the JTAG interface (see Section 4.3). It creates an instance of RspPacket to hold the data associated with the packet currently in use.

The GDB server needs to keep track of breakpoints and watchpoints (collectively known as matchpoints) which have been inserted. These use OpenRISC 1000 l.trap instructions. Class MpHash holds details of each matchpoint: its type, address and the instruction that was replaced by l.trap. The GdbServerSC constructor creates an instance of this class.

Finally the constructor declares the private function rspServer as a new SystemC THREAD.

The SystemC Thread, rspServer

On start up, the OpenRISC 1000 model loads an image from Flash memory which initializes the exception vectors in RAM, sets up any caches and then jumps to the reset vector (location 0x100). GDB debugging should not start until this initialization has occurred.

This is achieved by detecting when the processor first tries to access a location outside Flash memory (hence the need for this addresses to be passed to the constructor). At start up, the thread resets the JTAG interface of the Debug Unit, then waits until the next program counter has a value outside the flash memory address range.

This is followed by the main loop. The first part of the loop checks if a connection to a GDB client has been established, and if not loops trying to listen. When a new connection is established it immediately stalls the processor, pending instructions from the client.

The second part of the loop waits until the processor has stalled (it will already be stalled on first connection). Once it has stalled it notifies the GDB client, then processes the next RSP packet from the client using the function rspClientRequest. The majority of packets will leave the CPU unstalled, so subsequent moves round the loop will immediately come back to the same point and call rspClientRequest again.

The exceptions are continue, step and restart packets which unstall the processor. There will be no further RSP packets processed until the processor stalls again. This will either be due to hitting a breakpoint or the connection being dropped and reconnected.

	Note
	This loop relies on detecting a stalled processor (using the variable targetStopped) being a fast operation. It would not be efficient if the target had to be interrogated via JTAG between processing each GDB packet.

The processing of individual packets by rspClientRequest follows the same approach described in Embecosm Application Note 4 Howto: GDB Remote Serial Protocol: Writing a RSP Server [8]. The only difference is the code is in C++ rather than C. The details of individual packet actions are not described further in this application note. All the actions use reading and writing of SPRs and memory in the same way. However for this application they use the functions provided by the Debug Unit class, DebugUnitSC.

MpHash is a closed hash table, whose entries are linked lists of MpEntry entities (see Section 4.4.3). Each entry represents one breakpoint or watchpoint. Five types of matchpoint are supported:

Entries are keyed on both the address and type of the matchpoint. It is quite possible to have both a breakpoint and watchpoint on the same location, but they are separate entities.

	Note
	Although all five matchpoint types are supported in the matchpoint table, the current implementation of the GDB server does not provide an implementation for hardware breakpoints or any watchpoints.

The public interface to MpHash is as follows:

MpEntry is declared as a struct, rather than a class, to emphasize it is purely a data structure, with no explicit member functions. It represents a single matchpoint in the hash table.

There are three public member variables:

There is one private variable, next, a pointer to MpEntry, used to form lists of entries in the hash table. MpHash is declared a friend class, giving it access to this variable to construct the lists.

The directory sw/test-progs contains a number of simple test programs. Use the Makefile to build these. The programs include a simple "Hello World" program in hello.c, which compiles to the file hello.

First build the GDB server. Use the command make from the top level directory.

$ make

<makefile output>

time -p ./Vorpsoc_fpga_top

             SystemC 2.2.0 --- May 16 2008 10:30:46
        Copyright (c) 1996-2006 by all Contributors
                    ALL RIGHTS RESERVED
Loading flash image from sim/src/flash.in
(orpsoc.v.uart_top) UART INFO: Data bus width is 32. Debug Interface present.

(orpsoc.v.uart_top) UART INFO: Doesn't have baudrate output

Listening for RSP on port 51000
	  

In a separate window, change to the sw/test-progs sub-directory and build the example programs using make. Then start the OpenRISC 1000 implementation of GDB (see Embecosm Application Note 2: The OpenCores OpenRISC 1000 Simulator and Tool Chain: Installation Guide [6] for details of how to install the tool chain).

$ or32-uclinux-gdb
Building automata... done, num uncovered: 0/216.
Parsing operands data... done.
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=or32-uclinux".
(gdb) 
	  

First load the program symbol table using the file command. Then connect to the GDB server using the target remote command. Since no port number was specified, the default 51000 will be used:

(gdb) file hello
Reading symbols from .../sw/test-progs/hello...done.
(gdb) target remote :51000
Remote debugging using :51000
0x040001f0 in ?? ()
(gdb) 
	  

At start up the processor is stalled, so it looks to the GDB client as though the target has just hit a breakpoint at the address of the Previous Program Counter (PPC). Since the processor stalled just as it finished executing in Flash memory, the address of the PPC is an address in Flash. That has nothing to do with the "Hello World" program which will be loaded, and for which the symbol table has already been loaded. So the GDB client cannot identify which source code this location corresponds to and just reports it as ??.

The window with the GDB server acknowledges the connection:

Listening for RSP on port 51000
Remote debugging from host 0.0.0.0
	  

Since this is a local connection the remote host is reported as 0.0.0.0.

The client can now load the hello world program. This will take a few seconds, even for a program as small as this, since each word has to be loaded over the model of JTAG, taking round 750 clock cycles. Even with a model running at nearly 100kHz this takes some time.

(gdb) load hello
Loading section .text, size 0x1350 lma 0x0
Loading section .rodata, size 0x1f lma 0x1350
Start address 0x100, load size 4975
Transfer rate: 323 bytes/sec, 236 bytes/write.
(gdb) 
	  

A breakpoint can be set on the main program and execution continued:

(gdb) break main
Breakpoint 1 at 0x12f4: file hello.c, line 26.
(gdb) continue
Continuing.

Breakpoint 1, main () at hello.c:26
26        simputs ("Hello World!\n");
(gdb) list
21      #include "utils.h"
22
23
24      main()
25      {
26        simputs ("Hello World!\n");
27        simputs ("The answer is ");
28        simputn (6 * 7);
29        simputs ("\n");
30        simexit (42);
(gdb) 
	  

Placing a breakpoint on simputs allows the output generation to be followed:

(gdb) break simputs
Breakpoint 2 at 0x1234: file utils.c, line 105.
(gdb) c
Continuing.

Breakpoint 2, simputs (str=0x1350 "Hello World!\n") at utils.c:105
105       for( i = 0; str[i] != '\0' ; i++ ) {
(gdb) list
100      */
101     void  simputs( char *str )
102     {
103       int  i;
104
105       for( i = 0; str[i] != '\0' ; i++ ) {
106         simputc( (int)(str[i]) );
107       }
108
109     }       /* simputs() */
(gdb)
	  

At this stage no characters have been output, but continuing again will cause the function to execute once:

(gdb) continue
Continuing.

Breakpoint 2, simputs (str=0x1350 "Hello World!\n") at utils.c:105
105       for( i = 0; str[i] != '\0' ; i++ ) {
(gdb)
	  

Switching back to the server window, the first line of output can be seen:

Listening for RSP on port 51000
Remote debugging from host 0.0.0.0
Hello World!
	  

The GDB extensions for OpenRISC 1000 are supported, so the info spr and spr commands are both available:

(gdb) info spr cpucfgr
SYS.CPUCFGR = SPR0_2 = 32 (0x20)
(gdb) 
	  

The CPU configuration register is showing that only the ORBIS32 instruction set is currently supported.

Deleting all breakpoints the program will run to completion:

(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) continue
Continuing.
Remote connection closed
(gdb)
	  

The server window shows the program running to completion. In this example hello.c calls simexit which uses the OpenRISC 1000 l.nop 1 instruction to cause the simulation to terminate.

Listening for RSP on port 51000
Remote debugging from host 0.0.0.0
Hello World!
The answer is 42
546960700.00 ns: Exiting (42)
SystemC: simulation stopped by user.
Closing connection
real 2708.49
user 87.82
sys 0.53
$
	  

On completion the RSP connection is dropped.

The OpenRISC 1000 instruction set architecture specifies two SPRs describing the program counter. The Previous Program Counter (PPC) represents the address of the instruction just completed. The Next Program Counter (NPC) represents the address of the instruction about to be executed.

However the OpenRISC 1000 is a pipelined processor with a 4/5 stage pipeline, so at any one time up to 4 instructions can be at some stage of execution. The pipeline stages are:

The PPC represents the address of the instruction that has just completed the write back stage of the pipeline. The NPC represents the address of the instruction which is the next to reach the write back stage of the pipeline (which may be at an earlier phase than write back, if the pipeline is not currently full).

The problem comes if the NPC is written while the processor is stalled. This must cause a flush of the pipeline, so until the processor is unstalled there is no instruction anywhere in the pipeline waiting to be executed. Thus a subsequent read of the NPC will return zero, not the value just written.

This behavior can be seen by following a VCD trace through a number of debug actions. This uses the "Hello World" example from Section 4.5.1. The program is loaded and run to a breakpoint set at the start of main (address 0x12f4).

(gdb) target remote :51000
(gdb) load hello
Loading section .text, size 0x1350 lma 0x0
Loading section .rodata, size 0x1f lma 0x1350
Start address 0x100, load size 4975
Transfer rate: 82 bytes/sec, 236 bytes/write.
(gdb) break main
Breakpoint 1 at 0x12f4: file hello.c, line 26.
(gdb) continue
Continuing.

Breakpoint 1, main () at hello.c:26
26        simputs ("Hello World!\n");
	  (gdb) 	

At this point (111,173.85μs), the wave trace in Figure 4.9 shows the processor stalling. The program counter for the write back stage is the address of break point (0x12f4) and the instruction associated with the write back phase is the l.trap instruction (0x21000001) used to generate the trap.

Figure 4.9.  VCD trace of the OpenRISC 1000 pipeline following a l.trap stall.

The succeeding instructions can be seen part processed in the pipeline. Disassembling around the breakpoint, the assembly code is:

(gdb) disassemble 0x12f0 0x1300
Dump of assembler code from 0x12f0 to 0x1300:
0x000012f0 <main+12>:   l.sw     0(r1),r9
0x000012f4 <main+16>:   l.movhi  r3,0x0
0x000012f8 <main+20>:   l.ori    r3,r3,0x1350
0x000012fc <main+24>:   l.jal    <simputs>
End of assembler dump.
(gdb)
	  

The instruction at the breakpoint (0x12f4) is not l.movhi as shown in the disassembly, but has been replaced by the l.trap to cause the breakpoint. The next instruction, at location 0x12f8 is l.ori r3,r3,0x1350 (0xa8631350). This instruction is between instruction decode and execution stages. The address is shown in both stages and the instruction itself can be seen in the instruction decode stage.

On hitting a breakpoint, the first action of GDB is to set the program counter back by one instruction. This is because the instruction that was replaced by l.trap for the breakpoint must be put back so it can be executed before resuming any further execution. This involves writing the NPC, changing it from its value of 0x12f8 (the l.ori instruction) back to 0x12f4.

This behavior can be seen in Figure 4.10 at time 104,890.85μs. The write back program counter is left unchanged (0x12f4), since the instruction has already been executed. However the program counters for instruction decode and execute are set to zero. The program counter for instruction fetch is set to the new value, 0x12f4. The instruction registers for all stages have nonsense values in them (there is no OpenRISC 1000 instruction beginning with 0x14).

Figure 4.10.  VCD trace of the OpenRISC 1000 pipeline following a write setting NPC to 0x12f4.

The Next Program Counter (NPC) is used in GDB as the value of the Program Counter ($pc). This can be changed using the set command:

(gdb) set $pc=0x100
(gdb)
	  

The value appears as the new address for the instruction decode stage of the pipeline. This is shown in Figure 4.11 at time 110,264.85μs. Addresses for all other pipeline stages are unchanged, and the instruction values for these stages are still meaningless.

Figure 4.11.  VCD trace of the OpenRISC 1000 pipeline following a second write setting NPC to 0x100.

Once the pipeline is unstalled, it will refill. This can be achieved by continuing execution:

(gdb) continue
Continuing.

Breakpoint 1, main () at hello.c:26
26        simputs ("Hello World!\n");
(gdb) 
	  

Execution will restart from the new value of NPC (0x100, the reset vector). A disassembly shows the instructions at that address:

(gdb) disassemble 0x100 0x110
Dump of assembler code from 0x100 to 0x110:
0x00000100 <_start+0>:  l.addi   r1,r0,32512
0x00000104 <_start+4>:  l.addi   r2,r1,0
0x00000108 <_start+8>:  l.mfspr  r3,r0,0x11
0x0000010c <_start+12>: l.ori    r3,r3,0x2
End of assembler dump.
(gdb)
	  

The VCD trace in Figure 4.12 shows the processor unstalling at time 111,173.85μs. In consecutive cycles the pipeline fills with the instructions from locations 0x100 (0x9c207f00, l.addi r1,r0,0x7f00, 0x104 (0x9c410000, l.addi r2,r1,0), 0x108 (0xb4600011, l.mfspr r3,r0,0x11) and 0x10c (0xa8630002, l.ori r3,r3,0x2).

Figure 4.12.  VCD trace of the OpenRISC 1000 pipeline refill when the CPU is unstalled.

This complexity of behavior is not generally what is wanted by a debugger. GDB will regularly write the NPC to a new value, but expects that subsequent reads will return the value just written. It is therefore essential that notwithstanding any other arrangements the NPC must be cached while the processor is stalled.

GDB from time to time may write the NPC to its current value. The intention is that this should have no effect, yet if the NPC SPR is written the pipeline will be flushed. This can be particularly catastrophic if the flush causes a delayed branch to be lost.

Thus the interface must ensure that any request to write the value of the NPC does nothing if the value is the same as the value already there.

This appears to be a hardware bug. However there may be a good reason for the behavior, since it is quite explicit in the source Verilog.

The JTAG data registers are all one bit bigger than stated in Section 4.3. When shifting a register in an extra top bit is provided, but ignored. When shifting the register out however the extra bit is provided before the CRC. This affects all data registers. The data register specifying the debug chain has the format in Figure 4.13.

Figure 4.13.  JTAG chain data register actual implementation.

The formats of the data registers used with the RISC_DEBUG and WISHBONE debug chains are the same, as shown in Figure 4.14.

Figure 4.14.  JTAG RISC_DEBUG> and WISHBONE debug chains data register actual implementation.

The format of the data register used with the REGISTER debug chain is shown in Figure 4.15.

Figure 4.15.  JTAG REGISTER> debug chain data register actual implementation.

This is a genuine bug in the interaction between Debug Unit and CPU. When hardware single step is used, the pipeline can become confused, leading to multiple executions of the same instruction, and eventually to the same instruction being executed forever.

Hardware single-step is always used in two places. First when restarting after a breakpoint to execute the instruction that was replaced by l.trap. GDB single steps the instruction, then replaces it with l.trap, so the breakpoint can be used again.

Secondly GDB uses single step for the stepi command.

A sequence of stepi commands illustrates the problem:

(gdb) si
0x00001224 in simputs (str=0x0) at utils.c:102
102     {
(gdb) si
0x00001228      102     {
(gdb) si
0x00001228      102     {
(gdb) si
0x0000122c      102     {
(gdb) si
0x00001230      102     {
(gdb) si
0x00001230      102     {
(gdb) si
0x00001230      102     {
(gdb) si
0x00001230      102     {
	  

The VCD trace in Figure 4.16 shows the pipeline failing to fill correctly after some of the single steps

Figure 4.16.  VCD trace of the OpenRISC 1000 pipeline after multiple single steps.

From around 140ms, the pipeline refill starts to go wrong. The ticks on the dbg_stall line are the individual single steps. By 180ms the pipeline is completely filled with the instruction at address 0x1230 (0xd7e21ffc, l.sw -4(r2),r3).

Unfortunately single stepping is sometimes used by GDB in other circumstances. For example a step (high level instruction step) or nextcommand> may use multiple steps rather than setting and running to a temporary breakpoint. Under these circumstances the GDB client will hang, because the target does not seem to reach its target.

There is a workaround, which is to use ctrl-C (twice) to break the connection and then reconnect. The OpenRISC 1000 is stalled at the time, so on reconnection will be at the same location. Using continue allows the pipeline to refill correctly.

(gdb) s
^C^CInterrupted while waiting for the program.
Give up (and stop debugging it)? (y or n) y
(gdb) target remote :51000
Remote debugging using :51000
0x00001230 in simputs (str=0x1350 "Hello World!\n") at utils.c:102
102     {
(gdb) c
Continuing.

Breakpoint 4, simputs (str=0x1350 "Hello World!\n") at utils.c:105
105       for( i = 0; str[i] != '\0' ; i++ ) {
(gdb) 
	  

The raw load generated by the debugging script can be measured by comparing the number of cycles taken using the script, with the number of cycles taken when just loading the program and running to completion. The results, using a server with no compiler optimization (-O0) and no caching of memory or SPRs (see Section 5.2) are shown in Table 5.1.

As can be seen the debugging commands add over 11 million cycles to the server model in this baseline configuration.