DE102016120668A1 - Data communication system - Google Patents

Abstract

A data communication system is proposed that connects a master entity to at least one slave entity, the data communication system comprising a fault manager configured to perform the following steps: (a) determining whether a transaction was successful; (b) if the transaction was unsuccessful, performing at least one retry; and (c) if the at least one retry failed, triggering a predefined action. In addition, a method for communicating information via a data communication system and a computer program product is provided.

Description

BACKGROUND OF THE INVENTION

Embodiments of the present invention relate to a data communication system, in particular a bus system, which connects a master entity to at least one slave entity.

SUMMARY

1. (a) Bestimmen, ob eine Transaktion erfolgreich war;
2. (b) falls die Transaktion nicht erfolgreich war, Durchführen von mindestens einem Neuversuch;
3. (c) falls der mindestens eine Neuversuch nicht erfolgreich war, Auslösen einer vordefinierten Aktion.

A first embodiment relates to a data communication system connecting a master entity to at least one slave entity, the data communication system comprising a fault manager adapted to perform the following steps:

1. (a) determining if a transaction was successful;
2. (b) if the transaction was unsuccessful, performing at least one retry;
3. (c) if the at least one retry failed, triggering a predefined action.

1. (a) Bestimmen durch den Fehlermanager, ob eine Transaktion über das Kommunikationssystem erfolgreich war;
2. (b) falls die Transaktion nicht erfolgreich war, Durchführen von mindestens einem Neuversuch;
3. (c) falls der mindestens eine Neuversuch nicht erfolgreich war, Auslösen einer vordefinierten Aktion.

A second embodiment relates to a method of communicating information over a data communication system connecting a master entity to at least one slave entity, the data communication system comprising a fault manager, comprising:

1. (a) determining by the fault manager whether a transaction via the communication system has been successful;
2. (b) if the transaction was unsuccessful, performing at least one retry;
3. (c) if the at least one retry failed, triggering a predefined action.

1. (a) Mittel zum Bestimmen durch den Fehlermanager, ob eine Transaktion über das Kommunikationssystem erfolgreich war;
2. (b) falls die Transaktion nicht erfolgreich war, Mittel zum Durchführen von mindestens einem Neuversuch;
3. (c) falls der mindestens eine Neuversuch nicht erfolgreich war, Mittel zum Auslösen einer vordefinierten Aktion.

A third embodiment relates to a data communication system connecting a master entity to at least one slave entity, the data communication system comprising a fault manager comprising:

1. (a) means for determining by the fault manager whether a transaction via the communication system has been successful;
2. (b) if the transaction was unsuccessful, means for performing at least one retry;
3. (c) if the at least one retry failed, means for initiating a predefined action.

A fourth embodiment is directed to a computer program product that is directly loadable into a memory of a digital computing device and includes software code portions for performing the steps of the method described herein.

list of figures

• 1 stellt ein Diagramm eines Datenkommunikationssystems dar, das mit einer Master-Entität und mehreren Slave-Entitäten verbunden ist.
• 2 stellt einen ersten Teil eines Prozesses zum Betreiben des Datenkommunikationssystems von 1 dar.
• 3 stellt einen zweiten Teil eines Prozesses zum Betreiben des Datenkommunikationssystems von 1 dar.

Embodiments will be illustrated and illustrated with reference to the drawings. The drawings serve to illustrate the basic principle so that only aspects necessary for understanding the basic principle are illustrated. The drawings are not to scale. In the drawings, the same reference numerals denote similar features.

• 1 FIG. 12 illustrates a diagram of a data communication system connected to a master entity and multiple slave entities. FIG.
• 2 illustrates a first part of a process for operating the data communication system of 1 represents.
• 3 illustrates a second part of a process for operating the data communication system of 1 represents.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

1 represents a diagram of a data communication system 101 that is with a master entity 102 , a first slave entity 103 and a second slave entity 104 connected is. The data communication system 101 includes a first interface 105 that with the master entity 102 connectable, and a second interface 106 that with the slave entities 103 . 104 is connectable.

The data communication system 101 can be a bus. The master entity 102 can be a bus master or core. The first interface 105 can be a master interface (MIF). The second interface 106 can be a slave interface (SIF).

The first interface 105 includes a fault manager 107 , The error manager 107 look for a transaction failure of the data communication system 101 , in particular for a set of configurable address ranges, and may take action before reporting the failure, eg to the master entity 102 to seize. In the illustrated data communication system 101 is the error manager 107 Part of the first interface 105 , Alternatively, the error manager could 107 Part of the second interface 106 be. The error manager 107 can be a hardware error manager (HEM), ie Implemented hardware, for example as a SoC (silicon-on-chip) structure.

2 represents a first part of a process for operating the data communication system 101 from 1 represents.

At a step S1, a transaction request is made by the data communication system 101 from the master entity 102 at the first interface 105 receive. The transaction request may be a read request, a write request or a combination thereof.

At a step S2, the data communication system routes 101 the transaction request to the second interface 106 further.

At a step S3, an address and possibly data for a data transaction (eg, a write transaction) based on the transaction request becomes the error manager 107 passed. The step S3 may be performed before, parallel to or after the step S2.

In an optional step S4, the fault manager determines 107 whether the address of the data transaction is within a configured address range or a configured set of address ranges. If "Yes", the process proceeds to a step S5.

In step S5, the fault manager determines 107 whether a (pre) configured number of retries n made in response to a data transaction failure is greater than zero, that is, if n> 0. In other words, the fault manager determines 107 whether to retry a data transaction through the bus following a data transaction failure. If "Yes", the process proceeds to a step S6.

In step S6, data for the data transaction is stored and a flag (also called a "bus retry flag") is set. In particular, the stored data is sufficient for retrying the data transaction if it should fail. A set flag may indicate that a retry of the data transaction by the data communication system 101 should be performed if the data transaction previously failed.

In a step S7, the data communication system waits 101 on a transaction status of the data transaction, eg failed or successful.

If the answer is "No" at any of steps S4 or S5, the process proceeds to step S7.

In one variant, the process may not include step S4.

The actual data transaction to the first slave entity 103 and / or the second slave entity 104 based on the transaction request may be performed in parallel to the steps S3 to S7. This offers the advantage that a performance penalty can be avoided if the data transaction is successful.

3 illustrates a second part of the process of operating the data communication system of 1 The in 3 In the case of a failed data transaction following the step S7 of FIG 2 be performed.

In a step S8 is checked, for example by the error manager 107 whether the data transaction failed. In particular, it checks whether the data transaction on the data communication system 101 failed. If "Yes", the process goes to a step S9.

At step S9, the fault manager checks 107 Whether the flag has been set in step S6. In other words, it checks if the error manager 107 is configured to retry the data transaction. If "No", a data transaction error in step S10 to the master entity 102 reported. In such a scenario, a fault alarm may become the master entity 102 to be triggered. If "Yes", the process proceeds to a step S11.

In step S11, the fault manager triggers 107 retry the data transaction. For this, the data can be used, which in step S3 to the error manager 107 be passed on.

Then, at a step S12, the fault manager determines 107 whether the data retrieval triggered by the retry was successful. If "No", the process goes to a step S13.

At step S13, the fault manager determines 107 whether the number of retries has exceeded the preconfigured number of retries n. If "No", the process proceeds to step S11, which triggers another retry. If "Yes", the process proceeds to a step S14.

In step S14, the error manager reports 107 an error to the master entity 102 / a Bus monitoring device and can - if it is configured in this way - trigger a fault alarm.

If the answer at step S12 is "yes" (ie, the bus transaction was successful during the retry), the error manager reports 107 in step S15 no error to the master entity 102 / the bus monitoring device. Optionally, the error manager 107 store the number of retries for this transaction and / or a cumulative number of retries for a given set of transactions (eg, all transactions or transactions since restarting transactions for a predefined amount of time). The number of retries can be stored in a register. Additionally, at least one interrupt may be triggered based on the particular configuration.

After step S15 and step S14, step S16 follows, in which the retry flag previously set in step S6 and any data stored in step S6 are erased.

Thus, the error manager stops 107 Look for bus transaction failures, especially for a set of configurable address ranges, and take necessary actions, such as a retry, for a predetermined number of times before the failure is reported to the system. This has the advantage of avoiding unnecessary reports to the bus master or bus monitoring device in a case where a retry of the transmission results in a successful transmission to the destination. It also shifts some processing power from the bus master because of the error manager 107 is able to autonomously resolve a certain number of transaction failures. Only the failures that can not be resolved within the n number of retries will get the attention of the bus master.

In addition, using the error manager allows 107 faster response to a bus failure and reduces the complexity and space requirements of error handling software. In addition, master entities can be flexibly and independently configured based on different application scenarios: For example, a program bus need not be configured to support the retry on the peripheral area. These advantages are especially pronounced if the fault manager is a hardware fault manager. In the event that the fault manager is a hardware fault manager, the further benefits are obtained that the fault manager implemented as a hardware component makes the decision to retry, thereby offloading the system. In addition, there is essentially no effect on the performance of the data communication system due to the hardware fault manager during normal operation.

This approach also has the advantage of allowing for a reduction in the complexity of a customer software component that facilitates error management of the data communication system, e.g. a bus error management, treated. It also improves performance of the data communication system and the associated master and slave entities in faulty scenarios. In particular, performance of the master entity is improved by reducing the delay in a retry after a transaction failure. Another advantage is that the error manager reduces memory requirements. Yet another advantage is that a customer does not have to develop and manage complex bus fault management software. If the error manager is implemented, it can also be reused in subsequent chip generations.

It is not intended that the order in which the process is described be considered as a limitation, and any number of the described process blocks may be combined in any order to implement the process or alternative processes. In addition, individual blocks may be removed from the process without departing from the spirit and scope of the subject matter described herein. Furthermore, the process may be implemented in any suitable materials or combinations thereof without departing from the scope of the presently described subject matter.

For example, the data communication system, the master entity, the first slave entity, and / or the second slave entity may be implemented in a SoC (silicon-on-chip) device.

In particular, the examples proposed herein may be based on at least one of the following solutions. In particular, combinations of the following features could be used to achieve a desired result. The features of the method could be combined with any one or more features of the device, device, or system, or vice versa.

1. (a) Bestimmen, ob eine Transaktion erfolgreich war;
2. (b) Durchführen von mindestens einem Neuversuch, falls die Transaktion nicht erfolgreich war;
3. (c) Auslösen einer vordefinierten Aktion, falls der mindestens eine Neuversuch nicht erfolgreich war.

A data communication system is proposed which connects a master entity to at least one slave entity, the data communication system comprising a fault manager adapted to perform the following steps:

1. (a) determining if a transaction was successful;
2. (b) performing at least one retry if the transaction was unsuccessful;
3. (c) trigger a predefined action if the at least one retry failed.

In one embodiment, the data communication system is a bus system having an interface to the master entity and an interface to the at least one slave entity.

In one embodiment, the fault manager is implemented in software and / or hardware.

• - Durchführen von mindestens einem Neuversuch, falls er dazu konfiguriert worden ist, den mindestens einen Neuversuch durchzuführen;
• - Nichtdurchführen von mindestens einem Neuversuch, falls er dazu konfiguriert worden ist, keinen Neuversuch durchzuführen.

In one embodiment, the fault manager is configured to further perform the following steps:

• - performing at least one retry if it has been configured to perform the at least one retry;
• - not performing at least one retry if it has been configured not to retry.

In one embodiment, the fault manager is configured to further perform the at least one retry for a predefined area or predefined addresses.

In one embodiment, the fault manager is configured to further retry if a predefined number of maximum retries has not yet been met or exceeded.

In one embodiment, the fault manager is configured to store the number of retries for a single transaction.

In one embodiment, the fault manager is configured to store the number of retries for at least two transactions.

In one embodiment, the transaction comprises a read or write transaction to the at least one slave entity.

In one embodiment, the master entity is a bus master.

In one embodiment, the predefined action is to create a notification and / or an alarm.

In one embodiment, the predefined action comprises notifying the master entity of the unsuccessful transaction.

The features described with respect to the above data communication system may be applied according to or in one or more combinations with the other independent solutions (categories) mentioned herein.

1. (a) Bestimmen durch den Fehlermanager, ob eine Transaktion über das Kommunikationssystem erfolgreich war;
2. (b) falls die Transaktion nicht erfolgreich war, Durchführen von mindestens einem Neuversuch;
3. (c) falls der mindestens eine Neuversuch nicht erfolgreich war, Auslösen einer vordefinierten Aktion.

Also provided is a method of communicating information over a data communication system that connects a master entity to at least one slave entity, the data communication system comprising a fault manager, comprising:

1. (a) determining by the fault manager whether a transaction via the communication system has been successful;
2. (b) if the transaction was unsuccessful, performing at least one retry;
3. (c) if the at least one retry failed, triggering a predefined action.

1. (a) Mittel zum Bestimmen durch den Fehlermanager, ob eine Transaktion über das Kommunikationssystem erfolgreich war;
2. (b) Mittel zum Durchführen von mindestens einem Neuversuch, falls die Transaktion nicht erfolgreich war;
3. (c) Mittel zum Auslösen einer vordefinierten Aktion, falls der mindestens eine Neuversuch nicht erfolgreich war.

Furthermore, a data communication system is proposed that connects a master entity to at least one slave entity, wherein the data communication system comprises a defect manager, comprising:

1. (a) means for determining by the fault manager whether a transaction via the communication system has been successful;
2. (b) means for making at least one retry if the transaction was unsuccessful;
3. (c) means for triggering a predefined action if the at least one retry failed.

A computer program product is also provided which is loadable into a memory of a digital computing device and includes software code portions for performing the method steps as described herein.

In one or more examples, the functions described herein may be implemented at least in part in hardware, such as special hardware components or as a processor. More generally, the techniques may be implemented in hardware, processors, software, firmware, or any combination thereof. If implemented in software, the functions may function as one or more instructions or code on a computer readable Medium are stored or transmitted over such and can be performed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media corresponding to a tangible medium, such as data storage media, or communication media, including any medium, that facilitates transfer of a computer program from one location to another, eg, according to a communication protocol. In this way, computer-readable media can generally ( 1 ) tangible, computer-readable storage media that are non-volatile, or ( 2 ) correspond to a communication medium such as a signal or a carrier wave. Data storage media may be any available media that may be accessed by one or more computers or by one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. A computer program product may include a computer readable medium.

By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk or other magnetic storage devices, flash memory, or any other medium capable of storing desired program code in the form can be used by instructions or data structures that can be accessed by a computer. Also, any connection will work properly as a computer readable medium, i. H. as a computer-readable transmission medium. For example, if instructions are being transmitted from a web site, server or other remote source using coaxial cable, fiber optic cable, a twisted pair cable, digital subscriber line (DSL) or wireless technologies such as infrared, radio and microwave, then the coaxial cable, the fiber optic cable, the twisted pair cable, the DSL or the wireless technologies, such as infrared, radio and microwaves, are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include links, carrier waves, signals or other transient media, but instead target non-transient, tangible storage media. As used herein, a disc and a disc include a compact disc (CD), a laser disc, an optical disc, a digital versatile disc (DVD), a floppy disk, and a blu-ray disc, and discs are usually data magnetic reproduce, whereas discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Instructions may be executed by one or more processors, such as one or more central processing units (CPUs), digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays ( FPGAs - Field Programmable Logic Arrays), or other equivalent integrated or discrete logic circuits.

Accordingly, the term "processor" as used herein may refer to any of the foregoing structures or any other structure suitable for implementation of the presently described techniques. Additionally, in some aspects, the functionality described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding or implemented in a combined codec. Also, the techniques could be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide variety of devices or devices, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices that are configured to perform the disclosed techniques, but do not necessarily require implementation by various hardware devices. Rather, as described above, various units may be combined in a single hardware unit or provided by a collection of interoperable hardware units, including, as described above, one or more processors along with appropriate software and / or firmware.

Although various embodiments of the invention have been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of the invention without departing from the spirit and scope of the invention. It will be apparent to one skilled in the art that other components performing the same functions may be conveniently employed. It should be noted that features explained with reference to a particular figure may be combined with features of other figures, even in those cases where this has not been expressly mentioned. Further, the methods of the invention can be achieved either in pure software implementations using the appropriate processor instructions or in hybrid implementations that use a combination of hardware logic and software logic to achieve the same results. Such modifications of the inventive concept are intended to be covered by the appended claims.

Claims (15)

A data communication system connecting a master entity to at least one slave entity, the data communication system comprising a fault manager configured to perform the following steps: (a) determining if a transaction was successful; (b) if the transaction was unsuccessful, performing at least one retry; (c) if the at least one retry failed, triggering a predefined action. Data communication system after Claim 1 wherein the data communication system is a bus system having an interface to the master entity and an interface to the at least one slave entity. Data communication system after Claim 1 in which the fault manager is implemented in software and / or hardware. Data communication system after Claim 1 in which the fault manager is set up, continue to perform the following steps: - performing at least one retry if it has been set up to perform the at least one retry; - failing to perform at least one retry if it has been set up to refrain from retrying. Data communication system after Claim 1 in which the fault manager is set up to continue to perform the at least one retry for a predefined area or predefined addresses. Data communication system after Claim 1 in which the fault manager is set up to continue to retry if a predefined number of maximum retries has not yet been reached or exceeded. Data communication system after Claim 1 in which the fault manager is set up to store the number of retries for a single transaction. Data communication system after Claim 1 in which the fault manager is set up to store the number of retries for at least two transactions. Data communication system after Claim 1 in which the transaction comprises a read or write transaction towards the at least one slave entity. Data communication system after Claim 1 in which the master entity is a bus master. Data communication system after Claim 1 where the predefined action is to create a notification and / or an alarm. Data communication system after Claim 1 wherein the predefined action comprises notifying the master entity of the unsuccessful transaction. A method of communicating information over a data communication system connecting a master entity to at least one slave entity, the data communication system comprising a fault manager, comprising: (a) determining from the fault manager whether a transaction via the communication system was successful; (b) performing at least one retry if the transaction was unsuccessful; (c) trigger a predefined action if the at least one retry failed. A data communication system connecting a master entity to at least one slave entity, the data communication system comprising a fault manager comprising: (a) means for determining by the fault manager whether a transaction via the communication system has been successful; (b) means for making at least one retry if the transaction was unsuccessful; (c) means for triggering a predefined action if the at least one retry failed. Computer program product that is loadable into a memory of a digital processing device and the software code parts for performing the steps of the method according to Claim 13 includes.

Images