MaSoCist opensource 0.2 release

I’ve finally got to release the opensource tree of our SoC builder environment on github:

Changes in this release:

Active support for Papilio and Breakout MachXO2 board had been dropped
Very basic support for the neo430 (msp430 compatible) added, see Docker notes below
Includes a non-configureable basic ‘eval edition’ (in VHDL only) of our pipelined ZPUng core
Basic Virtual board support (using ghdlex co-simulation extensions)
Docker files and recipes included

Docker environment

Docker containers are in my opinion the optimum for automated deployment and for testing different configurations. To stay close to actual GHDL simulator development, the container is based on the ghdl/ghdl:buster-gcc-7.2.0 edition.

Here’s a short howto to set up an environment ready to play with. You can try this online at

https://labs.play-with-docker.com, for example.

Just register yourself a Docker account, login and start playing in your online sandbox.

If you want to skip the build, you can use the precompiled docker image by running

docker run -it -v/root:/usr/local/src hackfin/masocist

and skip (3.) below.

You’ll need to build and copy some files from contrib/docker to the remote Docker machine instance.

Run ‘make dist’ inside contrib/docker, this will create a file masocist_sfx.sh
Copy Dockerfile and init-pty.sh to Docker playground by dragging the file onto the shell window

Build the container and run it:

docker build -t masocist .

docker run -it -v/root:/usr/local/src masocist

Copy masocist_sfx.sh to the Docker machine and run, inside the running container’s home dir (/home/masocist):
```
sudo sh /usr/local/src/masocist_sfx.sh
```
Now pull and build all necessary packages:
```
make all run
```
If nothing went wrong, the simulation for the neo430 CPU will be built and started with a virtual UART and SPI simulation. A minicom terminal will connect to that UART and you’ll be able to speak to the neo430 ‘bare metal’ shell, for example, you can dump the content of the virtual SPI flash by:
```
s 0 1
```
Note: This can be very slow. On a docker playground virtual machine, it can take up to a minute until the prompt appears, depending on the server load.

Development details

The simulation is a cycle accurate model of your user program, which you can of course modify. During the build process, i.e. when you run ‘make sim’ in the masocist(-opensource) directory, the msp430-gcc compiler builds the software C code from the sw/ directory and places the code into memory according to the linker script in sw/ldscripts/neo430. This results in a ELF binary, which is again converted into a VHDL initialization file for the target. Then the simulation is built.

The linker script is, however very basic. Since a somewhat different, automatically generated memory map is used at this experimental stage, all peripherals are configured in the XML device description at hdl/plat/minimal.xml, however the data memory configuration (‘dmem’ entity) does not automatically adapt the linker script.

Turning this into a fully configurable solution is left to be done.