Difference: NewTriggerBusNetwork (1 vs. 19)

Revision 19
28 Dec 2007 - Main.JanMichel
Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="NewTriggerBus"
>
>
META TOPICPARENT name="NewTriggerBusConcept"
 

Overview

HUB
Revision 18
08 Oct 2007 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 104 to 104
 
Name Type Description F1 F2 F3
DAT 0x0 Normal data word Data
HDR 0x1 Transfer start / source changed Source adress Target adress DESCR
Changed:
<
<
TRM 0x2 Transfer Terminated Error pattern DESCR
EOB 0x3 End of Buffer res. res. res.
>
>
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
Revision 17
30 Apr 2007 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 106 to 106
 
HDR 0x1 Transfer start / source changed Source adress Target adress DESCR
TRM 0x2 Transfer Terminated Error pattern DESCR
EOB 0x3 End of Buffer res. res. res.
Changed:
<
<
ACK 0x4 Buffer acknowledge res. Length of buffer res.
EXT 0x5 Extended data word special data word for error detection
>
>
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
Revision 16
05 Dec 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 102 to 102
  unpacking

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

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

 

Address

Revision 15
04 Dec 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 104 to 104
 
Name Type Description F1 F2 F3
HDR 0x1 Initial Transfer Source adress Target adress Bit data
TRM 0x2 Initial Transfer Terminated Source adress Target adress Error pattern
Changed:
<
<
EOB 0x3 End of Buffer 0x0 CRC (optional) res.
ACK 0x3 End of Buffer 0x1 Length of buffer res.
DAT 0x4 Data word Data
>
>
EOB 0x3 End of Buffer res. res. res.
ACK 0x4 End of Buffer res. Length of buffer res.
DAT 0x0 Data word Data
EXT 0x5 Extended Data word future option
SIG 0x6 Signals future option
ILL 0x7 Illegal word - ignore Data
  the remaining are reserved

Revision 14
14 Jun 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 6 to 6
 

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.
Changed:
<
<
Therefore the use of channels which have different priority is proposed. The data structure is fixed on 32 bit word granularity. The first 32bit word of a transfer is always a header (or an early termination) which might be followed by data words. Such structure form a packet, with a length of at least 1 and maximun "infinity". One packet may devided further into buffers, the maximum buffer length is: 16 data and header words, plus one end-of-buffer (BUF) word or the final termination. Since each input port of a hub is able to handle 2 buffers per channel and path (see below), and no data id transported without acknowledge, no data can be lost in a normal operation.
>
>
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
 
Added:
>
>
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

Line: 19 to 32
  on endpoints or hubs.

The channels are working independent.
Changed:
<
<
Multiplexing on the NewTriggerBusMedia is done via a fixed priority. Each channel is furthermore divided into 3 pathes. The first 2 pathes define a locked protocol, the last one a streaming mode.
>
>
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.
 
Changed:
<
<
Channels and Pathes
>
>
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.
 
Changed:
<
<
Locked pathes are used for bus read/writes and triggers. The streaming path for triggerless operations.
>
>
Channels and Pathes
 

Locked path

Line: 49 to 65
 

Basic word

Changed:
<
<
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CID Type Bit data / adress
>
>
63-56 55-52 51 50-48 47-32 31-16 15-0
res. CID P Type F1 F2 F3
 
Deleted:
<
<
Bits are send in the following order: Bit31->Bit0 (Big-Endian).
  Meaning of the fields:
Added:
>
>

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:
Line: 75 to 94
 
13. 1100 res.
14. 1101 res.
15. 1110 res.
Changed:
<
<
16. 1111 Debug
>
>
16. 1111 A32-BUS
 

Type

The header type steers the state machine in the hub design, and is used for data packing and unpacking
Changed:
<
<
Name Type Description
INIT_HEADER 0x1 Initial Transfer
INIT_TERM 0x2 Initial Transfer Terminated
BUF 0x3 End of Buffer
DATA 0x4 Data word
ACK 0x5 Next buffer can be transmitted, answer to BUF
REPLY_HEADER 0x6 Reply to an initial transfer
REPLY_TERM 0x7 Reply to an initial transfer
>
>
Name Type Description F1 F2 F3
HDR 0x1 Initial Transfer Source adress Target adress Bit data
TRM 0x2 Initial Transfer Terminated Source adress Target adress Error pattern
EOB 0x3 End of Buffer 0x0 CRC (optional) res.
ACK 0x3 End of Buffer 0x1 Length of buffer res.
DAT 0x4 Data word Data
  the remaining are reserved

Address

Changed:
<
<
12 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 is ment for itself or can be discarded. 0xFFF is the broadcast addres. For downstream the address is the target, whereas for upstream the address is the source.

Idea of operation

>
>
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.
 
Changed:
<
<

broadcast transfers

>
>

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.
Line: 135 to 150
 
META FILEATTACHMENT attr="h" comment="HUB" date="1139572886" name="hub.jpg" path="hub.jpg" size="21516" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="handshake" date="1139851502" name="handshake.jpg" path="handshake.jpg" size="16575" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="streaming" date="1139851526" name="streaming.jpg" path="streaming.jpg" size="14660" user="IngoFroehlich" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="h" comment="Channels and Pathes" date="1144063262" name="pipes.jpg" path="pipes.jpg" size="14326" user="IngoFroehlich" version="1.2"
>
>
META FILEATTACHMENT attr="h" comment="Channels and Pathes" date="1150290363" name="pipes.jpg" path="pipes.jpg" size="12767" user="IngoFroehlich" version="1.3"
 
META TOPICMOVED by="IngoFroehlich" date="1139917115" from="DaqSlowControl.NewTriggerBusLink" to="DaqSlowControl.NewTriggerBusNetwork"
Revision 13
03 Apr 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

HUB
Changed:
<
<
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 the IPU data for the Matching Unit.
>
>
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 32 bit word granularity. The first 32bit word of a transfer is always a header (or an early termination) which might be followed by data words. Such structure form a packet, with a length of at least 1 and maximun "infinity". One packet may devided further into buffers, the maximum buffer length is: 16 data and header words, plus one end-of-buffer (BUF) word or the final termination. Since each input port of a hub is able to handle 2 buffers per channel and path (see below), and no data id transported without acknowledge, 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 3 pathes. The first 2 pathes define a locked protocol, the last one a streaming mode.

Channels and Pathes

Locked pathes are used for bus read/writes and triggers. The streaming path for triggerless operations.

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.
 
Deleted:
<
<
Therefore the use of channels which have different priority is proposed. The data structure is fixed on 32 bit word granularity. The first 32bit word is always a header which might be followed by data words.
 

Data structure

Line: 66 to 103
 

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.
Deleted:
<
<
handshake

The master initiates a transfer, choosing a certain channel (e.g. LVL1). For the initial transfer, the data stream can be send tranparently to all endpoints. In the meantime, the hubs lock for each downstream 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 DTU/IPU is not busy (for the DTU this means after the DAQ deadtime for this trigger), each individual endpoint is sending the reply packet upstream (if the media is free) for this channel (mid fig.). This means the individual channels are fully asynchronous, like the old trigger bus.
 
Deleted:
<
<
If an answer packet for a channel is arriving to the hub port, the lock is released for this channel and this port. The data is buffered in the meantime. After the last (enabled!) port has been unlocked, an concentrated answer packet 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.
 

If 2 channels have data at the same time the priority decides which transfer is done first.
Line: 106 to 135
 
META FILEATTACHMENT attr="h" comment="HUB" date="1139572886" name="hub.jpg" path="hub.jpg" size="21516" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="handshake" date="1139851502" name="handshake.jpg" path="handshake.jpg" size="16575" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="streaming" date="1139851526" name="streaming.jpg" path="streaming.jpg" size="14660" user="IngoFroehlich" version="1.1"
Added:
>
>
META FILEATTACHMENT attr="h" comment="Channels and Pathes" date="1144063262" name="pipes.jpg" path="pipes.jpg" size="14326" user="IngoFroehlich" version="1.2"
 
META TOPICMOVED by="IngoFroehlich" date="1139917115" from="DaqSlowControl.NewTriggerBusLink" to="DaqSlowControl.NewTriggerBusNetwork"
Revision 12
14 Mar 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 10 to 10
 

Data structure

Changed:
<
<

Header

>
>

Basic word

 

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
CID I F res D Bit Data / Data Length Address
>
>
CID Type Bit data / adress
 

Bits are send in the following order: Bit31->Bit0 (Big-Endian). Meaning of the fields:
Changed:
<
<

CID (Channel ID) and I (Interrupt)

>
>

CID (Channel ID)

 
Changed:
<
<
This describes, which of the 16 Channels are used. Depending if the C-Bit is set, channels for data transportation is used or an interrupt. The latter one have absolute priority and they have no following data. Here is a proposal for channel assignment for HADES:
>
>
This describes, which of the 16 Channels are used. Here is a proposal for channel assignment for HADES:
 
Changed:
<
<
Priority CID Data Channel Interrupt Channel
1. 0000 CTRL SYSTEM
2. 0001 LVL1 LSYNC
3. 0010 LVL2 res
4. 0011 res. (LVL3?) res.
5. 0100 res. res.
6. 0101 res. res.
7. 0110 RICH-IPU res.
8. 0111 SHW-IPU res.
9. 1000 TOF-IPU res.
10. 1001 RPC-IPU res.
11. 1010 MDC-IPU res.
12. 1011 res. res.
13. 1100 res. res.
14. 1101 res. res.
15. 1110 DBG res.
16. 1111 CTRL res.
>
>
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 Debug

Type

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

Name Type Description
INIT_HEADER 0x1 Initial Transfer
INIT_TERM 0x2 Initial Transfer Terminated
BUF 0x3 End of Buffer
DATA 0x4 Data word
ACK 0x5 Next buffer can be transmitted, answer to BUF
REPLY_HEADER 0x6 Reply to an initial transfer
REPLY_TERM 0x7 Reply to an initial transfer
the remaining are reserved
 
Deleted:
<
<

F (data Follows)

Should be used to indicate to the client that data is not complete after this bunch of data. This can happen due to limited buffers.

res (Reserved)

Version tag, should be 0 (not zero means different definition of header, future option)

D (Data is length) and Bit data

For data channel:

  • 0: Bits 23-12 "Bit Data"
  • 1: Bits 23-12 is Length of following 32Bit words (max. N-1 words).

For command channels only the 32bit header is allowed (no buffering for rapid communication), thus D + Bit data can be used as a status vector.
 

Address

12 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 is ment for itself or can be discarded. 0xFFF is the broadcast addres. For downstream the address is the target, whereas for upstream the address is the source.
Deleted:
<
<

Data

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CID Data field Address or additional data

CID is important, since words can be mixed completely. The use of the address field is free, but recommended to make life simpler for the client.
 

Idea of operation

broadcast transfers

Line: 83 to 73
  In the meantime, the hubs lock for each downstream 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 DTU/IPU is not busy (for the DTU this means after the DAQ deadtime for this trigger), each individual endpoint
Changed:
<
<
is sending the answer packet upstream (if the media is free) for this channel (mid fig.). This means the individual channels are fully asynchronous, like
>
>
is sending the reply packet upstream (if the media is free) for this channel (mid fig.). This means the individual channels are fully asynchronous, like
  the old trigger bus.

If an answer packet for a channel is arriving to the hub port, the lock is released for this channel and this port. The data is buffered in the meantime. After the last (enabled!) port has been unlocked, an concentrated answer packet 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
Line: 91 to 81
 

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

Concentrating

The rule for the 12Bit data field is: First all answers, which do not contain data (i.e. DL=0) are or'ed. On top of this, if aswers contain following data, for all these headers the length is summed and used for the Bits X-12 for the new header. This allows for fast answers, which do not carry additional data (like the LVL1/LVL2 busy release) to use 12 Bits for status/error (like frondend problems, tag mismatch).

If only one port carries data, it also very easy. This would be the case after singe addressing, when all but one ports acknowledge. The situation is more complicated when more than one port carry data. Here, the logic of the hub must split the transfer into 256 words long transfers, setting the F-Bit, After each block it has to wait for an answer from the upstream partner.

Similar logic has to be done by a receiver, when the F-Bit is set. Here, the answer packet should be prepared after the buffer is idle. This behaviour requires detailed simulation!

SYSTEM interrupt

24 23 22 21 20 19 18 17 16 15 14 13 12
Command CID-context

Command Command-Pattern
CID-RESET 000000001
CID-CLEAR 000000010
Hardware-RESET 000000011
LSYNC-INIT 00001DDDD

LSYNC

Since the transmitter has to know what is the depth of the channel buffer of the receiver, the LSYNC protocol has to be used. By default, all channel depths are set to 1, which is the minimun required to avoid deadlocks. The master unit (or what you define to be this module) can broadcast a SYSTEM-LSYNC-INIT interrupt to change this value and make sure on the other hand, what part of the Bit Data can be used for pattern transport. The maximum data length is 2^(DDDD)-1. E.g. if DDDD=0001, the data length is 1. DDDD=0000 is not allowed, DDDD=1100 would be the maximum (12 Bits).

Now it might be that not all modules are following the requirements by the master, thus, each SYSTEM-LSYNC-INIT has to be followed by a LSYNC interrupt (do not mix this!), if the own pipe is shorter than requested. LSYNCs are not forwarded but interpreted only by the neighbour. This allows each link to overwrite the settings of the master, keeping the complete system flexible and extendable for the future.
 

The streaming mode

Line: 125 to 88
 

streaming
Changed:
<
<
Streaming mode is very simple: If the endpoint never set F=0, the transfer has the length of infinity... Even concentrating is allowed, but this requires a sophisticated priority logic (future extension...)
>
>
Possible, later implementation. Also triggerless modes will be possible (needed for the MAPS-readout)
 

Implementation

Changed:
<
<
For implementation the same base design for the master, the hubs and the DTUs should be used. The master is a hub, but with a special connection to the input. A DTU is a hub which has only the internal endpoint (or brute: Even a hub could be a DTU).
>
>
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
Revision 11
21 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 13 to 13
 

Header

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
CID I F res D Bit Data Bit Data / Data Length Address
>
>
CID I F res D Bit Data / Data Length Address
 

Bits are send in the following order: Bit31->Bit0 (Big-Endian). Meaning of the fields:
Line: 24 to 24
 

Priority CID Data Channel Interrupt Channel
1. 0000 CTRL SYSTEM
Changed:
<
<
2. 0001 LVL1 res
>
>
2. 0001 LVL1 LSYNC
 
3. 0010 LVL2 res
4. 0011 res. (LVL3?) res.
5. 0100 res. res.
Line: 53 to 53
 

For data channel:
Changed:
<
<
  • 0: Bits 19-12 "Bit Data"
  • 1: Bits 19-12 is Length of following 32Bit words (max. 256 words)
>
>
  • 0: Bits 23-12 "Bit Data"
  • 1: Bits 23-12 is Length of following 32Bit words (max. N-1 words).
 

For command channels only the 32bit header is allowed (no buffering for rapid communication), thus D + Bit data can be used as a status vector.
Line: 93 to 93
 

Concentrating

Changed:
<
<
The rule for the 12Bit data field is: First all answers, which do not contain data (i.e. DL=0) are or'ed. On top of this, if aswers contain following data, for all these headers the length is summed and used for the Bits 19-12 for the new header.
>
>
The rule for the 12Bit data field is: First all answers, which do not contain data (i.e. DL=0) are or'ed. On top of this, if aswers contain following data, for all these headers the length is summed and used for the Bits X-12 for the new header.
  This allows for fast answers, which do not carry additional data (like the LVL1/LVL2 busy release) to use 12 Bits for status/error (like frondend problems, tag mismatch).

If only one port carries data, it also very easy. This would be the case after singe addressing, when all but one ports acknowledge. The situation is more complicated when more than one port carry data. Here, the logic of the hub must split the transfer into 256 words long transfers, setting the F-Bit, After each block it has to wait for an answer from the upstream partner.

Similar logic has to be done by a receiver, when the F-Bit is set. Here, the answer packet should be prepared after the buffer is idle. This behaviour requires detailed simulation!
Added:
>
>

SYSTEM interrupt

24 23 22 21 20 19 18 17 16 15 14 13 12
Command CID-context

Command Command-Pattern
CID-RESET 000000001
CID-CLEAR 000000010
Hardware-RESET 000000011
LSYNC-INIT 00001DDDD

LSYNC

Since the transmitter has to know what is the depth of the channel buffer of the receiver, the LSYNC protocol has to be used. By default, all channel depths are set to 1, which is the minimun required to avoid deadlocks. The master unit (or what you define to be this module) can broadcast a SYSTEM-LSYNC-INIT interrupt to change this value and make sure on the other hand, what part of the Bit Data can be used for pattern transport. The maximum data length is 2^(DDDD)-1. E.g. if DDDD=0001, the data length is 1. DDDD=0000 is not allowed, DDDD=1100 would be the maximum (12 Bits).

Now it might be that not all modules are following the requirements by the master, thus, each SYSTEM-LSYNC-INIT has to be followed by a LSYNC interrupt (do not mix this!), if the own pipe is shorter than requested. LSYNCs are not forwarded but interpreted only by the neighbour. This allows each link to overwrite the settings of the master, keeping the complete system flexible and extendable for the future.
 

The streaming mode

Revision 10
20 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"
Deleted:
<
<

THIS PAGE WILL BE REWRITTEN - DO NOT READ IT

 

Overview

HUB
Line: 15 to 13
 

Header

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
CID C F res D Bit Data Address
>
>
CID I F res D Bit Data Bit Data / Data Length Address
 

Bits are send in the following order: Bit31->Bit0 (Big-Endian). Meaning of the fields:
Changed:
<
<

CID (Channel ID) and C (Command)

>
>

CID (Channel ID) and I (Interrupt)

 
Changed:
<
<
This describes, which of the 16 Channels are used. Depending if the C-Bit is set, channels for data transportation is used or a command channel. The latter one have absolute priority. Here is a proposal for channel assignment for HADES:
>
>
This describes, which of the 16 Channels are used. Depending if the C-Bit is set, channels for data transportation is used or an interrupt. The latter one have absolute priority and they have no following data. Here is a proposal for channel assignment for HADES:
 
Changed:
<
<
Priority CID Data Channel Command Channel
1. 0000 CTRL ERROR
2. 0001 LVL1 RESET
3. 0010 LVL2 CLEAR
>
>
Priority CID Data Channel Interrupt Channel
1. 0000 CTRL SYSTEM
2. 0001 LVL1 res
3. 0010 LVL2 res
 
4. 0011 res. (LVL3?) res.
5. 0100 res. res.
6. 0101 res. res.
Changed:
<
<
7. 0110 res. res.
8. 0111 IPU1 res.
9. 1000 IPU2 res.
10. 1001 IPU3 res.
11. 1010 IPU4 res.
>
>
7. 0110 RICH-IPU res.
8. 0111 SHW-IPU res.
9. 1000 TOF-IPU res.
10. 1001 RPC-IPU res.
11. 1010 MDC-IPU res.
 
12. 1011 res. res.
13. 1100 res. res.
14. 1101 res. res.
Line: 45 to 43
 

F (data Follows)

Changed:
<
<
Should be used to indicate to the listener that data is not complete after this bunch of data. This can happen due to limited buffers.
>
>
Should be used to indicate to the client that data is not complete after this bunch of data. This can happen due to limited buffers.
 

res (Reserved)

Line: 55 to 53
 

For data channel:
Changed:
<
<
  • 0: Bit Data is "Bit Data"
  • 1: Bit Data is Length of following 32Bit words
>
>
  • 0: Bits 19-12 "Bit Data"
  • 1: Bits 19-12 is Length of following 32Bit words (max. 256 words)
 

For command channels only the 32bit header is allowed (no buffering for rapid communication), thus D + Bit data can be used as a status vector.

Address

Changed:
<
<
12 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 is ment for itself or can be discarded. 0xFFFF is the broadcast addres. For downstream the address is the target, whereas for upstream the address is the source.
>
>
12 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 is ment for itself or can be discarded. 0xFFF is the broadcast addres. For downstream the address is the target, whereas for upstream the address is the source.
 

Data

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
CID Data field Address or additional data
>
>
CID Data field Address or additional data
 
Changed:
<
<
CID is important, since words can be mixed completely. The use of the address field is free, but recommended to make life simpler for the listener.
>
>
CID is important, since words can be mixed completely. The use of the address field is free, but recommended to make life simpler for the client.
 

Idea of operation

broadcast transfers

Changed:
<
<
Broadcasts are used for trigger (here the DTUs send short answers) and IPU transfers (long data array follows):
>
>
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.
 

handshake

The master initiates a transfer, choosing a certain channel (e.g. LVL1).
Changed:
<
<
Since only the master is allowed to send downstream, the data stream can be send tranparently to all endpoints.
>
>
For the initial transfer, the data stream can be send tranparently to all endpoints.
  In the meantime, the hubs lock for each downstream 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 DTU/IPU is not busy (for the DTU this means after the DAQ deadtime for this trigger), each individual endpoint
Line: 93 to 91
 

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

more later...

Bit data and address

Downstream

For a normal trigger, the address should be set to the broadcast address. The data stream arrives to all endpoints, as usual. An endpoint is either a hub or a detector system. For the latter one the endpoint consist of the endpoint functionality as described here in the text and the old DTU operation (e.g. communication with the readout, busy, deadtime etc....). The bit data might contain trigger tag, code. For future use, additional 32bit words could be transfered

If the address is non-broadcast, this makes only sense for the CTRL channel (or???). Here, the additional 32bit word(s) may contain download configuration or a command. In principle, all endpoints which do not match the address can simply send the answer packet.
>
>

Concentrating

 
Changed:
<
<

Upstream

>
>
The rule for the 12Bit data field is: First all answers, which do not contain data (i.e. DL=0) are or'ed. On top of this, if aswers contain following data, for all these headers the length is summed and used for the Bits 19-12 for the new header. This allows for fast answers, which do not carry additional data (like the LVL1/LVL2 busy release) to use 12 Bits for status/error (like frondend problems, tag mismatch).
 
Changed:
<
<
As described above, in handshake mode NO data can be sent to the master, therefore the Bit Data can contain e.g. the busy status of a channel (12bit). So it would be nice if we restrict a hub to 11 output ports (+1 internal endpoint), this matches for the 12 Bit field.
>
>
If only one port carries data, it also very easy. This would be the case after singe addressing, when all but one ports acknowledge. The situation is more complicated when more than one port carry data. Here, the logic of the hub must split the transfer into 256 words long transfers, setting the F-Bit, After each block it has to wait for an answer from the upstream partner.
 
Changed:
<
<
However, this makes the design a little bit more complicated: In addition the hub has to remember that the last request was a non-broadcast (this needs 4 bits...), and when the answer paket arrives, the fast response after 4 bits is not possible. The hub has to wait for the complete 32bit header, decode the header, store the bit data (another 12bit) and wait for the handshake of all ports. Since all ports should send zero bit data execpt of one (here it might be non-zero) the bit data of all ports can be or-ed. Since modern FPGA have enough resources, why not save all bit data from all channels? If all ports have been unlocked, the answer packet is send upstream as usual, but with the stored and merged 12 bit data.
>
>
Similar logic has to be done by a receiver, when the F-Bit is set. Here, the answer packet should be prepared after the buffer is idle. This behaviour requires detailed simulation!
 
Deleted:
<
<
Why this overhead? This allows to monitor the busys of all hubs and detector systems while in full performace on the fly!
 
Changed:
<
<

The streaming mode

>
>

The streaming mode

 
Deleted:
<
<

Idea of operation

 

streaming
Changed:
<
<
The idea why this mode is needed is to get more debug information from the system. Nowadays, one has to log on all systems and type "dtuctrl status bla" and than starts certain debug programs. This is anoying and even not possible for the RPC system.

The streaming mode is started with the SQR bit and the start bit pattern in CID. The streaming mode does not know about channels. After that packet has arrived to all hubs and endpoints (an endpoint is also a "hub" with only one port), the handshake mode is stopped and the media is blocked from the point of view of the handhake logic as described above. This means after a short time no answer packets can come (this time can be calculated as a function of hub layers and clock). Now the master has the full control. Broadcast is not allowed in this mode. The request is send to all endpoint s (left fig.), but only one with a certain address will listen. The entpoints which do not match the address simply do not care and send no answer packet. Only one endpoint sends an answer packet, this is transported via all hubs without checking the content (mid fig.). The bit data is used to store the length of the trailing data words. If 2 ports are sending, of course this is an error condition, and an error packet should be send to the master (right fig.).

After the data has been send completely to the master, the master may initiate another request, or restart the handshake mode.
>
>
Streaming mode is very simple: If the endpoint never set F=0, the transfer has the length of infinity... Even concentrating is allowed, but this requires a sophisticated priority logic (future extension...)
 

Implementation

Revision 9
15 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

THIS PAGE WILL BE REWRITTEN - DO NOT READ IT

Overview

Deleted:
<
<
* HUB:
  HUB
Changed:
<
<
The link 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).
>
>
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 the IPU data for the Matching Unit.
 
Changed:
<
<
Therefore 2 modes of data transportation are proposed:
>
>
Therefore the use of channels which have different priority is proposed. The data structure is fixed on 32 bit word granularity. The first 32bit word is always a header which might be followed by data words.
 
Changed:
<
<
  • The handshake mode: Here, data is transported from the master to all endpoints using channels. The channel is locked until all enabled andpoints have sent a handshake. Data transportation from the endpoints to the master is very limited. Response time is fast.

  • The streaming mode: Data is transported from the master to one module and back without limitation. Handshake mode is stopped during streaming.

Basic header and protocols

The data stream (it does not matter if up- or downstream) always consist of a 32bit header which may followed by N 32bit words of data. Additional data word are always allowed downstream, for upstream only in streaming mode.
>
>

Data structure

 

Header

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
res CID SRQ DL Bit Data Address

Bits are send in the following order: Bit31->Bit0 (Big-Endian). It appears that the Bits31-28 are enough for fast reaction in handshake mode. This allows the fast reaction with low latency. The leading "1" is the start tag bit.
>
>
CID C F res D Bit Data Address
 
Added:
>
>
Bits are send in the following order: Bit31->Bit0 (Big-Endian).
  Meaning of the fields:
Changed:
<
<

res

>
>

CID (Channel ID) and C (Command)

 
Changed:
<
<
Version tag, should be 00 (not zero means different definition of header, future option)
>
>
This describes, which of the 16 Channels are used. Depending if the C-Bit is set, channels for data transportation is used or a command channel. The latter one have absolute priority. Here is a proposal for channel assignment for HADES:
 
Changed:
<
<

DL and Bit data

>
>
Priority CID Data Channel Command Channel
1. 0000 CTRL ERROR
2. 0001 LVL1 RESET
3. 0010 LVL2 CLEAR
4. 0011 res. (LVL3?) res.
5. 0100 res. res.
6. 0101 res. res.
7. 0110 res. res.
8. 0111 IPU1 res.
9. 1000 IPU2 res.
10. 1001 IPU3 res.
11. 1010 IPU4 res.
12. 1011 res. res.
13. 1100 res. res.
14. 1101 res. res.
15. 1110 DBG res.
16. 1111 CTRL res.
 
Deleted:
<
<
DL: "Data is Length"

  • 0: Bit Data is "Bit Data"
  • 1: Bit Data is Length of following 32Bit words
 
Changed:
<
<

Address

>
>

F (data Follows)

 
Changed:
<
<
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 is ment for itself or can be discarded.
>
>
Should be used to indicate to the listener that data is not complete after this bunch of data. This can happen due to limited buffers.
 
Changed:
<
<
There are special addresses
>
>

res (Reserved)

 
Changed:
<
<
  • 0x0000: The master address
  • 0xffff: The broadcast address
>
>
Version tag, should be 0 (not zero means different definition of header, future option)
 
Changed:
<
<
For downstream the address is the target, whereas for upstream the address is the source. Therefore, the address=0x0000 does not make much sense....
>
>

D (Data is length) and Bit data

 
Added:
>
>
For data channel:
 
Changed:
<
<

SRQ set, meaning of CID

>
>
  • 0: Bit Data is "Bit Data"
  • 1: Bit Data is Length of following 32Bit words
 
Changed:
<
<
Streaming Request Bit: If set by the master, the streaming mode is enabled or disabled for the complete system, depending on the 2 CID bits.
>
>
For command channels only the 32bit header is allowed (no buffering for rapid communication), thus D + Bit data can be used as a status vector.
 
Changed:
<
<
If set by an endpoint, a certain endpoint asks the master for streaming mode (future extension...) OR Using the 2 bits, also error conditions can by set
>
>

Address

 
Changed:
<
<
Direction CID Name Comment
Down 0000 Streaming Start  
Down 0001 Streaming Stop  
Down 0010 Reset Address field contains target (or broadcast), bit data may contain more info
Down 0011 Clear Address field contains target (or broadcast), bit data may contain more info
Up 0000 Streaming Request future option
Up 0001    
Up 0010 Error packet Address field may contain source of problem, bit data may contain more info
Up 0011    
>
>
12 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 is ment for itself or can be discarded. 0xFFFF is the broadcast addres. For downstream the address is the target, whereas for upstream the address is the source.
 
Changed:
<
<

SRQ unset

>
>

Data

 
Changed:
<
<
If Streaming Request bit is zero, a normal transfer is done, either handshake or streaming transfer
>
>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CID Data field Address or additional data
 
Changed:
<
<

The handshake mode

>
>
CID is important, since words can be mixed completely. The use of the address field is free, but recommended to make life simpler for the listener.
 
Deleted:
<
<

Channels

Here, CID is the channel ID:
 
Changed:
<
<
Priority CID Channel Name
1. 0000 LVL1
2. 0001 LVL2
3. 0010 res. (LVL3?)
4. 0011 CTRL
>
>

Idea of operation

 
Changed:
<
<
more channels are reserved (future option)
>
>

broadcast transfers

 
Changed:
<
<

Idea of operation

>
>
Broadcasts are used for trigger (here the DTUs send short answers) and IPU transfers (long data array follows):
 

handshake
Changed:
<
<
The master initiates a transfer, choosing a certain channel (e.g. LVL1). This normally a broadcast. Since only the master is allowed to send downstream, the bit stream can be send tranparently to all endpoints.
>
>
The master initiates a transfer, choosing a certain channel (e.g. LVL1). Since only the master is allowed to send downstream, the data stream can be send tranparently to all endpoints.
  In the meantime, the hubs lock for each downstream 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.).
Changed:
<
<
The release of this channel is done by the endpoints: If the DTU is not busy (after the DAQ deadtime for this trigger), each individual endpoint
>
>
The release of this channel is done by the endpoints: If the DTU/IPU is not busy (for the DTU this means after the DAQ deadtime for this trigger), each individual endpoint
  is sending the answer packet upstream (if the media is free) for this channel (mid fig.). This means the individual channels are fully asynchronous, like the old trigger bus.
Changed:
<
<
If an answer packet for a channel is arriving to the hub port, the lock is released for this channel and this port. After the last (enabled!) port has been unlocked, an answer packet is send by the hub upstream (to an upstream hub or master, right fig.). If the media is blocked, this packet request has to be latched and send whenever the upstream media is free. If 2 channels are released at the same time (because port 1 releases channel 1, and port 2 releases channel 2, and it was the last locked port, respectively) the priority decides which transfer is done first.
>
>
If an answer packet for a channel is arriving to the hub port, the lock is released for this channel and this port. The data is buffered in the meantime. After the last (enabled!) port has been unlocked, an concentrated answer packet 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.

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

more later...

 

Bit data and address

Revision 8
14 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"
Added:
>
>

THIS PAGE WILL BE REWRITTEN - DO NOT READ IT

 

Overview

* HUB:
Revision 7
14 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 20 to 20
 

Header

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
1 V CID SRQ DL Bit Data Address
>
>
res CID SRQ DL Bit Data Address
 

Bits are send in the following order: Bit31->Bit0 (Big-Endian). It appears that the Bits31-28 are enough for fast reaction in handshake mode. This allows the fast reaction with low latency. The leading "1" is the start tag bit.

Meaning of the fields:
Changed:
<
<

V

>
>

res

 
Changed:
<
<
Version tag, should be 0 (1 means different definituin of header, future option)
>
>
Version tag, should be 00 (not zero means different definition of header, future option)
 

DL and Bit data

Line: 132 to 132
 

For implementation the same base design for the master, the hubs and the DTUs should be used. The master is a hub, but with a special connection to the input. A DTU is a hub which has only the internal endpoint (or brute: Even a hub could be a DTU).
Changed:
<
<
For examples have a look to the NewTriggerBusLinkApplicationNotes
>
>
For examples have a look to the NewTriggerBusApplicationNotes
 

Line: 146 to 146
 
META FILEATTACHMENT attr="h" comment="HUB" date="1139572886" name="hub.jpg" path="hub.jpg" size="21516" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="handshake" date="1139851502" name="handshake.jpg" path="handshake.jpg" size="16575" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="streaming" date="1139851526" name="streaming.jpg" path="streaming.jpg" size="14660" user="IngoFroehlich" version="1.1"
Added:
>
>
META TOPICMOVED by="IngoFroehlich" date="1139917115" from="DaqSlowControl.NewTriggerBusLink" to="DaqSlowControl.NewTriggerBusNetwork"
Revision 6
14 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 20 to 20
 

Header

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
1 CID SRQ Bit Data Address
>
>
1 V CID SRQ DL Bit Data Address
 

Bits are send in the following order: Bit31->Bit0 (Big-Endian). It appears that the Bits31-28 are enough for fast reaction in handshake mode. This allows the fast reaction with low latency. The leading "1" is the start tag bit.

Meaning of the fields:
Added:
>
>

V

Version tag, should be 0 (1 means different definituin of header, future option)

DL and Bit data

DL: "Data is Length"

  • 0: Bit Data is "Bit Data"
  • 1: Bit Data is Length of following 32Bit words
 

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 is ment for itself or can be discarded.
Line: 37 to 48
 

For downstream the address is the target, whereas for upstream the address is the source. Therefore, the address=0x0000 does not make much sense....
Deleted:
<
<

Bit data

This is the length of the following 32bit word if data transportation is allowed. For the answer packets of the endpoints in handshake mode, the bit fiels may carry other information (part of the data layer)
 

SRQ set, meaning of CID

Line: 50 to 57
  Using the 2 bits, also error conditions can by set

Direction CID Name Comment
Changed:
<
<
Down 00 Streaming Start  
Down 01 Streaming Stop  
Down 10 Reset Address field contains target (or broadcast), bit data may contain more info
Down 11 Clear Address field contains target (or broadcast), bit data may contain more info
Up 00 Streaming Request future option
Up 01    
Up 10 Error packet Address field may contain source of problem, bit data may contain more info
Up 11    
>
>
Down 0000 Streaming Start  
Down 0001 Streaming Stop  
Down 0010 Reset Address field contains target (or broadcast), bit data may contain more info
Down 0011 Clear Address field contains target (or broadcast), bit data may contain more info
Up 0000 Streaming Request future option
Up 0001    
Up 0010 Error packet Address field may contain source of problem, bit data may contain more info
Up 0011    
 

SRQ unset

Line: 69 to 76
  Here, CID is the channel ID:

Priority CID Channel Name
Changed:
<
<
1. 00 LVL1
2. 01 LVL2
3. 10 res. (LVL3?)
4. 11 CTRL
>
>
1. 0000 LVL1
2. 0001 LVL2
3. 0010 res. (LVL3?)
4. 0011 CTRL

more channels are reserved (future option)
 

Idea of operation

Line: 93 to 102
 

Downstream

Changed:
<
<
For a normal trigger, the address should be set to the broadcast address. The data stream arrives to all endpoints, as usual. An endpoint is either a hub or a detector system. For the latter one the endpoint consist of the endpoint functionality as described here in the text and the old DTU operation (e.g. communication with the readout, busy, deadtime etc....). The bit data is the length of the additional data words, it can be one e.g. which means that one 32bit word is following (this might contain trigger tag, code).
>
>
For a normal trigger, the address should be set to the broadcast address. The data stream arrives to all endpoints, as usual. An endpoint is either a hub or a detector system. For the latter one the endpoint consist of the endpoint functionality as described here in the text and the old DTU operation (e.g. communication with the readout, busy, deadtime etc....). The bit data might contain trigger tag, code. For future use, additional 32bit words could be transfered
 

If the address is non-broadcast, this makes only sense for the CTRL channel (or???). Here, the additional 32bit word(s) may contain download configuration or a command. In principle, all endpoints which do not match the address can simply send the answer packet.
Revision 5
13 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 11 to 11
 

  • The handshake mode: Here, data is transported from the master to all endpoints using channels. The channel is locked until all enabled andpoints have sent a handshake. Data transportation from the endpoints to the master is very limited. Response time is fast.
Changed:
<
<
  • The streaming mode: Data is transported from the master to one module and back without limitation. Handshake mode is stopped during streaming. There is no need that the streaming mode is implemented in the first version
>
>
  • The streaming mode: Data is transported from the master to one module and back without limitation. Handshake mode is stopped during streaming.
 

Basic header and protocols

Line: 44 to 44
 

SRQ set, meaning of CID

Changed:
<
<
Streaming Request Bit: If set by the master, the streaming mode is enables or disabled for the complete system, depending on the 2 CID bits.
>
>
Streaming Request Bit: If set by the master, the streaming mode is enabled or disabled for the complete system, depending on the 2 CID bits.
 

If set by an endpoint, a certain endpoint asks the master for streaming mode (future extension...) OR Using the 2 bits, also error conditions can by set
Line: 61 to 61
 

SRQ unset

Changed:
<
<
If Streaming bit is zero, a normal transfer is done, either handshake or streaming transfer
>
>
If Streaming Request bit is zero, a normal transfer is done, either handshake or streaming transfer
 

The handshake mode

Line: 76 to 76
 

Idea of operation

Added:
>
>
handshake
  The master initiates a transfer, choosing a certain channel (e.g. LVL1). This normally a broadcast. Since only the master is allowed to send downstream, the bit stream can be send tranparently to all endpoints.
Changed:
<
<
In the meantime, the hubs lock for each downstream 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.
>
>
In the meantime, the hubs lock for each downstream 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 DTU is not busy (after the DAQ deadtime for this trigger), each individual endpoint
Changed:
<
<
is sending the answer packet upstream (if the media is free) for this channel. This means the individual channels are fully asynchronous, like
>
>
is sending the answer packet upstream (if the media is free) for this channel (mid fig.). This means the individual channels are fully asynchronous, like
  the old trigger bus.
Changed:
<
<
If an answer packet for a channel is arriving to the hub port, the lock is released for this channel and this port. After the last (enabled!) port has been unlocked, an answer packet is send by the hub upstream (to an upstream hub or master). If the media is blocked, this packet request has to be latched and send whenever the upstream media is free. If 2 channels are released at the same time (because port 1 releases channel 1, and port 2 releases channel 2, and it was the last locked port, respectively) the priority decides.
>
>
If an answer packet for a channel is arriving to the hub port, the lock is released for this channel and this port. After the last (enabled!) port has been unlocked, an answer packet is send by the hub upstream (to an upstream hub or master, right fig.). If the media is blocked, this packet request has to be latched and send whenever the upstream media is free. If 2 channels are released at the same time (because port 1 releases channel 1, and port 2 releases channel 2, and it was the last locked port, respectively) the priority decides which transfer is done first.
 

Bit data and address

Line: 108 to 110
 

Idea of operation

Added:
>
>
streaming
  The idea why this mode is needed is to get more debug information from the system. Nowadays, one has to log on all systems and type "dtuctrl status bla" and than starts certain debug programs. This is anoying and even not possible for the RPC system.
Changed:
<
<
The streaming mode is started with the SQR bit and the start bit pattern in CID. The streaming mode does not know about channels. After that packet has arrived to all hubs and endpoints (an endpoint is also a "hub" with only one port), the handshake mode is stopped and the media is blocked from the point of view of the handhake logic as described above. This means after a short time no answer packets can come (this time can be calculated as a function of hub layers and clock). Now the master has the full control. Broadcast is not allowed in this mode. The request is send to one endpoint with a certain address as usual. The entpoints which do not match the address simply do not care and send no answer packet. Only one endpoint sends an answer packet, this is transported via all hubs without checking the content. The bit data is used to store the length of the trailing data words. If 2 ports are sending, of course this is an error condition, and an error packet should be send to the master.
>
>
The streaming mode is started with the SQR bit and the start bit pattern in CID. The streaming mode does not know about channels. After that packet has arrived to all hubs and endpoints (an endpoint is also a "hub" with only one port), the handshake mode is stopped and the media is blocked from the point of view of the handhake logic as described above. This means after a short time no answer packets can come (this time can be calculated as a function of hub layers and clock). Now the master has the full control. Broadcast is not allowed in this mode. The request is send to all endpoint s (left fig.), but only one with a certain address will listen. The entpoints which do not match the address simply do not care and send no answer packet. Only one endpoint sends an answer packet, this is transported via all hubs without checking the content (mid fig.). The bit data is used to store the length of the trailing data words. If 2 ports are sending, of course this is an error condition, and an error packet should be send to the master (right fig.).
 

After the data has been send completely to the master, the master may initiate another request, or restart the handshake mode.
Line: 127 to 131
  -- IngoFroehlich - 10 Feb 2006

Added:
>
>

 
META FILEATTACHMENT attr="h" comment="HUB" date="1139572886" name="hub.jpg" path="hub.jpg" size="21516" user="IngoFroehlich" version="1.1"
Added:
>
>
META FILEATTACHMENT attr="h" comment="handshake" date="1139851502" name="handshake.jpg" path="handshake.jpg" size="16575" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="streaming" date="1139851526" name="streaming.jpg" path="streaming.jpg" size="14660" user="IngoFroehlich" version="1.1"
Revision 4
13 Feb 2006 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 9 to 9
 

Therefore 2 modes of data transportation are proposed:
Changed:
<
<
  • The handshake mode: Here, data is transported from the master to all endpoints using channels. The channel is locked until all enabled andpoints have send an handshake. Data transportation from the endpoints to the master is very limited. Response time is fast.
>
>
  • The handshake mode: Here, data is transported from the master to all endpoints using channels. The channel is locked until all enabled andpoints have sent a handshake. Data transportation from the endpoints to the master is very limited. Response time is fast.
 

  • The streaming mode: Data is transported from the master to one module and back without limitation. Handshake mode is stopped during streaming. There is no need that the streaming mode is implemented in the first version
Line: 20 to 20
 

Header

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
1 CID SRQ Bit Data Adress
>
>
1 CID SRQ Bit Data Address
 

Bits are send in the following order: Bit31->Bit0 (Big-Endian). It appears that the Bits31-28 are enough for fast reaction in handshake mode. This allows the fast reaction with low latency. The leading "1" is the start tag bit.
Line: 30 to 30
 

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 is ment for itself or can be discarded.
Changed:
<
<
There are special adresses
>
>
There are special addresses
 
Changed:
<
<
  • 0x0000: The master adress
  • 0xffff: The broadcast adress
>
>
  • 0x0000: The master address
  • 0xffff: The broadcast address
 

For downstream the address is the target, whereas for upstream the address is the source. Therefore, the address=0x0000 does not make much sense....
Line: 52 to 52
 
Direction CID Name Comment
Down 00 Streaming Start  
Down 01 Streaming Stop  
Changed:
<
<
Down 10 Reset Adress field contains target (or broadcast), bit data may contain more info
Down 11 Clear Adress field contains target (or broadcast), bit data may contain more info
>
>
Down 10 Reset Address field contains target (or broadcast), bit data may contain more info
Down 11 Clear Address field contains target (or broadcast), bit data may contain more info
 
Up 00 Streaming Request future option
Up 01    
Changed:
<
<
Up 10 Error packet Adress field may contain source of problem, bit data may contain more info
>
>
Up 10 Error packet Address field may contain source of problem, bit data may contain more info
 
Up 11    

SRQ unset

Line: 81 to 81
  In the meantime, the hubs lock for each downstream 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.

The release of this channel is done by the endpoints: If the DTU is not busy (after the DAQ deadtime for this trigger), each individual endpoint
Changed:
<
<
is sending the aswer packet upstream (if the media is free) for this channel. This means the individual channels are fully asynchronous, like
>
>
is sending the answer packet upstream (if the media is free) for this channel. This means the individual channels are fully asynchronous, like
  the old trigger bus.
Changed:
<
<
If an answer packet for a channel is arriving to the hub port, the lock is releaser for this channel and this port. After the last (enabled!) port has been unlocked, an answer packet is send by the hub upstream (to an upstream hub or master). If the media is blocked, this packet request has to be latched and send whenever the
>
>
If an answer packet for a channel is arriving to the hub port, the lock is released for this channel and this port. After the last (enabled!) port has been unlocked, an answer packet is send by the hub upstream (to an upstream hub or master). If the media is blocked, this packet request has to be latched and send whenever the
  upstream media is free. If 2 channels are released at the same time (because port 1 releases channel 1, and port 2 releases channel 2, and it was the last locked port, respectively) the priority decides.
Changed:
<
<

Bit data and adress

>
>

Bit data and address

 

Downstream

Changed:
<
<
For a normal trigger, the adress should be set to the broadcast adress. The data stream arrives to all endpoints, as usual. An endpoint is either a hub or a detector system. For the latter one the endpoint consist of the endpoint functionality as described here in the text and the old DTU operation (e.g. communication with the readout, busy, deadtime etc....). The bit data is the length of the additional data words, it can be one e.g. which means that one 32bit word is following (this might contain trigger tag, code).
>
>
For a normal trigger, the address should be set to the broadcast address. The data stream arrives to all endpoints, as usual. An endpoint is either a hub or a detector system. For the latter one the endpoint consist of the endpoint functionality as described here in the text and the old DTU operation (e.g. communication with the readout, busy, deadtime etc....). The bit data is the length of the additional data words, it can be one e.g. which means that one 32bit word is following (this might contain trigger tag, code).
 
Changed:
<
<
If the adress is non-broadcast, this makes only sense for the CTRL channel (or???). Here, the additional 32bit word(s) may contain download configuration or a command. In principle, all endpoints which do not match the adress can simply send the answer packet.
>
>
If the address is non-broadcast, this makes only sense for the CTRL channel (or???). Here, the additional 32bit word(s) may contain download configuration or a command. In principle, all endpoints which do not match the address can simply send the answer packet.
 

Upstream

Line: 110 to 110
 

The idea why this mode is needed is to get more debug information from the system. Nowadays, one has to log on all systems and type "dtuctrl status bla" and than starts certain debug programs. This is anoying and even not possible for the RPC system.
Changed:
<
<
The streaming mode is started with the SQR bit and the start bit pattern in CID. The streaming mode does not know about channels. After that packet has arrived to all hubs and endpoints (an endpoint is also a "hub" with only one port), the handshake mode is stopped and the media is blocked from the point of view of the handhake logic as described above. This means after a short time no answer packets can come (this time can be calculated as a function of hub layers and clock). Now the master has the full control. Broadcast is not allowed in this mode. The request is send to one endpoint with a certain adress as usual. The entpoints which do not match the adress simply do not care and send no answer paket. Only one endpoint sends an answer paket, this is transported via all hubs without checking the content. The bit data is used to store the length of the trailing data words. If 2 ports are sending, of course this is an error condition, and an error paket should be send to the master.
>
>
The streaming mode is started with the SQR bit and the start bit pattern in CID. The streaming mode does not know about channels. After that packet has arrived to all hubs and endpoints (an endpoint is also a "hub" with only one port), the handshake mode is stopped and the media is blocked from the point of view of the handhake logic as described above. This means after a short time no answer packets can come (this time can be calculated as a function of hub layers and clock). Now the master has the full control. Broadcast is not allowed in this mode. The request is send to one endpoint with a certain address as usual. The entpoints which do not match the address simply do not care and send no answer packet. Only one endpoint sends an answer packet, this is transported via all hubs without checking the content. The bit data is used to store the length of the trailing data words. If 2 ports are sending, of course this is an error condition, and an error packet should be send to the master.
 

After the data has been send completely to the master, the master may initiate another request, or restart the handshake mode.
Revision 3
10 Feb 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 20 to 20
 

Header

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Changed:
<
<
Adress Bit Data SRQ CID 1
>
>
1 CID SRQ Bit Data Adress
 
Changed:
<
<
Bits are send in the following order: Bit0->Bit31 (Little-Endian). It appears that the Bits0-3 are needed for fast reaction in handshake mode.
>
>
Bits are send in the following order: Bit31->Bit0 (Big-Endian). It appears that the Bits31-28 are enough for fast reaction in handshake mode. This allows the fast reaction with low latency. The leading "1" is the start tag bit.
 

Meaning of the fields:
Line: 115 to 115
  After the data has been send completely to the master, the master may initiate another request, or restart the handshake mode.
Added:
>
>

Implementation

 
Added:
>
>
For implementation the same base design for the master, the hubs and the DTUs should be used. The master is a hub, but with a special connection to the input. A DTU is a hub which has only the internal endpoint (or brute: Even a hub could be a DTU).

For examples have a look to the NewTriggerBusLinkApplicationNotes
 

Revision 2
10 Feb 2006 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBus"

Overview

Line: 26 to 26
 

Meaning of the fields:
Changed:
<
<

Adress

>
>

Address

 
Changed:
<
<
16 Bit address of the endpoint. The wide address range allow event for defining 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 adresses is that the endpoint knows if the data is ment for itself or can be discarded.
>
>
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 is ment for itself or can be discarded.
 

There are special adresses

  • 0x0000: The master adress
  • 0xffff: The broadcast adress
Changed:
<
<
For downstream the adress is the target, whereas for upstream the adress is the source. Therefore the adress=0x0000 does not make much sense....
>
>
For downstream the address is the target, whereas for upstream the address is the source. Therefore, the address=0x0000 does not make much sense....
 

Bit data

 
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)