Full Emulation Debug

To better mimic the hardware being emulated, Software Emulation kernels are spawned off as separate processes. If you are using GDB to debug the host code, breakpoints set on kernel lines will not be hit because the kernel code is not run within that process. To support the concurrent debugging of the host code as well as the kernel code, the SDAccel™ Environment provides a mechanism to attach to spawned kernels through the use of sdx_server.

As a result it is necessary to start three different terminals:

In the first terminal, start the sdx_server using the following command:
```
${XILINX_SDX}/bin/sdx_server --sdx-url
```
In a second terminal run the host code (xgdb). Follow the setup instructions in Launching GDB Standalone.
At this point, the first terminal running the sdx_server should provide a “GDB listener port NUM” on standard out. Keep track of the number returned by the sdx_server as the GDB listener port is used by GDB to debug the kernel process. When the GDB listener port is printed, the spawned kernel process has attached to the sdx_server and is waiting for commands from you. To control this process, you must start a new instance of GDB and connect to the sdx_server.

IMPORTANT!: If the sdx_server is running, then all spawned processes compiled for debug will connect and wait for control from you. If no GDB ever attaches or provides commands, the kernel code appears to hang.
In a third terminal, run the xgdb command, and at the GDB prompt, run the following commands:
- For Software Emulation:
```
“file ${XILINX_SDX}/data/emulation/cpu_em/generic_pcie/model/genericpciemodel”
```
- For Hardware Emulation:
  1. Locate the sdx_server temporary directory:/tmp/sdx/$uid.
  2. Find the sdx_server process id (PID) containing the DWARF file of this debug session.
  3. At the gdb command line, run: file /tmp/sdx/$uid/$pid/NUM.DWARF
In either case, connect to the kernel process:
```
target remote :NUM
```
Where NUM is the number returned by the sdx_server as the GDB listener port.

After these commands are executed you can set breakpoints on your kernels as needed, run the continue command, and debug your kernel code. When the all kernel invocations have finished, the host code should continue, and the connection will drop.

In case of the software and hardware emulation flows, there are restrictions with respect to the accelerated kernel code debug interactions. As this code is preprocessed, in the software emulation flow and actually translated in the hardware emulation flow into a hardware description language (HDL) and simulated during debugging, it is not always possible to set breakpoints at all locations. Especially with hardware emulation, only a limited number of breakpoints such as on preserved loops and functions are supported. Nevertheless, this mode is useful to debug the kernel/host interface.

TIP: When debugging Software/Hardware emulation kernels in the SDAccel GUI Environment, these steps are handled automatically and the kernel process is automatically attached, providing multiple contexts to debug both the host code and kernel code simultaneously.