Mid of 2011 I changed to a new project doing eclipse plugin development for a patent management application. In parallel I was still supporting the company of my former project. It was about UMTS prototyping in systemC . At this time, switching between those very different projects, I felt more and more uncomfortable with systemC /C++ and all its tooling around. So I got the idea, why not doing prototyping in java instead of systemC ?

Java and a development environment like eclipse give a lot of efficiency to the developer. Java is much easier to use, to read and to extent. But this is not the point in prototyping. Important is simulation speed. That’s basically the main reasons why doing prototyping in a high-level language. It’s just much faster that RTL based simulations (but never fast enough).

With the introduction of Just-In Time compilation (e.g. Hotspot), Java execution speed has been improved drastically. Nevertheless I was very unsure at the beginning of this project if will be able to reach systemc /C++ performance. So I tried first with a simple scheduler, set up simple examples and compared with systemC. First results were very impressive, just threaded processes showed a very bad performance, especially under Linux.

spin is not just a systemC conversion into Java. Instead the patterns that systemC supports (like modules, ports, signals and processes) have been integrated in a form that fits to Java. A simple module in spin looks like this:

public class Adder extends Module {

	public IInPort<Integer> in1, in2;
	public IOutPort<Integer> out;
	final int MASK = 0xff;

	public Adder(String name, IModule parent) {
		super(name, parent);

		new Processing(null, this) {

			public void initialize() {
				sensitive(in1.changed(), in2.changed());

			public void process(Schedule schedule) {
				out.write(((in1.val() + in2.val()) & MASK));

Now after 4 major architecture changes ( spin 0.51) main problems seem to be resolved and several, even simple examples are working fine. To compare performance I converted the “simplePerf” example (2 threads doing client server via a fifo) into spin/java and wrote another example called “simpleAdder” (1 thread with a source and several adder connected) in systemC++ and spin/java. These "benchmarks" now show a quite good performance.

spin is still an approach, not a product, Next points to think about are


  • Mixed Signals (data rate mechanisms)
  • TLM like mechanisms
  • Connecting to systemC TLM
  • Connecting to processor emulation


... to spin main page