Steve et al., Here is an updated "event format" document, based on discussion with Miro and some comments by George Stephans. Basically George pointed out some flaws in my 2-byte event headers and also that the "flex cable" <-> "motherboard" correspondence is NOT necessarily 1-to-1. The flex cable is, of course, fundamental. Also, I realized that it takes 8 bits to specify all of our flex cables, not 7. ============================================================================= It should be noted that this choice is VERY FLEXIBLE as it is determined by PROMs - programmed by Miro in each of the front end controllers. It can be fixed fairly late if desired. Furthermore, no actual board redesign would be needed even if we decide to change it in the year 2002 when the luminosity is higher. The 100 or so PROMs would have to be removed, reprogrammed, and replaced. Many unresolved issues remain: * Basic data format from the DAQ: Is it a ROOT TTree right out of the DAQ? Is it a C++ container class? Is it some VxWorks-specific native binary data format? * how does the data flow in the counting house from DAQ --> online & offline computers? * will we use the FEE electronics as described in the CDR or start over with a new system - eliminating e.g. the pipeline and changing the # of channels / chip? Nevertheless, this should get the discussion started and allow us to specify the raw data classes and make fake raw data etc. It's likely that this will change in some details at least once, but our code will be so modular and brilliantly written that this should cause no problems. My best guess as to the final choice is currently plan B (3 bytes) even though I intuitively prefer plan A (4 bytes) NOTE: If we drop the standard FEE, we can drop the pipeline cell bits and add bits to the ADC and/or channel count in the 3 or 4 byte schemes. ============================================================================= ============================================================================= Plan A: 1 word = 4 bytes Raw data would come in blocks corresponding to an individual flex cable. Each FEC would send one or two sequential blocks of data (1 block/ flex cable attached to that FEC) along the fiber into the VRB. A block would consist of some header words, which would look something like: word 1: event # word 2: flex cable # (0-255) & # of hits and a string of standard data words: M L S S B B 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 | | pipe. | flex cable | chip | channel | | | 0|E| cell | (0-255) | (0-15)| (0-63) |R| 7-bit ADC | | (0-15)| | | | | Unique Channel # (0-262143) | ADC (1+7bit) | bit31 = 0 implies a standard data word = 1 implies a header word and/or some other word in the data stream bit30 = E is an error bit, if E=1, then the data is considered inconsistent by the FEC. pipeline cell = may be needed for cell-to-cell variation corrections should be consistent within a chip or perhaps within a whole flex cable. flex cable = specifies which flex cable (flex cable) the data comes from. each LAYER (in fact each PLANE) should have an integral number of flex cables. chip = specifies which chip. There will be 4-16 chips attached to each flex cable. channel = there should be 64 channels / chip. ADC = 1 range bit + 7 bits of ADC ============================================================================= ============================================================================= Plan B: 1 word = 3 bytes A block would consist of some header words, which would look something like: word 1: event # word 2: flex cable # (0-255) & # of hits and a string of standard data words: M L S S B B 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 | | | pipe. | chip | channel | | | |0|E| cell | (0-15)| (0-63) |R| 7-bit ADC | | | (0-15)| Channel # within | | | | | this flex cable | ADC (1+7bit) | (0-1023) +: fewer bytes in data stream ?: less redundancy -: each hit is not really a stand-alone object within an event, but must be kept in detailed context with it's sibling hits (from the same flex cable). -: annoying word boundary behavior ============================================================================= ============================================================================= Plan C: 1 word = 2 bytes A block would get considerably more complicated here: overall header: word 1: event # word 2: flex cable # (0-255) word 3: total # of hits in that flex cable each chip would have a seperate header: word 1: pipeline cell#, chip # followed by a string of standard data words: M L S S B B 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 | | | channel | | | |0|E| (0-63) |R| 7-bit ADC | | | | | | | | ADC (1+7bit) | +: fewer bytes in data stream ?: less redundancy -: each hit is VERY context dependent. I really dislike this one. -: In the spectrometer, you would have a lot of header words/data word. -: Just fails instantly if we go to a 10-bit ADC or a 128-channel chip. ============================================================================ Mark