Difference: NewTriggerBusAPI (1 vs. 8)

Revision 8
31 Dec 2009 - Main.JanMichel
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusConcept"

Overview

The main idea of the API (application process interface) is that the user should be able to just read and write data
Changed:
<
<
and should not take care about the functionality of the NewTriggerBus. Moreover, mistakes done by the applications
>
>
and should not take care about the functionality of the DaqNetwork. Moreover, mistakes done by the applications
  should not disturb the operation of the network. Each application is responsible for the integrity of the data stream. This is not part of the API

The main ingredients of the API are 2 fifos: One is used for reading, and one for writing. In addition, there are control lines, which tell
Revision 7
28 Dec 2007 - Main.JanMichel
Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="NewTriggerBusData"
>
>
META TOPICPARENT name="NewTriggerBusConcept"
 

Overview

The main idea of the API (application process interface) is that the user should be able to just read and write data
Line: 125 to 125
 
META FILEATTACHMENT attr="h" comment="api_timing_3.png" date="1163179969" name="api_timing_3.png" path="api_timing_3.png" size="5747" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="api_timing_4.png" date="1163179988" name="api_timing_4.png" path="api_timing_4.png" size="7049" user="IngoFroehlich" version="1.1"
META FILEATTACHMENT attr="h" comment="api_timing_5.png" date="1163180005" name="api_timing_5.png" path="api_timing_5.png" size="6263" user="IngoFroehlich" version="1.1"
Added:
>
>
META TOPICMOVED by="JanMichel" date="1198859818" from="DaqSlowControl.TrbNetAPI" to="DaqSlowControl.NewTriggerBusAPI"
Revision 6
08 Dec 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusData"

Overview

Line: 22 to 22
 
WRITE_IN Data word is valid and should be transmitted
FIFO_FULL_OUT Stop transfer, the fifo is full
SHORT_TRANSFER_IN Only TRM word, no real transfer
Changed:
<
<
DTYPE_IN see NewTriggerBusNetworkDescr
ERROR_PATTERN see NewTriggerBusNetworkDescr
>
>
DTYPE_IN[0...3] see NewTriggerBusNetworkDescr
ERROR_PATTERN[0...31] see NewTriggerBusNetworkDescr
 
SEND_IN Release sending of the data
Changed:
<
<
TARGET_ADDRESS_IN Address of the target (only for active APIs)
>
>
TARGET_ADDRESS_IN[0...15] Address of the target (only for active APIs)
 

Only data words can be transmitted, HDR and TRM words are formed automatically using the DTYPE and ERROR_PATTERN.
Line: 34 to 34
 

Line Decription
DATA_OUT[0...50] Data word "network to application"
Changed:
<
<
TYP_OUT Which kind of data word: DAT, HDR or TRM
>
>
TYP_OUT[0...2] Which kind of data word: DAT, HDR or TRM
 
DATAREADY_OUT Data word is valid and might be read out
READ_IN Read data word
Revision 5
06 Dec 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusData"

Overview

Line: 24 to 24
 
SHORT_TRANSFER_IN Only TRM word, no real transfer
DTYPE_IN see NewTriggerBusNetworkDescr
ERROR_PATTERN see NewTriggerBusNetworkDescr
Added:
>
>
SEND_IN Release sending of the data
TARGET_ADDRESS_IN Address of the target (only for active APIs)
 

Only data words can be transmitted, HDR and TRM words are formed automatically using the DTYPE and ERROR_PATTERN.
Line: 31 to 33
 

Receiver port

Line Decription
Changed:
<
<
DATA_OUT Data word "network to application"
>
>
DATA_OUT[0...50] Data word "network to application"
 
TYP_OUT Which kind of data word: DAT, HDR or TRM
DATAREADY_OUT Data word is valid and might be read out
READ_IN Read data word
Line: 39 to 41
 

Control port

Line Decription
Deleted:
<
<
SEND_IN Release sending of the data
 
RUN_OUT Data transfer is running
MY_ADDRESS_IN My own address
Line: 48 to 49
 

General behaviour

Changed:
<
<
The transfer of data (long transfer) is started with SEND_IN if SHORT_TRANSFER_IN is 0. At the same time, DTYPE_IN has to be valid. The HDR is formed automatically.
>
>
The transfer of data (long transfer) is started with SEND_IN if SHORT_TRANSFER_IN is 0. At the same time, DTYPE_IN and TARGET_ADDRESS_IN have to be valid. The HDR is formed automatically.

If SHORT_TRANSFER_IN is 1, no HDR is formed. This initiates a transfer without any data, only with a TRM signal. If data words, however, have already been written into the fifo (pre-fill), the signal SHORT_TRANSFER_IN is ignored because short transfers are impossible with data words. NB that short transfers are always broadcasts.

For any kind of transfers, DTYPE_IN (for active APIs) and the ERROR_PATTERN have to be valid with the trailing edge of SEND_IN.

Reading is done some time later, after the channels is running (for active APIs). For passive APIs, it is vice versa: First, the application has to read. When reading the TRM word, the channels is running. The answer has to be formed, and written using the above description.

Passive APIs include address filtering: If the target address sent by the master is not matching MY_ADDRESS_IN, the packet will be auto-answered.
 

The active channel

Line: 57 to 67
 

Pre-fill and start

Changed:
<
<
Before the cannel transfer is started, a master might pre-fill the fifo up to the point where the fifo
>
>
Before the cannel transfer is started, the master might pre-fill the fifo up to the point where the fifo
  is full in order to have a faster reaction. This is an optional feature. It is also possible to start the channel first, and then fill the data words.

api_timing_1.png
Changed:
<
<
Early pre-fill and the starting phase of the channel master. This also shows
>
>
Early pre-fill and the startup phase of the channel master. This also shows
  the behaviour of a released transfer: During the FIFO_FULL the master releases the writing, and after the FIFO_FULL is pulled down it takes 2 clock cycles after the new data word can be written
Line: 102 to 112
 

End and release

The end of the story: The TRM word. After this has been read, the
Changed:
<
<
RUN_OUT will be released and a new transfer may by initialized.
>
>
RUN_OUT will be released and a new transfer might by initialized.
 

api_timing_5.png
Revision 4
05 Dec 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusData"

Overview

Changed:
<
<
The main idea of the API is that the user should be able to just read and write data and should not take case so much about the functionality of the NewTriggerBus. Moreover, mistakes done by the applications should not disturb the operation of the network (but of course you can mess up your own data stream)
>
>
The main idea of the API (application process interface) is that the user should be able to just read and write data and should not take care about the functionality of the NewTriggerBus. Moreover, mistakes done by the applications should not disturb the operation of the network. Each application is responsible for the integrity of the data stream. This is not part of the API
 
Changed:
<
<

Contents

>
>
The main ingredients of the API are 2 fifos: One is used for reading, and one for writing. In addition, there are control lines, which tell the application if a channel is available for transmission, to set the address of the endpoint, start and stop transfers etc.
 
Changed:
<
<
The main ingredients of the API are 2 fifos: One is used for reading, and one for writing. In addition, there are control lines, which tells the application if a channel is available or not, to set the address of the endpoint, start and stop the own transfer etc.
>
>
In addition, one has to know that there might be up to 2 APIs per channel: One active and one passive API. The active, as the name indicates, can initiate a transfer as a master, and has to wait for the answer of one or more endpoints (like for the MU, CTU, Monitor, Messaging). The passive API has to wait until it is addressed (IPU, DTU, slow control). The passive API can be in streaming mode: This means that first the networks is waiting for all answers from the endpoint, but before forwarding the data stream to the uplink (the CTS), it will be pre-processed by a streaming API (which is sitting somehow in the middle, like the TRB with an addon, ot the intelligent node)
 
Changed:
<
<
In addition, one has to know that we have for each channel 2 APIs: One active and one passive API. The active, as the name indicates, may initiate a transfer as a master, and has to wait for the answer of one or more endpoints (MU, CTU, Monitor, Messaging). The passive API has to wait until it is addressed (IPU, DTU, slow control)

So in total, and andpoint with one address might have up to 32 APIs, but in normal cases this number should be much less. This document describes the features of the API, the entity will be descibed somewhere else.
>
>
So in total, any endpoint with one dedicated address might have up to 32 APIs, but in normal cases this number should be much lower.
 

Signal description

Transmitter port

Line Decription
Changed:
<
<
DATA_IN Data word "application to network"
>
>
DATA_IN[0...50] Data word "application to network"
 
WRITE_IN Data word is valid and should be transmitted
FIFO_FULL_OUT Stop transfer, the fifo is full
Added:
>
>
SHORT_TRANSFER_IN Only TRM word, no real transfer
DTYPE_IN see NewTriggerBusNetworkDescr
ERROR_PATTERN see NewTriggerBusNetworkDescr
 
Changed:
<
<
Only data word can be transmitted, HDR and TRM words are formed automatically.
>
>
Only data words can be transmitted, HDR and TRM words are formed automatically using the DTYPE and ERROR_PATTERN.
 

Receiver port

Line Decription
DATA_OUT Data word "network to application"
TYP_OUT Which kind of data word: DAT, HDR or TRM
Changed:
<
<
DATAREADY_OUT Data word is valid and may be read
>
>
DATAREADY_OUT Data word is valid and might be read out
 
READ_IN Read data word

Control port

Line: 41 to 41
 
Line Decription
SEND_IN Release sending of the data
RUN_OUT Data transfer is running
Added:
>
>
MY_ADDRESS_IN My own address
 

Functional description

Added:
>
>

General behaviour

The transfer of data (long transfer) is started with SEND_IN if SHORT_TRANSFER_IN is 0. At the same time, DTYPE_IN has to be valid. The HDR is formed automatically.
 
Deleted:
<
<

Detailed Behaviour

 

The active channel

Revision 3
04 Dec 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusData"
Changed:
<
<
This page is preliminary
>
>

Overview

 

The main idea of the API is that the user should be able to just read and write data and should not take case so much about the functionality of the NewTriggerBus. Moreover, mistakes done by the applications
Line: 42 to 42
 
SEND_IN Release sending of the data
RUN_OUT Data transfer is running
Added:
>
>

Functional description

 
Changed:
<
<

Behaviour

>
>

Detailed Behaviour

 

The active channel

Revision 2
13 Nov 2006 - Main.IngoFroehlich
Line: 1 to 1
 
META TOPICPARENT name="NewTriggerBusData"
Added:
>
>
This page is preliminary

The main idea of the API is that the user should be able to just read and write data and should not take case so much about the functionality of the NewTriggerBus. Moreover, mistakes done by the applications should not disturb the operation of the network (but of course you can mess up your own data stream)

Contents

The main ingredients of the API are 2 fifos: One is used for reading, and one for writing. In addition, there are control lines, which tells the application if a channel is available or not, to set the address of the endpoint, start and stop the own transfer etc.

In addition, one has to know that we have for each channel 2 APIs: One active and one passive API. The active, as the name indicates, may initiate a transfer as a master, and has to wait for the answer of one or more endpoints (MU, CTU, Monitor, Messaging). The passive API has to wait until it is addressed (IPU, DTU, slow control)

So in total, and andpoint with one address might have up to 32 APIs, but in normal cases this number should be much less. This document describes the features of the API, the entity will be descibed somewhere else.

Signal description

Transmitter port

Line Decription
DATA_IN Data word "application to network"
WRITE_IN Data word is valid and should be transmitted
FIFO_FULL_OUT Stop transfer, the fifo is full

Only data word can be transmitted, HDR and TRM words are formed automatically.

Receiver port

Line Decription
DATA_OUT Data word "network to application"
TYP_OUT Which kind of data word: DAT, HDR or TRM
DATAREADY_OUT Data word is valid and may be read
READ_IN Read data word

Control port

Line Decription
SEND_IN Release sending of the data
RUN_OUT Data transfer is running

Behaviour

 

The active channel

This is how a CTU or the MU would use the API

Pre-fill and start

Added:
>
>
Before the cannel transfer is started, a master might pre-fill the fifo up to the point where the fifo is full in order to have a faster reaction. This is an optional feature. It is also possible to start the channel first, and then fill the data words.
  api_timing_1.png

Early pre-fill and the starting phase of the channel master. This also shows
Line: 31 to 80
  RUN_OUT will stay high. During this stage, all writes are ignored. Now it is time to wait for the answer!
Added:
>
>
If the application should only transmit a TRM word without any data, the SEND_IN has to be raised for 1 clock cycle without any data transfer.
 

Read

 
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)