The build system 'MaSoCist' behind this setup has been released as an opensource variant that can be played with as a virtualized microprocessor system - under some restrictions.

Unfortunately, the copyright terms of FPGA vendors do not permit to publish all ip core and setup files, therefore all vendor specific files are omitted from this release.

See Docker notes how to reproduce a cycle accurate example of a interactive session with an opensource CPU, simulated by the opensource simulator GHDL:

https://section5.ch/index.php/2018/11/04/masocist-opensource-0-2-release/

The simulation can be run interactively, for example using a virtual UART, as shown in this screen capture:

CPU options

Since only logic resources and pin I/O are true restrictions on an FPGA (apart from maximum clock frequencies, of course), any CPU core that fits may be baked into this hardware. The MaSoCist supports the following CPUs:

The 'netpp operating system'

The default SoC for networking is the ZPUng 'dagobert' edition, supplying some extra hardware acceleration:

The software, or say, the 'bare metal OS' makes usage of this hardware in a very lean and mean way, means that we managed to fit into 32kB of on-chip RAM:

Exporting hardware entities to the network

The XML framework of netpp plays a core role in making hardware accessible from the network. This can be very application specific: on one hand, we might want a robust system that can not be messed with, on the other a very thin remote control layer with minimum overhead.

In any case, we have a XML hardware description that describes:

The lean and mean way of doing things (during prototype phase) is, to grant direct access to a register by a network property. This is displayed below for a GPIO array example. Two GPIO banks are implemented that way where as each bank is represented by 16 bit wide input, output and direction registers.

The more safe way is using function handlers, or in C++Speak: Getters and Setters. In the example below you see a regref node. This would be converted to a handler node, when using the getter/setter approach. This would then also allow to abstract a GPIO array differently, for example by representing each single pin configuration as an array element. You'd then have to code the getters/setters accordingly.

XML advantages

I get this question a lot: Why do you use %&;:!wrkfstf heavy weight XML and not JSON or something 'nice'?

First note: There is no XML passed around on the network. Nada. It's a compact binary block and 'zero copy' as far as possible. Means, we can pass buffer data (like audio or images) around without copying overhead. Would not be possible in JSON.

So the XML takes a purely descriptive role and is converted to bare metal HDL, C headers, and documentation elements (for the hardware reference).

Now, looking at the description layer, it could be argued that JSON could be used. However, there are various reasons that speak XML:

Finally, when it comes to large SoC hardware descriptions with many registers and core instances, XML turned out the only description language to be maintainable.

Last but not least, the XML editor snapshot requires a comment: It's my favorite, very useful XMLMind XML editor (XXE), found at http://www.xmlmind.com/xmleditor/.