Skip to content

Synchronization Protocol

wangeddie67 edited this page May 8, 2024 · 8 revisions

You can find the following topics on this page:

  • The synchronization protocol between simulation processes
  • How interchiplet handles protocol commands.
  • How the delay of protocol commands is calculated.

List of Protocol Commands

Protocol commands and their syntax are listed as below:

Command Arguments Direction Timing/Function Usage
CYCLE <cycle> From simulation processes to interchiplet Timing Report execution time of simulation processes.
PIPE <cycle> <src_x> <src_y> <dst_x> <dst_y> simulation processes -> interchiplet Functional Request Named Pipe from the specified source to the specified destination.
READ <cycle> <src_x> <src_y> <dst_x> <dst_y> <nbytes> simulation processes -> interchiplet Timing Read transaction request from the specified source to the specified destination.
WRITE <cycle> <src_x> <src_y> <dst_x> <dst_y> <nbytes> simulation processes -> interchiplet Timing Write transaction request from the specified source to the specified destination.
SYNC <cycle> interchiplet -> simulation processes Both The response to one request from the simulator process.

TODO: Unsupported commands: BARRIER, LOCK, UNLOCK, RESULT.

TODO: More flexible format for address

Cycle command

CYCLE <cycle>

CYCLE command reports the execution cycle of one simulator process to interchiplet. This command does not need any response at this time.

After receiving a CYCLE command, one sub-thread updates the execution cycle with the value provided by the CYCLE command if the new execution cycle is greater than the recorded execution cycle. At last, the maximum execution cycles recorded by all CYCLE commands are reported as the total execution cycle.

TODO: Use the cycle command to build up period synchronization.

PIPE command

PIPE <cycle> <src_x> <src_y> <dst_x> <dst_y>

PIPE command is used to create a Named Pipe for each pair of communication. The name of PIPE is specified by the source and destination address, which is buffer{src_x}_{src_y}_{dst_x}_{dst_y}. For example, buffer0_0_0_1 means PIPE to send data from node (0,0) to node (0,1). If the request pipe does not exist, interchiplet creates one.

The PIPE command requires a response. One SYNC command after one PIPE command means that the required Pipe file has been available. The cycle fields within PIPE and the following PIPE command is ignored. Thus, the cycle field can be zero.

One example is as shown below:

sequenceDiagram    
participant Simulator Process 0
participant interchiplet
participant Simulator Process 1
Simulator Process 0->>+interchiplet: PIPE 0 0 0 0 1 
interchiplet->>interchiplet: Create PIPE file fifo0_0_0_1   
interchiplet->>-Simulator Process 0: SYNC 0
Simulator Process 1->>+interchiplet: PIPE 0 0 0 0 1 
interchiplet->>-Simulator Process 1: SYNC 0
Loading

Simulator Process 0 (node id 0,0) wants to send data to Simulator Process 1 (node id 0,1). interchiplet receives the PIPE command from simulator process 0 and creates the PIPE file. Then, interchiplet sends a SYNC command to simulator process 0. interchiplet directly issues the SYNC command to simulator process 1 after receiving the PIPE command from the simulation process because the required PIPE file already exists.

A separate PIPE command is used in the functional model to make sure the Pipe file is available. It is not required, but it is suggested that both the source and the destination processes send one PIPE command to interchiplet before opening, reading, and writing the specified PIPE file.

READ and WRITE commands

Both READ and WRITE commands require a certain amount of data from the specified source to the specified destination. The WRITE command is used at the source, while the READ command is used at the destination. src_x and src_y fields specify the source of the transaction, while the dst_x and dst_y fields specify the destination of the transaction. Hence, src_xsrc_ydst_x, and dst_y are the same in the paired READ and WRITE commands.

As described in the Overview, the sequence to perform the communication between processes has been abstracted as the transaction. Hence, the essential read/write operations to lock flags are abstracted into READ/WRITE commands. The cycle field in the WRITE command presents the time when the source component starts to wait for the destination memory location to be ready for overwriting. The cycle field in the READ command presents the time when the destination component starts to wait for data to be ready for read.

sequenceDiagram    
participant Simulator Process 0
participant interchiplet
participant Simulator Process 1
Simulator Process 0->>interchiplet: WRITE 5739284 1 0 0 0 1251
Simulator Process 1->>+interchiplet: READ 5736751 1 0 0 0 1251 
par Sync0
    interchiplet->>Simulator Process 0: SYNC 5739302 
and Sync1
    interchiplet->>-Simulator Process 1: SYNC 5739302 
end
Loading

READ and WRITE commands need a response. The SYNC command after one WRITE command means the source has finished sending data. The SYNC command after one READ command means the destination has finished reading data. The task or flow in the source and destination can continue after receiving the SYNC command. The execution cycle of the source and destination should be adjusted to the value specified in the cycle field of SYNC commands.

Currently, SYNC commands for READ and WRITE commands return the same value in the cycle field. The value equals the maximum value of the cycle among paired READ and WRITE commands plus the network delay.

The network delay is provided by Phase 2 of the previous iteration. interchiplet will load all delay information before starting simulation processes in Phase 1. When it receives the paired READ and WRITE commands, it will search for the first delay information message with the same source and destination. The matched delay information message will be dropped after use.

There is no implicit guarantee that the number and the order of transactions do not change crossing the iteration. Because the simulation flow is based on iteration, the difference crossing iteration should reduce as the simulation continues.

If the network delay from SComps is missing, the network delay only considers the propagation delay, which equals the data amount divided by network bandwidth. In the first iteration, the network delay is determined in the same way.

READ/WRITE is used in the timing model. Some trace-based simulators, like SniperSim, provide separated timing and function models. Hence, the PIPE command should not merge with READ/WRITE commands.

TODO: SYNC for READ and WRITE should provide different times.

TODO: WRITE may need to wait for previous READ to finish. Or ping-pang buffers should be supported.

File format

Trace file format

The trace file is one text file. Each line presents one package in NoC, as shown below.

2846404 0 0 0 1 1251
2847819 0 0 1 0 1251
2849313 0 0 1 1 1251
2850910 0 0 0 1 1251
2852506 0 0 1 0 1251
2854103 0 0 1 1 1251
5735741 0 1 0 0 14
5738752 1 0 0 0 14
5741853 1 1 0 0 14

The first argument is the packet injection cycle, followed by the source and the destination addresses. The last argument is the number of flits.

The trace file is generated by interchiplet. interchiplet always keeps packages in the order of the package injection cycle.

TODO: flexible format for address. Flexible format for different kinds of PComps and SComps.

Delay information file format

The delay infomation file is also one text file. Each line presents one package in NoC, as shown below.

2846354 0 0 0 1 1255
2847819 0 0 1 0 1255
2849313 0 0 1 1 1260
2850910 0 0 0 1 1255
2852506 0 0 1 0 1255
2854103 0 0 1 1 1260
5735683 0 1 0 0 18
5738744 1 0 0 0 18
5741835 1 1 0 0 23

The first argument is the packet injection cycle, followed by the source and the destination addresses. The last argument is the delay of this package, from the injection of the first flit to the ejection of the last flit.

A delay information file is generated by SComps. SComps does not need to sort packages. interchiplet will reorder packages according to the package injection cycle during reading file.

TODO: two delay values from the network, one for the source and the other for the destination.

TODO: flexible format for address. Flexible format for different kinds of PComps and SComps.

Clone this wiki locally