CN218332578U

CN218332578U - Firmware management device for FPGA chip, FPGA accelerator card and electronic equipment

Info

Publication number: CN218332578U
Application number: CN202222360850.5U
Authority: CN
Inventors: 张迪
Original assignee: Shenzhen Zhixing Technology Co Ltd
Current assignee: Shenzhen Zhixing Technology Co Ltd
Priority date: 2022-09-05
Filing date: 2022-09-05
Publication date: 2023-01-17
Anticipated expiration: 2032-09-05

Abstract

The utility model discloses a firmware management device for FPGA chip, FPGA accelerates card and electronic equipment, wherein, the firmware management device includes first memory, the second memory, logic execution unit and the control unit, if firmware strategy parameter in the first memory is used for the sign firmware mode of preventing falsification, the control unit sends first switch-on control instruction to logic execution unit, switch on the route between second memory and the FPGA chip, FPGA chip loading accelerates card firmware and accomplishes the back, the control unit sends first disconnection control instruction to logic execution unit, break off the route between second memory and the FPGA chip. After the FPGA chip finishes loading the acceleration card firmware, a channel between the second storage and the FPGA chip is disconnected, and the acceleration card firmware in the second storage cannot be tampered, so that the acceleration card is guaranteed to normally operate, and the acceleration card can recommend privacy data when executing a privacy calculation task or a federal learning task.

Description

Firmware management device for FPGA chip, FPGA accelerator card and electronic equipment

Technical Field

The utility model relates to a wireless communication technology field, in particular to firmware management device, FPGA accelerator card and electronic equipment for FPGA chip.

Background

The accelerator card is an electronic device connected with the server through a signal interface, and performs data exchange and communication with the server through the signal interface. The accelerator card firmware is a Field Programmable Gate Array (FPGA) program stored in Flash of the accelerator card, and is a basis for normal operation of the accelerator card.

In the related art, a privacy computing platform is generally implemented by taking an accelerator card as a carrier, and processing related to privacy data is placed on the accelerator card, so that the privacy data is ensured not to be leaked, and the privacy computing is safer and more reliable.

In the accelerator card, a Flash for storing the firmware is connected with an FPGA chip through a Queue Serial Peripheral Interface (QSPI), and when the accelerator card is powered on, the FPGA chip reads the accelerator card firmware stored in the Flash and performs configuration and operation. In the prior art, if the accelerator card firmware stored in Flash is tampered, the firmware loaded by the FPGA chip is the tampered firmware, so that the accelerator card cannot run.

SUMMERY OF THE UTILITY MODEL

The utility model provides a firmware management device, FPGA accelerating card and electronic equipment for FPGA chip for solve the accelerating card firmware of the storage that exists among the prior art and falsify, then can lead to the unable problem of operation of accelerating card.

In a first aspect, an embodiment of the present application provides a firmware management device for an FPGA chip, where the device includes: the device comprises a first memory, a second memory, a logic execution unit and a control unit;

the first end of the control unit is in signal connection with the first memory, the second end of the control unit is in signal connection with the control end of the logic execution unit, and the third end of the control unit is in signal connection with the first end of the FPGA chip; the first conducting end of the logic execution unit is in signal connection with the second memory, and the second conducting end of the logic execution unit is in signal connection with the second end of the FPGA chip;

the first memory is used for storing at least one firmware strategy parameter, wherein the firmware strategy parameter comprises a first firmware strategy parameter used for characterizing a firmware anti-tampering mode;

the second memory is used for storing an acceleration card firmware;

the control unit is configured to acquire the firmware policy parameter, send a first on control instruction to the logic execution unit when the firmware parameter is a first firmware policy parameter, and send a first off control instruction to the logic execution unit after receiving a first completion signal sent by the FPGA chip, where the first completion signal is used to represent that an action of loading the acceleration card firmware by the FPGA chip is completed;

the logic execution unit is configured to, after receiving the first conduction control instruction, conduct a path between the second memory and the FPGA chip, and after receiving the first disconnection control instruction, disconnect the path between the second memory and the FPGA chip.

According to the technical scheme, if the firmware strategy parameters stored in the first storage are used for representing the first firmware strategy parameters of the firmware anti-tampering mode, the control unit sends a first conduction control instruction to the logic execution unit, the logic execution unit conducts a channel between the second storage and the FPGA chip after receiving the first conduction control instruction, the FPGA chip loads the acceleration card firmware stored in the second storage, the control unit sends a first disconnection control instruction to the logic execution unit after receiving a first completion signal which is sent by the FPGA chip and used for representing that the FPGA chip loads the acceleration card firmware, and the logic execution unit disconnects the channel between the second storage and the FPGA chip after receiving the first disconnection control instruction. After the action of loading the acceleration card firmware on the FPGA chip is completed, the logic execution unit disconnects the channel between the second memory and the FPGA chip, so that the acceleration card firmware stored in the second memory cannot be tampered, and the normal operation of the acceleration card is guaranteed.

In one possible design, the apparatus further includes a third memory for storing the accelerator card backup firmware;

a third conducting end of the logic execution unit is in signal connection with the third memory;

the control unit is further configured to send a second disconnection control instruction to the logic execution unit when the firmware policy parameter is a first firmware policy parameter;

the logic execution unit is further configured to disconnect a path between the third memory and the FPGA chip after receiving the second disconnection control instruction.

According to the technical scheme, the accelerator card backup firmware is stored in the third memory, and when the accelerator card firmware stored in the second memory is loaded by the FPGA chip, the path between the third memory and the FPGA chip is disconnected, so that the accelerator card firmware in the second memory can be guaranteed to be loaded correctly.

In one possible design, the firmware policy parameters further include a second firmware policy parameter for characterizing a firmware tamper-resistant mode and a firmware auto-recovery mode;

the control unit is further configured to send the first on control instruction and the second off control instruction to the logic execution unit when the firmware policy parameter is a second firmware policy parameter; if the first completion signal is not received within a preset time length, sending the first off control instruction and the second on control instruction to the logic execution unit, and sending a reload instruction to the FPGA chip, wherein the second firmware strategy parameter is used for representing a firmware tamper-proof mode and a firmware automatic recovery mode;

the logic execution unit is further configured to, after receiving the second conduction control instruction, conduct a path between the third memory and the FPGA chip.

According to the technical scheme, if the firmware strategy parameter is the second firmware strategy parameter, the second firmware strategy parameter is used for representing a firmware anti-tampering mode and a firmware automatic recovery mode, when the FPGA chip fails to load the accelerator card firmware stored in the second memory, a channel between the third memory and the FPGA chip is conducted, and the FPGA chip loads the accelerator card backup firmware stored in the third memory, so that the probability that the accelerator card cannot normally work can be reduced, and the performance of the accelerator card is improved.

In a possible design, the control unit is further configured to send a second disconnection control instruction to the logic execution unit if a second completion signal sent by the FPGA chip is received after sending the reload instruction to the FPGA chip, where the second completion signal is used to indicate that an action of reloading the accelerator card backup firmware by the FPGA chip is completed.

According to the technical scheme, after the FPGA chip successfully loads the accelerator card backup firmware stored in the third memory, the passage between the third memory and the FPGA chip is disconnected, so that the anti-tampering function can be guaranteed to take effect.

In one possible design, the firmware policy parameters further include a third firmware policy parameter for characterizing a firmware development board mode;

the control unit is further configured to send the first on control instruction to the logic execution unit and send the second off control instruction to the logic execution unit when the firmware policy parameter is a third firmware policy parameter.

According to the technical scheme, when the firmware strategy parameter is the third firmware strategy parameter used for representing the firmware development board mode, the FPGA chip loads the acceleration card firmware stored in the second memory, and the acceleration card firmware can be modified according to the requirements of developers, so that the development cost is reduced.

In one possible design, the firmware policy parameters further include a fourth firmware policy parameter for characterizing a firmware development board mode and a firmware auto-recovery mode;

the control unit is further configured to send the first on control instruction and the second off control instruction to the logic execution unit when the firmware policy parameter is a fourth firmware policy parameter; and if the first completion signal is not received within a preset time length, sending the first disconnection control instruction and the second connection instruction to the logic execution unit, and sending a reload instruction to the FPGA chip.

According to the technical scheme, when the firmware strategy parameter is the fourth firmware strategy parameter for representing the firmware development board mode and the firmware automatic recovery mode, the FPGA chip fails to load the accelerator card firmware stored in the second memory, the channel between the third memory and the FPGA chip is switched on, the FPGA chip loads the accelerator card backup firmware stored in the third memory, and a developer does not need to replace the accelerator card firmware stored in the second memory with the accelerator card firmware which can be normally loaded before, but directly uses the accelerator card backup firmware stored in the third memory, so that convenience is provided for research and development, and the development cost is further reduced.

In a possible design, the apparatus further includes a PCIE interface in signal connection with a third end of the FPGA chip;

the control unit is further configured to, after receiving firmware policy parameter upgrade information through the PCIE interface and the FPGA chip, change the firmware policy parameters stored in the first memory according to the firmware policy parameter upgrade information.

According to the technical scheme, different requirements of users can be met by changing the firmware strategy parameters stored in the first storage on line.

In a possible design, the second memory is a Flash memory and/or the third memory is a Flash memory.

In one possible design, the logic execution unit is an analog switch.

In one possible embodiment, the first terminal of the control unit is connected to the first memory by an SPI signal.

In one possible design, the first conducting terminal of the logic execution unit is connected with the second memory through a QSPI signal; and/or

And the second conducting end of the logic execution unit is connected with the second end of the FPGA chip through a QSPI signal.

In one possible design, the third conducting terminal of the logic execution unit and the third memory are connected by a QSPI signal.

In a second aspect, an embodiment of the present application provides a firmware management method for an FPGA chip, which is applied to the firmware management apparatus for an FPGA chip according to any one of the first aspects, and the method includes:

acquiring firmware strategy parameters from a first memory, wherein at least one firmware strategy parameter is stored in the first memory;

when the firmware strategy parameter is a first firmware strategy parameter, controlling the conduction of a channel between a second memory and the FPGA chip, wherein the first firmware strategy parameter is used for representing a firmware anti-tampering mode;

and after receiving a first completion signal sent by the FPGA chip, controlling the second memory and the FPGA chip to be disconnected, wherein the second memory stores an acceleration card firmware, and the first completion signal is used for representing the completion of the action of loading the acceleration card firmware by the FPGA chip.

In one possible design, the method further includes:

and controlling the disconnection of a path between a third memory and the FPGA chip according to the first firmware strategy parameter acquired from the first memory, wherein the third memory is used for storing accelerator card backup firmware.

In one possible design, the firmware policy parameters further include a second firmware policy parameter for characterizing a firmware tamper-resistant mode and a firmware auto-recovery mode, and the method further includes:

when the firmware strategy parameter is a second firmware strategy parameter, controlling the conduction of a channel between the second memory and the FPGA chip and controlling the disconnection of a channel between the third memory and the FPGA chip;

and if the first completion signal is not received within a preset time, controlling the connection of a channel between the third memory and the FPGA chip, controlling the disconnection of a channel between the second memory and the FPGA chip, and sending a reload instruction to the FPGA chip.

In a possible design, after controlling the conduction of the path between the third memory and the FPGA chip, the method further includes:

and if a second completion signal sent by the FPGA chip is received, controlling the disconnection of a channel between the third memory and the FPGA chip, wherein the second completion signal is used for representing the completion of the action of reloading the accelerator card backup firmware by the FPGA chip.

In one possible design, the firmware policy parameters further include a third firmware policy parameter for characterizing a firmware development board mode, and the method further includes:

and when the firmware strategy parameter is a third firmware strategy parameter, controlling the conduction of a channel between the second memory and the FPGA chip and controlling the disconnection of a channel between the third memory and the FPGA chip.

In one possible design, the firmware policy parameters further include a fourth firmware policy parameter for characterizing a firmware development board mode and a firmware auto-recovery mode, and the method further includes:

when the firmware strategy parameter is a fourth firmware strategy parameter, controlling the conduction of a channel between the second memory and the FPGA chip and controlling the disconnection of a channel between the third memory and the FPGA chip;

In one possible design, after firmware policy parameter upgrade information is received through the PCIE interface and the FPGA chip, the firmware policy parameters stored in the first memory are changed according to the firmware policy parameter upgrade information.

In a third aspect, an embodiment of the present application further provides an FPGA accelerator card, which includes an FPGA chip and any one of the firmware management devices for the FPGA chip in the first aspect.

In a fourth aspect, an embodiment of the present application further provides an electronic device, including the firmware management apparatus for an FPGA chip according to any one of the first aspects or including the FPGA accelerator card according to the third aspect.

In one possible design, the electronic device is a server or a kiosk that supports private computing.

For each of the second aspect to the fourth aspect and possible technical effects achieved by each aspect, please refer to the above description of the technical effects that can be achieved by the first aspect or various possible schemes in the first aspect, and details are not repeated here.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without inventive effort.

Fig. 1 is a schematic structural diagram of a firmware management apparatus for an FPGA chip according to an embodiment of the present disclosure;

fig. 2 is a schematic structural diagram of another firmware management apparatus for an FPGA chip according to an embodiment of the present disclosure;

fig. 3 is a schematic structural diagram of another firmware management apparatus for an FPGA chip according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram of another firmware management apparatus for an FPGA chip according to an embodiment of the present disclosure;

fig. 5 is a schematic flowchart of a firmware management method for an FPGA chip according to an embodiment of the present application;

fig. 6 is a schematic flowchart of another firmware management method for an FPGA chip according to an embodiment of the present disclosure;

fig. 7 is a schematic flowchart of another firmware management method for an FPGA chip according to an embodiment of the present disclosure;

fig. 8 is a schematic flowchart of another firmware management method for an FPGA chip according to an embodiment of the present disclosure;

fig. 9 is a schematic flowchart of another firmware management method for an FPGA chip according to an embodiment of the present disclosure;

fig. 10 is a flowchart illustrating another firmware management method for an FPGA chip according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is obvious that the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments in the present invention, all other embodiments obtained by a person skilled in the art without creative efforts belong to the protection scope of the present invention.

In the embodiments of the present application, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying relative importance, nor order.

Fig. 1 exemplarily shows a schematic structural diagram of a firmware management apparatus for an FPGA chip according to an embodiment of the present application, and as shown in fig. 1, the apparatus includes: a first memory 101, a second memory 102, a logic execution unit 103, and a control unit 104;

a first end of the control unit 104 is in signal connection with the first memory 101, a second end of the control unit 104 is in signal connection with a control end of the logic execution unit 103, and a first end of a third-end PGA chip of the control unit 104 is in signal connection; a first conduction end of the logic execution unit 103 is in signal connection with the second memory 102, and a second conduction end of the logic execution unit 103 is in signal connection with a second end of the FPGA chip;

the first memory 101 is used for storing at least one firmware strategy parameter, wherein the firmware strategy parameter comprises a first firmware strategy parameter used for characterizing a firmware tamper-proof mode;

the second memory 102 is used for storing an acceleration card firmware;

the control unit 104 is configured to obtain a firmware policy parameter, send a first on control instruction to the logic execution unit 103 when the firmware parameter is a first firmware policy parameter, and send a first off control instruction to the logic execution unit 103 after receiving a first completion signal sent by the FPGA chip, where the first completion signal is used to represent that an action of loading the acceleration card firmware by the FPGA chip is completed;

the logic execution unit 103 is configured to, after receiving the first turn-on control instruction, turn on the path between the second memory 102 and the FPGA chip, and, after receiving the first turn-off control instruction, turn off the path between the second memory 102 and the FPGA chip.

The application discloses a firmware management device for an FPGA chip, if a firmware policy parameter stored in a first memory 101 is used for representing a first firmware policy parameter of a firmware tamper-resistant mode, a control unit 104 sends a first conduction control instruction to a logic execution unit 103, the logic execution unit 103 switches on a channel between a second memory 102 and the FPGA chip after receiving the first conduction control instruction, the FPGA chip loads an acceleration card firmware stored in the second memory 102, the control unit 104 sends a first disconnection control instruction to the logic execution unit 103 after receiving a first completion signal sent by the FPGA chip and used for representing that an action of loading the acceleration card firmware by the FPGA chip is completed, and the logic execution unit 103 disconnects the channel between the second memory 102 and the FPGA chip after receiving the first disconnection control instruction. After the action of loading the acceleration card firmware on the FPGA chip is completed, the logic execution unit 103 disconnects the path between the second memory 102 and the FPGA chip, so as to ensure that the acceleration card firmware stored in the second memory 102 cannot be tampered, thereby ensuring that the acceleration card operates normally.

In one embodiment, as shown in fig. 2, the firmware management apparatus for FPGA chip disclosed in the present application may further include a third memory 105 for storing the accelerator card backup firmware;

the third conducting terminal of the logic execution unit 103 is in signal connection with the third memory 105;

the control unit 104 is further configured to send a second disconnection control instruction to the logic execution unit 103 when the firmware policy parameter is the first firmware policy parameter;

the logic execution unit 103 is further configured to disconnect the path between the third memory 105 and the FPGA chip after receiving the second disconnection control instruction.

In the embodiment of the present application, when the device includes the third memory 105 for storing the backup firmware, and the firmware policy parameter stored in the first memory 101 is the first firmware policy parameter, the logic execution unit 103 firstly turns on the path between the second memory 102 and the FPGA chip, turns off the path between the third memory 105 and the FPGA chip, and turns off the path between the second memory 102 and the FPG chip after the FPGA chip finishes loading the acceleration card firmware stored in the second memory 102, thereby preventing the FPGA chip from being turned on simultaneously with the second memory 102 and the third memory 105, and ensuring the normal operation of the acceleration card.

It should be noted that the accelerator card backup firmware stored in the third memory 105 may be the same as the accelerator card firmware stored in the second memory 102, or may be a lower version of the accelerator card firmware stored in the second memory 102.

After the firmware tamper-proof mode is executed, the accelerator card can realize specific service functions without worrying about the loss of the service functions or the failure of the accelerator card caused by the rewriting of the firmware of the accelerator card.

The firmware policy parameters disclosed in the embodiment of the present application may further include, in addition to the first firmware policy parameter, a second firmware policy parameter for characterizing a firmware tamper-resistant mode and a firmware automatic recovery mode, a third firmware policy parameter for characterizing a firmware development board mode, and a fourth firmware policy parameter for characterizing a firmware development board mode and a firmware automatic recovery mode, and the apparatus disclosed in the present application is described in detail below based on different firmware policy parameters, respectively.

When the firmware policy parameter is a second firmware policy parameter for representing a firmware tamper-resistant mode and a firmware automatic recovery mode, the control unit 104 is further configured to send a first on control instruction and a second off control instruction to the logic execution unit 103, and if a first completion signal is not received within a preset time period, send the first off control instruction and the second on control instruction to the logic execution unit 103, and send a reload instruction to the FPGA chip; the logic execution unit 103 is further configured to turn on a path between the third memory 105 and the FPGA chip after receiving the second turn-on control instruction.

In a specific implementation, the control unit 104 may include a timer, and the control unit 104 starts timing after sending the first on control instruction and the second off control instruction to the logic execution unit 103, and stops timing when the preset time length is reached.

In this embodiment, when the second firmware policy parameter is the second firmware policy parameter, the logic execution unit 103 firstly turns on a path between the second memory 102 and the FPGA chip, turns off a path between the third memory 105 and the FPGA chip, and the FPGA chip loads the acceleration card firmware stored in the second memory 102, if the loading of the acceleration card firmware by the FPGA chip is completed within the preset time period, that is, the loading is successful, the logic execution unit 103 turns off the path between the second memory 102 and the FPGA chip, and if the loading of the acceleration card firmware by the FPGA chip is not completed within the preset time period, that is, the loading is failed, in order to ensure that the acceleration card can normally operate, the logic execution unit 103 turns on the path between the third memory 105 and the logic execution unit 103, and meanwhile, the control unit 104 sends a reload instruction to the FPGA chip, and the FPGA chip loads the acceleration card backup firmware stored in the third memory 105.

In the above embodiment, if the acceleration card firmware stored in the second memory 102 is damaged or a fault occurs during the process of upgrading the acceleration card firmware stored in the second memory 102, the FPGA chip fails to load the acceleration card firmware, that is, the acceleration card firmware is caused to be in error to cause the acceleration card to fail to operate.

It should be noted that, in other cases, that is, after the accelerator card is powered on, when the FPGA chip is turned on with the second memory 102, the FPGA chip may automatically load the accelerator card firmware stored in the second memory 102.

In a specific implementation, if the FPGA chip finishes loading the accelerator card backup firmware stored in the third memory 105, that is, the loading is successful, the FPGA chip sends a second completion signal to the control unit 104, where the second completion signal is used to represent that an action of reloading the accelerator card backup firmware by the FPGA chip is completed, the control unit 104 is further configured to send a second disconnection control instruction to the logic execution unit 103, and the logic execution unit 103 disconnects a path between the second memory 102 and the FPGA chip.

In addition, after the accelerator card backup firmware stored in the third memory 105 is loaded by the FPGA chip, the logic execution unit 103 may further disconnect a path between the third memory 105 and the FPGA chip.

The logic execution unit 103 disconnects the path between the second memory 102 and the FPGA chip, and disconnects the path between the third memory 105 and the FPGA chip, so that the accelerator card can be ensured to run smoothly after the firmware is loaded on the FPGA chip.

When the firmware policy parameter is a third firmware policy parameter for characterizing the firmware development board mode, the control unit 104 is further configured to send a first on control instruction and a second off control instruction to the logic execution unit 103.

Specifically, when the firmware policy parameter is the third firmware policy parameter, the logic execution unit 103 turns on the path between the second memory 102 and the FPGA chip, and turns off the path between the third memory 105 and the FPGA chip.

In the development board mode, a user is allowed to modify the accelerator card firmware, and in the mode, the accelerator card can be used as a development board for development verification.

When the firmware policy parameter is a fourth firmware policy parameter for characterizing the firmware development board mode and the firmware automatic recovery mode, the control unit 104 is further configured to send a first on control instruction and a second off control instruction to the logic execution unit 103, and if the first completion signal is not received within a preset time period, send the first off control instruction and the second on instruction to the logic execution unit 103, and send a reload instruction to the FPGA chip.

Specifically, when the firmware policy parameter is a fourth firmware policy parameter, the logic execution unit 103 firstly switches on the path between the second memory 102 and the FPGA chip, and switches off the path between the third memory 105 and the FPGA chip, if the loading of the accelerator card firmware in the second memory 102 by the FPGA chip is not completed within a preset time period, that is, the recording fails, the path between the second memory 102 and the FPGA chip is switched off, the path between the third memory 105 and the FPGA chip is switched on, and meanwhile, the control unit 104 sends a reload instruction to the FPGA chip, and the FPGA chip loads the accelerator card backup firmware stored in the third memory 105.

In this embodiment of the application, if the acceleration card firmware stored in the second memory 102 is damaged, or a fault occurs during the process of upgrading the acceleration card firmware stored in the second memory 102, the FPGA chip fails to load the acceleration card firmware, that is, the acceleration card firmware is in error to cause the acceleration card to fail to operate, and in order to ensure that the acceleration card can operate smoothly, the FPGA chip loads the acceleration card backup firmware stored in the third memory 105, so that the firmware management device for the FPGA chip disclosed in this embodiment of the application can reduce the probability that the acceleration card cannot operate.

In an embodiment, as shown in fig. 3, the apparatus disclosed in the present application may further include a PCIE interface 301 in signal connection with the third end of the FPGA chip; the control unit 104 is further configured to, after receiving the firmware policy parameter upgrade information through the PCIE interface 301 and the FPGA chip, change the firmware policy parameters stored in the first memory 101 according to the firmware policy parameter upgrade information.

The PCIE interface 301 in this embodiment of the application is configured to change the firmware policy parameters stored in the first memory 101, specifically, the FPGA chip receives firmware policy parameter upgrade information through the PCIE interface 301, the FPGA chip sends the received firmware side crack parameter upgrade information to the control unit 104, and the control unit 104 sends the information to the first memory 101, so as to implement remote online upgrade on the firmware policy parameters stored in the first memory 101, so as to meet the requirement change of a user.

In a specific implementation, the second memory 102 may be a Flash memory, and the third memory 105 may also be a Flash memory. The logic execution unit 103 may be an analog switch.

As shown in fig. 4, a first terminal of the control unit 104 and the first memory 101 may be connected by an SPI signal. The first conducting end of the logic execution unit 103 and the second memory 102 may be connected by QSPI signals; a second conducting end of the logic execution unit 103 is connected with a second end of the FPGA chip through a QSPI signal; the third conducting terminal of the logic execution unit 103 is connected to the third memory 105 through a QSPI signal.

In a specific implementation, the firmware policy parameter may be a binary value, for example, the binary value in the first register represents a firmware tamper-proof mode and a development board mode, the binary value in the second register represents a firmware automatic recovery mode, the firmware tamper-proof mode is denoted by 01, the firmware development board mode is denoted by 11, the firmware automatic recovery mode is denoted by 11, and the process of determining the firmware policy parameter may be implemented by using two comparators, where one end of the first comparator is connected to the first register, the other end of the first comparator is connected to the reference terminal, one end of the second comparator is connected to the second register, the other end of the second comparator is connected to the reference terminal, and the value output by the reference terminal is 10; if the comparison result output by the first comparator is smaller and the comparison result output by the second comparator is larger, the firmware strategy parameter is determined to be a second strategy parameter for representing the firmware anti-tampering mode and the firmware automatic recovery mode; if the comparison result output by the first comparator is greater than the comparison result output by the second comparator is less than the comparison result output by the first comparator, determining the firmware strategy parameter as a third firmware strategy parameter for representing the firmware development board mode; and if the comparison result output by the first comparator is greater than the comparison result output by the second comparator, determining the firmware strategy parameter as a fourth firmware strategy parameter for representing the firmware development board mode and the firmware automatic recovery mode.

The firmware management device for the FPGA chip comprises a first memory 101, a second memory 102, a third memory 105, a control unit 104 and a logic execution unit 103, wherein the control unit 104 acquires firmware strategy parameters from the first memory 101 and sends different instructions to the logic execution unit 103 according to the different firmware strategy parameters, and after the logic execution unit 103 receives the different instructions, the second memory 102 and the FPGA chip are correspondingly connected or disconnected, and the third memory 105 and the FPGA chip are connected or disconnected, so that different modes are realized, and the current firmware strategy parameters stored in the first memory 101 can be changed in an online upgrading mode.

Based on the same utility model concept, the embodiment of the present application further provides a firmware management method for an FPGA chip, and the implementation of the method can refer to the implementation of the above-mentioned device, and repeated parts are not described again.

As shown in fig. 5, a flowchart of a firmware management method for an FPGA chip provided in an embodiment of the present application is schematically shown, where the method is applied to any one of the firmware management apparatuses for an FPGA chip, and the method includes the following steps:

s501, acquiring firmware strategy parameters from a first memory, wherein at least one firmware strategy parameter is stored in the first memory;

s502, when the firmware strategy parameter is a first firmware strategy parameter, controlling the conduction of a channel between a second memory and the FPGA chip, wherein the first firmware strategy parameter is used for representing a firmware anti-tampering mode;

s503, after receiving a first completion signal sent by the FPGA chip, controlling a path between the second memory and the FPGA chip to be disconnected, wherein the second memory stores an acceleration card firmware, and the first completion signal is used for representing that the action of loading the acceleration card firmware by the FPGA chip is completed.

The firmware management method for the FPGA chip, provided by the embodiment of the application, includes the steps of firstly obtaining a first firmware strategy parameter from a first storage, conducting a channel between a second storage and the FPGA chip when the first firmware strategy parameter is the first firmware strategy parameter for representing a firmware anti-tampering mode, and disconnecting the channel between the second storage and the FPGA chip after receiving a first completion signal sent by the FPGA, wherein the first storage stores at least one firmware strategy parameter, the second storage stores an acceleration card firmware, and the first completion signal represents that an action of loading the acceleration card firmware by the FPGA chip is completed. After the acceleration card firmware is loaded on the FPGA chip, the path between the second memory and the FPGA chip is disconnected, so that the acceleration card firmware stored in the second memory 102 cannot be tampered, and thus the normal operation of the acceleration card can be guaranteed.

In an embodiment, when the first firmware policy parameter is acquired from the first memory, the method further includes controlling a path between a third memory and the FPGA chip to be disconnected, where the third memory is used for storing the accelerator card backup firmware.

The third memory stores the accelerator card backup firmware, and if the accelerator card firmware in the second memory is rewritten, the original accelerator card firmware may be lost or replaced, so that the original function cannot be normally operated.

In the embodiment of the present application, the firmware policy parameters may include, in addition to the first policy parameter for ensuring the tamper-resistant mode, a second firmware policy parameter for characterizing the firmware tamper-resistant mode and the firmware automatic recovery mode, a third firmware policy parameter for characterizing the firmware development board mode, and a fourth firmware policy parameter for characterizing the firmware development board mode and the firmware automatic recovery mode, and the following describes the embodiment of the present application with respect to different policy parameters.

When the firmware strategy parameter is a second firmware strategy parameter, controlling the connection of a channel between the second memory and the FPGA chip and controlling the disconnection of a channel between the third memory and the FPGA chip; and if the first completion signal is not received within the preset time, controlling the connection of a channel between the third memory and the FPGA chip, controlling the disconnection of a channel between the second memory and the FPGA chip, and sending a reload instruction to the FPGA chip.

And after the passage between the third memory and the FPGA chip is controlled to be conducted, if a second completion signal sent by the FPGA chip is received, the passage between the third memory and the FPGA chip is controlled to be disconnected, wherein the second completion signal is used for representing the completion of the action of reloading the accelerator card backup firmware by the FPGA chip.

And when the firmware strategy parameter is a third firmware strategy parameter, controlling the conduction of a channel between the FPGA chips of the second memory and controlling the disconnection of a channel between the third memory and the FPGA chips.

When the firmware strategy parameter is a fourth firmware strategy parameter, controlling the connection of a channel between the second memory and the FPGA chip and controlling the disconnection of a channel between the third memory and the FPGA chip; and if the first completion signal is not received within the preset time, controlling the conduction of a channel between the third storage and the FPGA chip, controlling the disconnection of a channel between the second storage and the FPGA chip, and sending a reload instruction to the FPGA chip.

And after the firmware strategy parameter upgrading information is received through the PCIE interface and the FPGA chip, the firmware strategy parameters stored in the first memory are changed according to the firmware strategy parameter upgrading information.

According to the application, the following four different application scenarios can be realized by the accelerator card through changing different firmware strategy parameters.

Firmware tamper-resistant mode: if the accelerator card has fixed functions and is not expected to be used as development verification work, the development verification can be realized through a tamper-proof mode.

Firmware tamper-resistant mode and firmware auto-recovery mode: under the firmware tamper-proof mode, if the function of the accelerator card is lost after an error occurs in remote upgrading, the accelerator card can be ensured to continuously run through the mode.

Firmware development board mode: if the accelerator card needs to be used as a development board, it can be adjusted to a development board mode.

Firmware development board mode and firmware automatic recovery mode: in the development board mode, if the function of the accelerator card is lost after an error occurs in remote upgrading, the accelerator card can be ensured to continuously run through the mode.

The above four strategies can be upgraded in an online mode without being operated on the site of a machine room, so that the upgrading efficiency can be improved.

For ease of understanding, the present application is described below in terms of specific examples.

As shown in fig. 6, a schematic flowchart of a firmware management method for an FPGA chip provided in an embodiment of the present application is shown, where the method includes the following steps:

s601, electrifying the accelerator card;

s602, the control unit acquires firmware strategy parameters from the first memory and determines the firmware strategy parameters as first firmware strategy parameters for representing the tamper-proof mode;

s603, the control unit sends a first conduction control instruction and a second disconnection control instruction to the logic execution unit;

s604, after receiving the first conduction control instruction and the second disconnection control instruction, the logic execution unit conducts a channel between the second memory and the FPGA chip and disconnects a channel between the third memory and the FPGA;

s605, the FPGA chip loads an acceleration card firmware from the second memory;

s606, the control unit judges whether a first completion signal is received, if so, S607 is executed, otherwise, the control unit continues to wait;

the first completion signal is used for representing the completion of the action of loading the acceleration card firmware on the FPGA chip.

S607, the control unit sends a first disconnection control instruction to the logic execution unit;

and S608, after the logic execution unit receives the first disconnection control instruction, disconnecting the path between the second memory and the FPGA chip.

As shown in fig. 7, a schematic flowchart of another firmware management method for an FPGA chip provided in the embodiment of the present application is shown, where the method includes the following steps:

s701, powering on an accelerator card;

s702, the control unit acquires the firmware strategy parameters from the first memory and determines the firmware strategy parameters as second firmware strategy parameters for representing a tamper-proof mode and an automatic recovery mode;

s703, the control unit sends a first on control instruction and a second off control instruction to the logic execution unit;

s704, after the logic execution unit receives the first conduction control instruction and the second disconnection control instruction, a channel between the second storage and the FPGA chip is conducted, and a channel between the third storage and the FPGA chip is disconnected;

s705, the FPGA chip loads an acceleration card firmware from the second memory;

s706, the control unit judges whether a first completion signal is received within a preset time length, if so, S707 is executed, and if not, S709 is executed;

the preset time length is the time length for loading the acceleration card fixing piece by the FPGA chip, and the first completion signal is used for representing the completion of the action for loading the acceleration card fixing piece by the FPGA chip.

S707, the control unit sends a first disconnection control instruction to the logic execution unit;

s708, after receiving the first disconnection control instruction, the logic execution unit disconnects a channel between the second memory and the FPGA chip;

s709, the control unit sends a second conduction control instruction to the logic execution unit and sends a reload instruction to the FPGA chip;

s710, after receiving the second conduction control instruction, the logic execution unit conducts a channel between the third memory and the FPGA chip;

s711, after receiving the reload instruction, the FPGA chip loads the accelerator card backup firmware from the third memory;

s712, after the loading of the accelerator card backup firmware by the FPGA chip is completed, a second completion instruction is sent to the control unit;

s713, after receiving the second completion instruction, the control unit sends a second disconnection control instruction to the logic execution unit;

and S714, after the logic execution unit receives the second disconnection control instruction, disconnecting the passage between the third memory and the FPGA.

As shown in fig. 8, a schematic flowchart of another firmware management method for an FPGA chip provided in the embodiment of the present application is shown, where the method includes the following steps:

s801, electrifying the accelerator card;

s802, the control unit acquires the firmware strategy parameters from the first memory and determines the firmware strategy parameters as third firmware strategy parameters for representing a development board mode;

s803, the control unit sends a first on control instruction and a second off control instruction to the logic execution unit;

s804, after receiving the first conduction control instruction and the second disconnection control instruction, the logic execution unit conducts a channel between the second memory and the FPGA chip and disconnects a channel between the third memory and the FPGA;

and S805, the FPGA chip loads the acceleration card firmware from the second memory.

As shown in fig. 9, a schematic flowchart of another firmware management method for an FPGA chip according to an embodiment of the present application is provided, where the method includes the following steps:

s901, powering on an accelerator card;

s902, the control unit acquires the firmware strategy parameters from the first memory and determines the firmware strategy parameters as fourth firmware strategy parameters for representing a development board mode and an automatic recovery mode;

s903, the control unit sends a first on control instruction and a second off control instruction to the logic execution unit;

s904, after receiving the first conduction control instruction and the second disconnection control instruction, the logic execution unit conducts a channel between the second memory and the FPGA chip and disconnects a channel between the third memory and the FPGA;

s905, the FPGA chip loads an acceleration card firmware from the second memory;

s906, the control unit judges whether a first completion signal is received within a preset time length, if so, the process is ended, otherwise, the S907 is executed;

s907, the control unit sends a second conduction control instruction to the logic execution unit and sends a reload instruction to the FPGA chip;

s908, after the logic execution unit receives the second conduction control instruction, a channel between the third memory and the FPGA chip is conducted;

and S909, after the FPGA chip receives the reload instruction, loading the accelerator card backup firmware from the third memory.

As shown in fig. 10, a schematic flowchart of another firmware management method for an FPGA chip provided in the embodiment of the present application is shown, where the method includes the following steps:

s1001, electrifying the accelerator card to finish starting the accelerator card;

it should be noted that the accelerator card activation may be accomplished by any one of the above methods for activating the accelerator card.

S1002, handshaking identification between the upper computer and the accelerator card;

s1003, an upper computer instruction sequentially passes through the PCIE interface, the PCIE signal line, the FPGA chip, the interconnection interface, the control unit and the SPI, and firmware strategy parameters are written into the first memory;

it should be noted that the PCIE signal line is a signal line between the PCIE interface and the FPGA chip, the interconnection interface is an interface between the FPGA chip and the control unit, and the SPI is a signal interface between the control unit and the first memory.

And S1004, the control unit returns a response instruction through the interconnection interface, the FPGA chip, the PCIE signal line and the PCIE interface, and the response instruction is used for representing the completion of the action of writing the firmware strategy parameters.

The method finishes the online upgrade of the firmware strategy parameters, and executes new firmware strategy parameters when the accelerator card is shut down and restarted next time. By the mode, remote online upgrading can be realized, and the acceleration card can be upgraded and maintained conveniently to meet the requirement change of a user.

Based on the same utility model design, this application embodiment still provides an FPGA accelerator card, including the FPGA chip with as above-mentioned arbitrary a firmware management device for the FPGA chip, this FPGA accelerator card's implementation can refer to the implementation of above-mentioned any one firmware management device for the FPGA chip, and repeated part is no longer repeated.

Based on the same utility model concept, this application embodiment still provides an electronic equipment, this electronic equipment include any one of the aforesaid a firmware management device for FPGA chip or including above-mentioned FPGA accelerator card, this electronic equipment's implementation can refer to any one of the aforesaid implementation of a firmware management device for FPGA chip, and repeated part is no longer repeated.

Specifically, the electronic device may be a server or an all-in-one machine supporting privacy computing.

Various modifications and alterations of this invention may be made by those skilled in the art without departing from the spirit and scope of this invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A firmware management apparatus for an FPGA chip, the apparatus comprising: the device comprises a first memory, a second memory, a logic execution unit and a control unit;

a first end of the control unit is in signal connection with the first memory, a second end of the control unit is in signal connection with a control end of the logic execution unit, and a third end of the control unit is in signal connection with a first end of the FPGA chip; the first conduction end of the logic execution unit is in signal connection with the second memory, and the second conduction end of the logic execution unit is in signal connection with the second end of the FPGA chip;

the control unit is configured to acquire a first firmware policy parameter stored in the first memory, send a first on control instruction to the logic execution unit, and send a first off control instruction to the logic execution unit after receiving a first completion signal sent by the FPGA chip, wherein the first firmware policy parameter is used for representing a firmware tamper-resistant mode;

the logic execution unit is configured to, after receiving the first conduction control instruction, conduct a path between the second memory and the FPGA chip to enable the FPGA chip to load the firmware stored in the second memory, and, after receiving the first disconnection control instruction, disconnect the path between the second memory and the FPGA chip.

2. The apparatus of claim 1, further comprising a third memory for storing backup firmware;

the control unit is further configured to obtain the first firmware policy parameter stored in the first memory, and send a second disconnection control instruction to the logic execution unit;

3. The apparatus of claim 2,

the control unit is further configured to acquire a second firmware policy parameter stored in the first memory, and send the first on control instruction and the second off control instruction to the logic execution unit; if the first completion signal is not received within a preset time length, sending the first off control instruction and the second on control instruction to the logic execution unit, and sending a re-downloading instruction to the FPGA chip, wherein the second firmware strategy parameter is used for representing a firmware anti-tampering mode and a firmware automatic recovery mode;

the logic execution unit is further configured to, after receiving the second conduction control instruction, conduct a path between the third memory and the FPGA chip to enable the FPGA chip to load the backup firmware.

4. The apparatus of claim 3,

the control unit is further configured to send the second disconnection control instruction to the logic execution unit if a second completion signal sent by the FPGA chip is received after the re-download instruction is sent to the FPGA chip.

5. The apparatus of claim 2,

the control unit is further configured to obtain a third firmware policy parameter stored in the first memory, send the first on control instruction to the logic execution unit, and send the second off control instruction to the logic execution unit, where the third firmware policy parameter is used to characterize a firmware development board mode.

6. The apparatus of claim 3,

the control unit is further configured to acquire a fourth firmware policy parameter stored in the first memory, and send the first on control instruction and the second off control instruction to the logic execution unit; and if the first completion signal is not received within a preset time, sending the first disconnection control instruction and the second connection instruction to the logic execution unit, and sending a re-downloading instruction to the FPGA chip, wherein the fourth firmware strategy parameter is used for representing a firmware development board mode and a firmware automatic recovery mode.

7. The apparatus according to any one of claims 1 to 6, wherein the apparatus further comprises a PCIE interface in signal connection with a third terminal of the FPGA chip;

the control unit is further configured to receive firmware policy parameter upgrade information through the PCIE interface and the FPGA chip, and change the firmware policy parameters stored in the first memory.

8. The apparatus of any of claims 2 to 6, wherein the second memory is a Flash memory and/or the third memory is a Flash memory.

9. The apparatus of any of claims 1-6, wherein the logic execution unit is an analog switch.

10. The apparatus according to any one of claims 1 to 6, wherein a first terminal of the control unit is connected to the first memory through an SPI signal.

11. The apparatus of any of claims 1-6, wherein the first pass terminal of the logic execution unit is connected to the second memory via a QSPI signal; and/or

12. The apparatus of any of claims 2 to 6, wherein the third pass terminal of the logic execution unit is connected to the third memory via a QSPI signal.

13. An FPGA accelerator card comprising an FPGA chip and the firmware management apparatus for the FPGA chip as claimed in any one of claims 1 to 12.

14. An electronic device comprising a firmware management device for an FPGA chip according to any one of claims 1 to 12 or comprising an FPGA accelerator card according to claim 13.

15. The electronic device of claim 14, wherein the electronic device is a server or kiosk that supports privacy computing.