# Computer Architecture Lab/SS2017/SPM project

Implementation of a shared scratch-pad memory with a concept of ownership for multiprocessor architectures.
The project will investigate:
* Implementation of shared SPM with a ownership concept (probably time-division)
* Synchronization and support for atomic operations
* Investigation of possible applications and programming models
The source code for this project can be obtained at henrikh/patmos
* Infrastructure
* Test code for the SSPM
Drawn using: http://asciiflow.com/

## Git

To add changes to next commit:
To commit (save the current state in history)
Push changes to remote server so Henrik can download it.

## Applications

* Message passing
* Sharing tables and calculations

## Instantiation of SSPM

Use the NoC framework and replace the NoC with the scratch-pad memory.

### Building the current work

The most up-to-date branch on Henrik's fork is SSPM-device.
The current SSPM implementation is mostly located in patmos/hardware/src/sspm/ but the top-level is in patmos/hardware/src/io/SSPM.scala.
Build the hardware emulator and run the example program
The -v flag enables waveform output. These waveforms can be opened in fx. Gtkwave. The waveform viewer can typically reload the waveform file, keeping any tapped signals, display forms and colorings.

### Replacing the NoC

Use Aegean to build the SoC.
This is an instance of Aegean with four cores.
Notice, that we only build the platform but do not synthesize the hardware (synth task).
This generates the VHDL for the entire SoC. The generate VHDL is in build/.

#### Interface and signals for the NoC

The interface for the NoC, which we must replace, is as following (from noc.vhd)

##### OCP interface

ocp_io_m_a is defined in argo/src/noc_interface.vhd as
We see that these are vectors of OCP interfaces for master and slave connections.
Where ocp_io_m is defined in argo/src/ocp/ocp.vhd as
We must use the Scala definitions, which are in patmos/hardware/src/ocp/ocp.scala
However, as is seen, this bundle only includes command, address and data! Where is "byte enable" and "response accept"? These are defined in OcpIO.scala:
Notice, that OcpCoreMasterSignals is extended to include the additional response accept signal. The "byte enable" signal doesn't seem to be defined for anything but memory.

### Injection of a device

Old stuff. Most current work is on SSPM-device branch.
Devices defined in the XML-configuration must be of the class CoreDevice. However, we need CmdAccept response from the slave, so we must look into how we can set up a IODevice. In patmos/InOut.scala all devices are connected to the OCP bus. It would be possible to hardwire a configuration of SSPM connectors here. In the branch IODevice-for-OCP this is done, by copying a lot from the network interface's configuration.

#### Who cares about CmdAccept anyway?

Look at the implementation of OcpIOBridge.
Notice that CmdAccept is only used to enable a register (essentially acting as a buffer) and RespAccept defaults to valid.
I wager that we should not care and should instead implement our device as a CoreDevice (for easier development) and then later introduce a wrapper/translation layer for replacing the NoC.

## Instantiation of SSPM Using Python Scripts

Another approach to instantiate the SSPM in the multicore platform is to take advantage of the python scripts used for generating aegean.vhd in the build folder.
Here we are interested in modifying
* aegean/python/codeGen/aegeanCode.py: Contains the functions used to generate the VHDL code in aegean.vhd. We add our own functions, getSSPM for generating the component code and bindSSPM for binding an instantiation of the component with other signals. We also add extra signals to the function declareSignals for use in the binding.
* aegean/python/codeGen/aegeanGen.py: Contains the functions used to generate the verilog code from the Chisel code files in patmos/hardware/src and copy the generated files into aegean.
In order to generate the patmos master and slave cores with the correct IO and support for this, we have to modify the following .xml files.
* aegean/config/ip/ip.xml: This file designates the devices that we add to patmos, and what their offset should be.
* aegean/config/io/dev.xml: This file describes the different devices which can be added to patmos, e.g. Uart and Leds.
Finally, we have to update the makefile /patmos/hardware/Makefile such that when we make the aegean platform, the python functions can properly make our SSPM.
* Added MEMSSPM=io.SSPMMain at the main classes for core.
* Added the following in order to build SSPM

## Arbitration

Two options
* Queue
* TDMA

### Time-division for atomic access

Time-division can be used to give atomic access.
By knowing that a CPU has access during a certain time-slot it is able to guarantee that it will have atomic operations.
This will however require some sort of synchronization, so the CPU know which time-slot they have priority access.
We will ignore interrupts in the core. This means that any application must turn off interrupts before using the TDMA in an atomic way.

### Requested ownership

A possible strategy for ownership is to let each CPU request ownership and then serve them in a round-robin fashion. So if lots of processes are not requesting ownership it is possible for the few left to get more frequent access.
This is a scalable approach which still limits the maximum delay to ownership.
It is like a bus: if no one pushes the stop-button, the bus will just continue.

## Work journal
### 21st, March

Discussed structure of project and possibilities. Agreed on the initial goals of the project with Martin.
The entities of our project are:
* The Patmos processors
* The arbitra/SSPM connection
* The actual SSPM
* The scheduling table/function

### 28th, March

* Andreas: Connection between Patmos and IO
* Henrik: What is needed to replace noc entity
* Jimmi: TDMA change function
* Emad: Message-passing software

### 4th, April

Benchmarking of SSPM v. Argo.
Synchronization.

### 25th, April

Rapport.

### 2nd, May

Presentation!