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.
|| Data word "application to network"
|| Data word is valid and should be transmitted
|| Stop transfer, the fifo is full
|| Only TRM word, no real transfer
|| see NewTriggerBusNetworkDescr
|| see NewTriggerBusNetworkDescr
|| Release sending of the data
|| 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.
|| Data word "network to application"
|| Which kind of data word: DAT, HDR or TRM
|| Data word is valid and might be read out
|| Read data word
|| Data transfer is running
|| My own address
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.
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.
- 10 Nov 2006