Overview

HUB

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.

Channels and Pathes

Locked path

handshake

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

streaming

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

Topic revision: r19 - 28 Dec 2007, JanMichel
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Hades Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)