Hi to all, I am attaching a trigger board schematic together with some explanations. Please read carefully because our decisions (especially on what counters we need) depend on what can this board do for us at 10MHz. First of all the MB (memory board) is not explained in full detail here because I dont have enough info yet. - Digitized data come to the MB at 10MHz and are calibrated (16 channels per MB) - Then they are pushed in a FIFO. - In parallel a sum (10bits) of all 16 channels is performed and the channel with the maximum energy (4 bits) is found (Esum and Emax). - The Esum,Emax are sent to the TB (Trig. Board) via a private backplane. - The TB which has a 60MHz clock passes the Esum and Emax to its Logic Unit and looks if any Trigger Type (TT) is satisfied. If YES an ACCEPT (ACC) is sent to the MB so the first event in FIFO is written to the Dual Port Memory buffer. If NO then the event is pushed deeper in FIFO waiting for the arrival of a GFLT (about 5.6ms later) before it is discarded. If a GFLT ACC comes the event in the bottom of the FIFO is written in the DP memory. (if the memory is full then the event could be still written on top of a triggered event--this is a potential problem). - The MB event banks are read by VME block transfers. 100 events correspond to 1kVMEwords or 4kBytes size. If we assume 32bit data transfer, this requires 1000 VME transfers. For 64bit it requires 500. The time required for VME to read a word (4bytes) is 0.2 microsec. I dont know yet what the time is per block transfer (probably we need the final MB to determine this). - The TB keeps a number of accumulating counters per run. These counters (every subcomponent can decide what it needs to count) can be stored in TB private memory which is 64 bit wide. Since the TB clock runs at 60MHz only (6x64 bits) size of counters can be read out by the VME before the next event arrives (after 96nsec =1/10MHz). This is a clear limitation in the number of counters we can store. If we assume that the 3 components need 4 counters each of 32 bits then we hit the limit! The TB can also pass the Esum to its memories and subsequently to the PPC (powerPC) SRAM. - The solution to the problem above is to keep the counters running until a full 100 event bank is read out from the MB and append the counter info as a "special event" at the end of the 100event bank. This allows us to store a sufficient number of counters including perhaps per bunch counters (for example dead time per bunch). - The triggered events keep on being written to the MB memory until it is full. Then an interrupt is send to the VME PPC to start reading them out (RO). - At the same time the first memory is RO the triggered events are now written in the second MB memory. If this memory gets filled before the RO of the first memory is finished then a dead time is introduced to the system. In this case a signal is issued in the private backplane to the TB and the dead time counter starts counting. One could think of keeping such counter per bunch crossing. These counters should perhaps be of 32-64 bits since they are accumulating counts. - The TB currently has an unused auxilliary logic plus a dual port SDRAM. One can think of using these for extra calculations/counters. OUR TRIGGER TYPES (after discussion with Jurek A.) ----------------------------------------- TT1: [c1 < Esum1