NGC Software Overview for General Detector Controller

1. Software for the New General detector Controller (NGC) Claudio Cumani / Jörg Stegmeier

2. NGC System Overview NGC LLCU (Linux) 2 2 2 2 2 3 3 3 3 3 Down Down Down Down Down Down Down Down NGC LLCU (Linux) AQ AQ [N] - ADC [N] - ADC [N] - ADC [N] - ADC [N] - ADC [N] - ADC [N] - ADC Up Up Up Up Up Up Up FEB Detector 4 - ADC Clock/Bias Driver Up Sequencer Detector Shutter-Ctrl Preamp-Ctrl Detector Detector Detector Detector Detector Detector LLCU = Linux Local Control Unit

3. IWS (Linux) NGC LLCU (Linux) NGC LLCU (Linux) NGC Computing Architecture • Programming Language: • C++ for control processes • Tcl/Tk for GUI and Startup-Scripts Instrument LAN Fast Ethernet/ Gigabit-Ethernet … With the current Linux-PC model we can achieve 200 Mbytes/s sustained input data-rate with co-adding (double correlated read-out)

4. Goals • One software basis for both optical and infrared applications. • Maximum heritage of the strength of both IRACE (infrared predecessor) and FIERA (optical predecessor). • Modular object oriented architecture. • Configurable for all possible system realizations (i.e. number of ADC-modules, number of bias-generators etc.). • Easily programmable clock-pattern generation. • Synchronization with external events. • Version control and automated testing.

5. Data Commands The Processes Instrument Workstation Error-System GUI Log-System Database Config.-Files FITS-Files Control Server Command/ Reply Real-Time Display Data-Acquisition-Process (Pre-Processing, Sorting,…) Acquisition Process (Pre-Processing, Sorting,…) Driver-Interface-Process Device Driver PCI-Bus Interface NGC LLCU Fiber-Optic-Link to NGC Front End

6. NGC-DCS Control Server • The control server can be used as NGC-HW Control Sub-System of the NGC Optical Software (NGCOSW). That is the maximum degree of communality as the same compiled and linked object is used by both applications to access the HW. • It can be configured at Run-Time for the one or the other purpose. • This is also used as general Engineering Tool. Instrument Workstation Error-System GUI Log-System Database Config.-Files FITS-Files Control Server Command/ Reply Infrared Applications

7. Controller Programming • The detector voltages are defined in a Voltage Configuration File in Short-FITS format (xxx.v). • Clock-Pattern blocks can be defined both in ASCII-Format (xxx.clk) and in a Binary Format (xxx.bclk, output of the Graphical Editing Tool BlueWave). The formats can be converted automatically. • Synchronization with external events (e.g. trigger) can be done after any state in any clock-pattern block. • A Sequencer Programming Language has been defined to program the clock-pattern execution. • There may be Multiple Sequencer Instances within one detector front end system.

8. Clock-Pattern Generation • The clock pattern blocks define sequences of clock states, which are stored in a RAM inside the NGC sequencer hardware. • The bits in the RAM define the state of each physical clock line plus: • Some control bits (“wait-for-trigger”, “end-of-pattern”). • The duration of each state (dwell time) is defined in the state itself. • Patterns can be programmed via a graphical tool (Bluewave)  PATRAM Pattern RAM High Pattern RAM Low … + 0: 00000000000001010001000000000000 00000000000000000000000000000000 State 1 … + 1: 00000000000001010001000000000001 00000000000000000000000000000100 State 2 … + 2: 00000000000001010001000000000001 00000000000000000000000000000100 State 3 : … +(n-1): 10000000000001010001000000000000 00000000000000000000000000000000 State n … + n: 00000000000001010001000000000000 00000000000000000000000000000000 State 1 … +(n+1): 00000000000001010001000000000001 00000000000000000000000000000100 State 2 … +(n+2): 00000000000001010001000000000001 00000000000000000000000000000100 State 3 : … +(n+m-1): 10000000000001010001000000000000 00000000000000000000000000000000 State m ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 64 60 56 52 48 44 40 36 32 28 24 20 16 12 8 4 1 Clock Pattern 1 Pattern 2 End of Pattern

9. Sequencer Programming • The sequencer program defines the order of execution of the defined clock pattern blocks. • Simple 7-instruction code RAM. • Easy to be compiled. Address : Pattern-RAM HI Pattern-RAM LO BIT [31..0] BIT [31..0] PATRAM+ 0: PATRAM+ 1: PATRAM+ 2: PATRAM+ 3: PATRAM+ 4: PATRAM+ 5: PATRAM+ 6: PATRAM+ 7: PATRAM+ 8: PATRAM+ 9: PATRAM+10: PATRAM+11: PATRAM+12: PATRAM+13: PATRAM+14: PATRAM+15: PATRAM+16: PATRAM+17: PATRAM+18: : : Clock-Pattern Block 1 Clock-Pattern Block 2 Clock-Pattern Block 3 Clock-Pattern Block 4 Clock-Pattern Block 1 Clock-Pattern Block 2 Clock-Pattern Block 3 Clock-Pattern Block 4 Address : <Instruction> <Rep> <Address> BIT [30..28] [26..11] [10..0] SEQRAM+0: [LOOP] [N] [-] SEQRAM+1: [EXEC] [N] [PATRAM offset] SEQRAM+2: [LOOP] [N] [-] SEQRAM+3: [EXEC] [N] [PATRAM offset] SEQRAM+4: [LOOPEND] [-] [-] SEQRAM+5: [JSR] [-] [SEQRAM offset] SEQRAM+6: [LOOPEND] [-] [-] SEQRAM+7: [EXIT] [-] [-] : : … +offset : [EXEC] [N] [PATRAM offset] … +offset+1: [EXEC] [N] [PATRAM offset] … +offset+2: [RETURN] [-] [-] [LOOP] = 010 [JSR] = 101 [EXEC] = 001 [LOOPINF] = 100 [RETRUN] = 110 [EXIT] = 000 [LOOPEND] = 011

10. Sequencer Program Language • The sequencer program language is fully driven by Setup Parameters (e.g. detector integration time, number of integrations, window parameters, …). • Support of Arithmetic Expression Evaluation (TCL-syntax) to derive any program-loop parameter from the setup parametersand to compute attributes like exposure time estimation and minimum DIT. • Support of Sub-Routines and Include-Files to minimize the code length.

11. External Synchronization • Synchronization points can be inserted at any place in any clock pattern executed by the sequencer program (i.e. set the “wait-for-trigger” bit in the particular state). • When reaching such a point the pattern execution is suspended until the arrival of an external trigger signal.

12. Infrared “Exposures” • Sustained Detector Read-Out and Video Display (display remains active during the “Exposure”). • Sustained Data-Transfer between NGC-LLCU and Instrument Workstation for application specific Post-Processing (slow control loops, e.g. secondary auto-guiding). • Starting an “Exposure” basically means “starting to transfer data to disk”. • Burst-Mode for fast raw data acquisition.

13. Data Acquisiton Processes • Multi-threaded pre-processing framework. • High concurrency (receive, process, transfer to multiple readers, handle command). • One process per read-out mode guarantees maximum independency and maximum safety (cannot corrupt working code, releases all resources). • Template Processes have been developed, which are an easy-to-use and stand-alone tool to visualize NGC raw-data on the real-time display. • Standard acquisition processes for the ESO Standard IR Detectors (HAWAII 1Kx1K, HAWAII2-RG 2Kx2K, SELEX, AQUARIUS, …) are available within the NGC software package. Special setups (e.g. mosaics) may require special software modules.

14. Frame Types • User-definable Frame-Types (Raw-Sample, Mean-Value, Standard-Deviation, Half-Chop-Cycle, Intermediate Results…). • The types can be selected to be generated/stored during an exposure. • Exposure Break-Conditions can be set per “per frame-type”. • Individual SW-Windows per frame-type.

15. Data Interface • FITS-Files • Wait for exposure termination and read the generated FITS-file(s). • Direct connection to Acquisition Process (e.g. real-time display) • Retrieve the binary image data with just minimum header information (dimension, type, sequential number). • Post-Processing Call-Back • The control server calls a user-defined procedure before the frame is stored.

16. Optical vs. IF NGC • Active intervention of the control-server during the exposure is required (application of new voltages in each state “wiping”, “integrating”, “reading”). • “Active” interface to different kinds of shutter controllers (open/close, status check, open/close delays, etc.).

17. Finite State Machine Detector controllers can be modeled as finite state machines i.e.: model of behavior composed of a finite number of states, transitions between those states, and actions

18. State Machine - UML • Designed using UML (Unified Modeling Language) • From this model, code can be automatically generated!

19. wsf Code generation tool: ESO wsf - workstation software framework: • state design (described by a configuration file) • automatic code generation from state design “automatically generated” code handles state transitions, messages, commands, error conditions, etc. (NOT the actions needed to drive an exposure!) • implementation of detector control code (CCD, shutter, etc)

20. Results • Code dimension: • NGC Base-SW: 220000 lines of code (Test SW = 16 %) • NGC IR-SW: 36000 lines of code (Test SW = 12 %) • NGC Optical SW: 82000 lines of code (Test SW = 27 %) • Code dimension for optical NGC ~ code dimensions for FIERA controller • Automatically generated code for optical NGC is 78% of the total optical NGC code (without Test SW) • All NGC software modules are under version control and contain test procedures for automated testing according to the ESO VLT SOFTWARE standards.

21. Goals are achieved…        • One software basis for both optical and infrared applications. • Maximum heritage of the strength of both IRACE (infrared predecessor) and FIERA (optical predecessor). • Modular object oriented architecture. • Configurable for all possible system realizations (i.e. number of ADC-modules, number of bias-generators etc.). • Easily programmable clock-pattern generation. • Synchronization with external events. • Version control and automated testing.