Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
  • G06F9/45533—Hypervisors; Virtual machine monitors
  • G06F9/45558—Hypervisor-specific management and integration aspects
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
  • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
  • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
  • G06F11/0793—Remedial or corrective actions
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0796—Safety measures, i.e. ensuring safe condition in the event of error, e.g. for controlling element
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
  • G06F13/38—Information transfer, e.g. on bus
  • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
  • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
  • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
  • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
  • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
  • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
  • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
  • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L49/00—Packet switching elements
  • H04L49/10—Packet switching elements characterised by the switching fabric construction
  • H04L49/109—Integrated on microchip, e.g. switch-on-chip
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
  • G06F9/45533—Hypervisors; Virtual machine monitors
  • G06F9/45558—Hypervisor-specific management and integration aspects
  • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
  • G06F9/45533—Hypervisors; Virtual machine monitors
  • G06F9/45558—Hypervisor-specific management and integration aspects
  • G06F2009/45583—Memory management, e.g. access or allocation
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
  • G06F9/45533—Hypervisors; Virtual machine monitors
  • G06F9/45558—Hypervisor-specific management and integration aspects
  • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2209/00—Indexing scheme relating to G06F9/00
  • G06F2209/50—Indexing scheme relating to G06F9/50
  • G06F2209/509—Offload
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
  • G06F2213/0026—PCI express

Definitions

• Cloud platforms such as Microsoft Azure and Amazon AWS run on a large fleet of physical servers (referred to herein as cloud servers) that are distributed across geographically dispersed data centers.
• cloud servers implement a virtualization software layer, known as a hypervisor, that allows for the hosting of virtual machines (VMs).
• VMs virtual machines
• IaaS Infrastructure- as-a-Service
• a physical server with an offload system including a SoC (system-on-chip) and a FPGA (field programmable gate array) is disclosed.
• One possible embodiment of the offload system is on a card.
• the SoC can be configured to offload one or more hypervisor functions from a CPU complex of the server that are suited for execution in software
• the FPGA can be configured to offload one or more hypervisor functions from the CPU complex that are suited for execution in hardware.
• FIG. 1 depicts a physical server topology that includes an offload card with a SoC and a FPGA according to certain embodiments.
• FIG. 2 depicts an architecture for the offload card of FIG. 1 according to certain embodiments.
• FIG. 3 depicts a JTAG (Joint Test Action Group) multiplexer implementation according to certain embodiments.
• JTAG Joint Test Action Group
• FIG. 4 depicts an example network processing flow according to certain embodiments.
• Embodiments of the present disclosure are directed to a physical server design that employs an offload card comprising a SoC (system-on-chip) and a FPGA (field- programmable gate array).
• the SoC and FPGA can run hypervisor functions traditionally executed by the server’s CPU complex, thereby offloading the processing burden for those functions from the CPU complex.
• the SoC of the offload card can run hypervisor functions that require or benefit from the flexibility of a general purpose processor (e.g., networking and storage control plane functions), while the FPGA of the offload card can run hypervisor functions that are suited for implementation/acceleration in hardware (e.g., networking and storage data plane functions).
• the offload card can improve the server’s efficiency while at the same time maintaining architectural flexibility.
• the FPGA can be re-programmed from accelerating one type/class of functions (e.g., networking) to accelerating another type/class of functions (e.g., storage). This is not possible with a hard logic-based accelerator such as an ASIC (application-specific integrated circuit).
• ASIC application-specific integrated circuit
• FIG. l is a simplified block diagram illustrating the high-level topology of a physical server 100 according to certain embodiments of the present disclosure.
• physical server 100 may be a cloud server that is deployed as part of the infrastructure of a cloud platform.
• physical server 100 may be mounted in a server rack within a data center operated by the cloud platform provider.
• physical server 100 may be deployed in other contexts and/or via other form factors, such as in an on-premises enterprise IT environment in the form of, e.g., a standalone server.
• cloud servers often implement a hypervisor for virtualization, which allows the cloud platform to offer services such as IaaS
• physical server 100 includes a novel offload card 102 comprising a SoC 104 and a FPGA 106.
• offload card 102 is implemented as a PCIe (Peripheral Component Interface Express)-based expansion card and thus interfaces with the mainboard of physical server 100 via a standard PCIe xl6 3.0 edge connector interface 108.
• offload card 102 may be implemented using any other type of peripheral interface.
• SoC 104 has its own RAM (random access memory) 110 and flash memory 112 and is communicatively coupled with FPGA 106 via at least interface that is internal to offload card 102: a PCIe interface 114 and an Ethernet interface 116.
• SoC 104 is communicatively coupled with a baseboard management controller (BMC) 118 of physical server 100 through I2C interface 108 and a number of other channels (e.g., USB and COM).
• BMC baseboard management controller
• FPGA 106 also has its own RAM 120 and flash memory 122 and is
• FPGA 106 includes two external Ethernet interfaces, one of which connects to an external network 126 (via, e.g., a TOR (top-of-rack) switch or some other network device) and the other of which connects to a NIC (network interface card/controller) 128 within physical server 100.
• an external network 126 via, e.g., a TOR (top-of-rack) switch or some other network device
• NIC network interface card/controller
• the topology shown in FIG. 1 enables some or all of the hypervisor functions traditionally run on CPU complex 124 of physical server 100 to instead be run on, and thus offloaded to, SoC 104 and FPGA 106 of offload card 102.
• hypervisor functions that benefit from the flexibility of a general purpose processor (or are simply too complex/dynamic to implement in hardware) can be run on SoC 104, which incorporates one or more general purpose processing cores. Examples of such functions include SDN (software-defined networking) control plane functions, which require complex routing computations and need to be updated relatively frequently to support new protocols and features.
• hypervisor functions that are suited to hardware acceleration can be implemented via logic blocks on FPGA 106.
• Examples of such functions include SDN data plane functions, which involve forwarding network data traffic according to control plane decisions, and storage data plane functions such as data replication, de- duplication, and so on.
• the hypervisor may be entirely vacated from CPU complex 124 and moved to offload card 102, in which case CPU complex 124 can run a minimal hypervisor that deals with issues that can only be run on the CPU complex itself, such as accessing certain registers, or no hypervisor at all and the remainder of the compute capacity of CPU complex 124 can be dedicated to guest workloads.
• offload card 102 can be easily re-purposed for different use cases or the same use case improved by re-programming the FPGA, and the FPGA logic can be updated if needed. This is advantageous in large-scale deployments where it may not be desirable to pull and replace a large number cards that are already in the field.
• SoC 104 and FPGA 106 are shown as being implemented on an expansion card (i.e., offload card 102) that interfaces with the physical server’s mainboard via a peripheral (e.g., PCIe) interface, in some embodiments an alternative offload architecture may be used. In a particular embodiment, one or more of SoC 104 and/or FPGA 106 may be implemented directly on the server mainboard.
• NIC 128 is depicted as being a standalone component, in some embodiments the functionality of NIC 128 may be incorporated into one or more other components shown in FIG. 1, such as in FPGA 106.
• NIC 128 is depicted as being a standalone component, in some embodiments the functionality of NIC 128 may be incorporated into one or more other components shown in FIG. 1, such as in FPGA 106.
• FPGA 106 field-programmable gate array
• FIG. 2 is a schematic diagram 200 that presents additional details regarding the architecture of offload card 102 of FIG. 1 according to certain embodiments. Various aspects of this architecture are discussed in turn below.
• SoC 104 can be implemented using any one of a number of existing system-on- chip designs that include one or more general purpose processing cores, interfaces for memory, storage, and peripherals, and a NIC. In a particular embodiment, SoC 104 may incorporate general purpose processing cores based on the ARM microprocessor architecture. [0029] As shown, SoC 104 is communicatively coupled with FPGA 106 via three separate interfaces, which are discussed in section 3.2 below. In addition, SoC is connected to (1) one or more DRAM (dynamic RAM) modules 202 corresponding to RAM 110 of FIG. 1 via a memory interface 204, (2) an eMMC (embedded multimedia card) device 206 corresponding to flash memory 112 of FIG.
• DRAM dynamic RAM
• eMMC embedded multimedia card
• I2C Inter Integrated Device
• SoC 104 can use DRAM module(s) 202 as its working memory for running program code, including hypervisor code offloaded from CPU complex 124 of physical server 100.
• the specific number and capacity of DRAM module(s) 202 and the specification of memory interface 204 can vary depending on the implementation.
• DRAM module(s) 202 can comprise 8 GB (gigabytes) of DDR4 DRAM organized as a single 1024M (megabit) x 64 bit + ECC (error correction code) memory bank and memory interface 204 can be configured as a single DDR4-2400 memory channel.
• SoC 104 can use eMMC device 204 as a non-transitory storage medium for storing and booting program code to be executed on the SoC, including hypervisor code offloaded from CPU complex 124, as well as storing FPGA configuration images to be applied to FPGA 106.
• BIOS flash memory component 210 can hold the system firmware for SoC 104 and security chip 214 can, among other things, ensure that this system firmware is not purposefully or inadvertently modified or corrupted by an attacker.
• I2C devices 216, 218, and 220 can provide various pieces of management information regarding offload card 102 to BMC 118. These pieces of information can include information such as operating temperature data, manufacturing information, and power consumption data.
• SoC 104 includes USB (Universal Serial Bus), COM, and JTAG (Joint Test Action Group) interfaces 224, 225, and 226 to external headers 228, 230, and 232 respectively, which can be used to connect SoC 104 with BMC 118 or external devices for debugging or management.
• JTAG Joint Test Action Group
• SoC 104 is communicatively coupled with FPGA 106 via three internal, chip-to-chip interfaces in FIG. 2: a PCIe interface 236, an Ethernet interface 238, and a JTAG interface 240.
• PCIe interface 236 provides both control and data transfer/exchange capabilities. For control capabilities,
• SoC 104 can use PCIe interface 236 (or alternatively a JTAG interface) to manage and update FPGA 106.
• SoC 104 can validate FPGA configuration images transferred from RAM 110 to FPGA 106 and can update the image on the FPGA or in the FPGA’s flash memory 122 using this interface.
• PCIe interface 236 can enable program code running on SoC 104 to send data to, and receive data from, FPGA 104. This is useful for, e.g., hypervisor code that is already written to exchange data over PCIe, because such code can be ported for execution on SoC 104 (or
• PCIe interface 236 can have 8 PCI 3.0 lanes (i.e., correspond to a PCI 3.0 8x interface). In other embodiments any other number of PCI lanes, such as 4, 12, 16, etc., may be supported.
• Ethernet interface 238 allows SoC 104 and FPGA 106 to exchange data in the form of network packets. This is useful for, e.g., hypervisor code that is already written to exchange data via network packets, because such code can be ported for execution on SoC 104 (or implementation on FPGA 106) with relatively few changes. For example, consider a scenario where network flow-based forwarding is implemented in hardware on FPGA 106 and a network control plane for determining routes for network flows is implemented in software on SoC 104. In this case, flow table exceptions and rules can be communicated between FPGA 106 and SoC 104 in the form of network packets. In a particular embodiment, Ethernet interface 238 can support 25G (gigabit) Ethernet.
• JTAG interface 240 provides a way for SoC 104 to communicate with FPGA 106 for low-level testing (e.g., debugging) and programming purposes.
• a JTAG multiplexer can be inserted in the JTAG path between SoC 104 and FPGA 106 that allows an external programmer device connected via external header 232 to drive interface 240.
• a“present” signal from the external programmer device will switch the signal path of JTAG interface 240 from SoC 104 to the device.
• FIG. 3 depicts an example diagram 300 of this architecture with a JTAG multiplexer 302 according to certain embodiments.
• FPGA 106 can be implemented using any one of number of existing FPGA chips.
• FPGA 106 can be implemented using an existing FPGA chip that supports a certain minimum number of programmable logic elements (e.g., 1000K elements) and a certain minimum transceiver/FPGA fabric speed grade (e.g., grade 2).
• FPGA 106 is communicatively coupled with I2C bus 222 and with SoC 104 via interfaces 236-240 discussed above.
• FPGA 106 is connected to (1) PCIe edge connector interface 108 via internal PCIe interface 242, (2) one or more DRAM module(s) 244 corresponding to RAM 120 of FIG.
• internal PCIe interface 242 enables FPGA 106 to communicate with CPU complex 124 and other PCIe devices installed in physical server 100 (including, e.g., NIC 128).
• PCIe interface 242 may be a PCIe 3.0 xl6 interface.
• FPGA 106 can use DRAM module(s) 244 as its working memory when executing logic programmed into the device, including hypervisor logic offloaded from CPU complex 124.
• the specific number and capacity of DRAM module(s) 244 and the specification of memory interface 246 can vary depending on the implementation.
• DRAM module(s) 202 can comprise 8 GB (gigabytes) of DDR4 DRAM organized as two 4GB banks of 512M x 64 bit + ECC and memory interface 246 can be configured as dual DDR4-2400 memory channels.
• QSPI flash memory module 248 can hold one or more FPGA configuration images that FPGA 106 can load upon power-up into order to configure itself to perform its designated functions. In certain embodiments, QSPI flash memory module 248 can hold at least three separate images, which is described in section 3.4 below. In addition to configuration from flash memory, FPGA 106 can also support configuration via an external JTAG programmer device, JTAG commands sent by SoC 104 over JTAG interface 240, CvP (Configuration via Protocol) over PCIe, and partial reconfiguration over PCIe.
• JTAG programmer device JTAG commands sent by SoC 104 over JTAG interface 240
• CvP Configuration via Protocol
• network transceiver module 250 enables FPGA 106 to receive incoming network traffic from and transmit outgoing network traffic to external network 126. Further, network transceiver module 252 enables FPGA 106 to exchange network traffic with NIC 128. This is useful in scenarios where FPGA 106 implements network plane functions because FPGA 106 can receive outgoing network packets from NIC 128 via module 252, process/transform them appropriately, and send them out to external network 126 via module 250. Conversely, FPGA 106 can receive incoming network packets from external network 126 via module 250, process/transform them appropriately, and send them to NIC 128 via module 252 (at which point they can be communicated to the correct destination VM).
• network transceiver modules 250 and 252 can be QSFP28 optical modules and Ethernet interfaces 254 and 256 can support 100G Ethernet.
• QSPI flash memory module 248 can store a minimum of three separate configuration images for FPGA 106: a golden image, a failsafe image, and a user application image.
• the golden image is factory tested at the time of initial manufacturing and comprises the normal intended functionality for FPGA 106.
• the failsafe image is programmed at the factory and is never overwritten after manufacturing.
• this failsafe image contains a minimum set of functions required by offload card 102 at power-up and the network interfaces of FPGA 106 are forced into a bypass mode where all traffic is passed directly between the interfaces without any intermediate processing by the FPGA.
• the user application image is an image that has been defined by a user/customer.
• offload card 102 At the time offload card 102 is powered-on, by default the golden image will be loaded from QSPI flash memory module 248 and applied to FPGA 106 for configuring its structures. If there any errors with this power-on process (or if problems are found during server runtime), the card can be rebooted to load the failsafe image instead of the golden image.
• FIG. 4 depicts a flowchart 400 of an example network processing workflow that may be implemented by physical server 100 according to certain embodiments.
• Flowchart 400 assumes that FPGA 106 of offload card 106 is configured to maintain a flow table comprising network flows determined by a network control plane running on SoC 104 and to forward data packets in accordance with the flow table.
• NIC 128 of physical server 100 can present an SR-IOV (single root IO virtualization) interface to a VM running on server 100.
• This SR-IOV interface (referred to as a virtual function) enables the VM to directly communicate with NIC 128, without involving the hypervisor.
• the VM can create a data payload for a network packet to be transmitted to a remote destination and can notify NIC 128 of this.
• NIC 128 can read the data payload from the guest memory space of the VM (block 406), assemble the data payload into one or more network packets with headers identifying, among other things, the IP address of the VM and the IP address of the intended destination (block 408), and output the network packet out of its egress port connected to network transceiver module 252 of FPGA 106 (block 410).
• FPGA 106 can receive the network packet and apply its network data plane logic to perform a lookup of the network packet’s 5-tuple (source IP address, source port, destination IP address, destination port, protocol) into a flow table. If a matching entry is found in the table (block 416), FPGA 106 can identify the next-hop destination for the network packet in the entry (block 418), update the header of the packet (block 420), and send the packet out of network transceiver module 250 to external network 126 (block 422), thereby ending the workflow.
• 5-tuple source IP address, source port, destination IP address, destination port, protocol
• FPGA 106 can send the network packet to SoC 104 over internal Ethernet interface 238 (block 424).
• a network control plane component running on SoC 104 can then calculate a next-hop destination for the packet and add a new entry for the packet’s network flow to the FPGA’s flow table via interface 238 (block 426). Using this new entry, FPGA 106 can execute blocks 420 and 422 and the workflow can end.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• General Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Quality & Reliability (AREA)
• Computer Hardware Design (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Stored Programmes (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Logic Circuits (AREA)
• Multi Processors (AREA)

Priority Applications (4)

Applications Claiming Priority (4)

Publications (1)

Family

ID=73457079

Family Applications (1)

Country Status (6)

Cited By (1)

Families Citing this family (31)

Family Cites Families (13)

• 2020
  • 2020-03-03 US US16/808,286 patent/US11593138B2/en active Active
  • 2020-04-16 WO PCT/US2020/028603 patent/WO2020236363A1/en not_active Ceased
  • 2020-04-16 CN CN202080037234.7A patent/CN113841120B/zh active Active
  • 2020-04-16 KR KR1020217037891A patent/KR102838679B1/ko active Active
  • 2020-04-16 EP EP20724984.8A patent/EP3973395B1/en active Active
  • 2020-04-16 JP JP2021569031A patent/JP7502338B2/ja active Active

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events