Sum processor (JemSum)
Jet processor (JemJet)
Input FPGAs (JemInputFPGA)
- Input (JemInput, only available in software)
  - Input channels (JemInputChannels)

The SubmoduleLists contain pointers to the submodules which are represented by an own class. The input channels are represented by an own class, too, but there is an inversion in the order (descending order instead of the commonly used ascending order). To prevent confusion, those lists and vectors are private and should be accessed via appropriate interface methods only. This is to be preferred within class member functions, too.

The class Jem has several methods to retrieve register contents in a vector for all channels, especially for the input channels. This prevents users from having to know every detail on the phyiscal distribution of the input channels on four input FPGAs.

There is also the possibility to read out the serial numbers of the JEM mainboard. This is described in the release notes of 2009-05-07 further down on this page. Physically, the readout is done via the sum processor, but those methods are gathered here where people would expect them to be. (Infact the JemSum methods are used). There is also the possibility to read out the version of each CPLD (non volatile firmware) and each FPGA (volatile firmware).

Jemjet

In this class the registers of the jet processor FPGA are made available.

JemSum

In this class the registers of the sum processor FPGA are made available. There is some additional functionality located in the sum processor. The readout of the three serial number chips of the JEM is done here. The class Jem has also a method using and explaining them.

Furthermore, the sum FPGA is also used to communicate with the TTCrx clock chip. This allows to set and read the TTCrx clock deskew values. The protocol for this communication is described in the code as well as in the FAQ below.

JemInputFPGA

In this class the registers of the jem input FPGAs are made available. It also contains a SubmoduleList filled with one JemInput. In the input FPGA register space, there are many block registers, meaning two bundled registers (e.g. containing the phases or masks) of 12 input channels each. The channelwise registers can be accessed via the JemInputChannels class, there is a method here to retrieve a pointer to the appropriate channel.

JemInput

This is a class which contains a SubmoduleList of JemInputChannels (descending order!). I am not really sure why this class is necessary, I guess it exists for historical reasons.

JemInputChannels

In this class the single (channelwise) registers of the input channels are made available. Some registers like phase, delay and all sort of masks are only available via block registers in JemInputFPGA.

Release notes / change log

2009-05-27

All methods in defsL1Calo/JemDefs.h that returned values for Jem Revision 0 (with 11 FPGAs) have a suffix "JemRev0" appended. dbL1Calo and jemServices were also updated.

2009-05-19

Finished JEM status panel in TDAQ (from a jemServices point of view, need to add a range check for boolean in panel itself) Need to remove readParity() etc. methods after adapting HDMC input channel status panel

Caused HDMC input channel status panel (LLPEstatus) to show incorrect sums of parity and lockloss errors (always zero) -> Need to make HDMC use the new interfaces and methods (This particular panel might have other problems, haven't made full tests before it is fully adapted to the new methods and uses interfaces to access JEM objects).

Introduced methods to access input channels, input fpgas, sum and jet

getInputChanPtr
getInputFpgaPtr
getSumPtr
getJetPtr

(jemServices doesn't use them widely yet, need to enforce this and make public SubmoduleLists private afterwards)

2009-05-15

SubmoduleList uses a descending input channel order (caused by the order of the parts). Decided to leave this untouched, but hide it completely behind interfaces that only work on a ascending (0..23, channel index = channel number) ordered vector. First step is to make jemServices use interfaces consequently,second one is to make all those SubmoduleLists private and provide interfaces with explicit names for packages that use and depend on the descending order

TDAQ status panel: modified to use standard methods for register access and convert those vectors with absolute channel numbering (0..87) to TDAQ mapping via well defined methods exported to defsL1Calo/JemDefs. The goal is to remove all local mappings in method and always use the standard absolute channel mapping within jemServices and call explicit conversion methods if exchanging data with TDAQ or HDMC. Careful, TDAQ and HDMC use a different mapping within one phi bin (h0,h1,h2,h3,e0,e1,e2,e3 vs e0,h0,e1,h1,e2,h2,e3,h3 bit 0 to bit 7).

2009-05-11

Removed old jemServices internal phase detection (also removed jemTests/JemKicker and the phase detection buttons from allModules (HDMC))

Firmware version checking included

Error with crate and jem number if invalid F/W is loaded
Warning if valid F/W, which is not flagged as production F/W, is loaded

Added gets to access input channel registers (those placed in channel adress space and those placed in fpga space) at common place in JemInputFPGA. Also added gets in Jem.xx using the gets of input fpgas to have only one method accessing the register classes directly

Introduced new methods to set and get the TTCrx clock deskew Changes:

ready status (can only set or get a setting if the finite state machine (FSM) is ready) Loop: waiting for rdy status, reset FSM if fails, try again in loop
read back of deskew if set is called -> compare values Throws an exception if any operation fails that prevents the setting or reading of the deskew value

2009-05-08: Enforced forward declaration of jemServices classes and moved types to file JemServicesTypes.h

Moved all "structs" and "enums" to JemServicesTypes.h Put them in a namespace [ClassName]Defs, JemCxxDefs is the only exception to prevent confusion with defsL1Calo/JemDefs

Started with exception handling (JemExceptions.h)

2009-05-07: Corrected names and registers for F/W version numbers and S/N

All register names are the HDMC display names if nothing else is explicitly stated.

JEM board_VERSION -> CPLD_VME_FW_VERSION class name BoardID -> CpldVmeFwVersion This is the version number of the CPLD mainly containing the VME interface

JTAG-CPLD version not implemented yet Register: address space: 0x2000 relative to JEM base Register. address 0x0 relative to space 0x2000 Lower 8 bits: first 6 bits "dones", 2 unused Upper 8 bits: F/W version number Needs some checking from Uli, then it needs to be implemented

JEM Board_MOD_IDB -> removed The S/N is only readable via the Sum FPGA since years but it still remained

JEM Board_MOD_IDA -> JEM_TYPE_ID class name BoardModIDA -> JemTypeId This is a value which represents the module type. JEM's id is 0x100E. CPM and CMM use the same system (register named IDA), PPM has a KIP identifier

There are 3 S/N chips on the JEM, one on the mainboard, one on the control module and one on the glink module. Each needs a FPGA for readout (some intelligence necessary), this is done via the Sum FPGA SUM Main_SerialNo: First 16 bit of the JEM mainboard S/N, (32 bit in total, first 16 bit are unique) SUM Control_SerialNo: First 16 bit (as above), Control module S/N (e.g. contains CAN functionality) SUM Glink_SerialNo: First 16 bit (as above), Glink module S/N

SUM_VERSION_REG -> SUM_FW_VERSION Class name SumProcID -> SumFwVersion

S/N and F/W version number overview for whole JEM via Jem::getJemVersionOverview

2009-05-05

Corrected register size from 8 to 6 bits of JEM.ROCLatR (class name) / Read_Request_Delay_REG (HDMC display name). NB: If an empty (every entry is zero) ReadoutConfig COOL folder has been loaded, the value 0x40 will be derived for the register and cause an error message. If a valid folder with an appropriate baseline pointer setting is loaded, a valid register value will be used.

A little FAQ and notes on specialities in this package

Overview on input FPGA mask registers

In the current production firmware, there are three kind of major masks:

DAQ mask (dmask)
RTDP mask (mask)
Energy mask (emask)

The DAQ mask (dmask) determines whether the contents of a certain channel are sent to the Data AQuisition (DAQ). In case of a set mask, only zeroes are sent. This dmask is completely indepent of both other masks.

The RTDP mask (mask) determines whether the contents of a certain channel are sent into the Real Time Data Path (RTDP), meaning sent to the Common Merger Modules (CMM). The differentiation between dmask and mask was introduced to allow the readout of corrupt data from a certain channel during a run without corrupting the data taken (e.g. making wrong trigger decisions on corrupt data). The mask can be called a first level mask in the sense that a set RTDP mask zeroes the data in the RTDP and a second level mask like the emask can't undo this.

The energy mask (emask) determines whether a channel's energy is used in the algorithms of the sum processor. This is necessary (and applied in S/W) for certain channels of the forward JEMs. Overlap suppression for all JEMs is currently applied in the F/W (2009-05-05). This prevents double counting. If a RTDP mask is set for a certain channel, it's data is always zeroed independent of the emask (see RTDP mask). Another thing to keep in mind is that this mask only makes sense if the em and had partner are masked at the same time since data is sent this way in the sum tree of the RTDP. Order should be em had, em had respectively channel number 0 1, 2 3 etc. NB: The current behaviour of the F/W might not lead to zeroing data if only one mask is set.

Error messages

Many error message are still send to std::cout or std::cerr and are therefore not visible within TDAQ. If you search for a "quiet" bug, try to run a console application (e.g. get JEM access via jemTests/JemTools.h and call configure).

Protocol for TTCrx deskew setting/reading

There is a special protocol for reading and setting the deskew values. Deskew values need to be converted first, there is a table in the "TTCrx reference manual" on p. 56ff. Deskew dec::120 corresponds to dec::6 (register content) The sum fpga contains the interface to the TTCrx module. There are two registers, one TTC status and one TTC control register.

How to read the set deskew values:

Open the control register
Uncheck write bit
Set "TTCrx reg no" to 0 (Deskew 1) or 1 (Deskew 2)
Click on write button
Click on read button in status reg
Convert via manual this value (careful per default in hex) to a "standard" deskew value

Writing is done via the control register, set the write bit, the register number for deskew 1/2 and the value in the data field. You need to convert standard deskew values, too, via the manual.

How to reset input channel lockloss and/or parity error counter

This is done via the pulse register in the FPGA register address space

Why do I see strange errors in FPGA block registers in FPGA "T" (registers for 12 channels each)

The same registers are used for all block registers in all FPGAs. FPGA T has only 16 used channels, but 24 do physically exist. The current solution in the firmware is to the same for all FPGAs, too, so input channels 88 to 95 can display errors in those block registers in HDMC. In jemServices every FPGA is treated equally, but there is a check at the end: if FPGA module name is "T", the last 8 channels are removed from the vector (at the end of the procedure). Therefore this behaviour is well defined but not that intuitive in HDMC. This is another reason why one should access registers via defined interfaces instead of raw access in the online S/W.

Why do I see strange errors in FPGA block registers in FPGA "T" (registers for 12 channels each)

For translating ErrorCodes and JEM input channels, I have added tools to the package calibTools: ErrorCodeTranslator and JemChanTranslator.

Generated on 16-May-2012 at 04:15:16