Overview

The network protocol is the most critical part of the complete concept. It should match the requirements (low latency), but should be flexible on the other hand for future extensions and allow for features like monitoring and configuration for the hubs (which then needs only power supply). In addition it should serve to transport mass data.

Therefore the use of channels which have different priority is proposed. The data structure is fixed on 64 bit word granularity, which matches all NewTriggerBusMedia's. The first 64bit word of a transfer is always a header (HDR) or an early termination (TRM). In the first case, data words (DAT) are following. Such structure form a packet, with a length of at least 1 (in the case that only an early TRM has been sent) and maximun "infinity". One packet may devided further into buffers, the maximum buffer length is defined by the receiver, and it only two by default (one HDR, one DAT), unless the receiver increases this value. This in needed to adapt the protocol to any programmable logic device, even the old one which do not have so much internal ressources. The buffer is terminated with an end-of-buffer (EOB) word or the final termination. Here is an example of one transfer:

HDR

DAT

"

EOB

HDR (repeated)

DAT

"

TRM

Since each input port of a hub is able to handle 2 buffers per channel, and no data is transported without acknowledge of the receiver, no data can be lost in a normal operation.

Idea of operation

The data stream is divided into 16 virtual channels, from which 15 can be defined by the user. One channel emulates an A32 remote bus with D32/64/128 to connect the internal registers of hubs and local busses on endpoints or hubs.

The channels are working independent. Multiplexing on the NewTriggerBusMedia is done via a fixed priority. Each channel is furthermore divided into 2 pathes: One for the initial (INIT) transfer, and one for the reply (REPLY). The reason for this is, that even if the INIT path is "plugged" on one channel, the REPLY path is free, to avoid deadlocks.

Moreover, each channel can be programmed in 2 modes: A locked mode, needed for triggered operation, and a free running (streaming) mode. The latter one is a future option.

Locked path

The master initiates a transfer, choosing a certain channel. For the initial transfer, the data stream can be send tranparently to all endpoints. In the meantime, the hubs lock for each port (the internal endpoints also counts!) this individual channel. This channel is locked now, and the master is not allowed to send more data on this channel until the channel is fully released (left fig.).

The release of this channel is done by the endpoints: If the endpoint has done all required operations, it can release the link by sending a packet on a reply path (mid fig.).

If an answer packet for a channel is arriving to the hub port, the lock is released for this channel and this port. The terminating word is buffered in the meantime. After the last (enabled!) port has been unlocked, an concentrated termination is send by the hub upstream (to an upstream hub or master, right fig.). If the media is blocked, the buffer has to be stored and send word by word whenever the upstream media is free.

Data structure

Basic word

63-56	55-52	51	50-48	47-32	31-16	15-0
res.	CID	P	Type	F1	F2	F3

Meaning of the fields:

P (Path)

0=INIT, 1=REPLY

CID (Channel ID)

This describes, which of the 16 Channels are used. Here is a proposal for channel assignment for HADES:

Priority	CID	Data Channel
1.	0000	CTRL
2.	0001	LVL1
3.	0010	LVL2
4.	0011	res. (LVL3?)
5.	0100	res.
6.	0101	res.
7.	0110	RICH-IPU
8.	0111	SHW-IPU
9.	1000	TOF-IPU
10.	1001	RPC-IPU
11.	1010	MDC-IPU
12.	1011	res.
13.	1100	res.
14.	1101	res.
15.	1110	res.
16.	1111	A32-BUS

Type

The header type steers the state machine in the hub design, and is used for data packing and unpacking

Name	Type	Description	F1	F2	F3
DAT	0x0	Normal data word	Data
HDR	0x1	Transfer start / source changed	Source adress	Target adress	DESCR
EOB	0x2	End of Buffer	Data
TRM	0x3	Transfer Terminated	Error pattern		DESCR
EXT	0x4	Extended data word	special data word for error detection
ACK	0x5	Buffer acknowledge	res.	Length of buffer	res.
SIG	0x6	Signals	future option
ILL	0x7	Illegal word - ignore	Data

For the detailed description of the HDR/DAT/EXT have a look to NewTriggerBusNetworkDescr

Address

16 Bit address of the endpoint. The wide address range allows a definition of fields for individual subsystems. This does not mean that there is some routing. This needs too much time and require to have routing tables in the hubs. The only reason for addresses is that the endpoint knows if the data should be processed or can be discarded. 0xFFFF is the broadcast addres.

Broadcast transfers

Broadcasts are used for trigger (here the DTUs send short answers) and IPU transfers (long data array follows). In addition it makes the buffer logic in the hubs very simple.

If 2 channels have data at the same time the priority decides which transfer is done first.

The streaming mode

Possible, later implementation. Also triggerless modes will be possible (needed for the MAPS-readout)

Implementation

For implementation a special IOFIFO will be used, the transfer will be transparent (with some extra features...).

For examples have a look to the NewTriggerBusApplicationNotes

-- IngoFroehlich - 10 Feb 2006