Patent Application
20090119425
Embodiments of the present invention relate to buffering of data in a data communication unit. The invention is applicable to, but not limited to, buffering of data according to the Flexray™ protocol specification.
In a real-time data communication system, a host processor, often referred to as a host central processing unit (CPU), communicates to elements in the data communication system via a communication controller (CC) that buffers the data to be communicated. It is known that data consistency in data communication systems must be preserved. Hence, the host central processing unit (CPU) is typically arranged to control operations of the communication controller (CC) to ensure that the CC and the host CPU have a consistent view on the data that is stored in the buffers, and transmitted by, the CC.
In recent years there has been a significant increase in the amount of electronics that have been introduced into vehicles. This trend is expected to continue as car companies introduce further advances in safety, reliability and comfort. The introduction of advanced control systems in vehicles, which combine multiple sensors, actuators and electronic control units, is beginning to place demands on the communication technology that are not currently addressed by existing communication protocols.
Furthermore, it is known that future in-car control applications have additional requirements that include the combination of higher data rates, deterministic behaviour and the support of fault tolerance. Thus, flexibility in both communication bandwidth and provision of system extensions are also key attributes in data communication systems for vehicles, as the need for increased functionality and on-board diagnostics also increase.
A consortium of companies has been developing a communication system, called Flexray™, which aims to address the requirements for an advanced communication system for future automotive applications, as well as address some of these unique challenges. At the core of the FlexRay™ communication system is the FlexRay™ communications protocol. Details of the Flexray™ communication system and protocol specification can be found at:
The FlexRay™ communication protocol provides flexibility and determinism by combining a scalable static and dynamic message transmission, thereby incorporating the advantages of known synchronous and asynchronous protocols. The FlexRay™ communication protocol defines a network as a combination of a communication channels that connect nodes of a cluster. Furthermore, according to the Flexray protocol, data is transmitted over the Flexray network in frames during communication cycles. Each communication cycle has one Static segment and optionally one dynamic segment.
The FlexRay™ communication protocol also supports:
Within the FlexRay™ communication protocol, communication channels are defined as an inter-node connection through which signals are conveyed for the purpose of communication. The communication channel abstracts both the network topology, e.g. in a bus or star form, as well as the physical transmission medium to be used, e.g. an electrical or optical medium. A physical layer incorporating an independent ‘bus guardian’ provides further support for error containment. The FlexRay™ communication system is targeted to support data rates of up to 10 Mbit/sec with increased flexibility for easy system extension and the dynamic use of bandwidth. The 10 Mbit/sec data rate is available on two communication channels, thereby providing a gross data rate of up to 20 Mbit/sec.
Referring now to
The control bit is followed by a number of data blocks 140. Buffer control logic 145 controls the transmission of data from the respective transmit buffers 120, 125 onto the Flexray™ communication channels 150. The buffer control logic 145 buffers (queues) the transmit buffers for subsequent transmission on the Flexray network, as well as schedules transmission on the communication channels 150.
The host CPU 105 sets the control bit of a transmit buffer over bus 110. Once a control bit 130 has been set, the respective transmit buffer 120, 125 becomes committed, i.e. valid for transmission. Thus, the host CPU 105 is unable to reset the control bit. The CC 115 is only able to reset the control bit 130, and notably only following transmission of the transmit buffer 120, 125.
If a transmit buffer 120, 125 is assigned for a slot in the static segment, and committed, then a valid (buffered) frame is transmitted. In this regard, a static segment is a static time division multiple access scheme that is applied to coordinate transmissions. If a transmit buffer 120, 125 is assigned to a slot in the static segment, and not committed by the host CPU 105, then a null frame is transmitted.
Referring now to
The scheduling is performed by checking two fields of each available transmit buffer, i.e. a frame identifier (ID) is checked against zSearchID in step 235, and the control bit is checked to see if it is a ‘1’, thereby indicating that the buffer is committed by the host, in step 240. If the condition is true for a transmit buffer then the upcoming slot is assigned to the CC in step 245 and the CC will transmit data stored in the transmit buffer. If the condition is false for a transmit buffer, then the upcoming slot is not assigned to the CC, as shown in step 250.
A transmission commences after the host CPU data is completely passed to the transmit buffer. In this manner, and for every slot and for each channel, the CC determines whether it is to transmit a frame, execute the required transmit sequence, and receive the status for that slot, i.e. the CC schedules operations for the upcoming slot.
After the scheduling operation is finished the CC performs a transmit operation in channel ‘x’, as shown in the flowchart 300 of
Referring now to
However, it is noteworthy that, within the known solution, the host CPU 105 is neither able to access, nor uncommit, an already committed transmit buffer unless it has already been transmitted by the CC on a communication channel.
Thus, it is not possible to access or uncommit an already committed transmit buffer for the following reasons:
EP0496177 A1 describes a method for chaining of transmit buffers. In response to a host CPU command, the data is transferred to the chained transmit buffers. The host CPU is interrupted after all of the transmit buffers are transmitted on the network.
US Patent Application US20050180445 describes a method whereby the host CPU transmits its data through a network by accessing a transmit buffer where the transmission flow is controlled by two transmission interfaces.
Thus, neither of the above two documents solve the aforementioned problems. Hence, a need exists for an improved data communication unit, integrated circuit and method of buffering data to support safe invalidation of a transmit buffer that includes data that is already scheduled by the CC, and/or the safe commitment of a transmit buffer.
In accordance with aspects of the present invention, there is provided an improved data communication unit, integrated circuit and method of buffering data therein, as defined in the appended Claims.
Exemplary embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:
In one embodiment of the present invention a data communication unit comprises a host processor operably coupled to a communication controller having a plurality of buffers comprising a plurality of data elements. The plurality of data elements comprise a lock data element for access by the host processor to acquire sole use of a respective buffer of the plurality of buffers and a commit data element for access by the host processor once sole use of the respective buffer has been acquired wherein use of the lock data element enables the host processor to un-commit a buffer that has previously been committed for transmission by the communication controller.
In this manner, the use of a lock data element, such as a lock bit, to access a commit data element, such as a commit bit, may enable the host processor to access a transmit buffer, for example during an invalidation operation performed by the host CPU, whilst ensuring that data consistency is preserved. In addition, the use of a lock data element and a commit data element may support safe invalidation of transmit buffers before and after a scheduling of a transmission by a CC.
In one embodiment of the present invention, the host processor may be arranged to perform a number of data validation updates and/or checks of a respective buffer once it has acquired sole use of a respective buffer of the plurality of buffers.
In one embodiment of the present invention, the host processor may be arranged to invalidate a buffer for transmission by resetting a commit data element of the respective buffer, for example after the respective buffer has been locked by the host processor. In this manner, the host processor may be able to invalidate (and potentially subsequently make valid again) a buffer that had been scheduled for transmission by the CC, but where the transmission had not yet started.
In one embodiment of the present invention, the communication controller may be configured to block the host processor from accessing the buffer by setting the lock data element of the respective buffer. In this manner, the communication controller can control the scheduling and transmission of buffered data without fear of interruption by the host processor. In this manner, the buffer data and buffer state are consistent and the buffer access ownership is preserved.
In one embodiment of the present invention, the data communication unit may be adapted for use with the Flexray™ communication protocol.
In one embodiment of the present invention, an integrated circuit comprises a host processor operably coupled to a communication controller having a plurality of buffers, each having a plurality of data elements. The plurality of data elements comprises a lock data element for access by the host processor to acquire sole use of a respective buffer of the plurality of buffers. The plurality of data elements also comprise a commit data element for access by the host processor once sole use of the respective buffer has been acquired wherein use of the lock data element enables the host processor to un-commit a buffer that has previously been committed for transmission by the communication controller.
In one embodiment of the present invention, a method of buffering data in a communication controller, comprising a plurality of buffers having a plurality of data elements, is described. The method comprises committing a buffer for transmission by the communication controller and acquiring sole use of a respective buffer of the plurality of buffers by setting a lock data element. The method further comprises controlling access of the respective buffer by the host processor once sole use of the respective buffer has been acquired by setting of a commit data element; and un-committing the committed buffer by the host processor via use the lock data element.
One embodiment of the present invention will be described in terms of a Flexray™ system. However, it will be appreciated by a skilled artisan that the inventive concept herein described may be embodied in any type of host CPU-communication controller architecture.
Referring now to
Furthermore, the commit bit 530 is followed by a lock data element 535, for example in the form of a lock bit, and a number of data blocks 540. The commit bit 530 and lock bit 535 control the enhanced functionality of the buffer control logic 545. In this regard, the expression ‘enhanced functionality’ encompasses a possibility to invalidate an already committed buffer, even if it was scheduled for transmission but is yet to be transmitted. Buffer control logic 545 controls the transmission of data from the respective transmit buffers 520, 525 onto the Flexray™ communication channels 550. In effect, buffer control logic 545 buffers (queues) the transmit buffers for subsequent transmission on the Flexray™ network, as well as schedules transmission on the communication channels 550.
For every slot, and for each channel, the CC 515 determines whether it is to transmit a data frame, execute the required transmit sequence, and receive a status for that slot. In this regard, the CC 515 schedules operations for the upcoming slot. The CC 515 performs scheduling according to the known Flexray™ protocol. After the scheduling operation is finished the CC 515 may or may not perform transmit operations based on the results of two validation stage results, as illustrated in
In accordance with embodiments of the present invention, the host CPU 505 is able to identify which entity, for example either the host CPU 505 or the CC 515, has temporary ownership of the respective transmit buffer 520, 525. To identify ownership, the host CPU 505 reads a lock bit 535 on the respective transmit buffer to identify whether it is locked by the host CPU 505, for example if the lock bit returns a ‘1’, or the CC 515 if the lock bit returns, for example, a ‘0’. In the former case, this means that the transmit buffer is not currently utilized by the CC 515 for transmission. In contrast, in the latter case, the CC 515 would be utilizing the buffer for transmission on the Flexray™ bus. In effect, if the lock bit returns a ‘0’, the CC 515 is blocking any attempt from the host CPU 505 to lock the respective transmit buffer 520, 525, and thereafter update or validate the data therein.
In order to access a buffer, the host CPU 505 first ‘locks’ a transmit buffer, which defines ownership of that transmit buffer, by setting the respective lock bit 535. The host CPU 505 locks a transmit buffer by writing, say, a ‘1’ to the buffer lock bit over bus 510. After the lock is ‘granted’, the host CPU 505 is then able to commit the respective transmit buffer 520, 525 for transmission by setting the corresponding commit bit 530. Thereafter, the host CPU 505 is able to unlock the transmit buffer by resetting the lock bit 535, thereby making the frame available for the CC to initiate transmission on the Flexray™ network.
Advantageously, by use of a commit bit 530 and lock bit 535 in the above manner, the host CPU 505 is able to reset the commit bit 530 of a transmit buffer, i.e. make it invalid for the CC transmit operation on the Flexray™ network, after the buffer has been locked by the host CPU 505. Thus, the host CPU 505 is able to freely update or validate data in the respective buffer without fear of the CC initiating transmission. By locking the transmit buffer, the host CPU 505 prevents the CC 515 from accessing the transmit buffer. If the lock is granted, the host CPU 505 has control rights over the respective transmit buffers 520, 525 that it has set the lock bit for, so that the CC 515 ignores the respective transmit buffer(s) 520, 525 during a scheduling and/or a transmission operation.
In this manner, the host CPU 505 is able to access a transmit buffer 520, 525 for write operations to a respective commit bit 530 only after the transmit buffer has been locked by the host CPU 505, by setting the lock bit 535. In one embodiment of the present invention, lock is granted to the host CPU 505 only when the CC 515 has not utilized the respective transmit buffer for an internal transmit operation.
Thus, the host CPU 505 is able to safely invalidate a committed transmit buffer, even if it has already been scheduled for transmission by the CC 515. Furthermore, the host CPU 505 is able to perform any number of validation/invalidation steps, as well as updating a transmit buffer with the latest data, before the buffer(s) is/are transmitted.
Furthermore, in one embodiment of the present invention, the host CPU 505 may be able to invalidate and subsequently make valid again a transmit buffer 520, 525 that was already scheduled for transmission, but where its transmission had not yet started, by setting or resetting a commit bit of the transmit buffer 520, 525.
If the host CPU 505 invalidates a transmit buffer 520, 525 after it was scheduled for transmission by the CC 515, but the transmission has not yet started, then dependent upon the communication cycle segment (e.g. whether it was static or dynamic) the CC 515 may or may not transmit a ‘null-frame’ based on the scheduled transmit buffer header data, to comply with the Flexray™ protocol.
Before the CC 515 transmits the data in a transmit buffer 520, 525, the CC 515 may perform a validation check to ascertain whether the buffer may have been (or may not have been) invalidated by the host CPU 505. Furthermore, the CC 515 prevents the granting of control over a respective transmit buffer 520, 525 to the host CPU 505 once a transmission has already started. This is achieved by the CC 515 setting the lock bit 535, thereby blocking any attempt by the host CPU 505 to lock the respective transmit buffer 520, 525.
Thus, the host CPU 505 may be able to invalidate a transmit buffer any time before the CC 515 starts transmission of the buffered frame of data. Prior to the CC 515 locking the transmit buffer 520, 525 for transmission, the host CPU 505 may be able to lock and perform invalidation operations on any number of transmit buffers.
In one embodiment of the present invention, the host CPU 505 is able to uncommit a transmit buffer by resetting the commit bit after the respective transmit buffer 520, 525 had been locked by the host CPU 505. In this case, the transmit buffer becomes invalid for transmission, noting that each transmit buffer has its own commit bit and lock bit.
In one embodiment of the present invention, if the CC 515 has started a frame transmission operation from a transmit buffer, then any host CPU lock request will be ignored and the lock will not be granted by the CC 515. Hence, the safety of validation/invalidation operations is guaranteed by clear buffer ownership controlled by the lock bit.
Referring now to
If the transmit buffer is valid in step 620, the first frame word from the transmit buffer is transmit, as shown in step 625. A determination is then made as to whether all of the frame words have been transmitted in step 630. If all of the frame words have not been transmitted in step 630, the next frame word is transmit from the buffer in step 645 and the process loops back to step 630. If all of the frame words have been transmitted in step 630, the host CPU may gain access to the transmit buffer by the CC unblocking the lock bit, as shown in step 635.
It will be understood that an improved data communication unit, integrated circuit and method of buffering data therein, as described above, aim to provide at least one or more of the following advantages:
It will be appreciated that any suitable distribution of functionality between different functional or logical units may be used without detracting from the inventive concept herein described. Hence, references to specific functional devices or logic elements are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit or IC, in a plurality of units or ICs or as part of other functional units.
In particular, it is envisaged that the aforementioned inventive concept can be applied by a semiconductor manufacturer to any integrated circuit comprising a host CPU and/or communication controller (or equivalent logic or functional elements or devices). It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device or application-specific integrated circuit (ASIC) and/or any other sub-system element.
Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps.
Furthermore, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.
Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to “a”, “an”, “first”, “second” etc. do not preclude a plurality.
Thus, an improved data communication unit, integrated circuit and method of buffering data therein have been described, wherein the aforementioned disadvantages with prior art arrangements have been substantially alleviated.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP06/62164 | 5/9/2006 | WO | 00 | 11/7/2008 |
