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:


 * 1) Implementation of shared SPM with a ownership concept (probably time-division)
 * 2) Synchronization and support for atomic operations
 * 3) 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

+-+ +-+ +-+ +--+--+  +--+--+ +--+--+   |        |       | +--++---+--+   +--+ +-++   +--+          |       +--+---+       |      |       | SSPM | |     |       +--+ Drawn using: http://asciiflow.com/
 * CPU | | CPU | | CPU |
 * CPU | | CPU | | CPU |
 * Arbiter       +---+ Schedule |
 * Arbiter       +---+ Schedule |

Git
To add changes to next commit:

git add -p

To commit (save the current state in history)

git commit -m "[What ever describes your changes best]"

Push changes to remote server so Henrik can download it.

git push origin

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.

The current SSPM implementation is mostly located in  but the top-level is in.

Build the hardware emulator and run the example program

make emulator make comp APP=sspm ./install/bin/emulator tmp/sspm.elf -v

The  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.

make AEGEAN_PLATFORM=default-altde2-115 platform

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.

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

entity noc is port(    clk	: in std_logic;    reset	: in std_logic;    ocp_io_ms	: in ocp_io_m_a;    supervisor	: in std_logic_vector(2 downto 0);    ocp_io_ss	: out ocp_io_s_a;    spm_ports_m	: out mem_if_masters;    spm_ports_s	: in mem_if_slaves;    irq	: out std_logic_vector(5 downto 0)  );

OCP interface
is defined in  as

type ocp_io_m_a is array((N*M)-1 downto 0) of ocp_io_m; type ocp_io_s_a is array((N*M)-1 downto 0) of ocp_io_s;

We see that these are vectors of OCP interfaces for master and slave connections.

Where  is defined in   as

type ocp_io_m is record MCmd       : std_logic_vector(OCP_CMD_WIDTH-1 downto 0); MAddr      : std_logic_vector(OCP_ADDR_WIDTH-1 downto 0); MData      : std_logic_vector(OCP_DATA_WIDTH-1 downto 0); MByteEn    : std_logic_vector(OCP_BYTE_WIDTH-1 downto 0); MRespAccept : std_logic; end record;

type ocp_io_s is record SResp      : std_logic_vector(OCP_RESP_WIDTH-1 downto 0); SData      : std_logic_vector(OCP_DATA_WIDTH-1 downto 0); SCmdAccept : std_logic; end record;

We must use the Scala definitions, which are in

// Signals generated by master class OcpMasterSignals(addrWidth : Int, dataWidth : Int) extends Bundle { val Cmd = Bits(width = 3) val Addr = Bits(width = addrWidth) val Data = Bits(width = dataWidth)

However, as is seen, this bundle only includes command, address and data! Where is "byte enable" and "response accept"? These are defined in :

// Masters include a RespAccept signal class OcpIOMasterSignals(addrWidth : Int, dataWidth : Int) extends OcpCoreMasterSignals(addrWidth, dataWidth) { val RespAccept = Bits(width = 1)

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  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  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.

// Register signals that come from master val masterReg = Reg(init = master.M) when(masterReg.Cmd === OcpCmd.IDLE || slave.S.CmdAccept === Bits(1)) { masterReg := master.M } // Forward master signals to slave, always accept responses slave.M := masterReg slave.M.RespAccept := Bits("b1")

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  in the build folder.

Here we are interested in modifying


 * : Contains the functions used to generate the VHDL code in . We add our own functions,   for generating the component code and   for binding an instantiation of the component with other signals. We also add extra signals to the function   for use in the binding.
 * : Contains the functions used to generate the verilog code from the Chisel code files in  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  files.


 * : This file designates the devices that we add to patmos, and what their offset should be.
 * : This file describes the different devices which can be added to patmos, e.g. Uart and Leds.

Finally, we have to update the makefile  such that when we make the aegean platform, the python functions can properly make our SSPM.

$(HWBUILDDIR)/SSPM.v: $(SRC) $(SBT) "run-main $(MEMSSPM) --targetDir $(HWBUILDDIR) --cse --backend v"
 * Added  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.

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!