Jurgen Engelfried October 12, 1993 Specification for CROS and RMH Readout Controllers ================================================== 1. Introduction --------------- The controller have to read out the equipments, and finally we need the data on the RS485/DART (diff. TTL) cables to be transported to the DM115/DC2 in the VME crate. The following conditions have to be meet, given by the overall trigger and data aquisition system: 1) Online deadtime <30usec. The frontend modules have to accept a new event in this time. 2) Mean readout time per event <100usec. With buffers in readout controllers we can stretch the readout time by a factor of 3. Each stream and/or each readout controller should produce a header (or trailer) with an identifier, a wordcount and an event number. The event number will be given to the controllers as a 4bit number on RS485, together with a strobe signal which is the readout trigger. 2. Expected Hits and Readout Time --------------------------------- CROS: DPWC: 4736 channels, 14 planes. with 7 tracks ==> 100 Hits TRD : 3072 channels, 6 planes. with 4 tracks ==> 24 Hits RICH: 2848 channels, 15 hits/ring. with 6 tracks ==> 100 Hits -------- 224 Hits RMH: PWC : 7680 channels, 12 planes. with 10 tracks ==> 120 Hits LPWC: 2628 channels, 7 planes. with 4 tracks ==> 28 Hits -------- 148 Hits Readout time: 5 Hits/usec ==> 44.8usec for CROS, 29.6usec for RMH With this, CROS is over and RMH is near the 30usec boundary. This means, we have to forsee to read out the systems with more than one readout controller (for CROS: split wire chambers and RICH/TRD). 3. Different Possibilities -------------------------- To fulfill all the requirements, we have the following possibilities: 1) The Readout Controller (successor of BIS.45056 and RMH equivalent) is reading out and converting directly to RS485/DART without any buffer in 16bit words. We need 2 streams for each CROS and RMH to have a readout time <30usec. The Controllers have to receive the event number and put it in a header or trailer. If the number of 16bit words is odd, the controller has to send an additional dummy word. After all data of one event are send, the Controller has to issue a EOR (end-of-record) signal. 2) The Readout controller is reading out and converting directly in ECLine (FERA compatible). The data will be pushed into a DYC+, which has a 16kByte multi-event buffer, can receive the event number, sends the EOR and packs the data in 32bit words. Several DYC+s can be chained to build one stream. If the DYC+ takes care of an odd number of 16bit words is not yet known. 3) The Controller has to combine the functions described in 1) and 2) by itself. 4. Proposal ----------- I propose the build the Controller with ECL output (possibilty 2), pushing data in a DYC+, which will take care of buffering and event number handling. The controller has only to receive a readout trigger and has to provide a "BUSY" signal during the actual readout. This system has the following advantages: 1) The DYC+ is used by several DART experiments. A prototyp will be tested this month. 2) The DYC+ is cheap ($100). 3) We might use the DYC+ if we have to read out more than 40 CAMAC words for each event. 4) The controllers itself are simpler. 5) We can combine all CROS and RMH into one stream. The specifications for the RS485/DART, the ECLine input for the DC2, and the event number are given in the appendix.