First App

Hopefully you’ve read the README, but I’ll repeat the highlights here. We can make the entire project, including dependencies by simply running make. Additionally, you can override the compiler and any flags you wish to pass through to it.

make

The make rule riscv_vector should only be provided when building for a platform that supports the RISCV Vector Extension version 1.0.

make riscv_vector CXX='riscv64-linux-gnu-g++' CFLAGS='-march=rv64gcv -Ofast -static'

We have two options for building networks, either by hand or through network_tool.

We have a network, but no real way to interact with it yet. Let’s take a quick moment to discuss the processor_tool.

In order to run the network we need to load it onto a processor. In our case this will be processor_tool_vrisp. The processor is bundled directly into the tool so that the overhead of the framework is kept as minimal as possible.

We can use the processor tool to apply spikes to our network, and see which of the output neurons spikes as a result. Here is the help info for the command we will use.

$ (echo "?") | framework-open/bin/processor_tool_vrisp | grep -E "(AS |ML |RUN |OC |OLF )"
ML network_json                     - Make a new processor from the network & load the network.
AS node_id spike_time spike_val ... - Apply normalized spikes to the network (note: node_id, not input_id)
RUN simulation_time                 - Run the network for "simulation_time" cycles
OC [node_id] [...]                  - Output the spike count for the given output or all outputs
OLF [node_id] [...]                 - Output the last fire time for the given output or all outputs

> ML tutorial/networks/tutorial_and.json
> AS 0 0 1
> AS 1 1 1
> AS 0 2 1
> AS 1 2 1
> RUN 4
> OC
node 2(A&B) spike counts: 1
> OLF
node 2(A&B) last fire time: 3.0

Great! We can see that when either neuron spikes alone (time steps 0 or 1) that the output neuron does not fire. Once both input neurons spike (time step 2) the output neuron spikes a time step later (time step 3).

Another aspect of network design we have neglected to talk about thus far is leak. The concept is simple in VRISP, when a neuron doesn't fire it either leaks away all of its charge each timestep, or it carrys its charge over to the next timestep. These modes are called "all" and "none" respectively. For the network shown here we are choosing to leak away all charge at every time step.

Now we can start building the standalone app that will run our network. To keep things simple, we will write everything in a single C++ source file so that you can see and understand the entire program. The entire file can be found here.

I’ve written a makefile rule that should allow you to just run make tutorial and it should produce a binary under bin/tutorial_app_vrisp. Let’s try running it a few times.

echo "${PWD}"
bin/tutorial_app_vrisp tutorial/networks/tutorial_and.json 0 0
bin/tutorial_app_vrisp tutorial/networks/tutorial_and.json 1 0
bin/tutorial_app_vrisp tutorial/networks/tutorial_and.json 0 1
bin/tutorial_app_vrisp tutorial/networks/tutorial_and.json 1 1

~/vrisp
Result: 0
Result: 0
Result: 0
Result: 1

We can see that our app correctly produces the truth table for an AND gate! Now time to see if we can do anything useful with it.

Let’s go one step further and get this app running on a raspberry pi, with real world inputs to our processor. We can wire up 2 buttons to act as the A and B inputs to the logic gate.

Most of the code will stay the same, so I will only show differences here, although the full source file can be found under tutorial/src/tutorial_and_pi_app.cpp. To begin include the WiringPi header.

#include <wiringPi.h>

Then we need to initialize the GPIO state on the pi.

int main(int argc, char *argv[]) {
  if (argc != 2) {
    fprintf(stderr, "usage: %s network_json\n", argv[0]);
    return 1;
  }

  json network_json;
  vector<string> json_source = {argv[1]};

  wiringPiSetupGpio();

  int APin = 17;
  int BPin = 23;

  pinMode(APin, INPUT);
  pinMode(BPin, INPUT);

  pullUpDnControl(APin, PUD_UP);
  pullUpDnControl(BPin, PUD_UP);

  ifstream fin(argv[1]);
  fin >> network_json;

  Processor *p = nullptr;
  Network *n = load_network(&p, network_json);

  if (!n) {
    fprintf(stderr, "%s: main: Unable to load network.\n", __FILE__);
  }

  while (true) {
      int AState = digitalRead(APin);
      int BState = digitalRead(BPin);

      p->apply_spike(Spike(0, 0, AState==LOW));
      p->apply_spike(Spike(1, 0, BState==LOW));

      p->run(2);

      bool output = p->output_count(0);
      printf("A&B: %d\n", output);

      delay(100);
  }
}

Feel free to change the pins used for either button, but for convenience they are set to GPIO 17 and 23 (Physical pins 11 and 16).

You can now compile and run the app on your pi by running make tutorial_pi. The result is a binary in bin/tutorial_app_pi_vrisp. If we run that we should initially see a stream of “A&B: 0”, which will stay zero when holding either button, but not both. As soon as we hold down both buttons “A&B: 1” should appear. If you see this behavior you now have an embedded neuroprocessor running and accept input from the real world!

#...
A&B: 0 # no buttons held
A&B: 0
A&B: 0 # A button held
A&B: 0
A&B: 0 # B button held
A&B: 0
A&B: 0
A&B: 1 # Both buttons held!
A&B: 1
A&B: 1
A&B: 1
#...

Now that we’ve covered the entire process end-to-end I hope you’ve begun to think of other application ideas. Naturally, neuromorphic computing is an attractive platform for control applications, which we’ll take a look at building in the next tutorial. The key here is that the platform is a solid base to build upon, that should be able to support a wide range of applications