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 (repeated)
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.
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
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.
Meaning of the fields:
CID (Channel ID)
This describes, which of the 16 Channels are used. Here is a proposal for channel assignment for HADES:
|| Data Channel
|| res. (LVL3?)
The header type steers the state machine in the hub design, and is used for data packing and
|| Normal data word
|| Transfer start / source changed
|| Source adress
|| Target adress
|| End of Buffer
|| Transfer Terminated
|| Error pattern
|| Extended data word
|| special data word for error detection
|| Buffer acknowledge
|| Length of buffer
|| future option
|| Illegal word - ignore
For the detailed description of the HDR/DAT/EXT have a look to NewTriggerBusNetworkDescr
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.
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)
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
- 10 Feb 2006