Lightning intro¶
This introduction aims to give you a very rapid introduction to the major tools and some of the fundamental concepts in the tools.
First, let’s write the simplest single-threaded source file main.c
:
1 2 3 4 5 6 | #include <stdio.h>
int main(void) {
printf("Hello world!\n");
return 0;
}
|
Build an executable¶
Now, let’s build this into an executable using XCC. The
executable will be produced within the XE file a.xe
:
$ xcc -target=XCORE-200-EXPLORER -g main.c
The xcc -g
tells the XCC tool to add debug information. We’ll need
that later.
What is a target?¶
Fundamentally, xcc -target
specifies the core architecture of the
target we are building for, in this case the XS2 architecure. But actually it
specifies much more that this - for instance, it specifies how many cores are
present, how they are connected, what the clock frequencies are,
and much more. The target is thus most closely associated with the physical PCB
and the xcore packages on that PCB.
Run on real hardware¶
The XRUN tool provides a convenient way of launching an executable on real hardware.
Connect your XCORE-200-EXPLORER development board to your host PC via the XTAG connector. Make sure you’ve also supplied power to the development board itself.
Run a.xe
using xrun --io
:
$ xrun --io a.xe
Hello world!
Congratulations! You’ve just built and executed your first xcore application. If you have problems with this step, you may need to configure and check your XTAG setup.
Debugging using XGDB on real hardware¶
You have already used the XGDB debugger indirectly when you used the simplified XRUN tool. However, if you want greater insight into how the application is running, you need to use the XGDB debugger directly. Start the debugger:
$ xgdb a.xe
This starts a new debug session with a new (gdb) prompt. You must now
connect
to the attached hardware and load
the application code:
(gdb) connect
...
(gdb) load
...
From now on, using XGDB on this single-threaded program is the same as using normal GDB. For instance, create a breakpoint, run up to that breakpoint, step to the next line and quit:
(gdb) break main
Breakpoint 1 at 0x400fc: file main.c, line 4.
(gdb) continue
Breakpoint 1, main () at main.c:4
4 printf("Hello world!\n");
Current language: auto; currently minimal
(gdb) step
Hello world!
5 return 0;
(gdb) quit
Run on the simulator¶
The tools include a near cycle-accurate hardware simulator called XSIM. XSIM is not just a simulation of an xcore tile itself - instead it simulates the entire package in which the tile sits. So in this example, it simulates both the tiles in an XCORE-200-EXPLORER package:
$ xsim a.xe
Hello world!
This output looks exactly the same as the output from XRUN. What’s the difference?
XRUN loads and runs an XE file on a real piece of hardware attached via an XTAG
XSIM loads and runs an XE file on a simulated piece of hardware, where that simulation is running on your host computer
How does XSIM know that it is simulating a two-tile package? XSIM is configured by the SYSCONFIG sector contained in the .xe file.
Debugging using XGDB¶
It’s possible to use XGDB to debug on the XSIM simulator. The steps are
identical to Debugging using XGDB on real hardware, except we use
connect -s
to connect to the simulator instead of
the hardware:
(gdb) connect -s
...
(gdb) load
...