A multi-chip die system and chip start-up method
Patent Information
- Application Number
- CN202411697012.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-25
- Publication Date
- 2026-09-18
- Estimated Expiration
- 2044-11-25
AI Technical Summary
[0003]本申请的目的在于提供一种多芯片裸片系统及芯片启动方法,旨在解决多芯片裸片系统中芯片裸片的启动依赖于高速通信接口D2D(Die to Die,芯片裸片至芯片裸片)建链完成的问题
[0053] 1. The bootloader can be pushed between multiple dies without relying on the D2D interface.
Smart Images

Figure CN119645925B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of chip technology, and specifically relates to a multi-chip die system and a chip boot method. Background Technology
[0002] With increasing chip design complexity and rising costs of advanced manufacturing processes, multi-die architectures have become an effective solution to the challenges of designing large-scale chips. The boot process for multi-die architectures is complex, involving the collaborative work and initialization of multiple dies. Summary of the Invention
[0003] The purpose of this application is to provide a multi-chip die system and a chip boot method, which aims to solve the problem that the boot of the chip die in the multi-chip die system depends on the establishment of a high-speed communication interface D2D (Die to Die).
[0004] According to a first aspect of this application, a multi-chip die system is provided, comprising: a first chip die and at least one second chip die;
[0005] A corresponding low-speed communication interface is provided between the first chip die and the at least one second chip die;
[0006] The first chip die is connected to off-chip memory, and the second chip die is provided with on-chip memory.
[0007] After the first chip die loads and starts the first chip boot program from the external memory, it reads the second chip boot program from the external memory and pushes it to the on-chip memory of the at least one second chip die through the low-speed communication interface.
[0008] The at least one second chip die loads from the on-chip memory and starts the second chip bootloader.
[0009] In an optional implementation, after the at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die through the low-speed communication interface.
[0010] The at least one second chip die loads and starts the second operating system from the on-chip memory;
[0011] After the first chip die pushes the second operating system, it loads and starts the first operating system from the off-chip memory.
[0012] In an optional implementation, the first chip die and the at least one second chip die are further provided with corresponding high-speed communication interfaces;
[0013] After the first chip die pushes the second chip boot program, the high-speed communication interface of the first chip die is initialized;
[0014] After the at least one second chip die starts the second chip boot program, the high-speed communication interface of the at least one second chip die is initialized;
[0015] The first chip die and the at least one second chip die establish a communication link between the high-speed communication interface.
[0016] In an optional implementation, after the at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die through the high-speed communication interface;
[0017] The at least one second chip die loads and starts the second operating system from the on-chip memory;
[0018] After the first chip die pushes the second operating system, it loads and starts the first operating system from the off-chip memory.
[0019] In an optional implementation, the at least one second chip die is provided with a command register and a status register; the first chip die writes a command to the command register through the low-speed communication interface, and the at least one second chip die reads the command written by the first chip die from the command register;
[0020] The at least one second chip die writes a status to the status register, and the first chip die reads the status written by the at least one second chip die from the status register through the low-speed communication interface.
[0021] In an optional implementation, the first chip die reads the status written in the status register, and after determining that at least one second chip die has completed loading and running the chip boot code, writes a command to the command register to start pushing the second chip boot program, and after pushing the second chip boot program, writes a command to the command register to indicate that the second chip boot program push is complete.
[0022] The first chip die also reads the status written in the status register, and after determining that the at least one second chip die has completed the startup of the second chip boot program, writes a command to the command register to start pushing the second operating system, and writes a command to the command register to complete the pushing of the second operating system after the second operating system is pushed.
[0023] In an optional implementation, after the second chip die loads and completes the chip startup code, it writes the status of the completed startup of the chip startup code to the status register.
[0024] The at least one second chip die loads and starts the second chip boot program from the on-chip memory after determining that the first chip die has started pushing the second chip boot program and the pushing of the second chip boot program is completed by reading the command written in the command register, and also writes the status of the completion of starting the second chip boot program to the status register.
[0025] The at least one second chip die loads and starts the second operating system from the on-chip memory after determining that the first chip die has started pushing the second operating system and the pushing of the second operating system is completed by reading the command written in the command register, and also writes the status of the second operating system startup to the status register.
[0026] According to a second aspect of this application, a chip boot method is provided, the method being executed in the multi-chip die system described in the first aspect, the method comprising:
[0027] The first chip die loads the first chip boot program from the off-chip memory and starts;
[0028] The first chip die reads the second chip boot program from the off-chip memory and pushes it to the on-chip memory of at least one second chip die through the low-speed communication interface;
[0029] The at least one second chip die loads from the on-chip memory and starts the second chip bootloader.
[0030] In an optional implementation, the method further includes:
[0031] After the at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die through the low-speed communication interface;
[0032] The at least one second chip die loads and starts the second operating system from the on-chip memory;
[0033] After the first chip die pushes the second operating system, it loads and starts the first operating system from the off-chip memory.
[0034] In an optional implementation, the method further includes:
[0035] After the first chip die pushes the second chip boot program, the high-speed communication interface of the first chip die is initialized;
[0036] After the at least one second chip die starts the second chip boot program, the high-speed communication interface of the at least one second chip die is initialized;
[0037] The first chip die and the at least one second chip die establish a communication link between the high-speed communication interface.
[0038] In an optional implementation, the method further includes:
[0039] After the at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die through the high-speed communication interface;
[0040] The at least one second chip die loads and starts the second operating system from the on-chip memory;
[0041] After the first chip die pushes the second operating system, it loads and starts the first operating system from the off-chip memory.
[0042] In an optional implementation, the first chip die reads the second chip bootloader from the off-chip memory and pushes it to the on-chip memory of at least one second chip die via the low-speed communication interface, including:
[0043] The first chip die reads the status register set in the second chip die. After determining that at least one second chip die has completed loading and running the chip boot code, it writes a command to start pushing the second chip boot program to the command register set in the second chip die. After pushing the second chip boot program, it writes a command to the command register to indicate that the second chip boot program push is complete.
[0044] In an optional implementation, after the at least one second chip die starts the second chip bootloader, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die via the low-speed communication interface, including:
[0045] The first chip die reads the status register set in the second chip die. After determining that at least one second chip die has completed the startup of the second chip boot program, it writes a command to start pushing the second operating system to the command register set in the second chip die. After pushing the second operating system, it writes a command to the command register to complete the pushing of the second operating system.
[0046] In an optional implementation, the method further includes:
[0047] After the second chip die loads and completes the chip startup code, it writes the status of the completed startup of the chip startup code to the status register set in the second chip die.
[0048] The at least one second chip die loads and starts the second chip bootloader from the on-chip memory, including:
[0049] The at least one second chip die reads the commands written in the command register set within the second chip die. After determining that the first chip die has started pushing the second chip boot program and completed pushing the second chip boot program, it loads and starts the second chip boot program from the on-chip memory, and also writes the status of completing the startup of the second chip boot program to the status register.
[0050] In an optional implementation, the at least one second chip die loads and boots the second operating system from the on-chip memory, including:
[0051] The at least one second chip die reads the command register set within the second chip die, and after determining that the first chip die has started pushing the second operating system and completed the pushing of the second operating system, loads and starts the second operating system from the on-chip memory, and also writes the status of the completion of starting the second operating system to the status register set within the second chip die.
[0052] Compared with related technologies, the technical solution of this application has the following advantages:
[0053] 1. The bootloader can be pushed between multiple dies without relying on the D2D interface.
[0054] 2. Low-speed communication interfaces such as UART have relatively low data rates but good signal quality, resulting in high reliability of data transmission in dies.
[0055] 3. The program for initializing the D2D interface is merged into the Bootloader, which is burned into the Flash memory. The Bootloader can be updated at any time, increasing the flexibility of D2D interface initialization.
[0056] 4. When pushing OS to multiple dies, you can choose a low-speed communication interface such as UART or a D2D interface as needed.
[0057] 5. The push protocol and process effectively ensure the reliability of the push data.
[0058] 6. In addition to UART interfaces, low-speed communication interfaces such as I2C can also be used for similar applications, which can save the sideband signals of D2D interfaces.
[0059] 7. The UART master device's die can manage other dies through the UART interface, such as obtaining the status of other dies, and can directly issue reset commands or restart other dies.
[0060] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures and processes shown in the description and the accompanying drawings. Attached Figure Description
[0061] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0062] Figure 1 This is a schematic diagram of a multi-die chip system.
[0063] Figure 2 This is a schematic diagram of the structure of a multi-die chip system according to an exemplary embodiment of this application.
[0064] Figure 3 This is yet another schematic diagram of a multi-die chip system according to an exemplary embodiment of this application.
[0065] Figure 4 This is a schematic diagram of the startup process of two dies according to an exemplary embodiment of this application.
[0066] Figure 5 This is a schematic diagram of another startup process for two dies according to an exemplary embodiment of this application.
[0067] Figure 6 This is a schematic diagram of the push handshake protocol flow of two dies according to an exemplary embodiment of this application.
[0068] Figure 7This is a schematic diagram of the structure of a three-die chip system according to an exemplary embodiment of this application.
[0069] Figure 8 This is a schematic flowchart of a chip startup method according to an exemplary embodiment of this application. Detailed Implementation
[0070] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0071] In a multi-chip die setup, each die is typically an independent System-on-a-Chip (SoC). The software code accompanying an SoC usually consists of three parts: Bootcode, Bootloader, and OS (Operating System). Bootcode is the initial startup code, stored in the chip's ROM, and completes the initial boot process, configuring and initializing the chip clock, reset, and basic peripheral interfaces. The Bootloader and OS are stored in external Flash memory. After the Bootcode runs, the Bootloader and OS are loaded into the chip's internal cache and executed sequentially.
[0072] Each multi-chip die has only one external Flash memory. This Flash memory can only be connected to one of the chip dies. After the Bootcode runs, when each chip die needs to load the Bootloader and OS from the external Flash memory, only that one chip die can directly read the Flash memory. Other chip dies can only read the Flash memory through cross-chip die access to complete the entire chip boot process.
[0073] See Figure 1 As shown, the internal interconnection structure of the multi-chip die structure 101, which includes two die dies, is as follows:
[0074] Two dies 102 are interconnected via a D2D (Die to Die) interface 105. During the boot code execution phase on the die, Die0 and Die1 read the boot code from their respective on-chip ROMs to begin the chip boot process. After the boot code runs, Die0 directly loads the bootloader from Flash 103. After the bootloader runs, it loads the OS directly from Flash. After the boot code runs, Die1 first configures and initializes the D2D interface link with Die0. Typically, the two dies synchronize their states during D2D interface link establishment via sideband signal 104. This requires that the boot codes of Die0 and Die1 must contain D2D interface initialization code. Only after the D2D interface link is established can Die0 read Flash through the Die data path via the D2D interface to load the bootloader and OS.
[0075] The above multi-chip die boot process has the following problems:
[0076] 1. Die0 must rely on the establishment of the D2D interface to obtain the complete Bootloader and OS.
[0077] 2. D2D interfaces are usually high-speed interfaces. The code for initializing the D2D interface must be integrated into the bootcode and fixed in the on-chip ROM. After the chip is manufactured, the bootcode cannot be modified, which makes the D2D initialization code lack flexibility.
[0078] 3. For multi-chip dies that implement switching functions, such as Ethernet, PCIe, IB and other protocol switching chips, the D2D interface is the data path for protocol switching. Usually, the D2D interface is not used by the on-chip MCU (Microcontroller Unit) as a path to access external Flash. If it is used as a path to access external Flash, the system implementation complexity will increase significantly and will occupy the protocol data processing bandwidth.
[0079] Based on the above analysis, this application achieves the goal of enabling each die in a multi-chip die to boot correctly and reliably without relying on the D2D interface by interconnecting dies through a low-speed communication interface and using a custom reliable transmission protocol between dies.
[0080] See Figure 2 As shown, this application exemplarily provides a multi-chip die system, which includes: a first chip die and at least one second chip die;
[0081] A corresponding low-speed communication interface is provided between the first chip die and at least one second chip die;
[0082] The first chip die is connected to external memory, and the second chip die is equipped with internal memory.
[0083] After the first chip die loads and starts the first chip boot program from the external memory, it reads the second chip boot program from the external memory and pushes it to the on-chip memory of at least one second chip die through a low-speed communication interface.
[0084] At least one second chip die loads from on-chip memory and starts the second chip bootloader.
[0085] The following example, which includes a second die chip, illustrates the multi-die system proposed in this application.
[0086] For example, see Figure 2 As shown, in the two-chip die system 201, low-speed communication interfaces are added to both dies 202. Figure 2The diagram shows a low-speed communication interface, UART (Universal Asynchronous Receiver / Transmitter). It is understood that other low-speed communication interfaces besides UART are also applicable to this application. UART functional modules are added to two Die 202s (Die 1 is the first die, and Die 0 is the second die) as a link between Die 1 and Die 0. Die 1 contains the UART master device (Uart_M), and Die 0 contains the UART slave device (Uart_S). The UART slave device in Die 0 has an internal bus access interface, allowing direct access to the on-chip memory, i.e., the cached SRAM shown in the diagram. It is understood that the on-chip memory can also be ROM or other types of memory. Both Die10 and Die1 have internal ROMs for storing chip boot code. Upon power-up, the chip boot code is activated. Die1 then reads and starts the first chip bootloader from external memory (Flash203 as shown in the diagram), and reads the second chip bootloader and second operating system (OS) from external memory (Die0). Die1 can push the second chip bootloader and OS to the SRAM cache within Die0 via the UART interface 204. Die0 can then directly run the second chip bootloader and OS from its SRAM cache to complete the boot process. Die1 directly reads its first chip bootloader and OS from Flash203 to complete its boot process. After Die0 and Die1 complete their boot processes, the D2D interface is initialized and the connection is successfully established. The entire multi-chip die system completes its boot process and can begin normal operation. As can be seen, in this boot process, the push of the bootloader and operating system (OS) relies on a low-speed communication interface between dies, such as the UART interface, instead of the D2D interface. Because low-speed communication interfaces like the UART interface have relatively low data rates and good signal quality, they offer high reliability when transmitting data such as the bootloader and operating system (OS) between dies. For example, see... Figure 3 As shown, the multi-chip die system 301 includes two dies 302, Die0 and Die1, with an external Flash 303 connected to each die. Die0 and Die1 are interconnected by two sets of interfaces: one is a low-speed communication interface UART 304, mainly used for data push, including firmware push; the other is a D2D interface 305, which serves as a data path between the two dies. Figure 3 COM_REG 306 is the data push protocol register, which is mainly used for handshaking between two dies during the data push process.
[0087] In some alternative implementations, after at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of at least one second chip die through a low-speed communication interface.
[0088] At least one second chip die loads and boots a second operating system from on-chip memory;
[0089] After the second operating system is pushed to the first chip die, the first operating system is loaded and started from the off-chip memory.
[0090] For example, after the second chip bootloader is started on the second chip die, the first chip die also reads the second operating system from the external memory and pushes it to the second chip die via a low-speed communication interface. Upon receiving the second operating system, the second chip die starts the second operating system. The first chip die also reads the first operating system from the external memory and starts the first operating system. It is understood that the first chip die can also read and start the first operating system from the external memory after the first chip bootloader starts, and then push the second chip bootloader and the second operating system to the second chip die.
[0091] The following description of the chip die startup process in a multi-chip die system still uses two chip dies as an example.
[0092] For example, see Figure 4 As shown, the startup process for the bare chip includes:
[0093] 401: After power-on reset is removed, the MCUs of Die0 and Die1 read their respective chip bootcodes from the ROM in the die and start up.
[0094] 402: After the Die1 bootcode starts, Die1 reads the first chip bootloader from Flash.
[0095] 403: The MCU of Die1 is running the first chip bootloader, and the first chip bootloader has finished starting.
[0096] 404: Die1 reads the second chip bootloader from the Flash and pushes it to the on-chip cache SRAM (i.e., on-chip memory) of Die0 via UART. Die0 will be notified when the push begins and is completed.
[0097] 405: Die0 is waiting for the second chip bootloader to complete.
[0098] 406: The MCU of Die0 runs the second chip bootloader. The second chip bootloader starts successfully and notifies Die1 of the successful startup status.
[0099] 407: Die1 reads the second operating system (OS) from Die0's Flash memory and pushes it to Die0's on-chip cache SRAM via UART. Die0 will be notified when the push begins and is completed.
[0100] 408: Die0 is waiting for the second operating system (OS) to be pushed out.
[0101] 409: The MCU of Die0 is running the second operating system (OS). The second operating system (OS) has started successfully and notifies Die1 of the successful startup status.
[0102] 410: Die1 reads the first operating system OS from Flash and starts the first operating system OS.
[0103] It should be noted that after power-on reset and removal, the UART connecting the two dies can be used for data transmission. Furthermore, during the chip boot process, the second chip bootloader and second operating system (OS) on Die0 are pushed from Die1 via UART, suitable for chips with less stringent boot time requirements. Because the UART interface is a low-speed communication interface, and the OS is typically quite large, it requires a relatively long time to push.
[0104] In some optional implementations, the first chip die and at least one second chip die are also provided with corresponding high-speed communication interfaces;
[0105] After the first chip die pushes the second chip boot program, the high-speed communication interface of the first chip die is initialized.
[0106] After starting the second chip boot program, at least one second chip die initializes the high-speed communication interface of at least one second chip die;
[0107] A communication link is established between a first chip die and at least one second chip die via a high-speed communication interface.
[0108] For example, the interconnection between the first and second chip dies can have two sets of interfaces. One set is a low-speed communication interface, mainly used for data push, including firmware push; the other set is a D2D interface, serving as a data path between the two dies. Since the second operating system is relatively large, pushing it using the low-speed communication interface would be slow. Therefore, after the second chip bootloader starts, a communication link using the D2D interface can be established between the first and second chip dies, thereby pushing the second operating system through the D2D interface. In this exemplary embodiment, since the D2D interface can be initialized after the bootloader starts, the initialization program for the D2D interface can be incorporated into the bootloader. Because the bootloader is burned into external flash memory, it can be updated at any time, thus increasing the flexibility of D2D interface initialization.
[0109] In some optional implementations, after at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of at least one second chip die through a high-speed communication interface.
[0110] At least one second chip die loads and boots a second operating system from on-chip memory;
[0111] After the second operating system is pushed to the first chip die, the first operating system is loaded and started from the off-chip memory.
[0112] The following description of the chip die startup process in a multi-chip die system still uses two chip dies as an example.
[0113] For example, such as Figure 5 As shown, the startup process for the two bare chips includes the following steps:
[0114] 501: After power-on reset is removed, the MCUs of Die0 and Die1 read their respective bootcodes from the ROM inside the Die to start up.
[0115] 502: After the Die1 chip bootcode starts, Die1 reads the first chip bootloader from Flash.
[0116] 503: The MCU of Die1 runs the first chip bootloader, and the first chip bootloader starts.
[0117] 504: Die1 reads the second chip bootloader from the Flash and pushes it to the on-chip cache SRAM of Die0 via UART. Die0 is notified when the push begins and is completed.
[0118] 505: Die0 is waiting for the second chip bootloader to be pushed out.
[0119] 506: The MCU of Die0 runs the second chip bootloader. The second chip bootloader starts successfully and notifies Die1 of the successful startup status.
[0120] 507: The second chip bootloader of Die0 and the first chip bootloader of Die1 simultaneously perform the initialization configuration within the Die, including the initialization of the D2D interface, and start the D2D interface negotiation and connection establishment.
[0121] 508: The D2D interface between Die0 and Die1 was successfully established.
[0122] 509: Die1 reads the second operating system (OS) from the Flash memory of Die0 and pushes it into the on-chip cache SRAM of Die0 through the D2D interface. Die0 is notified when the push begins and when it is completed.
[0123] 510: Die0 is waiting for the second operating system (OS) to be pushed out.
[0124] 511: The MCU of Die0 runs the second operating system (OS). The second operating system (OS) starts successfully and notifies Die1 of the successful startup status.
[0125] 512: Die1 reads the first operating system OS from Flash and starts the first operating system OS.
[0126] It should be noted that in the chip boot process described above, the second chip bootloader of Die0 is pushed via UART, and the second operating system (OS) of Die0 is pushed by Die1 via the D2D interface. This is suitable for chips with high boot time requirements. The D2D interface is a high-speed interface, and the OS is usually quite large. Pushing the OS via the D2D interface can be completed in a very short time, shortening the chip boot time. Based on this exemplary embodiment and the aforementioned exemplary embodiments, the OS can be pushed via a low-speed communication interface such as UART or the D2D interface as needed.
[0127] In some optional implementations, at least one second chip die is provided with a command register and a status register; the first chip die writes commands to the command register through a low-speed communication interface, and at least one second chip die reads the commands written by the first chip die from the command register;
[0128] At least one second chip die writes a status to a status register, and the first chip die reads the status written by at least one second chip die from the status register through a low-speed communication interface.
[0129] For example, this application has at least the following three improvements over related technologies:
[0130] First, a low-speed communication interface such as UART is added between dies. Besides UART, other low-speed communication interfaces such as I2C, I3C, and USB can also be used, thus saving sideband signals on the D2D interface. Taking UART as an example, the UART interface needs hardware function matching between the two dies, such as... Figure 3 In the diagram, Die1 contains the UART master device (Uart_M), and Die0 contains the UART slave device (Uart_S). The UART slave device has bus access rights within Die0, and read / write commands received by the UART slave device can directly access the cached SRAM and protocol register group COM_REG within Die0.
[0131] Secondly, the handshake protocol when Die0 pushes data to Die1 is used to ensure the reliability of data push.
[0132] Finally, Die1 pushes the second chip bootloader and the second operating system (OS) to Die0, without Die0 needing to read them.
[0133] In some optional implementations, the first chip die, after determining that at least one second chip die has completed loading and running the chip boot code by reading the status written in the status register, writes a command to the command register to start pushing the second chip boot program, and writes a command to the command register to indicate that the second chip boot program push is complete after pushing the second chip boot program.
[0134] The first chip die also reads the status written in the status register. After determining that at least one second chip die has completed the startup of the second chip boot program, it writes a command to the command register to start pushing the second operating system, and writes a command to the command register to complete the push of the second operating system after the push is completed.
[0135] As described above, the second chip die of this application writes its own status to the status register. The first chip die reads the status of the second chip die from the status register and determines whether to push the second chip bootloader and / or the second operating system to the second chip die based on the status. Simultaneously, the first chip die also writes commands to the command register, including commands to start and complete the pushing of the second chip bootloader and / or the second operating system. The second chip die can determine the start or completion of the pushing of the second chip bootloader and / or the second operating system by reading the command register.
[0136] In some optional implementations, after the second chip die loads and completes the chip startup code, it writes the status of the completed chip startup code to the status register;
[0137] At least one second chip die loads and starts the second chip boot program from the on-chip memory after determining that the first chip die has started pushing the second chip boot program and has completed pushing the second chip boot program, by reading the command written in the command register. It also writes the status of completing the startup of the second chip boot program to the status register.
[0138] At least one second chip die loads and starts the second operating system from the on-chip memory after determining that the first chip die has started pushing the second operating system and has completed pushing the second operating system, by reading the command written in the command register. It also writes the status of the second operating system startup to the status register.
[0139] The following description uses a two-chip die system as an example to illustrate the process of completing the handshake protocol using the status register and command register during the chip die startup.
[0140] For example, Table 1 below shows the status or command written in the status register and command register and their corresponding meanings.
[0141] Table 1
[0142]
[0143] This application utilizes a custom push handshake protocol to ensure reliable push completion. In this custom handshake protocol, Figure 3The COM_REG 306 register group in Die0 can be understood as the handshake register. The COM_REG register group includes the CMD command register group and the STATUS status register group. The bit width of these two registers can be defined as needed, such as 32 bits. In this application, the definitions of the CMD and STATUS register groups are shown in Table 1 above. The handshake meaning of the register groups can be defined according to the push handshake protocol requirements. The CMD register is written to by Die1 and read by Die0; this register group is used by Die1 to send commands to Die0. The STATUS register is written to by Die0 and read by Die1; this register group is used by Die0 to provide status feedback to Die1.
[0144] The COM_REG register group, combined with the firmware push process, provides a complete firmware push protocol flow as follows: Figure 6 As shown:
[0145] 601: Die1 starts the chip bootcode; Die0 starts the chip bootcode. The default value of the CMD register in Die0 is CMD_IDLE, indicating that there is no valid command. The default value of the STATUS register is STATUS_IDLE, indicating the initial state.
[0146] 602: After the Die1 chip bootcode starts, it reads the first chip bootloader code from Flash and starts running it.
[0147] 603: After the DieO chip bootcode successfully starts, the value of the STATUS register group is updated to STATUS_CODE_OK, indicating that the bootcode has started successfully and is waiting for the second chip bootloader to be pushed.
[0148] The first chip bootloader running on Die1 reads the STATUS status of Die0 via UART to determine if Die0's bootcode has started successfully. If Die0's bootcode starts successfully, proceed to step 604; if Die0's STATUS remains in the STATUS_IDLE state, Die1 waits for a period of time and reads the STATUS status again. If Die0's STATUS remains in STATUS_IDLE for an extended period, it indicates that Die0's bootcode startup has failed. Die1 can then write Die0's CMD register to CMD_RST_DIE via UART, sending a reset command to Die0 to reset Die1 and restart it.
[0149] It should be noted that in the following steps, Die1 means "the bootloader running on Die1", and Die0 means "the bootcode running on Die0".
[0150] 604: Die1 writes CMD_LOAD_START to Die0's CMD register via UART, indicating that the second chip bootloader of Die0 has started to be pushed.
[0151] When Die0 reads the CMD register as CMD_LOAD_START, it begins receiving the bootloader push from the second chip.
[0152] 605: Die1 reads the second chip bootloader from Die0's Flash and pushes it to Die0's cache via UART until the push is complete.
[0153] The Die0 internal cache receives writes from the second chip's bootloader.
[0154] 606: After Die1 pushes the second chip bootloader, Die1 writes CMD_LOAD_OVER to Die0's CMD register via UART, indicating that the second chip bootloader push is complete.
[0155] When Die0 reads the CMD register as CMD_LOAD_OVER, it learns that the cache has finished receiving the second chip's bootloader.
[0156] 607: Die0 verifies the second chip bootloader. If the verification is successful, the STATUS register is updated to STATUS_LOAD_OK, and the second chip bootloader is successfully started and run. If the verification fails, the STATUS register is updated to STATUS_LOAD_FAIL.
[0157] Die1 reads the STATUS register of Die0 via the UART interface to determine whether the second chip bootloader of Die0 has successfully started. If the second chip bootloader of Die0 starts successfully, proceed to step 608; if the verification of the second chip bootloader of Die0 fails and the startup fails, Die1 re-initiates the push of the second chip bootloader.
[0158] 608: The first chip bootloader running on Die1 writes CMD_OS_START to the CMD register of Die0 via UART, indicating that the second operating system (OS) has started to be pushed.
[0159] When the second chip bootloader running on Die0 reads the CMD register as CMD_OS_START, it begins to receive the second operating system OS push.
[0160] It should be noted that in the following steps, Die1 means "the bootloader running on Die1", and Die0 means "the bootloader running on Die0".
[0161] 609: Die1 reads Die0's second operating system OS from Flash and pushes it to Die0's cache via UART until the push is complete.
[0162] Die0's internal cache receives writes from the second operating system (OS).
[0163] 610: After Die1 finishes pushing the second operating system OS, Die1 writes CMD_OS_OVER to Die0's CMD register via UART, indicating that the second operating system OS push is complete.
[0164] Die0 waits until the CMD register is CMD_OS_OVER, then it knows that the buffer has finished receiving the second operating system OS.
[0165] 611: Die0 verifies the second operating system (OS). If the verification is successful, the STATUS register is updated to STATUS_OS_OK, and the second operating system (OS) is successfully started and running. If the verification fails, the STATUS register is updated to STATUS_OS_FAIL.
[0166] Die1 reads Die0's STATUS register via the UART interface to determine whether Die0's second operating system (OS) has successfully started. If Die0's second OS starts successfully, proceed to step 612; if Die0's OS verification fails and startup fails, Die1 re-initiates the second OS push.
[0167] 612: Die1 loads Die1's first operating system (OS) from Flash and starts the first OS.
[0168] It should be noted that for steps 608 to 611, the D2D interface can also be used for OS push. Through the D2D interface, Die1 can also access the CMD and STATUS register groups of Die0. The push protocol process is the same, only the D2D interface connection is established before the push, and the Uart interface is replaced with the D2D interface.
[0169] In the above exemplary embodiment, a reliable transmission protocol and corresponding process between multiple dies are implemented using status registers, command registers, and defined corresponding states and commands, thereby ensuring the reliability of the pushed data. Furthermore, the dies of the UART master device can also manage other dies through the UART interface, such as obtaining the status of other dies through the status register and directly issuing reset commands or restarting other dies using the command register.
[0170] The multi-chip die system proposed in this application is also applicable to the interconnection and chip boot of three or more dies. That is to say, the second chip die may include one or more. If multiple second chip dies are included, each second chip die has a corresponding low-speed communication interface with the first chip die. The push protocol in the above two-chip die system is still applicable to systems with more than two dies.
[0171] For example, Figure 7 The diagram shows a three-die multi-chip bare die system, where 701 identifies the multi-chip bare die, 702 identifies the three dies: Die0, Die1 and Die2, 703 identifies the external flash, i.e., off-chip memory, 704 identifies the UART interconnect interface, 705 identifies the D2D interface between dies, and 706 identifies the CMD and STATUS registers used for push protocol within the die.
[0172] Accordingly, see Figure 8 As shown, this application exemplarily provides a chip boot method, which is executed in the above-described multi-chip die system. The method includes:
[0173] In step 801, the first chip die loads the first chip boot program from the off-chip memory and starts;
[0174] In step 802, the first chip die reads the second chip boot program from the off-chip memory and pushes it to the on-chip memory of at least one second chip die through a low-speed communication interface;
[0175] In step 803, at least one second chip die is loaded from on-chip memory and the second chip bootloader is started.
[0176] In some alternative implementations, the method also includes:
[0177] After at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of at least one second chip die through a low-speed communication interface.
[0178] At least one second chip die loads and boots a second operating system from on-chip memory;
[0179] After the second operating system is pushed to the first chip die, the first operating system is loaded and started from the off-chip memory.
[0180] In some alternative implementations, the method also includes:
[0181] After the first chip die pushes the second chip boot program, the high-speed communication interface of the first chip die is initialized.
[0182] After starting the second chip boot program, at least one second chip die initializes the high-speed communication interface of at least one second chip die;
[0183] A communication link is established between a first chip die and at least one second chip die via a high-speed communication interface.
[0184] In some alternative implementations, the method also includes:
[0185] After at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of at least one second chip die through a high-speed communication interface.
[0186] At least one second chip die loads and boots a second operating system from on-chip memory;
[0187] After the second operating system is pushed to the first chip die, the first operating system is loaded and started from the off-chip memory.
[0188] In some alternative implementations, the first chip die reads the second chip bootloader from off-chip memory and pushes it to the on-chip memory of at least one second chip die via a low-speed communication interface, including:
[0189] The first chip die reads the status register set within the second chip die. After determining that at least one second chip die has completed loading and running the chip boot code, it writes a command to start pushing the second chip boot program to the command register set within the second chip die. After pushing the second chip boot program, it writes a command to the command register indicating that the second chip boot program push is complete.
[0190] In some optional implementations, after at least one second chip die starts the second chip bootloader, the first chip die reads the second operating system from external memory and pushes it to the on-chip memory of at least one second chip die via a low-speed communication interface, including:
[0191] The first chip die reads the status register set within the second chip die. After determining that at least one second chip die has completed the startup of the second chip boot program, it writes a command to start pushing the second operating system to the command register set within the second chip die. After pushing the second operating system, it writes a command to the command register indicating that the second operating system push is complete.
[0192] In some alternative implementations, the method also includes:
[0193] After the second chip die loads and completes the chip startup code, write the status of the completed chip startup code to the status register set in the second chip die.
[0194] At least one second chip die loads and starts the second chip bootloader from on-chip memory, including:
[0195] At least one second chip die loads and starts the second chip boot program from its on-chip memory after determining that the first chip die has started pushing the second chip boot program and that the pushing of the second chip boot program is complete, by reading the command written in the command register set in the second chip die. It also writes the status of the completion of the second chip boot program startup to the status register.
[0196] In some alternative implementations, at least one second chip die loads and boots a second operating system from on-chip memory, including:
[0197] At least one second chip die reads the command register set within the second chip die, and after determining that the first chip die has started pushing the second operating system and completed the pushing of the second operating system, loads and starts the second operating system from the on-chip memory, and also writes the status of the completion of starting the second operating system to the status register set within the second chip die.
[0198] The above method can be implemented in the multi-chip die system provided in the above embodiments. For specific implementation details, please refer to the description of the multi-chip die system in the above embodiments, which will not be repeated here.
[0199] It is understood that the circuit structures, names, and parameters described in the above embodiments are merely examples. Those skilled in the art can also make readily conceived combinations and adjustments to the structural features of the above embodiments according to their needs, and the concept of this application should not be limited to the specific details of the above examples.
[0200] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A multi-chip die system, characterized in that, include: A first chip die and at least one second chip die; The first chip die and the at least one second chip die are simultaneously provided with corresponding low-speed communication interfaces and high-speed communication interfaces; The first chip die is connected to off-chip memory, and the second chip die is provided with on-chip memory. After the first chip die loads and starts the first chip boot program from the external memory, it reads the second chip boot program from the external memory and pushes it to the on-chip memory of the at least one second chip die through the low-speed communication interface. The at least one second chip die loads and starts the second chip boot program from the on-chip memory; Before establishing a communication link between the high-speed communication interfaces, after the at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die through the low-speed communication interface; The at least one second chip die loads and starts the second operating system from the on-chip memory; After the first chip die pushes the second operating system, it loads and starts the first operating system from the off-chip memory; wherein, the first chip die does not transmit the second chip boot program and the second operating system to the second chip die through the high-speed communication interface; After the first chip die pushes the second chip boot program, the high-speed communication interface of the first chip die is initialized. After the at least one second chip die starts the second chip boot program, the high-speed communication interface of the at least one second chip die is initialized; The first chip die and the at least one second chip die establish a communication link between the high-speed communication interface; The initialization program for the high-speed communication interface is incorporated into the chip bootloader.
2. The multi-chip die system according to claim 1, characterized in that, The at least one second chip die is provided with a command register and a status register; the first chip die writes a command to the command register through the low-speed communication interface, and the at least one second chip die reads the command written by the first chip die from the command register; The at least one second chip die writes a status to the status register, and the first chip die reads the status written by the at least one second chip die from the status register through the low-speed communication interface.
3. The multi-chip die system according to claim 2, characterized in that, The first chip die reads the status written in the status register. After determining that at least one second chip die has completed loading and running the chip boot code, it writes a command to the command register to start pushing the second chip boot program. After pushing the second chip boot program, it writes a command to the command register to indicate that the second chip boot program push is complete. The first chip die also reads the status written in the status register, and after determining that the at least one second chip die has completed the startup of the second chip boot program, writes a command to the command register to start pushing the second operating system, and writes a command to the command register to complete the pushing of the second operating system after the second operating system is pushed.
4. The multi-chip die system according to claim 2, characterized in that, After the second chip die loads and completes the chip startup code, it writes the status of the completed startup of the chip startup code to the status register; The at least one second chip die loads and starts the second chip boot program from the on-chip memory after determining that the first chip die has started pushing the second chip boot program and the pushing of the second chip boot program is completed by reading the command written in the command register, and also writes the status of the completion of starting the second chip boot program to the status register. The at least one second chip die loads and starts the second operating system from the on-chip memory after determining that the first chip die has started pushing the second operating system and the pushing of the second operating system is completed by reading the command written in the command register, and also writes the status of the second operating system startup to the status register.
5. A chip boot method, characterized in that, The method is performed in the multi-chip die system according to any one of claims 1-4, and the method includes: The first chip die loads the first chip boot program from the off-chip memory and starts; The first chip die reads the second chip boot program from the off-chip memory and pushes it to the on-chip memory of at least one second chip die through the low-speed communication interface; The at least one second chip die loads from the on-chip memory and starts the second chip bootloader.
6. The chip startup method according to claim 5, characterized in that, The method further includes: After the at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die through the low-speed communication interface; The at least one second chip die loads and starts the second operating system from the on-chip memory; After the first chip die pushes the second operating system, it loads and starts the first operating system from the off-chip memory.
7. The chip startup method according to claim 5, characterized in that, The method further includes: After the first chip die pushes the second chip boot program, the high-speed communication interface of the first chip die is initialized; After the at least one second chip die starts the second chip boot program, the high-speed communication interface of the at least one second chip die is initialized; The first chip die and the at least one second chip die establish a communication link between the high-speed communication interface.
8. The chip startup method according to claim 7, characterized in that, The method further includes: After the at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die through the high-speed communication interface; The at least one second chip die loads and starts the second operating system from the on-chip memory; After the first chip die pushes the second operating system, it loads and starts the first operating system from the off-chip memory.
9. The chip startup method according to claim 5, characterized in that, The first chip die reads the second chip boot program from the off-chip memory and pushes it to the on-chip memory of at least one second chip die via the low-speed communication interface, including: The first chip die reads the status register set in the second chip die. After determining that at least one second chip die has completed loading and running the chip boot code, it writes a command to start pushing the second chip boot program to the command register set in the second chip die. After pushing the second chip boot program, it writes a command to the command register to indicate that the second chip boot program push is complete.
10. The chip startup method according to claim 6, characterized in that, After the at least one second chip die starts the second chip boot program, the first chip die reads the second operating system from the off-chip memory and pushes it to the on-chip memory of the at least one second chip die through the low-speed communication interface, including: The first chip die reads the status register set in the second chip die. After determining that at least one second chip die has completed the startup of the second chip boot program, it writes a command to start pushing the second operating system to the command register set in the second chip die. After pushing the second operating system, it writes a command to the command register to indicate that the second operating system push is complete.
11. The chip startup method according to claim 5, characterized in that, The method further includes: After the second chip die loads and completes the chip startup code, it writes the status of the completed startup of the chip startup code to the status register set in the second chip die. The at least one second chip die loads and starts the second chip bootloader from the on-chip memory, including: The at least one second chip die reads the commands written in the command register set within the second chip die. After determining that the first chip die has started pushing the second chip boot program and completed pushing the second chip boot program, it loads and starts the second chip boot program from the on-chip memory, and also writes the status of completing the startup of the second chip boot program to the status register.
12. The chip startup method according to claim 6, characterized in that, The at least one second chip die loads and starts the second operating system from the on-chip memory, including: The at least one second chip die reads the command register set within the second chip die, and after determining that the first chip die has started pushing the second operating system and completed the pushing of the second operating system, loads and starts the second operating system from the on-chip memory, and also writes the status of the completion of starting the second operating system to the status register set within the second chip die.
Citation Information
Patent Citations
Storage system
CN115151895A
System starting method and device and electronic equipment
CN116088950A
Processor system, starting method and computing equipment
CN116340254A