LOFAR2.0 Newsletter November 2019

LOFAR2.0 Station and Timing Distributor passes PDR

After a period of intense collaboration, the LOFAR2.0 team produced Stage One Station and Timing Distributor preliminary designs and associated documentation, and provided it to the PDR panel for review. The documentation was aimed at giving evidence that the envisioned capability enhancements can be achieved technically, and that the upgrade can be implemented within the provided boundary conditions. At the September 25-26 review meeting, the panel deemed the technical approach feasible. It also agreed that the proposed re-use of hardware designs and code is an efficient use of development time. The panel also endorses the new systems engineering approach, and encourages the team to ‘streamline’ the big number (hundreds) of requirements, and to continue detailing the identified interface definitions. Thanks to the panel for providing valuable feedback to the team, and success to the team with processing the review results and detailing schedule and cost, and with setting-up and starting the detailed design phase.

Firmware

The LOFAR2.0 Station Firmware team consists of Eric Kooistra, Jonathan Hargreaves and Pieter Donker. We work on the FPGA firmware that will run on the UniBoard2s that will be used in the Station Digital Processing (SDP). Last 2 months Eric has defined how the data from the antennas will be timestamped and aligned within the SDP. Jonathan has fixed a bug that caused bit errors on the 10GbE links of the UniBoard2, by using proper synthesis timing constraints. These 10GbE links are important because they will be used abundantly within SDP and also for output to CEP. Pieter has successfully ported our existing VHDL firmware code and RadioHDL workflow from SVN to GIT, so now the Firmware team is also using GIT for version control.

RCU

For RCU2, we now know ”what” we want to design and “how” we are going to design it: Starting from the station (level 2) requirements, the driving requirements for the whole RCU2 system (level 3) and for the RCU2 boards (level 4) has been derived. For the analogue design, a Rapid Prototyping approach is being used by INAF, where accurate simulation models are used to predict the behavior of the RCU2. This make it possible to obtain a first prototype already “compliant” to the required specifications. The simulation environment has been setup and tested by comparing the simulated performance to the measured performance of the LOFAR1 RCU, shown for example by the first graph. The performance of the LOFAR1 RCU has also be compared to the requirement of RCU2, shown for example by the second graph. The parts that can be re-used and those that needs to be improved or redesigned has been identified.

Different options and trade-offs for the analogue chain, digitisation, control and power of the RCU2 has been compared in a preliminary design document and the best options has been selected. We have now started with the ‘messy’ details of the detail design and hope to have a ‘RCU2’ to report in one of the next newsletters!

An ADC evaluation board has been made which can be connected to UniBoard2. In this way the ADC can be evaluated as well as the JESD204B ADC interface implemented on the FPGA. In the figures below the evaluation board connected to the UniBoard2 and the first captured samples are shown.

High Band Antenna

HBA development is well underway. The hardware requirements were derived from the top-level requirements. We had the first delta-DDR, where the Beamformer unit and ASIC were reviewed by internal and external experts. It gave valuable feedback, which will make the final design better. The new frontend LNA boards for the first prototype were produced by Albert van Duin on the new SMT machine. All boards work! The Beamformer boards, that have been jointly developed by the RF-team at Nancay, are planned to be produced beginning of December. Also the first RF setups with power and control are appearing in the radio EMC – room, where we will test part of the first HBA prototype tile. Great job HBA-team!

Recently it has been decided to reduce the scope of the LOFAR2.0 system. From now on the sub-system “Science Data Delivery System” (SDDS) is removed from LOFAR2.0. The main purpose of the SDDS was to archive data products and to deliver science data to astronomical researchers. The functionality of this sub-system is transfered to the Science Data Center (SDC). Therefore, also the requirements associated with that functionality will be handed over. With that, the top-level architecture is changed to Figure 1. LOFAR2.0 will evolve to a data taking machine, delivering data products to the SDC. Within, the SDC the data is further processed towards scientific data. A memo has been written to sharpen the interface in between LOFAR2.0 and SDC and a change request will be submitted to formalize the change.

Note, that the scope of SDC is broader then offering exclusively services on LOFAR data. Also, data from APERTIF, SKA and possible other facilities can be serviced via SDC.

The key drivers to make this split are:

1. Disentangle LOFAR and the SDC to make them more independent and therefore reduce overall complexity.
2. The dynamics of both differ significantly: while LOFAR takes data once and transforms that into data products and as an instrument has a limited life-time, the users of the SDC can re-process data products over and over again to retrieve all sorts of scientific relevant information from the same data set for a long time. Successful archives have proven that more science is retrieved from the data in the archive then the original purpose to take the data.
3. The operational organisation of both differ significantly. Both, LOFAR2.0 and SDC are key ingredients of the ASTRON strategy in the coming years.

It appears that functional decomposition of the LOFAR2.0 system and its subsystems is a very helpful exercise in the systems engineering effort. The functional decomposition refers to the process of defining a system in a number of functional terms representing the required functionality of the system from the use cases, science requirements and other stakeholder requirements, followed by defining lower-level functions and sequencing relationships from these high-level system functions. The idea is to try to divide the system in a set of atomic functions. The derived functions can be translated directly into functional requirements and, if necessary, performance requirements can be added.

The implementation of Polarion is such that functions are linked to products in the Product Breakdown Structure (i.e. a physical decomposition of the system) at one side and at the other side requirements are linked to the products. By doing this it can be easily checked whether all functions are linked to one or more products and vice versa, and whether functions are covered by functional and performance requirements. This is a helpful tool in determining the completeness of a set of requirements.

Telescope Manager (TM) is working hard to explore and define its boundaries. The move of the Science Data Delivery System (SDDS) to the Science Data Centre (SDC) as described above obviously has a high impact on TM. Also the uncertainties in the LOFAR Efficiency Improvement project are complicating a clear definition of TM. For the moment, the TM work therefore focuses on the Monitoring and Control part of Station and TM.

On November 12 LOFAR4SW had a Delta-DDR at ASTRON. The review assessed the requirements on the beamformer unit and ASIC, connecting the science use case requirements all the way down to functions on hardware level. The review panel was chaired by Hans van der Marel and was composed by Klaas Visser, David Prinsloo, Andre Gunst, Stephane Bosse, and Albert Jann Boonstra. This review was a good preparation for the DDR planned early in 2020.

The project organised a targeted end users meeting during the last European Space Weather Week in Liège (November 18-22). It was a very fruitful meeting, where we presented the project and had the opportunity to exchange with interested potential users. There was a lot of interest and feedback from the audience in both sessions, extending beyond the allocated time. The end users were requested to fill out a questionnaire with details about the various space weather data products that LOFAR4SW could potentially deliver. Although a more extended end users meeting is planned for May 2020 in Poland, the Space Weather week provided a good opportunity to obtain feedback from the end users already now.

The COBALT2.0 GPU cluster has been operational since the summer and is performing well. To exploit the boost in computing power that this new cluster provides, the science team is finalizing the plans for implementing the LOFAR Mega Mode. This new operational mode will enable COBALT2.0 to produce different data products, both for imaging and beamforming, from the same station input, greatly increasing the efficiency of LOFAR. As part of this work, COBALT2.0 will also be adapted to enable the simultaneous LBA and HBA imaging observations for the LOFAR2.0 DUPLLO survey.