Skip to main content

Getting Started With the C0-microSD+

Run the open-source Signaloid-Compute-Module-Demo-Calculator demo and plot the output distribution on your host.​

The demo pairs a C device application running on the Signaloid SoC with a Python host application. The device application uses UxHw® to add, subtract, multiply, or divide two uniform distributions on the module, and returns the resulting distribution to the host in a single execution, with no Monte Carlo loops.

The workflow is to build the device application on the Signaloid Cloud Compute Engine, flash it to the module, run the host application, and stop the core.

Prerequisites​

  • A C0-microSD+ and a host computer with a microSD slot or reader. Linux and macOS are documented below. For Windows status, see Host OS Support.
  • Python 3.10 or later for the host application and the flashing toolkit. See Python Environment.
  • A Signaloid account on the Signaloid Cloud Developer Platform and an API key.
  • The Signaloid CLI, installed and authenticated as shown in its installation and authentication documentation.
  • A GitHub account connected to your Signaloid account, as shown in GitHub Login.
  • The jq command-line JSON processor, which the demo Makefile uses to parse Signaloid CLI responses.
  • Root privileges (sudo), because raw block-device access requires them.

1. Identify the device​

Insert the C0-microSD+ into your computer. On macOS and Linux it is detected automatically as an unformatted block-storage device. It reports a capacity of 268.4 MB on macOS and 256 MiB on Linux, which are the same quantity written in decimal units and in binary units. If your operating system prompts you to format it, do not format the device, dismiss the prompt.

Find the device path.

  • macOS, run diskutil list and look for the unformatted 268.4 MB disk, for example /dev/disk4.
  • Linux, run lsblk and look for the unformatted disk that reports 256M, for example /dev/sdb.

For more detail, see Identify Your Module.

2. Build the device application​

Clone the demo repository recursively, so that you also get the Signaloid-Compute-Module-Utilities submodule with the flashing toolkit.

git clone --recursive https://github.com/signaloid/Signaloid-Compute-Module-Demo-Calculator.git
cd Signaloid-Compute-Module-Demo-Calculator

Configure two variables at the top of the Makefile.

  1. Set DEVICE to the device path you found in step 1, for example /dev/disk4.
  2. Set DEVICE_TYPE to SIGNALOID_C0_MICROSD_PLUS.

The Makefile then selects the default C0-microSD+ core for the build. To change the distributional representation precision or enable correlation tracking, set CORE_ID to one of the other C0-microSD+ core IDs listed in the Makefile. See the execution cores guide for how cores differ.

Then start the build.

make

The Makefile uses the Signaloid CLI to connect the repository on the Signaloid Cloud Compute Engine, start a build on the selected core, wait for it to finish, and download the resulting binary as signaloid-soc-application/<build-id>.main.bin.

note

The Signaloid Cloud Compute Engine builds the repository as it exists on GitHub. To build your own modifications later, fork the demo repository, push your changes to your fork, and clone and build from your fork. See Developing UxHw Applications.

3. Flash the application binary​

Flash the downloaded binary into the application region of the module's SPI flash.

make flash

The target stops the core first, so that a running device application does not access the SPI flash while the toolkit writes to it, and then flashes the binary with the C0_SD_toolkit.py script from the Signaloid-Compute-Module-Utilities submodule.

warning

Never remove the module, and never remove power from the host, while the toolkit is flashing. Flashing erases and reprograms whole 4 KiB sectors of the SPI flash, and a sector caught part way through holds neither its old contents nor its new contents.

For the full flashing reference, see Flash an Application.

4. Run the host application​

The Python host application brings the core up, sends the operands, triggers the computation, and reads back the Ux distributional result. Create its virtual environment with the make venv target, then run it.

make venv
sudo .venv/bin/python3 python-host-application/host_application.py --device-path /dev/disk4 --variant C0-microSD+ --reset-on-launch add "1.0(5)" "1.0(5)"

Replace /dev/disk4 with your device path. Each operand uses the concise distribution notation X.Y(Z), so "1.0(5)" is a uniform distribution centered on 1.0 with a ±0.5 tolerance. The host application prints the particle value of the result and plots the output distribution. Invoke the virtual environment interpreter directly, because a plain sudo python3 runs the system Python without the packages installed in the virtual environment.

You do not need a separate command to start the core. The host application always brings it up during initialization, then waits until the device application reports the waiting for command status before it sends anything. The --reset-on-launch flag makes that bring-up a stop followed by a start, so the device application restarts from its entry point with its state cleared. Pass it on the run that follows a flash, which guarantees that the code now executing is the binary you just flashed.

The demo also supports sub, mul, and div for the other operations, and sample for drawing samples from a built-in example distribution. The make run-all target runs every operation once with example operands.

5. Stop the core​

When you are done, hold the core in reset.

make stop

The target runs the config core-stop subcommand of the C0_SD_toolkit.py script. Passing --stop-on-exit to the host application does the same thing for you when the application finishes. The toolkit stops the core for you before it flashes, so that the running application does not access the SPI flash while the toolkit is writing to it. See Start and Stop the Core.

What just happened​

  1. make compiled the device application on the Signaloid Cloud Compute Engine and downloaded the resulting binary, and make flash wrote it into the SPI flash of the module over the SD interface.
  2. The host application released the RISC-V core through --reset-on-launch, and the device application started polling the COMMAND register for work.
  3. The host parsed each operand into a lower and an upper bound, wrote the four floats into the input half of the MMIO buffer, and wrote a command code into the COMMAND register.
  4. The Signaloid SoC initialised two variables as uniform distributions and computed the operation directly on them. UxHw propagated the distributions through the arithmetic in hardware, in one pass.
  5. The device wrote the resulting Ux distribution into the output half of the MMIO buffer and set the STATUS register to its done value. The host polled STATUS, read the distribution back, printed its particle value, and plotted it.

The register and buffer mechanics are the MMIO Interfacing Model, and the concepts behind the distributional representation are in UxHw in Silicon.

Next steps​

Last updated on