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

+-----+  +-----+ +-----+
|     |  |     | |     |
| CPU |  | CPU | | CPU |
|     |  |     | |     |
+--+--+  +--+--+ +--+--+
   |        |       |
+--+--------+-------+--+   +----------+
|                      |   |          |
|       Arbiter        +---+ Schedule |
|                      |   |          |
+---------+------------+   +----------+
          |
       +--+---+
       |      |
       | SSPM |
       |      |
       +------+

Drawn using: http://asciiflow.com/

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

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

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.

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

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

ocp_io_m_a is defined in argo/src/noc_interface.vhd 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 ocp_io_m is defined in argo/src/ocp/ocp.vhd 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 patmos/hardware/src/ocp/ocp.scala

// 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 OcpIO.scala:

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

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

$(HWBUILDDIR)/SSPM.v: $(SRC)
        $(SBT) "run-main $(MEMSSPM) --targetDir $(HWBUILDDIR) --cse --backend v"	

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!