Overview[edit]

This page is intended to compare the performance of the different classes of XDS emulators. It is not intended as an official benchmark and should be used for reference only, as the procedure depicted here is experimental and does not take into consideration a real-world debugging scenario.

It uses Code Composer Studio’s Debug Server Scripting (DSS) feature that allows running JTAG debug sessions from the command line
The use of DSS allows the benchmark process to be automated and reduce the influence of the graphical IDE in the measurements
It is focused on two major types of tests: throughput and interactive
The throughput tests perform data transfers to/from the target and measure the time elapsed to complete them.
The interactive tests perform a sequence of typical debug operations such as single step or display a series of printf statements (console output) that are relevant to the overall user experience.
The benchmarks chosen are very useful to compare the different JTAG debug probes.

For the most up-to-date results, please check the latest results

Test setup[edit]

The base host PC used specification is:

Core i7-2640M (Quad core, HT enabled, 2,80GHz)

8192GB DDR3 1333 MHz (PC3-10600)

Samsung SSD 840 EVO

Code Composer Studio v6.0.1.00040

TI Emulators package 5.1.507.2 (red) and 5.1.636.0 (blue)

For MSP432 only:

Code Composer Studio v6.1.0.00032

TI Emulators package 5.1.594.0

Important note about JTAG TCLK frequencies:[edit]

Some of the emulators allow setting limits to the JTAG TCLK frequency from the CCS Target Configuration editor, which can potentially increase the debugging and loading speed.

However, at the moment of connection the emulator performs some tests on the JTAG serial connection and automatically chooses a reliable TCLK speed, which can be lower than the setting configured in CCS. The most obvious practical effect is that some of the tests below show the same throughput even when setting different TCLK speeds.

For details on the JTAG emulator and board design constraints that affect performance, check the Target Connection Guide.

The XDS560 emulators actually report back the reliability of the JTAG TCLK measurements when the Test Connection button is used from the CCS Target Connection editor, and it is shown as:

The IR/DR scan-path tests used 50.00MHz as the final frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

The frequency of the JTAG TCLKR input is measured as 49.99MHz.

This helps to know the actual speed being used by the JTAG debugger.

Throughput tests[edit]

The tests on this section focus on data throughput from the host PC to the target processor to compare the performance of different emulators and JTAG settings.

Note: For MCUs the executable is loaded/executed in Flash and the binaries to SRAM, while for EPs the external RAM is used in all tests.

Executable Load[edit]

The Executable Load throughput test performs a standard program load of an ELF executable to the target device’s program memory. The program contains a large data array whose size varies depending on the device's amount of available memory.

Results on Cortex M3[edit]

Target device: CC2538 (CC2538 Development kit)

Executable (.out) load to Flash (kB/s)

Results on Cortex M4[edit]

Target device: TM4C129NCPDT (TM4C129 connected Launchpad)

Executable (.out) load to Flash (kB/s)

Target device: MSP432P401 (MSP432 Launchpad)

Executable (.out) load to Flash (kB/s)

Results on Cortex A8[edit]

Target device: AM3359 (BeagleBone Rev A4 with TI 20-pin connector)

Executable (.out) load to DDR (kB/s)

Results on C6600[edit]

Target device: C6678 (C6678 EVM)

Executable (.out) load to DDR (kB/s)

Results on C6740[edit]

Target device: C6748 (C6478 Experimenter's Kit)

Executable (.out) load to DDR (kB/s)

Results on F2800[edit]

Target device: TMS320F28335 (TMS320F28335 controlCARD)

Executable (.out) load to DDR (kB/s)

Binary Load/Save[edit]

The Binary Load/Save throughput tests perform a direct memory load/save to the target device’s RAM memory. The binaries are created using the tiobj2bin utility applied to the executables of the previous test, and thus their sizes vary accordingly.