METHOD FOR RESETTING A MASTER DEVICE OF A SYSTEM-ON-CHIP AND CORRESPONDING SYSTEM-ON-CHIP

Description

[0001] Implementations and embodiments relate to systems-on-chip, and in particular to resetting master devices capable of initiating transactions on a system-on-chip bus.

[0002] SoCs typically include one or more master devices capable of initiating transactions on one or more buses. A transaction is typically initiated by a master issuing a request and completed by receiving a response from a slave device or another master device that has a control interface operating in slave mode. Outstanding transactions may be initiated consecutively, meaning that new requests may be issued by the master before responses to previous requests are received.

[0003] When resetting a master device, the system must take into account the transactions in progress on the bus.

[0004] Indeed, if a master reset occurs while the master is issuing a transaction on the bus, the transaction may be incomplete and the bus may stall, requiring a full system reset.

[0005] And, if a master reset occurs while the master is waiting for a transaction response on the bus, orphaned responses will be present on the bus and will not be understood by the master after reset, potentially causing the master device to malfunction.

[0006] To take these constraints into account, a classic solution is to reset the complete system, or a coherent part of the system, to find after restarting a virgin, known, controlled state of the system or part of the system.

[0007] This solution is not applicable to SoCs with multiple master devices, where one of the masters performs a critical function, such as controlling a motor.

[0008] Another common solution is to wait for the master device to enter a "Wait For Interrupt" state to ensure that no transactions are in progress when the reset occurs.

[0009] This solution does not work when the processor is software-locked, for example in an infinite loop, and does not enter the interrupt-waiting state. In this case, the reset never occurs and a full system reset must be applied.

[0010] Another common solution is to reset the bus affected by the transaction at the same time as the master. This requires a specific bus architecture and a deep correlation between the bus infrastructure and the master device, which may limit the choice of master devices in the system and / or constrain the architecture of the interconnect system.

[0011] There is therefore a need to secure resets of master devices of systems on chips, without suffering the aforementioned constraints, i.e. in particular without resetting all the devices connected to the bus, to be compatible with software locks, and without imposing the infrastructure of the buses and the master devices connected to them.

[0012] US2019212794 describes a security island, integrated into a system-on-chip (SoC) that contains a security processor and security-related peripherals. During execution, the non-security-related portion of the system-on-chip may be reset, while the security island must continue to perform security functions. If the security island has pending requests from the rest of the SoC at the time of the reset, these pending transactions may be lost, resulting in a crash of the security island. The present invention provides a hardware mechanism to prevent the security island from crashing in the above scenario.

[0013] In this regard, a method of resetting a master device configured to initiate transactions on a bus of a system on chip is provided, comprising monitoring a completed or uncompleted state of the transactions initiated by the master device, and, in the event of receiving a reset command from the master device, effectively resetting the master device when the transactions initiated by the master device are in the completed state.

[0014] In other words, it is proposed to intercept a reset command and to retransmit it to the master device only when all previous transactions on the bus are completed. This makes it possible to guarantee a compatible state of the transactions on the bus with the reset of the master device, and in particular to avoid the presence of an incomplete transaction on the bus and a reception of an orphan response by the master device. The method according to this aspect is furthermore compatible with any type of associated communication protocol bus.

[0015] According to one embodiment, the monitoring comprises detection of signals passing through input and output ports of an interface between the master device and the bus.

[0016] Detecting the presence of signals on the input and output of the interface can in fact make it possible to monitor whether the transactions initiated by the master device are completed or not, in a way that is advantageously simple and compatible with any type of communication protocol.

[0017] According to one embodiment, a transaction comprises sending a request on the output port of the interface and receiving a response on the input port of the interface, and said monitoring comprises counting the number of requests sent on the output port and counting the number of responses received on the input port, a number of responses received equal to the number of requests sent being representative of the completed state of the transactions initiated by the master device.

[0018] Thus, as long as the difference between the counted number of requests issued and the counted number of responses received is not zero, the transactions initiated by the master device on the buses are in the unfinished state.

[0019] A blocking signal is generated upon receipt of the reset command from the master device, so as to block the initiation of a new transaction by the master device.

[0020] If the reset command is received from the master device during the transmission of a request, the blocking signal is advantageously generated after the end of the transmission of this request.

[0021] The blocking signal can be generated in this regard immediately after the master device has completed the transmission of a request, if the reset command is received during this transmission, in order to block the initiation of a next (new) transaction.

[0022] According to one embodiment, the generation of the blocking signal comprises an activation of an effective reset signal, and the effective reset of the master device comprises a deactivation of the effective reset signal, when the transactions initiated by the master device are in the completed state and when the received reset command has ended.

[0023] By "activation of a signal" is meant "placing the signal at a first logic level", for example the high level for a logic "1", and by "deactivation" is meant "placing the signal at a second logic level", for example the low level for a logic "0".

[0024] The reset command, seen by the master device, is in fact typically communicated by an activation of a signal, here called the effective reset signal, which imposes a stop of the activity and a reset of the master device, followed by a deactivation of the effective reset signal which authorizes a restart of the reset activity.

[0025] A transaction typically includes a response transmitted over the bus, and advantageously, responses transmitted over the bus when the effective reset signal is asserted are not communicated to the master device and are cleared from the bus.

[0026] By "cleared from the bus" we mean that the responses are received, and possibly confirmed, in such a way as to close the transaction from the point of view of the device sending the response.

[0027] According to another embodiment, the generation of the blocking signal comprises a transmission to the master device of a bus status signal forced to the busy state, the effective resetting of the master device comprising a pulsed activation of an effective reset signal.

[0028] Indeed, a bus status signal can conventionally be provided, for example to communicate a ready state or a busy state in order to carry out a handshake procedure, and this bus status signal is advantageously forced to the busy state, in order to block the initiation of a new transaction by reusing the initial function of the status signal.

[0029] This has the advantage of fitting perfectly into a system providing this type of bus status signal, such as for example in communication protocols on buses of the Advanced Microcontroller Bus Architecture (AMBA) type.

[0030] For example, a transaction including a response transmitted on the bus, responses transmitted on the bus when the bus status signal is forced to the busy state can be communicated to the master device.

[0031] The master device can then receive the data and "erase" it from the bus, i.e. close the transaction from the point of view of the peripheral sending the response.

[0032] According to one embodiment, an auxiliary reset command is generated upon receipt of a reset command from the master device, and if the transactions initiated by the master device are in the uncompleted state after expiration of a maximum response time.

[0033] The auxiliary command thus provides an alternative in the reset process in the event of a problem leading to transactions never being completed.

[0034] The auxiliary reset command may, for example, be intended for a secure control device, capable of making a secure decision on the matter, or possibly to command a reset of the complete system as a last resort.

[0035] A system-on-chip comprising a bus and at least one master device configured to initiate transactions on the bus is provided, wherein a reset management circuit having an input for receiving a reset command from the master device is configured to monitor a completed or uncompleted state of the transactions initiated by the master device, and, upon receipt of a reset command on the input, to effectively reset the master device when the transactions initiated by the master device are in the completed state.

[0036] According to one embodiment, the reset management circuit is configured to detect signals passing through input and output ports of an interface between the master device and the bus, in order to monitor said completed or uncompleted state of said transactions.

[0037] According to one embodiment, a transaction comprises a transmission of a request on the output port of the interface and a reception of a response on the input port of the interface, and the reset management circuit is configured to monitor said completed or uncompleted state of said transactions by counting the number of requests transmitted on the output port and by counting the number of responses received on the input port, a number of responses received equal to the number of requests transmitted being representative of the completed state of the transactions initiated by the master device.

[0038] The reset management circuit is configured to generate a blocking signal upon receipt of the reset command from the master device on the input, so as to block the initiation of a new transaction by the master device.

[0039] In case of reception of the reset command from the master device during the transmission of a request, the reset management circuit is advantageously configured to generate the blocking signal after the end of the transmission of this request.

[0040] Advantageously, the reset management circuit is configured to generate the blocking signal by activating an effective reset signal, and to reset the master device effectively by deactivating the effective reset signal, when the transactions initiated by the master device are in the completed state and when the reset command received on the input has ended.

[0041] Advantageously, a transaction includes a response transmitted on the bus, and the reset management circuit is configured not to communicate to the master device and to clear from the bus the responses transmitted on the bus when the effective reset signal is activated.

[0042] According to one embodiment, the reset management circuit is configured to generate the blocking signal by transmitting to the master device a bus status signal forced to the busy state, and to effectively reset the master device by pulse-enable an effective reset signal.

[0043] Advantageously, a transaction includes a response transmitted on the bus, and the reset management circuit is configured to communicate to the master device the responses transmitted on the bus, when the bus status signal is forced to the busy state.

[0044] According to one embodiment, the reset management circuit is configured to generate an auxiliary reset command, in the event of receipt of a reset command from the master device, and if the transactions initiated by the master device are in the unfinished state after expiration of a maximum response time.

[0045] Other advantages and characteristics of the invention will appear on examining the detailed description of embodiments and implementations, which are in no way limiting, and the appended drawings, in which: [ Fig 1 ] [ Fig 2 ] [ Fig 3 ] [ Fig 4 ] [ Fig 5 ] [ Fig 6 ] [ Fig 7 ] [ Fig 8 ] [ Fig 9 ] [ Fig 10 ] illustrate embodiments and implementations of the invention.

[0046] There figure 1 represents a system on chip SYS comprising a first master device MT_A connected to a first bus BUS_1 via a first interface INTF_A, as well as a second master device MT_B connected to a second bus BUS_2 via a second interface INTF_B.

[0047] The master devices MT_A, MT_B are capable of initiating transactions on the buses BUS_1, BUS_2. A transaction is initiated by the issuance of a request, and is closed, or terminated, by the receipt of a response to the request.

[0048] The master devices MT_A, MT_B can for example be processing units, such as processors, with central or special functions, or even elements with a particular function such as a direct memory access device (DMA).

[0049] The master devices MT_A, MT_B may be able to switch between master-type or slave-type functions on different interfaces, the respective INTF_A, INTF_B interfaces being the master-type interfaces (the slave-type interfaces are not shown).

[0050] Devices PRPH_1, PRPH_N, for example of slave type functions, are connected to the first bus BUS_1, and devices PRPH_N+1, PRPH_M, for example of slave type functions, are connected to the second bus BUS_2.

[0051] The first bus BUS_1 and the second bus BUS_2 are in this example connected by a BRDG gateway allowing communications to be translated from one bus to the other.

[0052] For example, the first bus BUS_1 may be of the AXI type (“Advanced eXtensible Interface” in English, and well known to those skilled in the art) and the second bus may be of the AHB type (“Advanced High-performance Bus” in English, and well known to those skilled in the art).

[0053] Of course, other types of system-on-chip buses are conceivable, in particular the buses usually called AMBA and well known to those skilled in the art (for “Advanced Microcontroller Bus Architecture” in English), such as the APB buses (“Advanced Peripheral Bus” in English) or ASB buses (for “Advanced System Bus” in English).

[0054] Furthermore, the two buses BUS_1, BUS_2 can be of the same technology and form a single bus, or other buses of technologies not mentioned here could be provided in the system on chip SYS.

[0055] The SYS system on chip comprises a clock and reset controller device RCC intended to provide clock signals (not shown) and reset commands COM_RST intended in particular for the master devices MT_A, MT_B, and more generally for the peripherals connected to the buses BUS_1, BUS_2 of the SYS system on chip.

[0056] The transmission path of the COM_RST reset commands is not related to the communications transmitted on the BUS_1, BUS_2 buses and, for this reason, is said to be asynchronous.

[0057] A reset management circuit GST_A, GST_B is provided for each, or at least one, master device MT_A, MT_B. The reset management circuits GST_A, GST_B are configured to receive the asynchronous reset command COM_RST intended for the respective master device MT_A, MT_B.

[0058] Each reset management circuit GST_A, GST_B is configured to retransmit to the corresponding master device MT_A, MT_B a reset command COM_RST_EFF, effectively with respect to the state of the transactions in progress at the time of the reset command COM_RST.

[0059] Indeed, each reset management circuit GST_A, GST_B comprises an input intended to receive the reset command COM_RST from the master device MT_A, MT_B, and is configured to monitor a completed or uncompleted state of the transactions initiated by the master device MT_A, MT_B. In the event of receipt of a reset command RST on the input, the reset management circuit GST_A, GST_B is configured to reset the master device MT_A, MT_B effectively when the transactions initiated by the master device are in the completed state. The master device is reset by means of the so-called "effective" reset command COM_RST_EFF.

[0060] In this example, the reset management circuits GST_A, GST_B are interposed at the interfaces INTF_A, INTF_B between the respective master device MT_A, MT_B and the respective bus BUS_1, BUS_2, for example in order to detect signals passing through input and output ports of said interfaces INTF_A, INTF_B.

[0061] In this regard, reference is made to the figure 2 .

[0062] There figure 2 illustrates an exemplary embodiment of a GST reset management circuit as previously described in relation to the figure 1 .

[0063] The GST reset management circuit is interposed at the interface between the respective master device and the bus BUS. The GST reset management circuit is configured to transmit, without modification, requests sent by the master device on an output port MT_OUT of the interface and responses received on an input port MT_IN of the interface.

[0064] In an example of an interface comprising input-output registers intended to transmit transaction data (usually referred to as “register slices” in English), monitoring of the completed or uncompleted state of the transactions initiated by the master device can, for example, be done on said registers.

[0065] The reset management circuit GST comprises a synchronization element RST_SYNC having an input connected to the reset command transmission path COM_RST issued by the clock and reset controller device RCC.

[0066] The RST_SYNC synchronization element is configured to synchronize an effective reset command COM_RST_EFF, with obtaining a completed status of the transactions initiated on the BUS bus by the master device.

[0067] The GST reset management circuit includes a CNT_REQ request counter configured to count the number of requests issued by the master device, and a CNT_ANS response counter configured to count the number of responses received.

[0068] For example, the request counter CNT_REQ is capable of detecting signals passing through the output port MT_OUT of the interface, to count said requests; and, similarly, the response counter CNT_ANS is capable of detecting signals passing through the input port MT_IN of the interface, to count said responses.

[0069] For this purpose, counters can rely on only part of the protocol signals to detect a request or a response, and are for example implemented by a combinational logic circuit.

[0070] The counted numbers are communicated to the RST_SYNC synchronization element, which is configured to subtract the number of counted responses from the number of counted requests, the result giving the number of transactions in progress on the bus BUS.

[0071] Advantageously, to limit the size of the counters, the same counter can be incremented for each request sent, and decremented for each response received, so as to be directly representative of the number of transactions in progress on the BUS bus.

[0072] In other words, the counters do not need to perform a reading of the signals and an analysis of their content, but the simple detection of a signal presence, for example in transit in the input-output registers or by a logical detection on the protocol signals, allows to perform the counts to monitor the completed or not state of the transactions initiated by the master device.

[0073] Thus, a zero number of transactions in progress on the BUS bus is representative of a completed state of the transactions initiated by the master device, while a non-zero number of transactions in progress on the BUS bus is representative of an uncompleted state of the transactions initiated by the master device.

[0074] As will become more apparent later, the RST_SYNC synchronization element is configured to generate a blocking signal to block the initiation of a new transaction by the master device, upon receipt of the RST reset command on the input.

[0075] The blocking signal can for example be materialized by an activation of an effective reset signal RST_EFF ( figures 4 à 6 ) which carries the effective reset command COM_RST_EFF.

[0076] A distinction should be noted between the effective reset command and the effective reset signal. Indeed, the effective reset command communicates an instruction logic, and is carried by the effective reset signal. The effective reset signal can have two logic levels, a high level or a low level, whose logic values ​​and the translation of these values ​​into instruction terms are chosen arbitrarily. We will say that the effective reset signal is "activated" at the level chosen to produce a control effect, and that the effective reset signal is "deactivated" at the resting level, chosen not to produce any control effect of its own. We conventionally define that the effective reset signal is activated at the high level and deactivated at the low level.The effective reset command produces a "reset" of the variable elements of the master device and a blocking of its activity on the bus when the effective reset signal is activated, then a restart to the initial state and normal operation of the master device is allowed when the effective reset signal is deactivated.

[0077] So, in this example, the synchronization element RST_SYNC activates the effective reset signal RST_EFF ( figures 4 à 6 ) to block the initiation of a new transaction by the master device, and deactivates the effective reset signal RST_EFF when the transactions initiated on the bus BUS are in the completed state, and the reset command RST is completed.

[0078] The RST_SYNC synchronization element can be configured to provide a reset confirmation signal ACKRST (usually "acknowledgment" in English), after the actual reset.

[0079] In this particular embodiment, the reset management circuit GST further comprises a receiving element ANS_DRP configured to erase from the bus any responses transmitted when the master device is blocked in this way. Responses received when the master device is blocked are not communicated to the master device.

[0080] By "cleared from the bus" we mean that the responses are received, and possibly that a confirmation signal (for example of the "acknowledgement" type in English) is sent to the peripheral sending the response, so as to close the transaction on the BUS bus correctly according to the protocol used.

[0081] Furthermore, the GST reset management circuit may comprise its own reset input, intended to receive a reset signal RST_GST dedicated to the GST reset management circuit. This is provided in particular for a reset command of the complete system, including the GST reset management circuit, to start from a blank state.

[0082] We now refer to the figures 3 à 6 .

[0083] There figure 3 is a functional diagram illustrating an example of execution of the reset of a master device, implemented by a GST reset management circuit as previously described in relation to the figure 2 .

[0084] THE figures 4 , 5 And 6 are timing diagrams representing the signals involved when performing the reset according to this example, and for different situations.

[0085] In the drawings, for brevity, the term "reset" is replaced by the usual English term "reset".

[0086] At a step 310 of the method for resetting the master device 300, a command for resetting the master device is received.

[0087] The method comprises on the one hand a step 320 of verifying whether a transaction is being initiated by the master device, i.e. whether the generation of a request is in progress. For example, the request counter CNT_REQ can be provided for this purpose and transmit the information to the synchronization element RST_SYNC.

[0088] If a query is being generated when the reset command 310 is received, then step 320 waits (Y) until the query has finished being generated.

[0089] If there is no request generation in progress or when the request has finished being generated (N), then the effective reset signal is activated in step 330, so as to block the initiation of a new transaction by the master device.

[0090] Then, at a step 340, the method waits (Y) until there are no more pending responses to the requests previously initiated by the master device. In other words, step 340 corresponds to monitoring a completed or uncompleted state of the transactions initiated by the master device.

[0091] After step 340, when all pending responses are received, and therefore the initiated transactions are in the completed state (N), the method comprises a step 350 of verifying that the reset command has ended, and possibly waiting (N) for the reset command to end.

[0092] As mentioned previously for the actual reset command, the reset command received in step 310 includes the activation of a signal, and ends when this signal is deactivated.

[0093] Finally, in step 360, the effective reset signal is deactivated after the initiated transactions are in the completed state 340 (Y), and after the reset command signal is deactivated 350 (N). Furthermore, after step 360, the method may comprise transmitting the reset confirmation signal ACKRST (not shown).

[0094] There figure 4 represents the signals generated during the method 300 in the case where no TRSCT transaction has been initiated before or during the reception of the COM_RST reset command. Thus, the number of pending transactions TRSCT_NB is zero, and the effective reset signal RST_EFF is activated and deactivated at the same time as the RST reset signal. In other words, the effective reset COM_RST_EFF is commanded to the master device at the same time as the COM_RST reset command is received.

[0095] There figure 5 represents the signals generated during the method 300 in the case where a TRSCT transaction is initiated by the master device during the reception of the COM_RST reset command. Thus, the effective reset signal RST_EFF is activated after the end of the generation of the REQ request, and the number of current transactions TRSCT_NB is equal to 1, which is representative of an unfinished state of the transactions initiated by the device. The reset signal is kept activated until the number of current transactions TRSCT_NB becomes zero. After receiving the ANS response to the REQ request, the number of current transactions TRSCT_NB is zero, the transactions initiated by the master device are therefore in the finished state, and the effective reset signal RST_EFF is deactivated. After the effective reset command COM_RST_EFF, the confirmation ACKRST can be transmitted.

[0096] There figure 6 represents the signals generated during the method 300 in the case where TRSCT transactions are initiated by the master device before and during the reception of the COM_RST reset command. The number of current transactions TRSCT_NB is therefore 1 at the time of reception of the COM_RST reset command, and increased to 2 after the generation of a second REQ2 request. The number of current transactions TRSCT_NB returns to 1 after the reception of the ANS 1 response to the first REQ1 request, and becomes zero after the reception of the ANS2 response to the second REQ2 request. The ANS 1, ANS2 responses are not communicated to the master device and are erased from the bus. When the transactions initiated by the master device are in the completed state (i.e. the number of current transactions TRSCT_NB is zero), the effective reset signal RST_EFF is deactivated and the ACKRST confirmation can be transmitted.

[0097] There figure 7 illustrates an example of embodiment of the GST reset management circuit as an alternative to the example described previously in relation to the figure 2 The common elements between these examples of realization nevertheless support the same references and will not all be detailed again in the following.

[0098] This example differs from the example in relation to the figure 2 in that the GST circuit does not include the ANS_DRP receiving element, but includes a BUS_GAT blocking circuit configured to transmit a BUS_ST status signal from the BUS bus to the master device.

[0099] The BUS_ST status signal is intended to perform a handshake procedure between the master device and the BUS, in order to determine if the BUS can accept a new request. The BUS_ST status signal can typically have a ready state or a busy state.

[0100] This type of BUS_ST status signal is used, for example, in communication on an Advanced eXtensible Interface (AXI) bus.

[0101] Briefly, in the handshake procedure in the AXI protocol, a validity signal "valid" is sent by the master device to inform the destination device that the information on the BUS bus can be read. The status signal BUS_ST is provided by a flow management system, integrated into the BUS bus to inform that the bus is ready, and therefore operational to accept a new transaction, or that it is busy and therefore not operational to accept a new transaction. If a busy signal is transmitted to the master device, then the latter cannot send a new request.

[0102] The GST reset management circuit can be configured to retransmit the BUS_ST status signal received on the BUS bus, during normal operation.

[0103] And, in case of reception of a COM_RST reset command, the synchronization element is advantageously configured to force the BUS_ST status signal to the busy state, in order to block the initiation of a new transaction by the master device.

[0104] Thus, in this example, the generation of the blocking signal to block the initiation of a new transaction by the master device is performed by forcing the BUS_ST status signal to the busy state.

[0105] In this example, responses transmitted on the bus when the bus status signal BUS_ST is forced to the busy state are communicated normally to the master device.

[0106] We now refer to the figures 8 à 10 .

[0107] There figure 8 is a functional diagram illustrating the execution of the reset of a master device, implemented by a GST reset management circuit as previously described in relation to the figure 7 .

[0108] THE figures 9 And 10 are timing diagrams representing the signals involved when performing the reset according to this example, and for different situations.

[0109] At a step 810 of the method for resetting the master device 800, a command for resetting the master device is received.

[0110] The method comprises a verification step 820 whether a transaction is being initiated by the master device, similar to the verification step 320 described previously in relation to the figure 3 .

[0111] If there is no request generation in progress or when the request has finished being generated (N), then the bus status signal is forced to the busy state BSY, during a step 830, so as to block the initiation of a new transaction by the master device.

[0112] A monitoring step 840 waits (Y) for a completed status of the transactions initiated by the master device.

[0113] After step 840, when all pending responses are received, and therefore the initiated transactions are in the completed state (N), the effective reset command is generated during a step 850. The effective reset is controlled by a pulse of the effective reset signal, i.e. an activation of the signal for a duration long enough to reset the master device, and a deactivation of the signal.

[0114] Of course, a verification step (not shown) similar to the verification step 350 described previously in relation to the figure 3 can be provided between the monitoring step 840 and the step of generating the actual reset command 850.

[0115] And, after step 850, the method 800 may also include transmitting the reset confirmation signal ACKRST (not shown).

[0116] There figure 9 represents the signals generated during the method 800 in the case where a TRSCT transaction is initiated by the master device during the reception of the reset command COM_RST. Thus, the bus status signal BUS_ST is initially in the ready state RDY, and is forced to the busy state BSY after the end of the generation of the request REQ. Of course, the number of current transactions TRSCT_NB becomes 1, and represents an unfinished state of the transactions initiated by the master device. The bus status signal BUS_ST is busy BSY until the number of current transactions TRSCT_NB becomes zero. After receiving the response ANS to the request REQ, the number of current transactions TRSCT_NB is zero, which represents a completed state of the transactions initiated by the master device. As a result, the effective reset command COM_RST_EFF is generated as a pulsed activation of the effective reset signal RST_EFF.In addition, the bus status signal BUS_ST is no longer forced and resumes its handshake function and returns, for example, to the ready state RDY. After the effective reset command COM_RST_EFF, the confirmation ACKRST can be transmitted.

[0117] There figure 10 represents the signals generated during the method 800 in the case where TRSCT transactions are initiated by the master device before and during the reception of the reset command COM_RST. The number of current transactions TRSCT_NB is therefore 1 at the time of reception of the reset command COM_RST. Before receiving the reset command COM_RST, the bus status signal BUS_ST is not forced to the busy state (BSY) and remains ready RDY. At the end of the generation of a second request REQ2, the number of current transactions TRSCT_NB is set to 2, and, being representative of an unfinished state of the transactions on the bus, the bus status signal BUS_ST is forced to the busy state BSY. The number of current transactions TRSCT_NB returns to 1 after receiving the ANS2 response to the second request REQ2, and becomes zero after receiving the ANS1 response to the first request REQ1.The ANS2, ANS1 responses are communicated to the master device normally. When the transactions initiated by the master device are in the completed state (i.e. the number of pending transactions TRSCT_NB is zero), the effective reset command COM_RST_EFF is generated as a pulse in the effective reset signal RST_EFF, the bus status signal BUS_ST returns to the ready state RDY and the confirmation ACKRST can be transmitted.

[0118] The responses ANS2, ANS1 may be received in a different order from the order in which the requests REQ1, REQ2 are sent. It will be noted that, in an advantageously simple and versatile manner, the monitoring does not include an identification of the responses received, and therefore does not take into account the order in which the responses received are received to evaluate the completed or uncompleted state of the transactions initiated by the master.

[0119] Furthermore, all the embodiments and implementations described above in relation to the figures 1 à 10 may provide for an auxiliary reset command to be generated, if transactions initiated by the master device are in the uncompleted state after a maximum response time has expired.

[0120] For example, a timer can be provided in the GST reset management circuits, the action of which could be located, in loop (Y) of the response reception waiting steps 340, 840 (in relation to the figures 3 And 8) monitoring the completed or uncompleted state of transactions initiated by the master device. And, if beyond an arbitrarily chosen maximum duration the initiated transactions have remained in the uncompleted state, then the auxiliary reset command can be transmitted to a possible secure control device, or for example in order to reset all the peripherals of the system on chip, as a last resort solution.

Claims

1. A method for resetting a master device (MT_A, MT_B) configured to initiate transactions (TRSCT) on a bus (BUS_1, BUS_2) of a system-on-chip (SYS), comprising monitoring a completed or non-completed state of the transactions (TRSCT) initiated by the master device and, in case of reception of a master device reset command (COM_RST), effectively resetting (COM_RST_EFF) the master device when the transactions initiated by the master device are in the completed state, wherein a blocking signal is generated at the time of reception of the master device reset command (COM_RST), so as to block initiation of a new transaction by the master device (MT_A, MT_B), characterised in that in case of reception of the master device reset command (COM_RST) during transmission of a request, the blocking signal is generated after the end of transmission of this request.

2. The method according to claim 1, wherein said monitoring comprises detecting signals transiting on input (MT_IN) and output (MT_OUT) ports of an interface between the master device and the bus (INTF_A, INTF_B).

3. The method according to claim 2, wherein a transaction comprises issuing a request (REQ) on the output port (MT_OUT) of the interface and receiving an answer (ANS) on the input port (MT_IN) of the interface, and said monitoring comprises counting the number of requests transmitted (CNT_REQ) on the output port and counting the number of answers received (CNT_ANS) on the input port, a number of answers issued equal to the number of requests transmitted being representative of the completed state of the transactions (TRSCT) initiated by the master device.

4. The method according to claim 1, wherein generating the blocking signal comprises activating an effective reset signal (RST_EFF), and effectively resetting (COM_RST_EFF) the master device comprises deactivating the effective reset signal (RST_EFF), when the transactions initiated by the master device are in the completed state and when the reset command (COM_RST) received has ended.

5. The method according to claim 4, wherein a transaction comprises an answer (ANS) transmitted on the bus, and answers transmitted on the bus when the effective reset signal (RST_EFF) is activated are not communicated to the master device (MT_A, MT_B) and are cleared from the bus.

6. The method according to claim 1, wherein generating the blocking signal comprises transmitting to the master device (MT_A, MT_B) a bus state signal (BUS_ST) forced to the busy state (BSY), effectively resetting (COM_RST_EFF) the master device comprising pulsedly activating an effective reset signal (RST_EFF).

7. The method according to claim 6, wherein a transaction comprises an answer (ANS) transmitted on the bus, and the answers transmitted on the bus when the bus state signal (BUS_ST) is forced to the busy state (BSY) are communicated to the master device (MT_A, MT_B).

8. The method according to one of the preceding claims, wherein, an auxiliary reset command is generated upon reception of a master device reset command (COM_RST), and if the transactions (TRSCT) initiated by the master device are in the non-completed state after expiry of a maximum response time.

9. A system-on-chip comprising a bus (BUS_1, BUS_2) and at least one master device (MT_A, MT_B) configured to initiate transactions on the bus, wherein a reset management circuit (GST_A, GST_B) including an input for receiving a master device reset command (COM_RST), is configured to monitor a completed or non-completed state of the transactions initiated by the master device, and in case of reception of a reset command (COM_RST) on the input, for effectively resetting (COM_RST_EFF) the master device when the transactions initiated by the master device are in the completed state, wherein the reset management circuit (GST) is configured to generate a blocking signal at the time of reception of the master device reset command (COM_RST) on the input, so as to block initiation of a new transaction by the master device, characterised in that in case of reception of the master device reset command (COM_RST) during transmission of a request, the reset management circuit (GST) is configured to generate the blocking signal after the end of transmission of this request.

10. The system-on-chip according to claim 9, wherein the reset management circuit (GST_A, GST_B) is configured to detect signals transiting on input (MT_IN) and output (MT_OUT) ports of an interface (INTF_A, INTF_B) between the master device and the bus, in order to monitor said completed or non-completed state of said transactions.

11. The system-on-chip according to claim 10, wherein a transaction comprises issuing a request (REQ) to the output port (MT_OUT) of the interface and receiving an answer (ANS) to the input port (MT_IN) of the interface, and the reset management circuit (GST) is configured to monitor said completed or non-completed state of said transactions by counting the number of requests (CNT_REQ) issued on the output port and counting the number of answers (CNT_ANS) received on the input port, a number of answers received equal to the number of requests issued being representative of the completed state of the transactions initiated by the master device.

12. The system-on-chip according to claim 9, wherein the reset management circuit (GST) is configured to generate the blocking signal by activating an effective reset signal (RST_EFF), and to reset (COM_RST_EFF) the master device effectively by deactivating the effective reset signal (RST_EFF), when the transactions initiated by the master device are in the completed state and when the reset command (COM_RST) received on the input has ended.

13. The system-on-chip according to claim 12, wherein a transaction comprises an answer (ANS) transmitted on the bus, the reset management circuit (GST) is configured not to communicate to the master device and to clear from the bus the answers transmitted on the bus when the effective reset signal (RST_EFF) is activated.

14. The system-on-chip according to claim 9, wherein the reset management circuit (GST) is configured to generate the blocking signal by transmitting to the master device a bus state signal (BUS_ST) forced to the busy state (BSY), and to reset (COM_RST_EFF) the master device effectively by pulsedly activating an effective reset signal (RST_EFF).

15. The system-on-chip according to claim 14, wherein a transaction comprises an answer (ANS) transmitted on the bus, and the reset management circuit (GST) is configured to communicate to the master device the answers transmitted on the bus when the bus state signal (BUS_ST) is forced to the busy state (BSY).

16. The system-on-chip according to one of claims 9 to 15, wherein the reset management circuit (GST) is configured to generate an auxiliary reset command, in case of reception of a master device reset command (COM_RST), and if the transactions initiated by the master device are in the non-completed state after expiry of a maximum response time.