Work in progress

Some scattered notes on using the Xilinx SDK.

SDK Hints

Some helpful things we've figured out:

  • Do not power cycle the FPGA Board or disconnect the JTAG/USB cable while SDK is running. Always quit SDK first.
    • If an active SDK session loses the JTAG connection, the JTAG cable will get locked and will fail to function for the current or future SDK sessions. The SDK may freeze in this state. Use Task Manager to kill eclipse.exe and xmd.exe. Then run iMPACT (Programs->Xilinx Design Suite 13.4->ISE Design Tools->32/64-bit Tools->iMPACT), double-click Boundary Scan, choose Output->Cable Reset. Then re-launch SDK to reestablish the JTAG connection.
  • The XMD console view in SDK is useful for debugging issues when communicating via JTAG. Open Xilnx Tools->XMD Console. In the new XMD Console tab, type verbose in the command box (bottom of the tab).
  • Force SDK to prompt for a workspace on every launch (Window->Preferences->General->Startup and Shutdown->Workspaces; check "Prompt for workspace on startup"). We found this is the best way to avoid confusion about what workspace is active.
  • Remarkably, ChipScope Analyzer and the SDK debugger can access the same JTAG cable simultaneously. This can be very useful (i.e. capture PHY state signals via ChipScope to verify what software sees via register reads).
  • Console tabs:
    • You can choose what log is shown in console tabs (little drop down arrow in Display Selected Console button\).
    • You can "pin" a console (Pin Console button), which prevents anything from switching the log source.
    • You can add a console tab, to view multiple logs simultaneously, each pinned to a different source. Having one tab pinned to SDK Log and one to C-Build is useful.
  • Changing the SDK log level to Trace is helpful for debugging odd SDK behavior (Window->Preferences->Xilinx SDK->Log Information Level)

SDK Bugs

Some bugs and workarounds we've figured out for Xilinx SDK 13.4 on the WARP FPGA Board v2.2 (Virex-4 FX100 FPGA).

XMD: Unable to decode ELF start address

When using the SDK "Run" launch process targeting a PPC design on the Virtex-4, we get an XMD error "Unable to decode ELF start address (), assuming 0x0."

Other users have reported the same issue (see Xilinx forums), and Xilinx's own documentation references the problem (ug757.pdf pg. 7). It seems Xilinx isn't planning a fix (see post 5 in the forums link).

The consequence of this error is that XMD will always begin executing code from address 0x0 and not he usual PPC boot address of 0xFFFFFFC. If the linker script places .text at some other address, the application won't boot and the XMD .elf download will appear to fail. You can see this behavior in the XMD log. Enable XMD verbose mode (type verbose at the XMD prompt), then watch the output during a "Run" launch. The final command xcontinue 34 0x0 -status_on_stop indicates XMD is attempting to boot from address 0x0, no matter what the linker script says.

The workarounds we've found:

  • Use the "Run" launch process, then press the FPGA Board PPC reset button (typically mapped to the down push button, near the power jack). This will force the PPC to start executing code from the PPC reset vector (0xFFFFFFFC), which, if the .elf is valid, will boot the PPC then jump to the address for .text specified in your linker script. We've seen this work, but are not entirely convinced it's robust.
  • Update the address map in XPS to place the memory you want to boot from at 0x0. For example we put the IOCM at 0x0 in the OFDM ref design. Then in your linker script assign .text to that memory. This will allow the "Run" launch process to succeed.
  • Use the "Debug" launch process. This processes uses GDB to read the start address, which succeeds where XMD fails.
  • If you can't update your address map (likely if you're using the 2GB DRAM, which should be at 0x0), you can still use the "Run" launch process. Let it execute normally. Then, when it fails to boot, at the XMD prompt run stop then con 34 0xFFFFFFFC. This will force the PPC to start executing code from the PPC reset vector (0xFFFFFFFC), which, if the .elf is valid, will boot the PPC then jump to the address for .text specified in your linker script.

PPC ISOCM access via XMD

The PowerPC instruction side on chip memory (ISOCM) interface is a useful feature- a memory block for code which the PPC can access without occupying the main PLB. But, because the ISOCM memory is not on the main PLB, the debugger cannot access it directly. The PPC405 core provides special instructions and registers for accessing the ISOCM interface via the PLB. The debugger (XMD) can use this passthrough, but it requires specific flags be passed during XMD initialization. Unfrotunately Xiilnx did not automate the process of setting these flags, even in projects which use the ISOCM.

The ISOCM flags are passed with the XMD connect command:

connect hw ppc -debugdevice isocmstartadr X isocmsize Y isocmdcrstartadr Z


  • X: the base address of the ISOCM, as specified in the XPS project
  • Y: the size of the ISOCM space in bytes, as specified in the XPS project
  • Z: the address of the DCR ISOCM registers, seemingly fixed at 0x100

So for a 64KB ISOCM at 0xFFFF0000, the command would be connect hw ppc -debugdevice isocmstartadr 0xFFFF0000 isocmsize 65536 isocmdcrstartadr 0x100.

To automate this in the SDK (so it works with "Run" and "Debug" launch processes), open the Run/Debug settings for your software project and go to the Debugger Options tab. Notice the ISOCM field under PowerPC 405 Debugger Connection Options. The SDK will pass the value from this field to the isocmstartadr XMD argument. Unfortunately, the SDK will not pass arguments for isocmsize or isocmdcrstartadr automatically.

But, the SDK not sanitize the value entered in the ISOCM field before passing it to XMD. We can use this to cheat and pass all the XMD flags we need. Set the value of the ISOCM field to (replacing X/Y as defined above):

X isocmsize Y isocmdcrstartadr 0x100

This will result in an XMD connect command of connect hw ppc -debugdevice isocmstartadr X isocmsize Y isocmdcrstartadr 0x100, exactly what we need.

Be very careful constructing the ISOCM field entry. Any typos here will result in XMD errors (at best), more likely an XMD crash and subsequent SDK crash.

Some related links:

Last modified 10 years ago Last modified on May 8, 2012, 10:26:57 PM