Claudio Salati

@ T3LAB

Partecipazione a diversi progetti di ricerca finanziata regionali, nazionali ed europei. Professore a contratto per più di 25 anni presso le Università di Parma, Bologna e Ferrara. Docente in corsi interni presso Telettra, Italtel e Siemens. Pubblicazioni in riviste e congressi, nazionali e internazionali. Seminari presso diverse istituzioni. Attualmente CTO di T3LAB. In passato: responsabile R&D della B.U. Transportation and Logistics e Responsabile sviluppo SW di Datalogic Automation, responsabile dell’architettura del sistema di gestione della BUTR di Italtel/Siemens, responsabile R&D di Sarmont, responsabile Laboratorio Reti di Calcolatori e Sistemi Distribuiti di Telettra. Laurea in Ingegneri Elettronica presso l’Uniiversità di Bologna e MS CS:CE presso Stanford University. Sono stato membro del TC57 WG07 della IEC (International Electrotechnical Commission). Internazionalista in Nicaragua nel 1985 e tre turni di servizio in Sar-El in Israele negli anni 2011 e 2012. Ho camminato un tratto della GEA, l’E5 da Verona al Lago di Costanza, il Sentiero di Gesù e le Alte Vie no. 1 e 2 delle Dolomiti.

Talks

2017	A Linux centered SW infrastructure for the support of asymmetric multi-processing
45'	Multi-core, multi-ISA processors need complex SW infrastructures to be effectively used. The talk presents such an infrastructure with an emphasis on inter-process communication and the programming model it encourages. An HPC application that proves its capabilities and performance is also shown. Several silicon vendors are making available multi-core chips where different cores have very different characteristics: some may be powerful microprocessors, others may be small microcomputers, others DSPs, not to mention GPUs and FPGAs. In general, they can be considered examples of multi-ISA architectures (architectures with a functional asymmetry). A typical use case of these architectures is the consolidation of the several computing nodes that are present on a car and that must handle tasks as different as the control of servo devices, the infotainment, and the connection to internet and to GPS. Another use case is embedded HPC. All these devices cannot be run by a single OS kernel, and an application must be distributed across a set of autonomous processing elements, each with its own run-time environment, and each with its own partition of the HW resources of the chip (I/O, memory, cache). If we want to effectively use these platforms all the autonomous processing elements must be able to interact with each other: a multi-vendor, de facto standard for in-chip interprocessor communications already exists, rpmsg on shared memory, but it has several limits: • It is only the equivalent of a Data-link layer service. • Its API is different on different RTOSs. • On Linux, even though it is already supported as part of the main branch, it is implemented as a bus driver. Its API is accessible only from kernel space, and this is true in particular for the definition of service access points. We have complemented rpmsg with two transport protocols, supporting respectively unreliable and reliable, message based communications. Both protocols are interfaced on Linux via sockets, of type DGRAM and SEQPACKET respectively, and this allows users to create their own communication endpoints in the protocol family rpmsg. The same protocols have been implemented in a portable form also for RTOSs, and also on RTOSs they have been made available through a socket-like API. Finally a remote procedure call environment has been developed on top of the socket API: this RPC environment has been derived from eRPC, but we have enhanced it in several ways, e.g. with the introduction of a global broker that allows to relocate services across the different processing elements of the chip. All developments have been based either on SW provided by silicon vendors or on open source SW: Linux, FreeRTOS, OpenAMP (portable version of rpmsg and its port on FreeRTOS and Zynq), eRPC. All developments will become available as open source SW. As a demonstrator we have implemented a computer vision application for blob analysis, where the main program, running on the Linux managed main processing unit of a TI Sitara AM572x, invokes via eRPC the functions of the TI image processing library that runs on the 2 DSPs of the HW platform. Video Slides Talk page

2017

A Linux centered SW infrastructure for the support of asymmetric multi-processing

45'

Multi-core, multi-ISA processors need complex SW infrastructures to be effectively used. The talk presents such an infrastructure with an emphasis on inter-process communication and the programming model it encourages. An HPC application that proves its capabilities and performance is also shown. Several silicon vendors are making available multi-core chips where different cores have very different characteristics: some may be powerful microprocessors, others may be small microcomputers, others DSPs, not to mention GPUs and FPGAs. In general, they can be considered examples of multi-ISA architectures (architectures with a functional asymmetry). A typical use case of these architectures is the consolidation of the several computing nodes that are present on a car and that must handle tasks as different as the control of servo devices, the infotainment, and the connection to internet and to GPS. Another use case is embedded HPC. All these devices cannot be run by a single OS kernel, and an application must be distributed across a set of autonomous processing elements, each with its own run-time environment, and each with its own partition of the HW resources of the chip (I/O, memory, cache). If we want to effectively use these platforms all the autonomous processing elements must be able to interact with each other: a multi-vendor, de facto standard for in-chip interprocessor communications already exists, rpmsg on shared memory, but it has several limits: • It is only the equivalent of a Data-link layer service. • Its API is different on different RTOSs. • On Linux, even though it is already supported as part of the main branch, it is implemented as a bus driver. Its API is accessible only from kernel space, and this is true in particular for the definition of service access points. We have complemented rpmsg with two transport protocols, supporting respectively unreliable and reliable, message based communications. Both protocols are interfaced on Linux via sockets, of type DGRAM and SEQPACKET respectively, and this allows users to create their own communication endpoints in the protocol family rpmsg. The same protocols have been implemented in a portable form also for RTOSs, and also on RTOSs they have been made available through a socket-like API. Finally a remote procedure call environment has been developed on top of the socket API: this RPC environment has been derived from eRPC, but we have enhanced it in several ways, e.g. with the introduction of a global broker that allows to relocate services across the different processing elements of the chip. All developments have been based either on SW provided by silicon vendors or on open source SW: Linux, FreeRTOS, OpenAMP (portable version of rpmsg and its port on FreeRTOS and Zynq), eRPC. All developments will become available as open source SW. As a demonstrator we have implemented a computer vision application for blob analysis, where the main program, running on the Linux managed main processing unit of a TI Sitara AM572x, invokes via eRPC the functions of the TI image processing library that runs on the 2 DSPs of the HW platform.

Video

Slides

Talk page