Overview

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 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 the application if a channel is available for transmission, to set the address of the endpoint, start and stop transfers 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)

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
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
SHORT_TRANSFER_IN	Only TRM word, no real transfer
DTYPE_IN[0...3]	see NewTriggerBusNetworkDescr
ERROR_PATTERN[0...31]	see NewTriggerBusNetworkDescr
SEND_IN	Release sending of the data
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.

Receiver port

Line	Decription
DATA_OUT[0...50]	Data word "network to application"
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

Control port

Line	Decription
RUN_OUT	Data transfer is running
MY_ADDRESS_IN	My own address

Functional description

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 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

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

Pre-fill and start

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.

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

The running channel

Continous transfer if data words are always in the pipeline. Care has to be taken if no new data word can be provided, then WRITE_IN has to be pulled down after the last valid word.

End of run

The last words. SEND_IN is released, RUN_OUT will stay high. During this stage, all writes are ignored. Now it is time to wait for the answer!

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

A typical read cycle after the answer arrives from the slaves. Same is true like for the writing: READ_IN may stay high to save 1 clock cycle. But the target must be able to read the offered word, otherwise it is lost.

End and release

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

-- IngoFroehlich - 10 Nov 2006