Si Strip FEE Update

1. Si Strip FEE Update V. Cianciolo Silicon Group Meeting 07 September 2004

2. ROCs • For 1st round prototyping implement as four identical “hybrid boards” + one RCC board

3. Hybrids • 4 hybrids get power from and communicate w/ 1 RCC. • Up to 8 RCCs communicate with 1 “FEM” via cable bus. • Boards to arrive next week. • SVX4s and other parts already here. Insert decoupling caps on adapter board here Power Connectors Signal Connectors

4. 4 4 4 4 4 4 4 4 4 4 4 4 Sig Pwr Pwr Sig Pwr Sig Pwr Sig Sig Pwr Pwr Sig RCC Boards • Multiple RCC boards are daisy-chained together to a “FEM” board, so a full system test is possible. • Boards and parts should be here next week RCC RCC RCC RCC RCC RCC FEM

5. “FEMs” • The “FEM” boards are slightly modified versions of our original testboards. • “FEM” is in “”s because it doesn’t communicate with a DCM or even a Minidaq, but directly with a PC via USB and a LABView GUI. • Currently no Pilot Module (more later…). • Boards and parts should be here next week.

6. Communication • We have identified all necessary communication bus signals (SVX4-to-RCC and RCC-to-FEM). • We are in the process of writing all necessary firmware. • With a few exceptions the code is identical to that written and tested on original testboard. • Multi-event buffering • External Level-1 handling • Serial download board selection • Multiple-hybrid readout • Splitting of control functions between RCC and FEM.

7. Note to Chi… • The 0-suppression error handling I’m about to describe is only meant to allow compatibility w/ existing DCMs so we can test system operation as early as next run. • We can modify as necessary based on new-DCM design.

8. Data Formatting - I • The SVX4s buffer up to four events of analog data. • Control signals necessary for this are issued by the FEM upon receipt of L1 signal. • If an event isn’t currently converting (digitizing and being sent to the RCC) the conversion process is begun. • The RCCs collect data from their SVX4s, package it and ship it to the “FEM” upon receipt of ENDDAT token. • Note: there are two FIFOs in the RCC to buffer digitized data so that conversion and readout to the DCM can occur simultaneously. • Since we’re 0-suppressing it is in principle possible to have “too much” data, so that the transfer doesn’t finish. • This would actually indicate a serious noise problem since even at several times expected central AuAu occupancies we will be able to complete conversion . • Completion can be recognized, and a trailer word is added to the data packet only for successful transfer.

9. Data Formatting - II • Upon receipt of L1 the “FEM” constructs header and trailer words per current PHENIX specs. • It broadcasts ENDDAT, collects data from its RCCs, packages it and sends it to the host PC. • It needs a counter or some signal to pre-indicate the fall of ENDDAT so it can calculate trailer words and cleanly end the event.

10. Testing Things • Single ROC (shakeout almost all firmware). • Multiple ROC (need more SVX4s for this). • Tests w/ sensors. • Expect to be ready for these tests by end of the year if $$ available. • Should we test w/ beam during upcoming run? • I’m imagining a telescope outside experiment acceptance. • Needs development of FEM (no “”s) prototype.

11. Next Development Steps • FEM • Change USB interface to “old-style” DCM interface (+ GTM + ARCNet). • Go to “new-style” DCM when defined. • Note: handling 0-suppression overruns with error bits in userwords. • Pilot Module • Need > 16 signals on RCC/FEM bus (or more complicated RCC). • Complicates optical transmission. • Would like to try LVDS communication. • RCC’s drive cable to FEMs outside acceptance. • Pilot becomes simply a connector. • Relatively easy to insert long cable in the FEM/RCC communication chain and test this. • ROC • Need to thin, shrink. • Should incorporate decoupling caps. • May want to move to ASIC format for RCC.