Method of resetting a master device of a system on chip and corresponding system on chip
By monitoring and blocking incomplete transactions, the problem of bus pauses and isolated responses caused by master device resets in on-chip systems is solved, achieving safe and compatible resets in multi-master systems, applicable to any communication protocol bus.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- STMICROELECTRONICS (GRENOBLE 2) SAS
- Filing Date
- 2021-12-03
- Publication Date
- 2026-07-31
AI Technical Summary
In on-chip systems, when the master device is reset, unfinished transactions may cause the bus to stall or respond in isolation. Traditional solutions such as resetting the entire system or waiting for an interrupt have limitations, especially in multi-master systems, particularly when resetting critical functional devices, as they are incompatible with or restrict device selection.
By monitoring the transaction status initiated by the master device, the master device is reset only when all transactions are completed. The reset management circuitry intercepts the reset command and generates a blocking signal to ensure bus compatibility and avoid incomplete transactions and isolated responses.
It achieves bus compatibility during master device reset, avoids incomplete transactions and isolated responses, is applicable to any communication protocol bus, and supports safe reset of multi-master systems.
Smart Images
Figure CN114610672B_ABST
Abstract
Description
[0001] Cross-references to related applications
[0002] This application claims priority to French application FR 2012718, filed on 4 December 2020, which is incorporated herein by reference in its entirety. Technical Field
[0003] This disclosure generally relates to systems-on-a-chip, and in certain embodiments to the reset of a master device capable of initiating transactions on the bus of a system-on-a-chip. Background Technology
[0004] A system-on-a-chip typically includes one or more master devices capable of initiating transactions on one or more buses. Transactions are typically initiated by a request from a master device and completed by receiving a response from a slave device or another master device with a control interface operating in slave mode.
[0005] Unfinished transactions can be initiated consecutively, meaning that the master device can issue a new request before receiving a response to a previous request.
[0006] During a master device reset, the system must consider ongoing transactions on the bus. For example, if a master device reset occurs while the master is issuing a transaction on the bus, the transaction may be incomplete, the bus may stall, and a system-wide reset may be required. Furthermore, if a master device reset occurs while the master is waiting for a transaction response on the bus, isolated responses will appear on the bus. After the reset, the master will not be able to understand these responses, thus posing a risk of master device failure.
[0007] To account for these limitations, the traditional solution is to reset the entire system or a relevant part of the system so that, upon reboot, the system or part of the system can be returned to a clean, known, and controlled state. This solution cannot be applied to systems-on-a-chip with multiple master devices, one of which performs critical functions such as motor control.
[0008] Another traditional solution is to wait for the master device to enter a Wait For Interrupt state to ensure that no transactions are in progress during the reset. This solution only works if the processor pauses in software, for example, in an infinite loop, and does not enter a Wait For Interrupt state. In this case, the reset will never occur, and a system-wide reset must be applied.
[0009] Another traditional solution is to reset the bus affected by the transaction simultaneously with the master device. This solution requires a specific bus architecture and a deep association between the bus infrastructure and the master device, which can limit the choice of master devices in the system or constrain the architecture of the interconnect system.
[0010] Therefore, it is advantageous to ensure the reset of the master device of the system-on-chip, without the aforementioned restrictions. Specifically, all devices connected to the bus should not be reset to ensure compatibility with software blocking and to avoid imposing restrictions on the bus and the infrastructure of the master devices connected to the bus. Summary of the Invention
[0011] According to one aspect, a method for resetting a master device is proposed, the master device being configured to initiate transactions on a system-on-chip bus, the method having monitoring of the completed or incomplete state of transactions initiated by the master device, and, upon receiving a command to reset the master device, effectively resetting the master device when the transactions initiated by the master device are in a completed state.
[0012] In other words, the reset command is intercepted and only retransmitted to the master device after all previous transactions on the bus have completed. This ensures the compatibility of transactions on the bus with the master device's reset and avoids the presence of incomplete transactions on the bus and the master device receiving isolated responses. According to this aspect, the method is also compatible with any type of associated communication protocol bus.
[0013] According to one embodiment, monitoring includes detecting signals transmitted through input and output ports of the interface between the host device and the bus.
[0014] Detecting the presence of signals at the input and output of the interface does indeed allow for monitoring the completion of transactions initiated by the master device in a simple and advantageous manner compatible with any type of communication protocol.
[0015] According to one embodiment, a transaction includes issuing a request on an output port of the interface and receiving a response on an input port of the interface. Monitoring includes counting the number of requests issued at the output port and counting the number of responses received at the input port, the number of received responses being equal to the number of requests issued indicating the completion status of a transaction initiated by the master device.
[0016] Therefore, as long as the difference between the counted number of issued requests and the counted number of received responses is not zero, the transaction initiated by the master device on the bus is in an incomplete state.
[0017] According to one embodiment, a blocking signal is generated upon receiving a command to reset the master device, thereby preventing the master device from initiating a new transaction.
[0018] If a command to reset the master device is received during the transmission of a request, a blocking signal is advantageously generated after the transmission of the request has ended.
[0019] In this regard, if a reset command is received during the issuance period to prevent the start of the next (new) transaction, a blocking signal can be generated immediately after the master device's request has been issued.
[0020] According to one embodiment, preventing the generation of a signal includes activating a valid reset signal, and the valid reset of the master device includes deactivating the valid reset signal when the transaction initiated by the master device is in a completed state and when the received reset command has ended.
[0021] “Signal activation” means “setting the signal to the first logic level”, such as the high level of logic “1”, while “deactivation” means “setting the signal to the second logic level”, such as the low level of logic “0”.
[0022] The reset command seen by the master device is usually delivered via an activation signal, referred to here as the valid reset signal. This signal forces the master device's activity to stop and reset to zero, followed by the deactivation of the valid reset signal, which authorizes the activity to be reset to zero and restart.
[0023] Transactions typically involve responses transmitted on the bus. Advantageously, responses sent on the bus when a valid reset signal is activated are not transmitted to the master device and are erased from the bus.
[0024] "Erase from bus" means that the response is received and optionally acknowledged in a way that closes the transaction from the perspective of the device that issued the response.
[0025] According to another embodiment, the generation of the blocking signal includes sending a signal to the master device to force it into a busy state, and the effective reset of the master device is activated by a pulse of the effective reset signal.
[0026] Bus status signals can typically be provided, for example, to establish a link (handshake) with a communication-ready or busy state. Advantageously, the bus status signal can be forced into a busy state to prevent the initiation of new transactions by reusing the initial function of the status signal.
[0027] This has the advantage of being a perfect fit for systems that provide signals for this type of bus status, such as protocols used for communication on buses of the “AMBA” advanced microcontroller bus architecture type.
[0028] For example, since transactions include responses sent on the bus, responses sent on the bus can be transmitted to the master device when the bus status signal is forced into a busy state.
[0029] Therefore, the master device can receive data and "erase" it from the bus, that is, close the transaction from the perspective of the peripheral device that issued the response.
[0030] According to one embodiment, upon receiving a command to reset the master device, and if a transaction initiated by the master device remains incomplete after the maximum response time has expired, a secondary reset command is generated. Therefore, the secondary command provides an alternative during the reset process in case of problems that prevent transactions from ever completing.
[0031] For example, an auxiliary reset command can be used to control security devices to make a security decision on the problem, or optionally as a last resort to command the entire system to reset.
[0032] According to another aspect, a system-on-chip (SoC) having a bus and at least one master device is proposed, the master device being configured to initiate transactions on the bus. A reset management circuit includes input for receiving a command for resetting the master device, the reset management circuit being configured to monitor the completion or incomplete state of transactions initiated by the master device, and, upon receiving a reset command, effectively reset the master device when the transactions initiated by the master device are in a completed state.
[0033] According to one embodiment, the reset management circuitry is configured to detect signals transmitted on the input and output ports of the interface between the master device and the bus to monitor the completion or incomplete status of a transaction.
[0034] According to one embodiment, a transaction includes issuing a request on an output port of the interface and receiving a response on an input port of the interface. A reset management circuit is configured to monitor the completion or incomplete state of a transaction by counting the number of requests issued on the output port and by counting the number of responses received on the input port, wherein the number of received responses is equal to the number of requests issued indicating the completion state of a transaction initiated by the master device.
[0035] According to one embodiment, the reset management circuit is configured to generate a blocking signal when it receives a command to reset the master device at the input in a manner that prevents the master device from initiating a new transaction.
[0036] If a command to reset the master device is received during the transmission of a request, the reset management circuitry is advantageously configured to generate a blocking signal after the transmission of the request has ended.
[0037] Advantageously, the reset management circuit is configured to generate a blocking signal by activating a valid reset signal, and to effectively reset the master device by deactivating the valid reset signal when a transaction initiated by the master device is completed and when a reset command received at the input has ended.
[0038] Advantageously, transactions include responses sent on the bus. The reset management circuitry is configured to not communicate with the master device and to erase responses sent on the bus when a valid reset signal is activated.
[0039] According to one embodiment, the reset management circuit is configured to generate a blocking signal by sending a bus status signal that forces the master device into a busy state, and to effectively reset the master device by activating a valid reset signal in a pulsed manner.
[0040] Advantageously, transactions include responses sent on the bus. The reset management circuitry is configured to transmit responses sent on the bus to the master device when the bus status signal is forced into a busy state.
[0041] According to one embodiment, the reset management circuit is configured to generate an auxiliary reset command upon receiving a command to reset the master device, and if a transaction initiated by the master device is in an incomplete state after the maximum response time has expired. Attached Figure Description
[0042] To gain a more complete understanding of this disclosure and its advantages, reference is now made to the following description in conjunction with the accompanying drawings, wherein:
[0043] Figure 1 This is a schematic diagram of the system-on-a-chip in the embodiment;
[0044] Figure 2 This is a schematic diagram of the reset management circuit in an embodiment;
[0045] Figure 3 This is a flowchart of the method in the embodiment;
[0046] Figure 4 , Figure 5 and Figure 6 This is a timing diagram of an embodiment;
[0047] Figure 7 This is a schematic diagram of the reset management circuit in an embodiment;
[0048] Figure 8 This is a flowchart of the method in the embodiment; and
[0049] Figure 9 and Figure 10 This is a timing diagram of an embodiment. Detailed Implementation
[0050] Figure 1 A system-on-a-chip (SYS) is shown, having a first master device ((MT_A)) connected to a first bus (BUS_1) via a first interface (INTF_A) and a second master device (MT_B) connected to a second bus (BUS_2) via a second interface (INTF_B).
[0051] The master devices (MT_A) and (MT_B) can initiate transactions on buses (BUS_1) and (BUS_2). A transaction is initiated by issuing a request and closed or completed by receiving a response to the request.
[0052] The master devices (MT_A) and (MT_B) can be, for example, processors with central or special functions, or components with specific functions, such as direct memory access (DMA) devices.
[0053] The master devices (MT_A) and (MT_B) can switch between master type and slave type functions on different interfaces. The corresponding interfaces (INTF_A) and (INTF_B) are master type interfaces (slave type interfaces are not shown).
[0054] For example, peripheral devices (PRPH_1) and (PRPH_N) of type function are connected on the first bus (BUS_1), and peripheral devices (PRPH_N+1) and (PRPH_M) of type function are connected on the second bus (BUS_2).
[0055] In this example, the first bus (BUS_1) and the second bus (BUS_2) are connected via a bridge (BRDG), allowing communication to be switched from one bus to the other. For example, the first bus (BUS_1) could be of the Advanced Extensible Interface (AXI) type, and the second bus could be of the Advanced High Performance Bus (AHB) type. Of course, other types of buses for the system-on-chip are also possible, such as Advanced Microcontroller Bus Architecture (AMBA), Advanced Peripheral Bus (APB), Advanced System Bus (ASB), etc.
[0056] In addition, the two buses (BUS_1) and (BUS_2) can use the same technology to form the same single bus, or the system on chip (SYS) can provide a bus with other technologies not mentioned here.
[0057] The system-on-a-chip (SYS) includes a reset and clock controller device (RCC) for providing clock signals (not shown) and reset commands (COM_RST), specifically for the master devices (MT_A) and (MT_B), and more generally for peripheral devices connected to the buses (BUS_1) and (BUS_2) of the system-on-a-chip (SYS).
[0058] The transmission path of the reset command (COM_RST) is not linked to the communication transmitted on buses (BUS_1) and (BUS_2), hence it is called asynchronous.
[0059] A reset management circuit (GST_A) and (GST_B) are provided for each or at least one master device (MT_A) and (MT_B). The reset management circuit (GST_A) and (GST_B) are configured to receive asynchronous reset commands (COM_RST) for each master device (MT_A) and (MT_B).
[0060] Each reset management circuit (GST_A) and (GST_B) is configured to effectively resend the reset command (COM_RST_EFF) to the corresponding master device (MT_A) and (MT_B) relative to the state of the transaction in progress when the reset command (COM_RST) is sent.
[0061] In practice, each reset management circuit (GST_A) and (GST_B) includes an input for receiving a command (COM_RST) to reset the master device (MT_A) and (MT_B), and is configured to monitor the completion or incomplete status of transactions initiated by the master device (MT_A) and (MT_B). Upon receiving a reset command (RST) on the input, the reset management circuit (GST_A) and (GST_B) are configured to effectively reset the master device (MT_A) and (MT_B) when a transaction initiated by the master device is in a completed state. The master device reset is performed via an "valid" reset command (COM_RST_EFF).
[0062] In this example, reset management circuits (GST_A) and (GST_B) are inserted at interfaces (INTF_A) and (INTF_B) between the respective master devices (MT_A) and (MT_B) and the respective buses (BUS_1) and (BUS_2), for example, to detect signals transmitted on the input and output ports of interfaces (INTF_A) and (INTF_B).
[0063] Figure 2 It shows, for example, relative to Figure 1 The above-described embodiment of the Reset Management Circuit (GST) is described. The Reset Management Circuit (GST) is inserted at the interface between the corresponding master device and the bus (BUS). The Reset Management Circuit (GST) is configured to send requests issued by the master device on the interface's output port (MT_OUT) and responses received on the interface's input port (MT_IN) without modification.
[0064] In one example of an interface that includes input-output registers provided for transmitting transaction data (often referred to as a "register slice"), monitoring the completed or incomplete status of a transaction initiated by the master device can be performed, for example, on a register.
[0065] The reset management circuit (GST) includes a synchronization element (RST_SYNC) with an input connected to a path for transmitting reset commands (COM_RST) issued by the reset and clock controller device (RCC).
[0066] The synchronization element (RST_SYNC) is configured to synchronize a valid reset command (COM_RST_EFF) with the master device that has obtained the completion status of a transaction initiated on the bus (BUS).
[0067] The reset management circuit (GST) includes a request counter (CNT_REQ) and a response counter (CNT_ANS). The request counter is configured to count the number of requests issued by the master device, and the response counter is configured to count the number of responses received.
[0068] For example, the request counter (CNT_REQ) can detect signals transmitted on the interface's output port (MT_OUT) to count requests; and similarly, the response counter (CNT_ANS) can detect signals transmitted on the interface's input port (MT_IN) to count responses.
[0069] For this purpose, a counter can detect a request or response based on only a portion of the protocol's signals, and can be created, for example, by combinational logic circuitry.
[0070] The count is transmitted to the synchronization element (RST_SYNC), which is configured to subtract the count response count from the count request count, resulting in the number of transactions in progress on the bus (BUS).
[0071] Advantageously, in order to limit the size of the counter, the same counter can be incremented for each request issued and decremented for each response received, thereby directly representing the number of transactions in progress on the bus (BUS).
[0072] In other words, the counter does not need to perform signal reading and analysis of its contents. Furthermore, simple detection of signal presence, such as during transmissions in input-output registers or through logical detection of protocol signals, allows counting to be performed to monitor the completion or incomplete status of transactions initiated by the master device.
[0073] Therefore, a zero number of ongoing transactions on the bus indicates the completion status of transactions initiated by the master device. Conversely, a non-zero number of ongoing transactions on the bus indicates the incomplete status of transactions initiated by the master device.
[0074] As will be shown in more detail below, the synchronization element (RST_SYNC) is configured to generate a block signal when a reset command (RST) is received on the input to prevent the master device from initiating a new transaction.
[0075] For example, blocking a signal can be achieved by effectively resetting the signal (RST_EFF). Figures 4 to 6 This is achieved through activation, which is carried by a valid reset command (COM_RST_EFF) via a valid reset signal (RST_EFF).
[0076] It should be noted that there is a distinction between a valid reset command and a valid reset signal. In an embodiment, the valid reset command transmits instruction logic, and the valid reset command is carried by the valid reset signal. The valid reset signal can have two logic levels, either high or low. The logic values and their translation in terms of instructions are arbitrarily chosen. The valid reset signal is "activated" at the selected level to produce the command effect. The valid reset signal is "deactivated" at the reset level, choosing not to produce its own command effect.
[0077] The valid reset signal is typically defined as being activated at a high level and deactivated at a low level. A valid reset command "zeros" the variable elements of the master device and blocks their activity on the bus when the valid reset signal is activated. When the valid reset signal is deactivated, the master device is allowed to restart in its initial state and normal operation.
[0078] Therefore, in this example, the synchronization element (RST_SYNC) activates the valid reset signal (RST_EFF). Figures 4 to 6 This prevents the master device from initiating new transactions and deactivates the valid reset signal (RST_EFF) when a transaction initiated on the bus (BUS) is completed and the reset command (RST) is completed.
[0079] The synchronization element (RST_SYNC) can be configured to provide a reset acknowledgment signal (ACKRST) (typically "acknowledgment") after a valid reset. In this particular embodiment, the reset management circuitry (GST) also includes a receive element (ANS_DRP) configured to erase any transmitted possible responses from the bus if the master device is blocked in this manner. Responses received when the master device is blocked are not transmitted to the master device.
[0080] "Erase from bus" means that a response is received, and optionally means that an acknowledgment signal (e.g., "acknowledgment" type) is sent to the peripheral device that issued the response, thereby properly closing the transaction on the bus (BUS) according to the protocol used.
[0081] In addition, the Reset Management Circuit (GST) may include its own reset input for receiving a reset signal (RST_GST) dedicated to the Reset Management Circuit (GST). Specifically, this is configured to reset the entire system, including the Reset Management Circuit (GST), to start from a clean state.
[0082] Figure 3 It is shown that, as described above Figure 2 A block diagram illustrating an embodiment of master device reset implemented by the reset management circuit (GST). Figure 4 , Figure 5 and Figure 6 This is a timing diagram showing the signals involved during the reset execution and for various other situations according to this embodiment.
[0083] In step 310 of the method for resetting master device 300, a command to reset master device is received. This method includes step 320, which verifies whether a transaction is being initiated by the master device, that is, whether request generation is in progress. For example, a request counter (CNT_REQ) can be provided for this purpose, and information can be transmitted to the synchronization element (RST_SYNC).
[0084] If a request is being generated during the receipt of reset command 310, step 320 waits (Y) until the request generation is complete. If no request generation is in progress, or when request generation has already been completed (N), a valid reset signal is activated in step 330 to prevent the master device from initiating a new transaction.
[0085] Then, in step 340, the method waits (Y) for no further expected response to the request previously initiated by the master device. In other words, step 340 corresponds to monitoring the completion or incomplete status of the transaction initiated by the master device.
[0086] After step 340, when all expected responses are received, and therefore when the initiated transaction is in a completed state (N), the method includes step 350, verifying that the reset command has ended, and optionally waiting (N) for the reset command to end.
[0087] As described above, for a valid reset command, the reset command received in step 310 includes the activation of a signal, and the process ends when the signal is deactivated.
[0088] Finally, in step 360, after the initiated transaction is in the completed state 340(Y) and after the reset command signal is deactivated 350(N), the valid reset signal is deactivated. Furthermore, after step 360, the method may include sending a reset acknowledgment signal (ACKRST) (not shown).
[0089] Figure 4 The diagram illustrates the signal generated during method 300 if no transaction (TRSCT) is initiated before or during receiving the reset command (COM_RST). Therefore, the number of ongoing transactions (TRSCT_NB) is zero, and the valid reset signal (RST_EFF) is activated and deactivated simultaneously with the reset signal (RST). In other words, a valid reset (COM_RST_EFF) command is sent to the master device simultaneously with receiving the reset command (COM_RST).
[0090] Figure 5 This indicates a signal generated during method 300 when a transaction (TRSCT) is initiated by the master device during the receipt of a reset command (COM_RST). Therefore, after the generation of the request (REQ) is complete, the valid reset signal (RST_EFF) is activated, and the number of ongoing transactions (TRSCT_NB) equals 1, indicating the incomplete state of the transaction initiated by the device. The reset signal is maintained and activated until the number of ongoing transactions (TRSCT_NB) becomes zero. After receiving a response (ANS) to the request (REQ), the number of ongoing transactions (TRSCT_NB) is zero, therefore the transaction initiated by the master device is in a completed state, and the valid reset signal (RST_EFF) is deactivated. An acknowledgment (ACKRST) can be sent after the valid reset command (COM_RST_EFF).
[0091] Figure 6 The diagram illustrates the signals generated during method 300 when a transaction (TRSCT) is initiated by the master device before and during receiving the reset command (COM_RST). Therefore, the number of ongoing transactions (TRSCT_NB) is 1 at the moment the reset command (COM_RST) is received, and becomes 2 after the second request (REQ2) is generated. The number of ongoing transactions (TRSCT_NB) returns to 1 after receiving the response (ANS1) to the first request (REQ1), and becomes zero after receiving the response (ANS2) to the second request (REQ2). Responses (ANS1) and (ANS2) are not transmitted to the master device and are erased from the bus. When the transaction initiated by the master device is in a completed state (i.e., the number of ongoing transactions (TRSCT_NB) is zero), the valid reset signal (RST_EFF) is deactivated, and an acknowledgment (ACKRST) can be sent.
[0092] Figure 7 An embodiment of the reset management circuit (GST) is shown above as an example of the above. Figure 2 Alternatives to the described examples. However, the elements common to these embodiments have the same reference numerals and will not be described in detail below.
[0093] This embodiment is related to... Figure 2 The difference in the embodiment is that the circuit (GST) does not include a receiving element (ANS_DRP), but instead includes a blocking circuit (BUS_GAT) configured to send a bus (BUS) status signal (BUS_ST) to the master device.
[0094] Status signals (BUS_ST) are used to perform the process of establishing a link (handshake) between the master device and the bus (BUS) to determine whether the bus (BUS) can accept a new request. Status signals (BUS_ST) can typically have a ready state or a busy state. This type of status signal (BUS_ST) is used, for example, in communication on the Advanced Extensible Interface (AXI) bus.
[0095] In short, during the link establishment process in the AXI protocol, the master device sends a validity signal ("valid") to notify the receiver peripheral device that it can read information on the bus (BUS). The status signal (BUS_ST), provided by the flow management system and integrated into the bus (BUS), indicates whether the bus is ready and therefore operable to accept new transactions, or whether it is busy and therefore inoperable to accept new transactions. If a busy signal is sent to the master device, then the latter cannot send new requests.
[0096] The reset management circuit (GST) can be configured to retransmit the status signal (BUS_ST) received on the bus (BUS) during normal operation.
[0097] Furthermore, upon receiving a reset command (COM_RST), the synchronization element is advantageously configured to force the status signal (BUS_ST) into a busy state to prevent the master device from initiating new transactions.
[0098] Therefore, in this example, the generation of a blocking signal that allows the master device to prevent it from initiating new transactions is performed by forcing the status signal (BUS_ST) into a busy state.
[0099] In this example, when the bus status signal (BUS_ST) is forced into a busy state, the response sent on the bus is transmitted to the master device normally.
[0100] Figure 8 It is shown that, as described above, regarding Figure 7 A block diagram illustrating the execution of master device reset implemented by the reset management circuit (GST). Figure 9 and Figure 10 This is a timing diagram showing the signals involved in various situations during the execution of the reset according to this embodiment.
[0101] In step 810 of the method for resetting the master device 800, a command to reset the master device is received. This method includes step 820, which verifies whether the master device is initiating a transaction, similar to the steps described above. Figure 3 The verification step 320 is described.
[0102] If no request is being generated, or if request generation (N) has already been completed, the bus status signal is forced into a busy state (BSY) during step 830, thereby preventing the master device from initiating a new transaction.
[0103] Monitoring step 840 waits (Y) for the completion status of the transaction initiated by the master device. After step 840, when all expected responses are received, and therefore when the initiated transaction is in a completed state (N), a valid reset command is generated during step 850. A valid reset is commanded by a pulse of a valid reset signal, that is, the activation of the signal lasts long enough to reset the master device, and the deactivation of the signal.
[0104] Of course, a similar approach to the one described above can be provided between the monitoring step 840 and the generation of the valid reset command 850. Figure 3 The verification step 350 described is a verification step (not shown). Furthermore, after step 850, method 800 may also include the transmission of a reset acknowledgment signal (ACKRST) (not shown).
[0105] Figure 9 The diagram illustrates the signals generated during method 800 when a transaction (TRSCT) is initiated by the master device during the receipt of a reset command (COM_RST). Therefore, the bus (BUS_ST) status signal is initially in the ready state (RDY) and is forced into the busy state (BSY) after the request (REQ) is generated. Naturally, the number of ongoing transactions (TRSCT_NB) becomes 1, indicating the incomplete state of the transaction initiated by the master device.
[0106] The bus status signal (BUS_ST) is busy (BSY) until the number of ongoing transactions (TRSCT_NB) becomes zero. After receiving a response (ANS) to a request (REQ), the number of ongoing transactions (TRSCT_NB) becomes zero, indicating the completion status of a transaction initiated by the master device.
[0107] Therefore, a valid reset command (COM_RST_EFF) is generated in the form of a pulse activation of a valid reset signal (RST_EFF). Furthermore, the bus status signal (BUS_ST) is no longer forced and returns to its link establishment function, returning to, for example, the ready state (RDY). An acknowledgment (ACKRST) can be sent after the valid reset command (COM_RST_EFF).
[0108] Figure 10 The diagram illustrates the signals generated during method 800 before and during a transaction initiated by the master device (TRSCT) before receiving the reset command (COM_RST). Therefore, at the moment the reset command (COM_RST) is received, the number of ongoing transactions (TRSCT_NB) is 1. Before receiving the reset command (COM_RST), the bus (BUS_ST) status signal is not forced into the busy state (BSY) and remains in the ready state (RDY).
[0109] After the second request (REQ2) is generated, the number of ongoing transactions (TRSCT_NB) becomes 2, and the bus status signal (BUS_ST) is forced into a busy state (BSY), indicating that the transaction on the bus is incomplete. After receiving the response (ANS2) to the second request (REQ2), the number of ongoing transactions (TRSCT_NB) returns to 1, and becomes zero after receiving the response (ANS1) to the first request (REQ1).
[0110] Responses (ANS2) and (ANS1) are typically transmitted to the master device. When a transaction initiated by the master device is in a completed state (i.e., the number of ongoing transactions (TRSCT_NB) is zero), a valid reset command (COM_RST_EFF) is generated in the form of a pulse in the valid reset signal (RST_EFF), the bus status signal (BUS_ST) returns to the ready state (RDY), and an acknowledgment (ACKRST) can be sent. Responses (ANS2) and (ANS1) can be received in an order different from the order in which requests (REQ1) and (REQ2) were sent.
[0111] It is worth noting that, in a favorable multi-price and direct manner, monitoring does not include identifying the received responses. Therefore, it does not consider the order in which responses were received to assess the completion or incompleteness of a transaction initiated by the master device.
[0112] Furthermore, if a transaction initiated by the master device remains incomplete after the maximum response time expires, then the above regarding... Figures 1 to 10 All the implementations and embodiments described can provide generated auxiliary reset commands.
[0113] For example, a stopwatch can be provided in the reset management circuit (GST), and the stopwatch's action can be positioned to wait for a monitoring response 340, 840 (regarding) to receive the completed or incomplete status of a transaction initiated by the master device. Figure 3 and Figure 8The process is repeated in the loop (Y) of the steps. Furthermore, if the initiated transaction remains in an incomplete state beyond the arbitrarily selected maximum duration, an auxiliary reset command can be sent to an optional security control device, or, for example, to reset all peripherals of the on-chip system as a last resort.
[0114] Although described in detail, it should be understood that various changes, substitutions, and variations can be made without departing from the spirit and scope of this disclosure as defined by the appended claims. In different figures, the same elements are designated by the same reference numerals. Furthermore, the scope of this disclosure is not intended to be limited to the specific embodiments described herein, as it will be readily understood by those skilled in the art from this disclosure that existing or future processes, machines, manufactures, material compositions, apparatuses, methods, or steps can perform substantially the same functions or achieve substantially the same results as the corresponding embodiments described herein. Therefore, the appended claims are intended to include such processes, machines, manufactures, material compositions, apparatuses, methods, or steps within their scope.
[0115] Therefore, the specification and drawings are simply regarded as a description of this disclosure as defined by the appended claims, and are intended to cover any and all modifications, variations, combinations or equivalents falling within the scope of this disclosure.
Claims
1. A method for resetting a master device, comprising: A system-on-a-chip device that includes a master device and a bus; The master device initiates the transaction on the bus; Monitor the status of the transaction, which is either in a completed state or an incomplete state. In response to determining that the transaction is in the completed state and receiving a reset command, the master device is reset; In response to receiving the reset command, a blocking signal is generated; as well as In response to generating the blocking signal, the master device blocks the initiation of a new transaction; If a command to reset the master device is received during the transmission of the request, the blocking signal is generated after the transmission of the request is completed.
2. The method of claim 1, wherein the system-on-chip device further comprises an interface having an input port and an output port, monitoring a status of the transaction comprises: Detect the signals on the input port and the output port.
3. The method of claim 2, wherein a respective transaction comprises issuing a request on the output port and receiving a response on the input port, monitoring the status of the transaction further comprises: The number of requests issued at the output port is counted, and the number of responses received at the input port is counted, wherein the number of responses received is equal to the number of requests issued corresponding to the state of the transaction being in the completed state.
4. The method of claim 1, wherein generating the block signal comprises: Activating the reset signal and resetting the master device includes: deactivating the reset signal.
5. The method of claim 4, wherein a respective transaction includes a response signal, the response signal being transmitted on the bus, the method further comprising: In response to generating the blocking signal, the reception of the response signal from the bus to the master device is blocked, and blocking the reception of the response signal further includes erasing the response signal on the bus.
6. The method of claim 1, wherein generating the block signal comprises: Transmitting a signal corresponding to the state of the bus to the master device, wherein the state of the bus is in a forced busy state, and resetting the master device includes: activating a pulse signal corresponding to the reset command.
7. The method of claim 6, wherein a respective transaction includes a response signal, the response signal being transmitted on the bus, the method further comprising: In response to the bus being in the forced busy state, the response signal is transmitted to the master device.
8. The method of claim 1, further comprising: An auxiliary reset command is generated in response to the following: After the maximum response time expires, the transaction is determined to be in an incomplete state. as well as The reset command is received by the master device.
9. A system-on-a-chip device, the system-on-a-chip device comprising: bus; A master device, coupled to the bus, is configured to initiate transactions on the bus; as well as A reset management circuit, coupled to the master device and the bus, is configured to: Monitor the status of the transaction, which is either in a completed state or an incomplete state. The master device is reset in response to the following: Determine that the transaction is in the completed state; and A reset command is received at the input of the reset management circuit; The reset management circuit is further configured to: generate a blocking signal in response to receiving the reset command; and, in response to generating the blocking signal, prevent the initiation of a new transaction by the master device. If the reset command is received during the transmission of the request, the reset management circuit is configured to generate the blocking signal after the transmission of the request has ended.
10. The system-on-a-chip device of claim 9, further comprising an interface having an input port and an output port, wherein the reset management circuit monitors the state of the transaction including: Detect the signals on the input port and the output port.
11. The system-on-chip device of claim 10, wherein a respective transaction comprises issuing a request on the output port and receiving a response on the input port, monitoring a status of the transaction further comprises: The number of requests issued at the output port is counted, and the number of responses received at the input port is counted, wherein the number of responses received is equal to the number of requests issued corresponding to the state of the transaction being in the completed state.
12. The system-on-chip device of claim 9, wherein generating the stall signal comprises: Activating the reset signal and resetting the master device includes: deactivating the reset signal.
13. The system-on-a-chip device of claim 12, wherein the corresponding transaction includes a response signal transmitted on the bus, and wherein the reset management circuitry is further configured to block the reception of the response signal from the bus to the master device in response to generating the blocking signal, the blocking of the reception of the response signal further comprising: The response signal is erased on the bus.
14. The system-on-a-chip device of claim 9, wherein generating the blocking signal comprises: Transmitting a signal corresponding to the state of the bus to the master device, wherein the state of the bus is in a forced busy state, and resetting the master device includes: activating a pulse signal corresponding to the reset command.
15. The system-on-a-chip device of claim 14, wherein the corresponding transaction includes a response signal transmitted on the bus, and wherein the reset management circuitry is further configured to transmit the response signal to the master device in response to the state of the bus being in the forced busy state.
16. The system-on-chip device of claim 9, wherein the reset management circuitry is further configured to generate an auxiliary reset command in response to: After the maximum response time expires, the transaction is determined to be in an incomplete state; and The reset command is received by the master device.
17. An apparatus including a system-on-a-chip, the system-on-a-chip comprising: bus; A master device, coupled to the bus, is configured to initiate transactions on the bus; as well as A reset management circuit, coupled to the master device and the bus, is configured to: Monitor the status of the transaction, which is either in a completed state or an incomplete state. The master device is reset in response to the following: Determine that the transaction is in the completed state; and A reset command is received at the input of the reset management circuit; The reset management circuitry is further configured to generate a blocking signal in response to receiving the reset command; And in response to generating the blocking signal, the master device blocks the initiation of a new transaction; If the reset command is received during the transmission of the request, the reset management circuit is configured to generate the blocking signal after the transmission of the request has ended.
18. The apparatus of claim 17, the system-on-chip further comprising an interface having an input port and an output port, wherein a respective transaction comprises issuing a request on the output port and receiving a response on the input port, monitoring a status of the transaction further comprises: The number of requests issued at the output port is counted, and the number of responses received at the input port is counted, wherein the number of responses received is equal to the number of requests issued corresponding to the state of the transaction being in the completed state.