A package-compatible heterogeneous multi-core chip startup extension method and device and chip

Abstract

The application discloses a package-compatible heterogeneous multi-core chip starting expansion method and device and a chip, and the method comprises the following steps: step S1, configuring a starting configuration bit, wherein the starting configuration bit is provided with a configuration bit of an expansion starting mode, and the expansion starting mode is a mode of taking a non-main starting XPU core as a host to complete starting; step S2, after the chip exits power-on reset or hot reset, reading the value of the starting configuration bit, and if it is the expansion starting mode, sending an enabling signal; step S3, when the enabling signal of the expansion starting mode is received, controlling to start a target peripheral clock, and mapping a target XPU core access address space to a target storage space; and step S4, writing a starting program required for starting into the target storage space, and completing starting configuration of the target XPU core. The application can expand to realize that the non-main starting XPU core is taken as the host to start, and has the advantages of suitable flexibility, strong expansibility, low implementation cost and the like.

Description

Technical Field

[0001] This invention relates to the field of heterogeneous multi-core microprocessor chip technology, and in particular to a package-compatible heterogeneous multi-core chip boot expansion method, apparatus and chip. Background Technology

[0002] Heterogeneous multi-core microprocessor SoC systems possess extremely high integration and complexity, making them the mainstream microprocessor chips today. The self-booting mechanism of heterogeneous multi-core chips serves as the interface between the embedded processor and its supporting packaging and board designs. It is crucial for the robust application of embedded processors, thus making the chip's self-booting process a critical step in achieving high-performance chips.

[0003] For the self-booting of heterogeneous multi-core microprocessor chips, existing technologies typically rely on a specific type of processing core (XPU, such as CPU, DSP, or GPU) as the primary boot core to complete the system startup initialization configuration. This means that only one type of XPU core is designated as the sole primary boot core, thus only supporting one type of XPU core as the primary boot core. All other programmable cores can only act as secondary cores. However, in practical applications, user boot requirements may be diverse. For example, users may need to use other non-primary XPU cores for booting. The aforementioned solutions, which only support one type of XPU core as the primary boot core, cannot meet these diverse boot needs.

[0004] For released chips, the main boot core configuration is fixed. This released heterogeneous multi-core microprocessor chip has only one main boot core. In order to meet the needs of users to use different main boot cores to complete system boot, the current solution is to redesign the boot scheme. However, since the boot program (ROM Boot Loader, RBL) is usually fixed in the chip's non-erasable non-volatile memory (BOOTROM) to ensure security and the integration of heterogeneous multi-core processors, the RBL is difficult to modify. It is necessary to modify the corresponding circuit in the chip and then redesign the matching package and board to achieve the purpose of modifying the boot scheme. This will greatly increase the implementation cost and extend the product cycle.

[0005] Chinese patent application CN116594953A discloses a multi-core heterogeneous chip based on PCIe interconnect, a boot method, and a system. This solution uses a PCIe interconnect to enable each sub-chip in the multi-core heterogeneous chip to independently load and run its corresponding boot image using a single boot software package, thus achieving joint computing across multiple sub-chips. However, this type of solution still only supports one type of kernel as the primary boot core to complete system startup, and cannot meet the needs of using other non-primary boot cores for startup, requiring additional resources to complete the boot process. Summary of the Invention

[0006] The technical problem to be solved by this invention is: In view of the technical problems existing in the prior art, this invention provides a heterogeneous multi-core chip boot expansion method, device and chip that is simple to operate, flexible in application, highly scalable, low in implementation cost and compatible in packaging. It does not require changes to chip packaging and board design, and can make full use of existing resources to expand and realize a non-master boot XPU kernel as the host to complete the chip boot initialization configuration.

[0007] To solve the above-mentioned technical problems, the technical solution proposed by this invention is as follows:

[0008] A package-compatible heterogeneous multi-core chip boot extension method is used to extend the chip boot process by using a non-host XPU kernel as the host. The steps include:

[0009] Step S1. Configure the boot mode in the boot configuration bit. The boot configuration bit is set with an extended boot mode configuration bit. The extended boot mode is a boot mode in which the target XPU kernel is used as the host to complete the chip boot. The target XPU kernel is a non-host boot XPU kernel.

[0010] Step S2. After the chip exits power-on reset or thermal reset, read the value of the startup configuration bit, determine the startup mode based on the value of the startup configuration bit, and if it is determined to be an extended startup mode, send an enable signal for the extended startup mode.

[0011] Step S3. When the enable signal of the extended boot mode is received, control the clock of the target peripheral to be turned on, and map the address space accessible after the target XPU core is powered on to the memory space connected to the target peripheral.

[0012] Step S4. Burn the boot program required for the target XPU kernel to the storage space of the target peripheral connection, so that the target XPU kernel can execute the boot program by accessing the storage space of the target peripheral connection after power-on, and complete the boot initialization configuration of the target XPU kernel as the host.

[0013] Further, in step S1, the reserved bits in the boot configuration bits are used as extended configuration bits to configure an extended boot mode in which a non-master boot XPU kernel is used as the host for booting, and the bits in the boot configuration bits other than the reserved bits are used as non-extended mode configuration bits to configure a non-extended boot mode in which the master boot XPU kernel is used as the host for chip booting.

[0014] Further, in step S2, the value of the boot configuration bit is read from the system-level control register after the chip exits power-on reset or thermal reset. If the value of the boot configuration bit indicates that the target XPU core is used as the host in the extended boot mode, an enable signal for the extended boot mode is sent to the on-chip interconnect network and the clock power management module. Otherwise, an invalid signal for the extended boot mode is sent to the on-chip interconnect network and the clock power management module.

[0015] Furthermore, in step S3, when the clock power management module receives the enable signal of the extended startup mode, it controls the target peripheral clock to be turned on when the power-on reset and warm reset are completed; when the clock power management module receives the invalid signal of the extended startup mode, it turns off the peripheral clock when the power-on reset and warm reset are completed.

[0016] Furthermore, in step S3, when the on-chip interconnect network receives the enable signal of the extended boot mode, it controls the address space accessible after the target XPU core is powered on to be mapped to the FLASH space of the target peripheral connection. When the on-chip interconnect network receives the invalid signal of the extended boot mode, it controls the target XPU core to complete the boot as a slave device.

[0017] Furthermore, in step S3, when an invalid signal for extended boot mode is received, the address space accessible after the XPU is powered on is divided into two segments. The first segment of the address space is mapped to the end of the on-chip memory space to store the page table configuration segment of the XPU, and the second segment of the address space is mapped to a designated memory space to store the jump program, so as to control the target XPU kernel to complete the boot process as a slave.

[0018] Furthermore, in step S4, the startup program required for the target XPU kernel to start includes a page table configuration program and a jump program. After the target XPU kernel is powered on, it accesses the storage space connected to the target peripheral to configure the page table and then jumps to execute the main program.

[0019] A package-compatible heterogeneous multi-core chip boot extension device for extending the chip boot process by using a non-master boot XPU kernel as the host, comprising:

[0020] The configuration module is used to configure the boot mode in the boot configuration bit. The boot configuration bit is set with an extended boot mode configuration bit. The extended boot mode is a boot mode in which the target XPU kernel is used as the host to complete the chip boot. The target XPU kernel is a non-host boot XPU kernel.

[0021] The startup mode determination module is used to read the value of the startup configuration bit after the chip exits power-on reset or thermal reset, determine the startup mode based on the value of the startup configuration bit, and send an enable signal for extended startup mode if it is determined to be an extended startup mode.

[0022] The extended boot mode configuration module is used to control the activation of the target peripheral clock when the extended boot mode enable signal is received, and to map the address space accessible by the target XPU kernel after power-on to the memory space connected to the target peripheral.

[0023] The program burning module is used to burn the boot program required for the target XPU kernel to the storage space of the target peripheral connection, so that the target XPU kernel can execute the boot program by accessing the storage space of the target peripheral connection after power-on, and complete the boot initialization configuration of the target XPU kernel as the host.

[0024] A heterogeneous multi-core chip includes a processor and a memory, wherein the memory is used to store a computer program and the processor is used to execute the computer program to perform the above-described method.

[0025] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above.

[0026] Compared with existing technologies, the advantages of this invention are as follows: This invention addresses the booting of heterogeneous multi-core microprocessor chips that have only one main boot core. By extending the configuration bit of the boot configuration bit to include an extended boot mode, which corresponds to a boot mode where a non-main boot XPU core acts as the host to complete the chip boot, the boot mode is determined by reading the value of the boot configuration bit after the chip exits power-on reset or hot reset. If it is an extended boot mode, the clock of the target peripheral is enabled, and the address space accessible after the target XPU core is powered on is mapped to the memory space connected to the target peripheral. Then, the boot program required for the target XPU core to boot is burned into the memory space connected to the target peripheral and executed. This allows the original non-main boot XPU core to be extended into the host to complete the initialization configuration for system booting using existing on-chip resources, without changing the original chip packaging and board design. It can achieve package-compatible heterogeneous multi-core chip boot extension, reduce chip production design costs and production design cycle, and improve chip scalability, reliability, and stability. Attached Figure Description

[0027] Figure 1 This is a schematic diagram illustrating the implementation process of the XPU as a slave kernel in the traditional boot scheme.

[0028] Figure 2 This is a schematic diagram illustrating the implementation process of the heterogeneous multi-core chip boot extension method with package compatibility in this embodiment. Detailed Implementation

[0029] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0030] As disclosed in this invention, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. The words "first," "second," and similar terms used in this invention disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, words such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects.

[0031] To facilitate understanding, the relevant technical background of the present invention will first be introduced by way of example.

[0032] To ensure the reliability of chip self-booting, heterogeneous multi-core microprocessor chips use hardware-fixed code to store the RBL in a non-erasable memory bank, which is connected to the on-chip interconnect network bus. Only one type of XPU core is configured as the sole master core to read the RBL program from the memory bank and then load it into the core for execution via the on-chip interconnect network bus. Other XPU cores act as slave cores, and the slave cores execute the corresponding XPU user program by continuously checking whether the entry address register has a value.

[0033] Heterogeneous multi-core microprocessor chips may have multiple primary boot cores or only one. For released heterogeneous multi-core microprocessor chips with only one primary boot core, the configuration is fixed; only this single primary boot XPU core can be used for booting, while previously non-primary boot XPU cores can only boot as slave cores. For example... Figure 1 As shown, this non-master boot XPU kernel, by default, loops through the ROM space of the BOOTROM to check if the entry address register has a value. If a value is found, it jumps to the corresponding address for execution; if the value is 0, it waits. Specifically, the master boot XPU kernel configures the entry address register of this non-master boot XPU kernel, causing the non-master boot XPU to switch its access from ROM space to RAM space. This allows it to jump to the tail space of on-chip memory to execute the page table configuration program, and then jumps to the main program for execution.

[0034] The released heterogeneous multi-core microprocessor chips have three boot methods: NoBoot boot, Slave Boot boot, and Host Boot boot. NoBoot boot involves burning the user program into a readable and writable memory space, allowing the master core to execute from a specified address. Slave Boot involves placing the user program in peripheral memory, with the RBL program reading the user program from the peripheral memory, loading it into the internal readable and writable memory space, and then jumping to the user program to begin execution. Host Boot involves an external host (PCIe, SRIO, etc.) first loading the user program into the chip's internal memory space, then the external host writes the kernel's entry address into the corresponding entry address register and issues a boot completion flag, indicating that the external host has completed loading the user program. At this point, the RBL detects that the external host's transfer is complete and jumps to the user program.

[0035] Currently released heterogeneous multi-core microprocessor chips typically boot using Host Boot or Slave Boot methods, with the specific process usually as follows:

[0036] 1. First, the configuration segment, user program segment, and entry address segment are stored in the Boot Image. The Boot Image has two formats depending on the boot method: Raw format and BootTable format. The Raw format is a pure binary format, which is directly burned into the directly addressable readable and writable storage space. It is mainly used for NoBoot boot and Host Boot for some external hosts that know the internal address space of the chip. The BootTable format is used for Slave Boot and Host Boot for some external hosts that do not know the internal address space of the chip.

[0037] 2. After the chip is reset, the main core executes the RBL program, reads the boot configuration bits, determines the boot method, and sets the corresponding peripherals for initialization according to different user needs;

[0038] 3. Depending on the boot method, the user program can be read directly from the directly addressable memory space or moved from the FLASH connected to the peripheral device to the destination address (internal readable and writable memory space), or the user program can be moved to the destination address by the high-speed peripheral device as the host, and the corresponding value can be written into the entry address register of the XPU kernel.

[0039] 4. Other non-master XPU kernels act as slave kernels. When each kernel detects that the entry address register has a value, it jumps to its own user program for execution.

[0040] The aforementioned heterogeneous multi-core microprocessor chip's boot method only supports a single XPU core as the main boot core to complete the system boot initialization configuration. Other cores can only boot as slave cores, and it cannot support multiple different main boot cores to complete autonomous boot. Therefore, it cannot meet the user's need to use the original non-main boot XPU core as the main boot core, nor can it meet the usage habits and diverse needs of different users. For the released chips, if we want to meet the user's need to use different main boot cores to complete the system boot, we can only redesign the boot scheme and modify the corresponding circuit. Redesigning the matching package and board will greatly increase the implementation cost and extend the product cycle.

[0041] Encapsulation compatibility refers to enabling new or modified components to integrate with existing systems without altering the existing system interfaces, thus maintaining the external interface unchanged.

[0042] This invention addresses the booting of heterogeneous multi-core microprocessor chips that have only one main boot core. It extends the boot configuration by setting an extended boot mode in the boot configuration bit. This extended boot mode corresponds to using a non-main boot XPU core as the host to complete the chip boot. After the chip exits power-on reset or hot reset, the boot mode is determined by reading the value of the boot configuration bit. If it is an extended boot mode, the target peripheral clock is enabled, and the address space accessible after the target XPU core powers on is mapped to the memory space connected to the target peripheral. The boot program required for the target XPU core is then burned into the memory space connected to the target peripheral and executed. This allows the original non-main boot XPU core to be extended into a host to complete the initial configuration for system booting using existing on-chip resources, without changing the original chip packaging or board design. It enables package-compatible heterogeneous multi-core chip boot extension, reducing chip production design costs and production design cycles, while improving chip scalability, reliability, and stability.

[0043] This invention achieves package-compatible heterogeneous multi-core chip boot extension, which can not only meet the boot requirements of users with different XPU cores, allowing users to flexibly choose different XPU cores for booting according to their own needs and usage habits, but also achieve package compatibility, avoiding the need to modify circuits and redesign packages and boards due to redesigning boot schemes. This greatly reduces the chip production and design costs and production and design cycle, and simplifies the chip production and maintenance process, thereby improving the scalability and applicability of heterogeneous multi-core chip self-boot extension.

[0044] The present invention will be further described below with reference to specific embodiments.

[0045] like Figure 2As shown, this embodiment encapsulates a compatible heterogeneous multi-core chip boot extension method to extend the chip boot process by using a non-master boot XPU kernel as the host. The steps include:

[0046] Step S1. Configure the boot mode in the boot configuration bit. The boot configuration bit has an extended boot mode configuration bit. The extended boot mode is the boot mode in which the target XPU kernel is used as the host to complete the chip boot. The target XPU kernel is a non-host XPU kernel.

[0047] In this embodiment, by extending the configuration bits for the extended boot mode in the boot configuration bits, an extended boot mode is configured to use a non-primary boot XPU kernel as the host to complete the chip boot process. Optionally, reserved bits in the boot configuration bits can be used as extended configuration bits; that is, by configuring the reserved bits in the boot configuration bits, the boot mode can be configured to use a non-primary boot XPU kernel as the host to boot. Alternatively, bits other than reserved bits in the boot configuration bits can be used as non-extended mode configuration bits to configure a non-extended boot mode where the primary boot XPU kernel is used as the host to complete the chip boot process; that is, the normal boot mode where the original primary boot XPU kernel is used as the host.

[0048] Understandably, other methods can be used to configure the boot configuration bits according to actual needs. For example, different values ​​of the same data bits can be used to correspond to the normal boot mode and the extended boot mode respectively.

[0049] This embodiment modifies the boot configuration bit to add an extended boot mode where the original non-main boot XPU kernel is used as the host boot kernel. This allows users to flexibly select the desired boot mode through the configuration of the boot configuration bit without adding any on-chip resources.

[0050] Step S2. After the chip exits power-on reset or thermal reset, read the value of the startup configuration bit, determine the startup mode based on the value of the startup configuration bit, and if it is determined to be extended startup mode, send the extended startup mode enable signal.

[0051] In this embodiment, the value of the boot configuration bit is read from the system-level control register after the chip exits power-on reset or thermal reset. If the value of the boot configuration bit indicates that the target XPU core is in extended boot mode as the host, an enable signal for extended boot mode is sent to the on-chip interconnect network and the clock power management module. Otherwise, an invalid signal for extended boot mode is sent to the on-chip interconnect network and the clock power management module.

[0052] For example, if a reserved bit of the boot configuration bit is added as a configuration bit for extended boot mode, the value of the boot configuration bit is locked by the system-level control register after power-on reset or thermal reset. Then, the value of the boot configuration bit is judged. If it is determined to be a newly added reserved bit configuration, the newly added XPU core as an extended boot mode enable signal (valid signal) for host boot is output to the on-chip interconnect network and clock power management module. If it is another value, the newly added XPU core as an extended boot mode invalid signal for host boot is output to the on-chip interconnect network and clock power management module.

[0053] Step S3. When the enable signal for extended boot mode is received, control the clock of the target peripheral to be turned on, and map the address space accessible after the target XPU kernel is powered on to the memory space connected to the target peripheral.

[0054] In this embodiment, when the clock power management module receives the extended boot mode enable signal (valid signal), it controls the target peripheral clock to be turned on at the end of the power-on reset or warm reset. When the clock power management module receives the extended boot mode invalid signal, it turns off the peripheral clock at the end of the power-on reset or warm reset. That is, the clock power management module controls the turning on or off of the target peripheral clock at the end of the power-on reset or warm reset based on whether the extended boot mode enable signal is valid. When the enable signal is valid, if it is determined that the power-on reset or warm reset has ended, it controls the turning on of the target peripheral clock to prepare for booting based on the newly added XPU kernel as the host. If the enabled signal is invalid, it controls the turning off of the peripheral clock at the end of the power-on reset or warm reset to prepare for booting with the original host XPU kernel as the host.

[0055] In this embodiment, the on-chip interconnect network monitors the extended boot mode enable signal in real time. When the on-chip interconnect network receives the extended boot mode enable signal, i.e., when the enable signal is valid, it controls the mapping of the address space accessible after the target XPU core is powered on to the FLASH space connected to the target peripheral. Specifically, it can be a space starting from the FLASH base address. When the on-chip interconnect network receives the extended boot mode invalid signal, it controls the target XPU core to complete the boot as a slave device.

[0056] Optionally, when the on-chip interconnect network receives an invalid signal for extended boot mode, the address space accessible after the XPU is powered on is divided into two segments. The first segment is mapped to the end of the on-chip memory space to store the page table configuration segment of the XPU, and the second segment is mapped to a designated memory space to store the jump program, so as to control the target XPU kernel to complete the boot process as a slave.

[0057] Specifically, the on-chip interconnect network controls the mapping of access addresses by monitoring the enable signal of the extended boot mode. If it receives an enable signal for a newly added XPU kernel to boot as a host, it maps the address space accessible after the XPU is powered on to the FLASH space connected to the destination peripheral. If it receives an invalid XPU host boot signal, it divides the address space accessible after the XPU is powered on into two segments. The on-chip interconnect network maps the first segment to the end of the on-chip memory space to store the XPU configuration program segment, and maps the second segment to the BOOTROM space to store the jump program, so as not to affect the logic of the XPU booting as a slave.

[0058] Understandably, other methods can also be used to control the target XPU kernel to complete the boot process as a slave, depending on actual needs.

[0059] Step S4. Burn the boot program required for the target XPU kernel to the storage space of the target peripheral connection, so that the target XPU kernel can execute the boot program by accessing the storage space of the target peripheral connection after power-on, and complete the boot initialization configuration of the target XPU kernel as the host.

[0060] In this embodiment, the boot program required for the target XPU kernel to start includes a page table configuration program and a jump program. If the current determination is an extended boot mode, the page table configuration program and the main program required for the target XPU kernel to start are burned into the FLASH storage space of the target peripheral. When the target XPU kernel is powered on, it can directly access the FLASH storage space of the peripheral. After the target XPU kernel is powered on, it executes the page table configuration by accessing the storage space connected to the target peripheral and then jumps to execute the main program. This realizes a packaged and compatible heterogeneous multi-core chip boot extension scheme that uses existing on-chip resources to extend the original non-main boot XPU kernel into a host to complete the system boot initialization configuration.

[0061] In specific application embodiments, the software module corresponding to the above method of the present invention can be used as a boot patch compatible with heterogeneous multi-core embedded processor products. This patch can be used to realize the boot extension of packaged and compatible heterogeneous multi-core chips. The original non-main boot core XPU can be flexibly used as the host for boot initialization configuration to meet the usage habits and diverse needs of different users. At the same time, it can avoid modifying the circuit, redesigning the package and board, etc., which greatly reduces the chip design and implementation cost and improves the chip's flexibility and applicability.

[0062] This embodiment also provides a package-compatible heterogeneous multi-core chip boot extension device for extending the chip boot process by using a non-master boot XPU kernel as the host, including:

[0063] The configuration module is used to configure the boot mode of the boot configuration bit. The boot mode includes an extended boot mode in which the target XPU kernel is used as the host to complete the chip boot. The target XPU kernel is a non-host boot XPU kernel.

[0064] The startup mode determination module is used to read the value of the startup configuration bit after the chip exits power-on reset or thermal reset, determine the startup mode based on the value of the startup configuration bit, and send an enable signal for extended startup mode if it is determined to be an extended startup mode.

[0065] The extended boot mode configuration module is used to control the activation of the target peripheral clock when the extended boot mode enable signal is received, and to map the address space accessible by the target XPU kernel after power-on to the memory space connected to the target peripheral.

[0066] The program burning module is used to burn the boot program required for the target XPU kernel to the storage space of the target peripheral connection, so that the target XPU kernel can execute the boot program by accessing the storage space of the target peripheral connection after power-on, and complete the boot initialization configuration of the target XPU kernel as the host.

[0067] The package-compatible heterogeneous multi-core chip boot extension device in this embodiment corresponds one-to-one with the package-compatible heterogeneous multi-core chip boot extension method described above, and will not be described in detail here.

[0068] This embodiment further provides a heterogeneous multi-core chip, including a processor and a memory, wherein the memory is used to store a computer program and the processor is used to execute the computer program to perform the method described above.

[0069] It is understood that the method described in this embodiment can be executed by a single device, such as a computer or server, or it can be applied to a distributed scenario where multiple devices cooperate to complete the task. In a distributed scenario, one of the multiple devices may execute only one or more steps of the method described in this embodiment, and the multiple devices interact to complete the method. The processor can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit, or one or more integrated circuits, and is used to execute relevant programs to implement the method described in this embodiment. The memory can be implemented using read-only memory (ROM), random access memory (RAM), static storage devices, and dynamic storage devices. The memory can store the operating system and other applications. When the method described in this embodiment is implemented through software or firmware, the relevant program code is stored in the memory and called and executed by the processor.

[0070] This embodiment further provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above.

[0071] Those skilled in the art will understand that the above embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create an implementation for the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0072] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Therefore, any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention should fall within the protection scope of the present invention.

Claims

1. A package-compatible heterogeneous multi-core chip boot extension method, used to extend the chip boot process by using a non-master boot XPU core as the host, characterized in that the steps include... include: Step S1. Configure the boot mode in the boot configuration bit. The boot configuration bit is set with an extended boot mode configuration bit. The extended boot mode is a boot mode in which the target XPU kernel is used as the host to complete the chip boot. The target XPU kernel is a non-host boot XPU kernel. Step S2. After the chip exits power-on reset or thermal reset, read the value of the startup configuration bit, determine the startup mode based on the value of the startup configuration bit, if it is determined to be an extended startup mode, send an extended startup mode enable signal to the on-chip interconnect network and clock power management module, otherwise send an extended startup mode invalid signal to the on-chip interconnect network and clock power management module. Step S3. When the on-chip interconnect network and the clock power management module receive the enable signal of the extended boot mode, control the clock of the target peripheral to be turned on, and map the address space accessible after the target XPU core is powered on to the memory space connected to the target peripheral. When the on-chip interconnect network receives the invalid signal of the extended boot mode, control the target XPU core to complete the boot as a slave. Step S4. Write the boot program required for the target XPU kernel to the storage space of the target peripheral connection, so that the target XPU kernel can execute the boot program by accessing the storage space of the target peripheral connection after power-on. The boot program required for the target XPU kernel includes a page table configuration program and a jump program. After the target XPU kernel is powered on, it executes the page table configuration by accessing the storage space of the target peripheral connection and then jumps to execute the main program to complete the boot initialization configuration of the target XPU kernel as the host.

2. The method for booting up a heterogeneous multi-core chip with package compatibility according to claim 1, characterized in that, In step S1, the reserved bits in the boot configuration bits are used as extended configuration bits to configure the extended boot mode where the non-master boot XPU kernel is used as the host to boot, and the bits other than the reserved bits in the boot configuration bits are used as non-extended mode configuration bits to configure the non-extended boot mode where the master boot XPU kernel is used as the host to complete the chip boot.

3. The method for booting up heterogeneous multi-core chips with packaging compatibility according to claim 1, characterized in that, In step S2, the value of the boot configuration bit is read from the system-level control register after the chip exits power-on reset or thermal reset. If the value of the boot configuration bit indicates that the target XPU core is being booted as the host in the extended boot mode, an enable signal for the extended boot mode is sent to the on-chip interconnect network and the clock power management module. Otherwise, an invalid signal for the extended boot mode is sent to the on-chip interconnect network and the clock power management module.

4. The method for booting up and extending a heterogeneous multi-core chip with package compatibility according to claim 3, characterized in that, In step S3, when the clock power management module receives the enable signal of the extended startup mode, it controls the target peripheral clock to be turned on when the power-on reset and warm reset are completed; when the clock power management module receives the invalid signal of the extended startup mode, it turns off the target peripheral clock when the power-on reset and warm reset are completed.

5. The packaging-compatible heterogeneous multi-core chip boot extension method according to claim 4, characterized in that, In step S3, when the on-chip interconnect network receives the enable signal for extended boot mode, it maps the address space accessible after the target XPU core is powered on to the FLASH space of the target peripheral connection.

6. The method for booting up a heterogeneous multi-core chip with package compatibility according to any one of claims 1 to 5, characterized in that, In step S3, when an invalid signal for extended boot mode is received, the address space accessible after the XPU is powered on is divided into two segments. The first segment is mapped to the end of the on-chip memory space to store the page table configuration segment of the XPU, and the second segment is mapped to a designated memory space to store the jump program, so as to control the target XPU kernel to complete the boot process as a slave.

7. A package-compatible heterogeneous multi-core chip boot extension device, used to extend the chip boot process by using a non-master boot XPU core as the host, characterized in that, include: The configuration module is used to configure the boot mode in the boot configuration bit. The boot configuration bit is set with an extended boot mode configuration bit. The extended boot mode is a boot mode in which the target XPU kernel is used as the host to complete the chip boot. The target XPU kernel is a non-host boot XPU kernel. The startup mode determination module is used to read the value of the startup configuration bit after the chip exits power-on reset or thermal reset, and determine the startup mode based on the value of the startup configuration bit. If it is determined to be an extended startup mode, an extended startup mode enable signal is sent to the on-chip interconnect network and the clock power management module; otherwise, an extended startup mode invalid signal is sent to the on-chip interconnect network and the clock power management module. The extended boot mode configuration module is used to control the target peripheral clock to be turned on when the on-chip interconnect network and the clock power management module receive the extended boot mode enable signal, and to map the address space accessible by the target XPU core after power-on to the memory space connected to the target peripheral. When the on-chip interconnect network receives the extended boot mode invalid signal, it controls the target XPU core to complete the boot as a slave. The program burning module is used to burn the boot program required for the target XPU kernel to the storage space connected to the target peripheral device, so that the target XPU kernel can execute the boot program by accessing the storage space connected to the target peripheral device after power-on. The boot program required for the target XPU kernel to start includes a page table configuration program and a jump program. After the target XPU kernel is powered on, it executes the page table configuration by accessing the storage space connected to the target peripheral device and then jumps to execute the main program to complete the boot initialization configuration of the target XPU kernel as a host.

8. A heterogeneous multi-core chip, comprising a processor and a memory, wherein the memory is used to store computer programs, characterized in that, The processor is used to execute the computer program to perform the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

Images