It is a good starting point to simulate a single compute tile of a distributed memory system. Therefore a simple example is included and demonstrates the general simulation approach and gives an insight in the software building process.

Simulating only a single compute tile is essentially an OpenRISC core plus memory and the network adapter, where all I/O of the network adapter is not functional in this test case. It can therefore only be used to simulate local software.

You can find this example in $OPTIMSC/examples/dm/compute_tile.

In default mode they start a server to connect the host software to, but you can use the parameter --standalone to run them in standalone. If you start the simulation now

you will get this output

The simulations always expect vmem files that initialize the memories. This needs to be generated from the compiled source code.

Our demonstration software is available in an extra repository:

Build a simple “Hello World” example:

You will then find the executable elf file as hello/hello.elf. Furthermore some other files are build:

• hello.dis is the disassembly of the file

• hello.bin is the elf representation of the binary file

• hello.vmem is a textual copy of the binary file

You can now run the example again, this time with a different memory initialization file:

the simulation should terminate with:

Furthermore, you will find a file called stdout.000 which shows the actual output:

But how does the actual printf-output get there when there is no UART or similar?

OpTiMSoC software makes excessive use of a useful part of the OpenRISC ISA. The “no operation” instruction l.nop has a parameter K in assembly. This can be used for simulation purposes. It can be used for instrumentation, tracing or special purposes as writing characters with minimal intrusion or simulation termination.

The termination is forced with l.nop 0x1. The instruction is observed and a trace monitor terminates when it was observed at all cores (shortly after main returned).

With this method you can simply provide constants to your simulation environments. For variables this method is extended by putting data in further registers (often r3). This still is minimally intrusive and allows you to trace values. The printf is also done that way (see newlib):

This function is called from printf as write function. The trace monitor captures theses characters and puts them to the stdout file.

You can easily add your own “traces” using a macro defined in baremetal-libs/src/libbaremetal/include/optimsoc-baremetal.h:

Next you might want to build an actual multicore system. In a first step, you can just start simulations of compute tiles with multiple cores:

You can observe, the simulation runs become longer. After each run, inspect the stdout.* files.

Next we want to run an actual NoC-based tiled manycore system-on-chip, with the examples you get system_2x2_cccc. The nomenclature in all pre-packed systems first denotes the dimensions and then the instantiated tiles, here cccc as four compute tiles.

Execute it again to get the hello world experience:

In our simulation all cores in the four tiles run the same software. Before you shout “that’s boring:” You can still write different code depending on which tile and core the software is executed. A couple of functions are useful for that:

• optimsoc_get_numct(): The number of compute tiles in the system

• optimsoc_get_numtiles(): The number of tiles (of any type) in the system

• optimsoc_get_ctrank(): Get the rank of this compute tile in this system. Essentially this is just a number that uniquely identifies a compute tile.

There are more useful utility functions like those available, find them in the file baremetal-libs/src/libbaremetal/include/optimsoc-baremetal.h.

A simple application that uses those functions to do message passing between the different tiles is hello\_mpsimple. This program uses the simple message passing facilities of the network adapter to send messages. All cores send a message to core 0. If all messages have been received, core 0 prints a message “Received all messages. Hello World!”.

Have a look what the software does (you find the code in $OPTIMSOC_APPS/baremetal/hello_mpsimple/hello_mpsimple.c). Let’s first check the output of core 0.

Finally, let’s have a quick glance at a more realistic application: heat_mpsimple. You can find it in the same place as the previous applications, hello and hello_mpsimple. The application calculates the heat distribution in a distributed manner. The cores coordinate their boundary regions by sending messages around.

Can you compile this application and run it? Don’t get nervous, the simulation can take a couple of minutes to finish. Have a look at the source code and try to understand what’s going on. Also have a look at the stdout log files. Core 0 will also print the complete heat distribution at the end.

In the previous tutorials you have seen some software running on a simple OpTiMSoC system. Until now, you have only seen the output of the applications, not how it works on the inside.

This problem is one of the major problems in embedded systems: you cannot easily look inside (especially as soon as you run on real hardware as opposed to simulation). In more technical terms, the system’s observability is limited. A common way to overcome this is to add a debug and diagnosis infrastructure to the SoC which transfers data from the system to the outside world, usually to a PC of a developer.

OpTiMSoC also comes with an extensive debug system. In this section, we’ll have a look at this system, how it works and how you can use it to debug your applications. But before diving into the details, we’ll have a short discussion of the basics which are necesssary to understand the system.

Many developers know debugging from their daily work. Most of the time it involves running a program inside a debugger like GDB or Microsoft Visual Studio, setting a breakpoint at the right line of code, and stepping through the program from there on, running one instruction (or one line of code) at a time.

This technique is what we call run-control debugging. While it works great for single-threaded programs, it cannot easily be applied to debugging parallel software running on possibly heterogenous many-core SoC. Instead, our solution is solely based on tracing, i.e. collecting information from the system while it is running and then being able to look at this data later to figure out the root cause of a problem.

The debug system consists of two main parts: the hardware part runs on the OpTiMSoC system itself and collects all data. The other part runs on a developer’s PC (often also called host PC) and controls the debugging process and displays the collected data. Both parts are connected using either a USB connection (e.g. when running on the ZTEX boards), or a TCP connection (when running OpTiMSoC in simulations).

At the moment running “verilated” simulations is the best supported way of observing the system traces. We will therefore run the examples from before using a verilated simulation and observing the system in the graphical user interface.

In the following we will have a look at building such a system and how to observe it with the GUI. In tbench/verilator/dm you find systems identical to the RTL simulation. We will directly start with the system_2x2_cccc. In the base folder you should simply make it:

The command will first generate the verilated version of the 2x2 system. Finally it builds the toplevel files and links to tb_system_2x2_cccc and tb_system_2x2_cccc-vcd. The latter generates a full VCD trace file of the hardware, which is much slower and also easily takes up tens of GB.

Similar to the steps described above you will need to build the software, e.g., the heat example. Again you need to link the vmem file. Now start the simulation:

It will start a debug server and wait for connections:

In another console now start the OpTiMSoC GUI:

In the first dialog window you need to set the debug backend to Simulation TCP Interface and proceed then. After the GUI started you need to connect using Target System$\to$Connect. The system view should change to a 2x2 system.

The last step is to run the system by Target System$\to$Start CPUs. The execution trace on the bottom of the window will start showing execution sections and events. By moving the mouse over the section you will find the description of the section. Similarly for the events you find a short description of the event.

The recommended platform for software development or any other system which needs no I/O is the ZTEX boards². Various variants exist, the supported boards are the 1.15 series version b and d, where the latter is twice as large as the former and can therefore contain more processor cores. The 2x2 example works with both boards.