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
+-----+  +-----+ +-----+
|     |  |     | |     |
| 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/srcand 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.SSPMMainat 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.
11th, April
18th, April
25th, April
Rapport.
2nd, May
Presentation!