In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.
Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.
Permanent link for public information only:
Permanent link for all public and protected information:
The Zynq UltraScale+™ MPSoC (Multi-Processing System on Chip) is the second generation of SoC following the 28nm Zynq- 7000 All Programmable SoC. Xilinx has developed the architecture based on the most advanced TSMC 16nm FinFET process technology for high performance and power efficiency.
The Zynq UltraScale+ MPSoC boasts over 6000 interconnects linking the processing system and programmable logic blocks. At the heart of the processing-system is the 64-bit ARM® Cortex®-A53, available in dual or quad core options, providing greater than 2x performance over its Cortex®-A9 predecessor in the Zynq-7000. It also integrates a dual core ARM Cortex®-R5 real-time processor for real time response and low latency for safety critical and high reliability applications. The Zynq UltraScale+ MPSoC enables the highest levels of security and ensures things like information assurance, anti-tamper and multiple layers of encryption and authentication during boot-up.
The Zynq UltraScale+ MPSoC can interface with high speed DDR4 and LPDDR4 SDRAM memories. It incorporates high performance peripherals (PCIe up to Gen 3.0, USB 3.0, Display Port, 100G Ethernet MAC) and can be available on platforms with H.265 video codec unit, high end Analog-to-Digital/Digital-to-Analog Converters (RFSoC families) or HBM memories.
As an ARM-based processor, the software ecosystem includes a broad OS environment, hypervisors, open source software, commercial solutions and safety certifiable solutions.
All these new architectural elements are coupled with the Vivado® Design Suite and the free Software Development Kit (SDK). Moreover and for several years, XILINX has been addressing the design challenges of complex system development with Vivado High Level Synthesis (HLS) and SDx environments, giving the ability to take C/C++/OpenCL straight to hardware without RTL coding.
Finally, XILINX announced a new class of devices in 7nm process technology named ACAP (Adaptive Compute Acceleration Platform) and a family: Versal. The devices will combine acceleration, adaptable and intelligent engines with programmable logic and an ARM processing subsystem.
This presentation will discuss the families of Intel SoC FPGA devices from 28nm Cyclone V SoC through to the newly-announced 10nm Agilex SoCs. Starting off with a discussion of the benefits of integrating processor and FPGA onto a single die, detail will be given as to use cases for their application and technical differences and evolutions between the family members and their evolution over time.
The presentation will move on to discuss the embedded processor families used and the software operating systems that run on these devices, and their uses along with the long-term support strategy for both hardware and software.
The debug infrastructure required to co-debug FPGA programmable hardware and software will also be presented, illustrating how FPGA + processor solutions can be debugged in on debugging environment, with the technical detail as to how this works.
Tools required for the build and integration of the devices will be discussed along with PC requirements to build the projects. The presentation will focus on technical detail and architectural comparisons between FPGA family members.
Kris Chaplin (Intel)
User question, discussions, and demonstrations
The Muon to Central Trigger Processor Interface (MUCTPI) is a key element of the first level, hardware trigger of the ATLAS experiment. It is being upgraded for the next run of the Large Hadron Collider (LHC) at CERN. The new MUCTPI is implemented as a single ATCA blade with high-end processing FPGAs for the low-latency, parallel trigger processing. A Xilinx Zynq System-on-Chip (SoC) consisting of a programmable logic part and a processor part is used for control. The processor part of the SoC is based on ARM processor cores and runs Linux. Several options for building the operating system, the root file system and the application software including an ATLAS run control application, as well as interfacing to the run control system in a controlled technical network have been investigated.
CERN Radiation Protection is developing a state-of-the-art radiation monitor, CROME (CERN RadiatiOn Monitoring Electronics), measuring dose rates from 50nSv/h over a range of 9 decades without auto-scaling. Converted into electrical current, the frontend electronics accurately (+-1%) measures from 1fA to 1uA.
CROME’s main purpose is to measure radiation across CERN sites to protect persons by triggering interlock signals based on doses calculations and conﬁgurable conditions.
As a safety device, CROME is subject to strict constraints to fulﬁl SIL2 (Safety Integrity Level 2) requirements. CROME uses a Xilinx Zynq 7020 SoC, for all computations.
The FPGA section of the Zynq is dedicated to safety critical functions:
Real time electronics management and data acquisition
Floating point dose rates calculations using various concurrent algorithms
Integral doses calculations
Decision making algorithms, alarm and interlock signals triggering.
The Zynq dual ARM cores run a custom homemade Linux OS primarily used to:
Manage the secured bidirectional communication between the FPGA section and the processors (some 200 x 64bits pipelined parameters)
Communicate with the SCADA Supervision through a homemade TCP/IP protocol, ROMULUS
Manage the non-safety critical calculations or tasks like data compression, storage, events generation...
As a safety related system, CROME’s SoC can boot throughout an SD card, TFTP/PXE server, flash memory or an eMMC. It implements hardening techniques such as TMR, Software Error Mitigation Core, Isolation Flow, ECC protected memories and a custom intra-sections data exchange mechanism. This feature has been extensively tested at CHARM facility to assess the decoupling between safety critical functions inside the FPGA and potential crashes of the OS.
The control of CERN’s beam-transfer kicker magnet high-voltage pulse generators requires often the use of digital control in FPGAs to allow tight timing control (jitter better than one ns) and fast protection of the high-voltage thyratron and semiconductor switches. A FPGA is a perfect candidate for the digital logic, it is however limited in integration possibilities with the actual and future control systems.
TE-ABT has recently levered the market push for integrated devices, so called Systems on a Chip (SoC). This technology allows for a tightly coupled ARM (Cortex A9 in case of the Xilinx Zynq 7000) processing system and programmable logic in a single device thus avoiding difficult placement and routing on an electronic card. This paper presents two projects where the Xilinx Zynq SoC has been used. It is used in the fast interlock detection system to integrate it neatly within the CERN control framework, by using embedded linux and running a Snap7 server. In the second project it implements a lower-tier communication bridge between a front-end computer, using serial communication in software and high-fan out multiplexing in the programmable logic for timing and analogue control logic.
The APx platform encompasses multiple ATCA blade types, supporting CMS Phase 2 detector back end FPGA-based processing. Central to the APx architecture are two custom-designed ZYNQ mezzanines. The ZYNQ-IPMC is a DIMM form-factor, enhanced IPM controller for ATCA, with primary responsibility for sensor and power control. The Embedded Linux Mezzanine (ELM), has primary responsibility for payload configuration and operation.
ZYNQ-IPMC software is implemented in C/C++ and uses FreeRTOS, running on a XC7Z020 or XC7Z014S device. The Gen-1 board, the ELM1, runs a Petalinux distribution on a XC7Z045 device, with an ELM2 currently in design using an Ultrascale+ SoC device. Both boards allow customization of the programmable logic (PL) to the specific requirements of the host blade. Internal register IO in blade FPGAs is AXI-based, with access by the ELM CPU via a MGT-based AXI bridge.
ELM-based services are an evolution of the model successfully deployed on the CMS CTP7 card during LHC Run 2. Services include FPGA bitfile loading, I2C IO support for optical modules and special-purpose ICs, hosting a 10GbE endpoint, and FPGA control. Control methods include shell scripts, custom applications, and remote procedure call (RPC) modules which allow system PCs to access FPGA-specific functions.
SoC images on both boards are fully updatable over the LAN, and both boards have LAN-accessible console interfaces. APx FPGA images can be bundled with associated support resources to guarantee software/firmware compatibility. A mechanism spanning both SoC boards provides automatic assignment of geographic IP addresses via DHCP.
Thomas Andrew Gorski
(University of Wisconsin Madison (US))
The Phase 2 CMS tracker back-end processing system is composed by two types of "Detector, Trigger and Control" (DTC) boards interfacing the inner and outer tracker, and by the "Track Finding Processor" (TFP) board performing level-1 track reconstruction from the outer tracker data. Several groups are building hardware to prove key and novel technologies needed in the back-end processing system. Each of these development platforms is using different slow control devices and architectures. While the main functionality of the boards is different, they all share similar management requirements. These can be fulfilled using an integrated solution based on Zynq Ultrascale+ (US+) System-on-Chip (SoC) devices as presented here.
The Zynq US+ SoC provides FPGA logic, high-performance ARM-A53 multi-core processors and two ARM-R5 real-time capable processors. The ARM-R5 cores are used to implement the IPMI/IPMC functionality and communicate via backplane with the shelf manager at power-up. The ARM-R5 are also connected to the power supply (via PMBus), to voltage and current monitors, to clock generators and jitter cleaners (via I2C, SPI). Once full power is enabled from the crate, a Linux starts on the ARM-A53 cores. The FPGA is used to implement some of the low-level interfaces including IPBus, or glue-logic. The SoC is the central entry point to the main FPGAs on the motherboard via IPMB and TCP/IP based network interfaces. The communication between the Zynq US+ SoC and the main FPGAs uses the AXI chip-to-chip protocol via MGT pairs keeping infrastructure requirements in the main FPGAs to a minimum.
(Indiana University (US)), Marc Dobson
PetaLinux - Presentation + Tutorial1h 30m
This presentation gives a basic introduction to ZYNQ device(s), explains its booting process, and gives a tutorial covering the necessary steps required for building a working Linux system for ZedBoard (Zynq 7000) with Xilinx Vivado and PetaLinux Tools. Finally, a live demonstration of Linux booting over network with NFS root file system is given.
Keyshav Suresh Mor
(Eindhoven Technical University (NL)), Petr Zejdl
(Fermi National Accelerator Lab. (US))
CentOS on Xilinx Zynq Ultrascale+ MPSoC System on Chip45m
The Xilinx Zynq Ultrascale+ MPSoC is a System on Chip (SoC), which is used in the upgrade of the ATLAS Muon to Central Trigger Processor Interface (MUCTPI) module. It interfaces the MUCTPI module to the ATLAS run control system. While the Linux kernel for the ARM-based processor part of the SoC is being prepared using the Yocto framework, the root file system can be prepared using the dnf cross installation tool to install the CentOS for ARM Linux distribution. Additional software packages can be easily installed or can be natively compiled, e.g. on an evaluation board. This way the ATLAS run control system can be built in its own environment and a run control application can be produced which runs over CentOS on the SoC.
In an interactive demo, the basic functionality of CentOS will be presented running on a ZCU102 evaluation board which has a Zynq Ultrasscale+ MPSoC. Using common system services and installing new functionality, it will be shown that this system behaves like a regular PC with CERN Centos 7.
(National Technical Univ. of Athens (GR))
CentOS: cross-Installation, cross-compilation of an application, and performance measurements45m
Presentation of the SLAC tools for running CentOS7 on Zynq 7000.
The presentation will cover the following aspects:
Install SLAC tools via RPM;
Cross-install a Centos7 ARM64 ROOTFS with python script;
Write an SD card from the created ROOTFS;
Boot a ZCU102 from the SD card;
Cross compile an echo server (ZMQ+msgpack) for ZCU102 and compile for a Linux host;
Run echo server and measure data throughput.
C++ variant encode to msgpack transfer with ZMQ decode to C++ valiant, re-encode sent back and decode.
(SLAC National Accelerator Laboratory (US))
(CERN), Diana Scannicchio
(University of California Irvine (US))
CaRIBOu - A versatile data acquisition system20m
The process of a detector development includes a subtask concerning the readout of data and controlling the detector. It typically consist of designing hardware in form of a readout board containing programmable logic to provide an interface to the chip, power supplies for biasing the detector chip, as well as DACs and ADCs for setting and measuring operation parameters, test pulses, etc. One also needs to write software for control and readout. This process can be repeated again and again for each new chip developed, which requires different voltage levels or different number of data lines. The CaRIBOu system, on the other hand, provides a robust, versatile DAQ system, which can be easily adjusted to the needs of different detector chips. Using such a system saves development cost and reduces the time needed to get first data from the detector. CaRIBOu is a combination of hardware and software modules that forms a stand-alone readout and DAQ system for detector prototypes. It was initially developed for testing newly developed pixel-detector chips for ATLAS and for a future CLIC detector. Adding support for a new chip is a matter of writing a piece of code performing an interface between the chip-specific features and the standard data and control interface of the CaRIBOu system. The system is based on a Xilinx Zynq System-on-Chip (SoC) architecture combining the power of a programmable hardware (FPGA) and a fully-featured Linux operating system based on the Yocto framework. It can run either stand-alone, storing data to a local filesystem, or connected via network interface to a data storage or a superior control system. The data decoding and analysis can be done either directly in the system both in software and in FPGA-based hardware, or it can be stored in a raw format and analysed offline.
The talk presents the structure and capabilities of the CaRIBOu system and shows example applications and future plans.
ATLAS CSC, Pixel - Zynq based SoC RCE Readout and Evolution20m
The Reconfigurable Cluster Element (RCE) readout is a generic DAQ concept based on SoC building blocks with associated networking solution that was initially developed on an ATCA platform at SLAC in 2007. The combination of Gen-1 RCE on Virtex4/PowerPC and HSIO carried out the ATLAS pixel IBL stave QA/QC and installation commissioning in 2013. The RCE Gen-3 design migrated its base to the ZYNQ-7000 SoC in 2013, with the ATCA based Cluster on Board (COB) running the upgrade ATLAS muon CSC readout since 2015. ZYNQ based RCE mezzanine integrated onto the portable HSIO-2 also provided a popular test stand and test beam setup for ATLAS pixel upgrade. This evolved setup with RCE running Arch-Linux is also operating the ATLAS AFP readout. Recent development also established ATLAS ITk pixel RD53 readout on RCE platforms and engaging in system test setups that can readout large number of channels from ITk pixel staves and rings. This development is coupled to the evolution of RCE hardware base to Ultrascale+ MPSoC and potentially also the forthcoming ACAP devices. This development for many applications over the last 10+ years also brought extensive experience in software/firmware infrastructure that supported setups widely distributed in ATLAS that provided a stable ATLAS application development platform with controlled releases to benefit from SLAC RCE core utility upgrades that’s always in flux to serve many non-ATLAS applications also. The RCE core utility suite offers dataflow backbone with DMA engines, Reliable UDP (RUDP) protocol and low latency PGP protocol etc. The application software development also yielded experience with different inter-process communication schemes, data serialization formats, and running Centos-7 on ZYNQ etc. In this presentation, we will discuss the key highlights from the extensive experience and current development for both the hardware platforms and software/firmware infrastructure.
(SLAC National Accelerator Laboratory (US))
The APOLLO Platform - Use of SoC Devices in ATLAS and CMS20m
Many of the ATCA blades being proposed include some flavor of SoC on each blade. I will discuss where our SoC, a commercial Zynq 7000 series mezzanine board will fit in in our Apollo family of ATCA blades. The Apollo family of boards are made up of a services module, a command module, a SoC mezzanine, an Ethernet switch, and an IPMC. The services module is the primary board used for connecting to the ATCA power & data backplanes and serves as the host for the other boards. The Command module mates with Service module and is the application specific board hosting the high power FPGA and optics and has low and high-speed links back to the SoC mezzanine on the service module. Focusing on the SoC, I will discuss the topology and access control of I2C sensors between IPMC and SoC; the use of the SoC for system control and monitoring of Service and Command module components; our thoughts on the software access to these via the SoC; and our current ideas on PS-PL use such as prescaled DAQ path processing, histogramming, and/or calibration.
Daniel Edward Gastler
(Boston University (US))
The Zynq MPSoC in the gFEX hardware trigger in ATLAS20m
The Global Feature Extractor (gFEX) is a hardware jet trigger system that will be installed in the ATLAS experiment at CERN during Phase 1 upgrades. The gFEX will read out the entire calorimeter at the full LHC collision rate of 40 MHz and thus be able to calculate global quantities. This allows for the implementation of large-radius jet algorithms, potentially refined with jet subjet information, to select Lorentz-boosted objects like bosons and top quarks. The gFEX will additionally be able to implement event based local pile-up suppression within the large-radius jet algorithms. The global nature of the gFEX allows for the calculation of quantities like MET and algorithms like “jets without jets”. The gFEX board consists of three Ultrascale+ Virtex FPGAs and one Zynq+ MPSoC. Each of the FPGAs deal with a specific pseudo-rapidity range of calorimetry data and the Zynq+ MPSoC coordinates this process. The Zynq+ is also in charge of the control and monitoring of the board. The SoC is loaded with a customized Operating System (OS) built using the Yocto Project with the custom layer meta-l1calo. This talk will discuss the design and structure of the OS, along with SoC-specific considerations for operating the gFEX board. The gFEX is unique in its global view of events and its ability to trigger efficiently on jets and events with complex substructure. Its addition to the hardware trigger of ATLAS will increase the performance and sensitivity of the trigger to many important physics processes.
(University of Chicago (US))
Exploring the use of a Zynq MPSoC for machine learning inference in hardware triggers20m
One of the ongoing technical challenges in experimental high energy physics is the real-time filtering (triggering) of data that may contain interesting interactions from a physics perspective. These challenges are especially pertinent on the hardware level for the general purpose LHC experiments since the first stage of triggering needs to simultaneously function on the order of tenths of microseconds and select for these interesting events. A current challenge is optimizing the tradeoff between the latency and the mis-classification rate of interactions. Our dataset is one of pseudo-calorimeter data (each represented by an image) of simulated events and the task is to classify each event as signal or background. Our approach is to implement a neural network (NN)-based algorithm for this task on an Zynq UltraScale+ MPSoC. To this end, we start with a NN trained on offline data in a high level programming language. Then, we use a high level synthesis tool and library to convert the NN into a hardware implementation on the Zynq MPSoC. Given the success of NNs in image classification and the ability of the MPSoC to use both the ARM processor and the programmable logic (FPGA) to implement NNs in a highly parallelized and energy-efficient fashion with low fixed latency, we believe this may be a fruitful approach for future triggering improvements. We see potential applications as an R&D system for the ATLAS experiment’s Run 3 gFEX system and potentially as part of the trigger in the Run 4 (HL-LHC) ATLAS Global Event Processor.
Emily Ann Smith
(University of Chicago (US))
The SoC-based Readout Drivers of the ATLAS Pixel/IBL detector20m
From 2015 to 2018 the ATLAS Pixel detector has gradually been installing new readout drivers (RODs) that are used for data readout, configuration, monitoring, and calibration of the Pixel frontends. The RODs are 9U VME boards utilizing FPGA technology. The main FPGA is a Xilinx Virtex 5 Soc which contains a PPC440 processor. The processor is used to configure the frontend chips and to read back monitoring information from the FPGAs. Up until recently the operating system running on the PPC was xilkernel. During the current shutdown of the LHC xilkernel is being replaced by a recent Linux kernel which will provide superior stability and debugging capabilities. The architecture of the system and the issues that were encountered will be presented in this talk.
(Acad. of Sciences of the Czech Rep. (CZ))
A SoC module for the ATLAS Tile Calorimeter PreProcessors at the HL-LHC20m
In 2026, the LHC will be upgraded to the High Luminosity LHC (HL-LHC) allowing it to deliver up to 7 times the instantaneous design luminosity. The ATLAS Tile Calorimeter (TileCal) Phase-II Upgrade will accommodate the detector and data acquisition system to the HL-LHC requirements. The on- and off-detector readout electronics will be completely re-designed to cope with new data rates and radiation levels for the Phase-II Upgrade. The on-detector electronics will transfer digitized data for every bunch crossing (~25 ns) to the Tile PreProcessor (TilePPr) in the counting rooms which is interfaced with the ATLAS Trigger and Data AcQuisition (TDAQ),and the ATLAS Detector Control System (DCS).
The TilePPr module is being designed as a full-size ATCA blade form factor. This system is composed of an ATCA Carrier Blade Board (ACBB) and four FPGA based Compact processing Modules (CPM) with AMC form factor. The high-speed communication with the on-detector electronics, data acquisition and core processing functionalities relies on the CPMs, while functionalities for power management, control and configuration of the boards are implemented in separated mezzanine cards.
One of these mezzanine boards is the Tile Computer on Module (TileCoM). This 204-pin SODIMM form factor board is equipped with a System-on Chip Xilinx ZYNQ UltraScale+ FPGA running embedded Linux operating system. The main role of the TileCoM is the remote control and configuration of all the boards placed in the ACBB, remote configuration of the on-detector electronics FPGAs and interface with the DCS for monitoring.
This contribution presents the design of the TileCoM module, as well as the integration plans of the TileCoM with the TileCal readout system and ATLAS DCS.
Fernando Carrio Argos
(Univ. of Valencia and CSIC (ES))
ATLAS TREX - VME digital modules using Zynq MPSoC20m
During LS2, the legacy PreProcessor system of the ATLAS Level-1 Calorimeter Trigger (L1Calo) will be extended with new VME digital modules, called Tile Rear Extension (TREX). The main task of the TREX modules will be to extract copies of the Tile digitised results from the legacy trigger data path, and to transmit them to the new L1Calo Feature Extractor processors, via optical links running at 11.2 Gbps.
The operating conditions of the TREX modules will be continuously monitored by the ATLAS Detector System (DCS). The slow-control functionality and the communication with the DCS will be managed on each TREX by an on-board, commercial, Zynq MPSoC based module. The Zynq device will collect permanently environmental parameters from various sources on the TREX board, and transfer them to the DCS via an embedded OPC UA server and an Ethernet interface. Additionally, the Zynq device will act as a board manager, being able to initiate power-on/-off sequences, whenever this will be requested by the DCS or by the VME controlling software, or to reconfigure various TREX programmable devices upon specific commands received from the VME.
Details on the implementation, functionality and operation of the Zynq MPSoC module will be presented in this talk.
(Ruprecht Karls Universitaet Heidelberg (DE))
(Indiana University (US))
Balena as a deployment stack - Presentation + Tutorial45m
Alongside the many gains brought by the addition of SoCs to boards are new management, operation, and development challenges. These SoCs require mechanisms for deploying, maintaining, and managing a large-scale heterogeneous cluster. Doing so requires the maintenance of multiple OS and application build tool chains, mechanisms for deploying and updating both at scale, and tools for accessing and monitoring each, both individually and in batch processes.
Many possible solutions exist to address these challenges. One near-off-the-shelf solution presented here is the open source project Balena. Balena is a tool stack that is rapidly growing in popularity amongst IoT providers who are using it to manage fleets of remote devices. At its core, Balena consists of (1) a Yocto layer in a linux build recipe that creates pre-configured unique images (BalenaOS) for SoCs, and (2) a set of cloud services that enable the operation of hundreds of devices running the BalenaOS once booted.
Internally BalenaOS utilises Docker and git tooling to deploy applications and provide automated network configuration, access control, and ssh access to both the host OS and containers. Balena cloud services and node-based API pair with these mechanisms to provide management, configuration, and debugging tools for device fleets.
This presentation will provide an overview of the Balena toolstack, and review the advantages and disadvantages of using a Balena-flavoured CERN CentOS and a local Balena cloud service within the context of CERN SoC management needs. A CentOS-Balena instance deployed on a Zynq will be demonstrated.
Janet Ruth Wyngaard
(University of Notre Dame (US))
For hardware control and monitoring tasks, System-on-Chip devices offer the perfect combination of flexibility and performance for hardware owners as well as a convenient computing platform for control and back-end experts to implement local control and back-end interface software.
The industry standard OPC-UA represents a well-adapted middleware solution for hardware integration into back-end applications in the frame of detector control systems (DCS) or detector configuration/calibration engines. In the case of SoCs, OPC-UA can be directly embedded into the processing part and thus allows e.g. for easy network integration of SoC-based software. Exploiting the power of the quasar framework to generate OPC-UA servers from object-oriented device models, the software development process can be significantly facilitated as well as the integration e.g. into WinCCOA or python/C++-based applications simplified.
In this contribution, applications of SoCs in the context of control system projects within the ATLAS Phase-II upgrades are presented and usage scenarios as well as network integration aspects discussed. A general overview of OPC-UA and quasar, as well as the current status and experience with it on SoC devices will be given.
OPC-UA on Zynq: Walk-through, experience and a demo - Tutorial part I40m
The tutorial will focus on creation of OPC-UA servers for Zynq SoCs using the quasar framework. Firstly, a short walk-through of quasar will demonstrate the general workflow for newcomers with a demo of building an OPC-UA server for a laptop and using it.
practical walk-through of ecosystem - show tooling, Eclipse integration, UaExpert etc...
making of an OPC-UA server for a desktop with some simple monitoring
OPC-UA on Zynq: Walk-through, experience and a demo - Tutorial part II50m
Subsequently, the usage of quasar on SoCs will be detailed. The build process for Zynq will be explained using four different strategies: Yocto, PetaLinux, native CentOs and usage of cross-compiler/SDK. The current status and mileage will be shown. In the last part an interactive demo will present building for a real Zynq board and integration of some sensors and controls with OPC-UA connectivity.
(University of California Irvine (US)), Marc Dobson
Xilinx Cybersecurity offering in Industrial Internet of Things (IIoT)15m
Xilinx Cybersecurity offering in Industrial Internet of Things (IIoT) is part of the whole Secure Chain. This offer includes HW Security Devices, Secure Boot, Validated OS, Trusted Apps, Secure Comms, System Monitoring and Gateways/Firewalls. This session shows the history of HW Security Features from Virtex-5 to Zynq-UltraScale+ MPSoC with its implemented passive and active features. The role of FPGA/SoC vendors is in the Enterprise Network, at the Controller level, Control Network, IO devices and in Asset – but not in the Cloud or Internet domain. The Xilinx SoC Endpoint Security Platform in Hardware may be extended with a Mocana Comprehensive, full-stack IoT Security platform solution, which builds on HW Root of Trust and is Endpoint Security IIC Industrial Internet Security Framework compliant. This Mocana solution supports device enrolment, secure update, secure transport and remote attestation.
Intel/Altera - Secure Device Manager for Startix10 & Agilex SoC15m
Security is becoming ever more important as time progresses and is fast becoming a requirement during the architectural decision-making process. From secure boot and authentication through to cryptographic engines FPGAs have an evolving solution to address market needs.
During this brief 10 minute presentation, the headline evolution of secure boot in SoC FPGA devices will be presented, and the new Secure Device Manager (SDM) available in Stratix 10 and Agilex SoC devices will be discussed, demonstrating a field-upgradable security solution to common cryptographic authentication, encryption and revocation needs.
State of Linux distributions at CERN and developments in the community by CERN IT Linux Team20m
After giving a status update on the supported CERN linux distributions, we will talk about the CentOS community and Special Interest Groups (SIG) which is the framework for managing contributions. An overview of the alternative architecture SIG will be given. Finally few key features of the next CentOS release will be discussed.