Title of Invention	A FLEX RAY COMMUNICATION CHIP
Abstract	FlexRay communication module (100) with which to couple a FlexRay communication interface (101) to a user (102) assigned to the FlexRay communication module in a FlexRay network through which messages are transmitted, whereby the FlexRay communication module (100) contains the following components: a first configuration (105) for storing at least one part of the transmitted messages and a second configuration (104) for connecting the first configuration (105) to the user (102) as well as a third configuration (103) for connecting the FlexRay communication interface (101) to the first configuration (105). (Figure 1)

Title of Invention

A FLEX RAY COMMUNICATION CHIP

Abstract

FlexRay communication module (100) with which to couple a FlexRay communication interface (101) to a user (102) assigned to the FlexRay communication module in a FlexRay network through which messages are transmitted, whereby the FlexRay communication module (100) contains the following components: a first configuration (105) for storing at least one part of the transmitted messages and a second configuration (104) for connecting the first configuration (105) to the user (102) as well as a third configuration (103) for connecting the FlexRay communication interface (101) to the first configuration (105). (Figure 1)

Full Text	FLEXRAY COMMUNICATION MODULE Prior Art The invention is with regard to a FlexRay communication module with which to couple a FlexRay communications interface to a user assigned to the FlexRay communication module in the FlexRay network, through which messages are transmitted. Networking of control units, sensors and actuating elements with the help of a communication system and that of a bus system i.e., of a communications interface, has increased dramatically in recent years in the construction of modem motor vehicles or even in machine construction, particularly in the field of machine tools as well as in automation. Synergetic effects can thus be achieved through distribution of functions across several control units. One is hereby talking about distributed systems. Communication between different stations takes place increasingly through a bus system i.e., a communication system. Communication transactions on the bus systems, accessing and receiving mechanisms as well as error management are regulated by a protocol. An established protocol in this connection is the FlexRay protocol of which FlexRay protocol specification v2.0 forms the basis. FlexRay is a quick, deterministic and error-tolerant bus system, particularly for application in a motor vehicle. The FlexRay protocol functions according to the process of time division multiple access (TDMA), whereby fixed time slots are allocated to the components i.e., the users and/or to the messages to be transmitted, in which they have exclusive access to the communications interface. The time slots are thereby repeated in a fixed cycle so that, that point in time at which a message is transmitted through the bus, can be predicted precisely and bus access takes place in a deterministic manner. In order to optimally use the band breadth for message transmission on the bus system, FlexRay sub-divides the cycles into a static and a dynamic part. The fixed time slots are thereby located at the beginning of a bus cycle in the static part. Time slots are dynamically assigned in the dynamic part in which exclusive bus access is only possible for a short time in each case, so-called mini slots. Only when bus access takes place within a mini slot, is the time slot extended by the required time. The band breadth is thus only used up when it is actually required. FlexRay thereby communicates through two physically separated cables with a data rate of a maximum of 10 Mbyte/s each. The two channels thereby correspond to the physical layer, particularly of the OSI (open system architecture) layer model. These now mainly serve the redundant and therewith error-tolerant transmission of messages but can, however, also transmit diverse messages which would then result in doubling the data rate. FlexRay can, however, also be operated with low data rates. In order to implement synchronous functions and optimise the band breadth through short intervals between two messages, the components distributed in the communication network i.e., the user, requires a common time basis, a so-called global time. For clock synchronisation, synchronisation communication is transmitted in the static part of the cycle whereby the local time of a component is corrected in such a manner, corresponding to the FlexRay specification, by means of a specific algorithm that all local clocks run synchronous to a global clock. A FlexRay hub or FlexRay user or host contains a user-processor i.e., the host processor, a FlexRay controller or communications controller as well as a bus guardian in the case of bus monitoring. The host processor i.e., the user processor thereby supplies and processes data that is transmitted via the FlexRay communications controller. Messages and/or message objects can be configured for communication in a FlexRay network with e.g. up to 254 data bytes. The objective of the invention is now to provide a FlexRay communication module that optimally supports communication in a FlexRay network. Advantage of the Invention This objective is met by a FlexRay communications module with which to couple a FlexRay communication interface as a physical layer to a user assigned to the FlexRay communication module in a FlexRay network through which messages are transmitted. The FlexRay communication module thereby advantageously contains a first configuration for storing at least one part of the transmitted messages and a second configuration for connecting the first configuration to the user, as well as a third configuration for connecting the FlexRay communication interface i.e., the physical layer, to the first configuration. The first configuration, thereby, advantageously contains a message handler and a message RAM, whereby the message handler takes control with regard to the data path of the first and second configuration related to a data access with regard to the message RAM. The message RAM of the first configuration is advantageously divided into a header segment and a data segment. The second configuration advantageously contains an input buffer memory and an output buffer memory for connecting to the host i.e., the FlexRay user and/or the host processor, whereby either the input buffer memory or the output buffer memory or, at best, both memories are respectively divided in a preferred design into a partial buffer memory and a non-addressable memory that can each only be alternatively read and/or written, whereby data integrity is ensured. The alternate reading and/or writing of the respective partial buffer memory and associated non-addressable memory can be advantageously achieved through interchanging the respective access or through interchanging the memory content. It is thus of advantage if each partial buffer memory and each non-addressable memory is designed in such a manner that a data region and/or a header region each of two FlexRay messages can be stored. For problem-free customisation to different users or hosts, the second configuration contains an interface module that is composed of a user-specific partial module and a user-independent partial module, so that only the user-specific partial module need be modified for user customisation and the flexibility of the FlexRay communication module is overall increased. The partial modules can thereby also be respectively implemented within one interface module in the software i.e., each partial module can be implemented as a software function. Corresponding to the redundant transmission paths in the case of FlexRay, the third configuration advantageously contains a first interface module and a second interface module and is, for its part, divided into two data paths with two data directions respectively. The third configuration advantageously also contains a first and a second buffer memory too in order to carry the two data paths and the, in each case, two data direction computation. Thus, here too, the first and second buffer memories are designed in such a manner that at least one data segment each of two FlexRay messages can be stored. Each interface module of the third configuration advantageously contains a shift register and a FlexRay protocol finite state machine. The FlexRay protocol specification, v2.0 in particular, can be completely supported by the FlexRay communication module in accordance with the invention and up to e.g., 64 messages and/or message objects can be configured therewith. A flexible configurable message RAM thereby results for storing a varying number of message objects, subject to the size of the respective data field and data segment of the message respectively. Messages or message objects that have data fields of different lengths can thus be advantageously configured. The message RAM is thus beneficially designed as FIFO (first in, first out), so that a configurable receiving FIFO emerges. Each message and each message object respectively in memory can be configured as a receive buffer, transmit buffer or as a part of the configurable receiving-FIFOs. Acceptance filtering on Frame ID, Channel ID and cycle counter in the FlexRay network is similarly possible. Network management is thus supported in an advantageous manner. Apart from this, maskable module interrupts are provided in a beneficial manner. Other advantages and beneficial designs emerge from the features of the claims as well as from the description. Drawing The invention is described in greater detail using the following figures in the drawings. Figure 1 is, thereby, a schematic illustration of the communications module and its connection to the physical layer i.e., the communications interface and the communications or host user. Figure 2 is a detailed presentation of a specific design of a communication module from Figure 1 as well as its interface. The structure of the message RAM is illustrated in Figure 3. Figures A to 6 schematically describe the architecture and the process of data access in the direction of user to message RAM. Figures 7 to 9 schematically describe the architecture and the process of data access in the direction of message RAM to user. The message handler and the finite state machines contained therein are schematically presented in Figure 10. Figure 11 once again illustrates the components of the communications module as well as the user and the corresponding data paths controlled by the message handler. Figure 12 describes access distribution based on the data paths in Figure 11. The invention is described in greater detail below by means of the exemplary embodiments. Exemplary Embodiments Figure 1 is a schematic illustration of a FlexRay communication module 100 for connecting a user or host 102 to a FlexRay communications interface 101 i.e., the physical layer of FlexRay. For this purpose, the FlexRay communication module 100 is connected through an interface 107 to the user and user processor 102 respectively and through an interface 106 to the communications interface 101. For problem-free connection based, on the one hand, on transmission times and on the other on data integrity, three configurations are basically schematically differentiated in the FlexRay communication module. The first configuration 105 thereby serves for storing of at least one part of the messages to be transmitted, a clipboard in particular. A second configuration 104 is switched to between user 102 and this first configuration 105 through interfaces 107 and 108. Similarly, a third configuration 103 is switched to between user 101 and the first configuration 105 through interfaces 106 and 109 through which very flexible input and output of data as part of messages, particularly FlexRay messages, in and/or from the first configuration 105 can be achieved with guarantee of data integrity at optimal speed. This communication module 100 is presented once again in detail in a preferred design in Figure 2. Also presented in detail are the respective interfaces 106 to 109. The second configuration 104 thereby contains a receive buffer memory or an input buffer memory 201 (input buffer IBF), and a despatch buffer memory or output buffer memory 202 (output buffer OBF) as well as an interface module comprising two parts 203 and 204, whereby one partial module 203 is user-independent and the second partial module 204 is user-specific. The user-specific module 204 (customer CPU interface CIF) connects one user-specific host CPU 102 i.e., a client-specific user, to the FlexRay communication module. A bi-directional data line 216, an address line 217 as well as a control input 218 is provided for this. Also provided is an interrupt output 219. The user-specific partial module 204 is connected to a user-independent partial module 203 (generic CPU interface, GIF) i.e., the FlexRay communication module or the FlexRay-IP-module possesses a generic i.e., general, CPU interface to which a large number of varying client-specific host CPUs can attach themselves through corresponding user-specific partial modules i.e., customer CPU interfaces CIF. Thereby, subject to the user, only partial module 204 need be varied, which means a significantly lower complexity. The receive buffer memory or an input buffer 201, and a despatch buffer memory or output buffer 202 can be designed in a memory module or even in the separated memory modules. The input buffer 201 thereby serves intermediate storage of messages for transmission to the message RAM 200. The input buffer is thereby advantageously designed in such a manner that it can store two complete messages comprising respectively of a header segment, particularly with configuration data and a data segment or payload segment. The input buffer is thereby designed to have two parts (partial buffer memory and non-addressable memory) whereby transmission between user CPU 102 and the message RAM 200 is speeded up by alternately writing the two parts of the input buffer and by access change respectively. Despatch buffer memory or output buffer OBF similarly serves intermediate storage of messages for transmission from message RAM 200 to user CPU 102. The output buffer 202 is thereby also designed in such a manner that two complete messages comprising a header segment, particularly with configuration data and a data segment or payload segment, can be stored. Here too, the output buffer 202 is sub divided into two parts, a partial buffer memory and a non-addressable memory, whereby here too transmission between user and/or host CPU 102 and the message RAM 200 can be speeded up by alternative reading of both parts and/or through access change. This second configuration 104, comprising blocks 201 to 204 is connected to the first configuration 105 as illustrated. Configuration 105 comprises a message handler (MHD) 200 and a message RAM 300. The message handler monitors and/or controls data transfer between the input buffer 201 as well as the output buffer 202 and the message RAM 300. The same similarly monitors and/or controls data transmission in the other direction through the third configuration 103. Message RAM is preferably designed as a single-ported RAM. This RAM stores messages and message objects respectively i.e., the actual data together with configuration and status data. The precise structure of the message RAM 300 is illustrated in greater detail in Figure 3. The third configuration 103 comprises blocks 205 to 208. Corresponding to both channels of the FlexRay physical layer, this configuration 103 is divided into two data paths each with two data directions. This is apparent by interfaces 213 and 214 wherein the two data directions for channel A, RxA and TxA for receiving (RxA) and sending (TxA) as well as for channel B, RxB and TxB are presented. An optional, bi-directional control input is indicated with interface 215. Connecting the third configuration 103 takes place through a first buffer memory 205 for channel B and a second buffer memory 206 for channel A. These two buffer memories (transient buffer RAMs: RAM A and RAM B) serve as intermediate storage for data transmission from and/or to the first configuration 105. Corresponding to both channels, these two buffer memories 205 and 206 are respectively connected to an interface module 207 and 208, which contain the FlexRay protocol controller or bus protocol controller comprising a send/receive shift register and the FlexRay protocol finite state machine. The two buffer memories 205 and 206 thus serve as intermediate storage for data transmission between the shift registers of the interface modules or FlexRay protocol controller 207 and 208 and the message RAM 300. Here too the data fields, i.e. the payload segment or data segment of two FlexRay messages are stored in an advantageous manner through each buffer memory 205 and 206. The global time unit (GTU), which is illustrated by 209 in the communication module 100, is responsible for representing the global time period in FlexRay ie., the micro tick \|iT and the macro tick MT. Similarly the error-tolerant clock synchronisation of the cycle counter and monitoring of temporal intervals in static and dynamic segments are regulated by the global time unit 209. Block 210 represents the general system universal control (SUC) through which the operation modi of the FlexRay communication controller can be monitored and controlled. Wakeup, start up, re-integration and/or integration, normal operation and passive operation are a part of this. Block 211 represents the network and error management (NEM) as described in the FlexRay protocol specification v2.0. In conclusion, block 212 represents the interrupt control (INT), which manages the status and error interrupt flags and monitors and/or controls the interrupt outputs 219 to user CPU 102. Apart from this, block 212 contains an absolute and a relative timer and an internal clock respectively with which to create the time interrupts. Message objects and message buffer respectively can be configured with up to 254 data bytes for communication in a FlexRay network. The message RAM 300 is, in particular, a message RAM which can store up to a maximum of 64 message objects, for example. All functions that concern the handling and managing respectively of messages are implemented by the message handler 200. These are e.g., acceptance filtering, transfer of messages between the two FlexRay protocol controller blocks 207 and 208 and the message RAM 300 as well as control of the sending sequence and the availability of configuration data and status data respectively. An external CPU i.e., an external processor of the user processor 102 can directly access the register of the FlexRay communication module with the user-specific part 204 through the user interface. A plurality of registers is used thereby. These registers are used in order to configure and to control the FlexRay protocol controller i.e., the interface modules 207 and 208, the message handler (MHD) 200, the global time unit (GTU) 209, the general system universal controller (SUC) 210, the network and error management unit (NEM) 211, the interrupt controller (INT) 212 as well as access to the message RAM 300 and, similarly, to indicate the corresponding status. At least parts of this register are explained in greater detail in Figures 4 to 6 and 7 to 9. This type of described FlexRay communication module, in accordance in with invention, enables a simple conversion of the FlexRay specification v2.0 through which an ASIC or a micro controller with corresponding FlexRay functionality can be simply generated. Partitioning of the message RAM 300 is described in Figure 3. For the functionality of a FlexRay communication controller, required in accordance with FlexRay protocol specifications, a message RAM is required to make available messages to be transmitted (transmit buffer) as well as for the storing of error-free, received messages (receive buffer). A FlexRay protocol permits messages with a data segment i.e., a payload segment of 0 to 254 bytes. As illustrated in Figure 2, the message RAM is part of the FlexRay communication module 100. The process described below as well as the corresponding message RAM describe the storing of messages to be transmitted as well as of received messages, particularly by using a random access memory (RAM), whereby the mechanism in accordance with the invention enables storing of a pre-determined size of a variable number of messages in the message RAM. The number of storable messages is thus subject to the size of the data segment of the individual messages through which the size of the memory required can be minimised on the one hand without having to reduce the size of the data segment of messages and on the other hand, an optimal utilisation of the memory takes place. This variable partitioning of a memory RAM, particularly a RAM-based message memory, for a FlexRay communication controller is described in greater detail. As an example, a message RAM for implementation is now pre-set (m, n as natural numbers) with a fixed word length of n bits, for example, 8, 16, 32 etc. as well as a pre-determined memory depth of n words. The message RAM 300 is thus partitioned into two segments, a header segment HS and a data segment DS (payload section, payload segment). One header segment HB and one data segment DB per message is thus created. Header segments HBO, HB1 to HBk and data segments DBO, DB1 to DBk are thus created for messages 0, 1 to k (k as a natural number). A differentiation is thus made between first and second data in a message, whereby the first data corresponds to configuration data and/or status data with regard to the FlexRay message and is respectively stored in a header segment HB (HBO, HB1, ..., HBk). The second data, which corresponds to the actual data that is to be transmitted, is correspondingly stored in data segments DB (DBO, DB1, ., DBk). Thus a first data volume (measured in bit, byte or words) per message emerges for the first data and a second data volume (also measured in bit, byte or words) for the second data of a message, whereby the second data volume per message can be different. Partitioning into a header segment HS and data segment DS is now variable in the message RAM 300 i.e. no default limits exist between the segments. Partitioning into a header segment HS and data segment DS is, in accordance with the invention, subject to the number k of messages as well as to the second data volume i.e., the volume of actual data, of a message and/or of all k messages put together. In accordance with the invention, a data pointer DPO, DP1 to DPk respectively is now directly allocated to the configuration data KDO, KD1 to KDk of the respective message. A fixed number of words, here two, is allocated to each header segment HBO, HB1 to HBk in a special design so that a configuration date KD (KDO, KD1, ..., KDk) and a data pointer DP (DPO, DP1, .., DPk) are always stored together in a header segment HB. Data segment DS for storing the actual message data DO, D1 to Dk attaches itself to this header segment HS with the header segments HB whose size and/or first data volume is subject to the number k of the messages to be stored. With regard to its data volume, this data segment (or data section) is subject to respective data volumes of message data stored, here, e.g., six words in DBO, one word in DB1 and two words in DBk. The respective data pointers DPO, DP1 to DPk thus always point to the beginning i.e., to the start address of the respective data segment DBO, DB1 to DBk in which data DO, D1 to Dk of the respective messages 0, 1 to k are stored. Partitioning of the memory RAM into a header segment HS and a data segment DS is thus variable and dependent upon the number of messages itself as well as the respective data volume of a message and therewith the total two data volumes. The header segment will become smaller if fewer messages are configured and the segments that free up in the memory RAM can be used as an add-on for the data segment DS for storing of data. This variability ensures an optimal storage utilisation whereby using smaller memories is also possible. The free data segment FDS, especially its size, likewise subject to the combination of the number k of stored messages and the respective second data volume of messages, is thus minimal and can even become 0. Apart from using data pointers, it is also possible to store the first and second data, i.e., the configuration data KD (KDO, KD1, .., KDk) and the actual data D (D =, D1, ..., Dk) in a default sequence so that the sequence of the header segments HBO to HBk in the header segment HS and the sequence of data segments DBO to DBk in data segment DS are respectively identical. In this case, one data pointer could in fact even be dispensed with. In a special design, an error-identifier, especially a parity-bit-generator element and an error identification verifier, especially a parity-bit-verifying-element is allocated to the message RAM in order to ensure the correctness of data stored in HS and DS in that a check sum can also be stored, especially as a parity-bit, per word or per segment (HB and/or DB). Other monitoring identifiers e.g., a CRC (cycle redundancy check) or even more powerful identifiers such as ECC (error code correction) are conceivable. The following are the advantages when compared to a pre-determined partitioning of the memory RAM: During programming, the user can decide whether he would like to use a larger number of messages with a small data field or whether he would like to use a smaller number of messages with a large data field. Storage space is optimally utilised when configuring messages that have a data segment of varying sizes. The user has the possibility of using a data storage segment collectively for different messages. While implementing the communication controller at an integrated circuit, the size of the memory RAM can be customised to the requirements of the application by aligning the memory depth of the used storage without modifying the other functions of the communication controller. Furthermore, host-CPU access i.e., writing and reading of configuration data and/or status data and of actual data, through buffer memory configuration 201 and 202 is described in greater detail using Figures 4 to 6 as well as 7 to 9. The objective thereby is to create a coupling with regard to data transmission in such a manner that data integrity can be ensured and high transmission speed can be simultaneously guaranteed. Control of these procedures takes place through the message handler 200 which is described later in greater detail in Figures 10, 11 and 12. Write-access to message RAM 300 by the host-CPU of user-CPU 102 through the input buffer memory 201 is first described in greater detail in Figures 4, 5, and 6. In this connection, Figure 4 illustrates the communication module 100 once again, whereby only those parts of the communication module 100 that are relevant here are shown for reasons of clarity. This, for one, is the message handler 200, responsible for controlling process flows as well as two control registers 403 and 404 which, as illustrated, can be located outside the message handler 200 in the communication module 100 or can also be contained in the message handler 200 itself. 403 thereby represents the input buffer command request register and 404 the input buffer command mask register. Write access of host-CPU 102 to the message RAM 300 thus take place through an interconnected input buffer 201. This input buffer 201 is now designed to be partitioned and/or doubled, namely as a partial buffer memory 400 and a non-addressable memory 401 allocated to the partial buffer memory. Thus, as described below, continuous access takes place by the host-CPU 102 to messages and/or message objects, respective data of the message RAM 300 therewith ensuring data integrity and faster transmission. Access control takes place through the input buffer command request register 403 and through the input buffer command mask register 404. The respective bit locations in 403 are presented here, for example, for a breadth of 32 bits in register 403 with numbers from 0 to 31. The same applies to register 404 and bit locations 0 to 31 in 404. In accordance with the invention, bit locations 0 to 5, 15, 16 to 21 and 31 of register 403, for example, now receive a special function with regard to process flow control. Identifier IBRH (input buffer request host) can thus be entered in bit locations 0 to 5 of register 403 as a message identifier. Similarly, identifier IBRS (input buffer request shadow) can be entered in bit locations 16 to 21 of register 403. Likewise, IBSYH in register location 15 of 403 and IBSYS in register location 31 of 403 can be entered as access identifiers. Locations 0 to 2 of register 404 are also perfect, whereby other identifiers are entered as data identifiers in 0 and 1 with LHSH (load header section host) and LDSH (load data section host). These data identifiers here are in the simplest form viz., designed in each case as one bit. A start identifier is written with STRXRH (set transmission X request host) in bit location 2 of register 404. Process flow of write access to the message RAM through the input buffer is described below. The host-CPU writes the data of the message to be transferred in the input buffer 201. The host-CPU can, thereby, only write the configuration data and header data KD of a message for the header segment HS of the message RAM or only the actual data D of a message to be transferred for the data segment DS of the message RAM or both. Which part of a message i.e., configuration data and/or the actual data is to be transferred is determined by the special data identifiers LHSH and LDSH in the input buffer command mask register 404. Thus, whether the header data i.e., the configuration data KD gets transferred is determined by LHSH (load header section host), while the LDSH (load data section host) determines whether the data D is to be transferred. Since the input buffer memory 201 is designed with two parts, one part being the buffer memory 400 and the other a non-addressable memory 401 associated with the same, and a two-way access should take place, two other data identifier segments are provided as a counterpart to LHSH and LDSH that are related to the non-addressable memory 401. These data identifiers in bit locations 16 and 17 of register 404 are termed LHSS (load header section shadow) and LDSS (load data section shadow). The transfer procedure with regard to the non-addressable memory 401 is thus controlled by these. If the start bit and/or the start identifier STXRH (set transmission X request host) is now placed in bit location 2 of the input buffer command mask register 404, a transmission request is automatically set for the corresponding message object after completed transfer of the respective configuration data and/or actual data to be transferred to the memory RAM i.e., automatic transmission of a transferring message object is controlled, especially started, using this start identifier STXRH. The start identifier STXRS (set transmission X request shadow ), which, for example, is contained in bit location 18 of the input buffer command mask register 404 and is designed as a bit here too in the simplest case, is the counterpart to this corresponding to the non-addressable memory. The function of STXRS is analogous to the function of STXRH, only related to the non-addressable memory 1. If the host-CPU 102 writes the message identifier, particularly the number of the message object in the message RAM 300 to which data of the input buffer memory 201 is to be transferred, in bit locations 0 to 5 of the input buffer command request register 403 i.e., according to IBRH, the partial buffer memory 400 of the input buffer memory 201 and the associated non-addressable memory 401 are interchanged and/or respective access by host-CPU 102 and memory RAM 300 to the two partial memories 400 and 401 is interchanged, as indicated by the semi-circuiar arrow. Data transfer i.e., data transmission to the message RAM is also thereby started, for example. Data transfer to the message RAM 300 itself takes place from the non-addressable memory 401. Register segments IBRH and IBRS are simultaneously interchanged. LHSH and LDSH are similarly interchanged with LHSS and LDSS and STXRH with STXRS. IBRS thus indicates the identifier of the message i.e., the number of the message object for which a transfer i.e., a transfer from the non-addressable memory 401, is in progress and/or which message object i.e., which segment in the message RAM, was the last to receive data (KD and/or D) from the non-addressable memory 401. The identifier (here 1 bit once again, for example) IBSYS (input buffer busy shadow) in bit location 31 of the input buffer command request register 403 indicates whether a transfer is currently taking place, involving the non-addressable memory 401. Thus, for example, when IBSYS=1, a transfer is just being made from the non-addressable memory 401 and when IBSYS =1, it is not. This bit IBSYS is, for example, set by writing IBRH i.e., bit locations 0 to 5 in register 403 in order to indicate that a transfer between the non-addressable memory 401 and the memory RAM 300 is underway. IBSYS is re-set upon completion of this data transfer to the message RAM 300. While data transfer from the non-addressable memory 401 is taking place, the host-CPU 102 can write the next message to be transferred in the input buffer memory and/or in the partial buffer memory 400. The identifier can be further refined with the help of another access identifier IBSYH (input buffer busy host) for example, in bit location 15 of register 403. If the host-CPU 102 is writing IBRH, i.e., the bit locations 0 to 5 of register 403 while a transfer between the non-addressable memory 401 and the memory RAM is taking place i.e., IBSYS = 1, then IBSYH is set in the input buffer command request register 403. As soon as the current transfer is concluded, the requested transfer (request through STXRH; refer above) is started and the IBSYH bit is re-set. The IBSYS bit remains set during the entire time in order to indicate that data is being transferred to the message RAM. All utilized bits of all exemplary embodiments can, thereby, also be designed as identifiers with more than one bit. Of advantage is the one-bit solution on grounds of storage and processing economy. The mechanism thus described permits the host-CPU 101 to continuously transfer data to the message object located in the message RAM and comprising a header segment HB and data segment DB, provided that the access speed of the host-CPU 102 to the input buffer memory is less than or equal to the internal data transfer rate of the FlexRay-IP-module i.e., of the communication module 100. In Figures 7, 8 and 9, read access to the message RAM 300 by the host-CPU or user-CPU 102 through the despatch buffer memory or output buffer memory 202 is now described in greater detail. For this purpose, Figure 7 presents the communication module 100 once again, whereby here too only the relevant parts of the communication module 100 are shown for reasons of clarity. This is, for one, the message handler 200 responsible for process flow control as well as two control registers 703 and 704 which, as illustrated, can be housed outside the message handler 200 in the communication module 100 or can even be contained in the message handler 200 itself. 703, thereby, represents the output buffer command request register and 704 the output buffer command mask register. Read-access by host-CPU 102 to the message RAM 300 thus takes place through the interconnected output buffer 202. This output buffer 202 is now also designed to be partitioned and/or doubled, namely as a partial buffer memory 701 and a non-addressable memory 700, allocated to the partial buffer memory. Thus, as described below, continuous access by the host-CPU 102 to messages and/or message objects, respective data of the message RAM 300 takes place and data integrity and faster transmission in the opposite direction, now from the message RAM to the host, are therewith ensured. Access control takes place through the output buffer command request register 703 and through the input buffer command mask register 704. The respective bit locations in 703 are also represented in register 703 with numbers of 0 to 31 here, for example, for a breadth of 32 bits. The same applies to register 704 and bit locations 0 to 31 in 704. In accordance with the invention, bit locations 0 to 5, 8 and 9, 15 and 16 to 21 of register 703, for example, now receive a special function with regard to process flow control of the read access. Identifier OBRS (output buffer request shadow) can thus be entered in bit locations 0 to 5 of register 703. Similarly, identifier OBRH (output buffer request host) can be entered in bit locations 16 to 21 of register 703. An identifier OBSYS (output buffer busy shadow) can be entered as access identifier in bit location 15 of register 703. Locations 0 and 1 of the output buffer command mask register 704 are also perfect, whereby other identifiers are entered as data identifiers in bit locations 0 and 1 with RDSS (read data section shadow) and RHSS (read header section shadow). Other data identifiers are, for example, provided in bit locations 16 and 17 with RDSH (read data section host) and RHSH (read header section host). Here too these data identifiers are designed in the simplest form viz., designed as one bit in each case. A start identifier REQ is entered in bit location 9 of register 703. Furthermore a switching identifier VIEW is provided that is, for example, entered in bit location 8 of register 703. The host-CPU 102 requests for data of a message object from the message RAM 300 by writing the identifier of the required message i.e., particularly the number of the required message object, according to OBRS i.e., in bit locations 0 to 5 of register 703. The host-CPU can, as in the opposite direction, hereby also either read only the status and configuration data respectively and header data KD of a message i.e., from a header segment or only the actual data D of a message to be transferred i.e., from the data segment, or read both. Which part of the data i.e., from the header segment and/or data segment, is to be transferred is hereby determined by RHSS and RDSS, comparable to the opposite direction. This means that RHSS indicates whether the header data is to be read and RDSS indicates whether the actual data is to be read. A start identifier serves to start the transfer from the memory RAM to the non-addressable memory 700. This means that if, as in the simplest case, one bit is used as an identifier, transfer from the message RAM 300 to the non-addressable memory 700 is started by setting bit REQ in bit location 9 in the output buffer command request register 703. The current transfer is again indicated by an access identifier, here again in the simplest case by a bit OBSYS in register 703. In order to avoid collisions, it is of advantage if bit REQ is only set when OBSYS is not set, i.e., when no transfer is currently taking place. Message transfer between the message RAM 300 and the non-addressable memory 700 then takes place here too. The actual process flow could now be controlled and take place on the one hand comparable to the opposite direction as described below in Figures 4, 5, and 6 (complementary register allocation) or, however, be re-set in a variation by an additional identifier viz., a switching identifier VIEW in bit location 8 of register 703. This means bit OBSYS is re-set after conclusion of the transfer and by setting the bit VIEW in the output buffer command request register 703, the partial memory 701 and the associated non-addressable memory 700 get interchanged and/or the access to the same gets interchanged and host-CPU 102 can now read the message object requested for from the message RAM i.e., the corresponding message from the partial buffer memory 701. Thereby, here too, register cells OBRS and OBRH can be interchanged comparable with the opposite transfer direction in Figures 4 to 6. Similarly RHSS and RDSS are interchanged for RHSH and RDSH. A provision can be made here too as a protective mechanism that bit VIEW is only set when OBSYS is not set i.e., when no transfer is currently taking place. Read access by host-CPU 102 to the message RAM 300 thus take place through an interconnected output buffer memory 202. Like the input buffer memory, this output buffer memory too is designed doubled and/or with two parts in order to ensure continuous access by host-CPU 102 to the message objects that are stored in the message RAM 300. Here too the advantage of high data integrity and accelerated transfer is achieved. Utilising the described input and output buffers ensures that a host-CPU can uninterruptedly access the message RAM despite the internal module latency time. In order to safeguard this data integrity, the data transfer, particularly forwarding in the communication module 100, is undertaken by the message handler 200 (MHD). The message handler 200 is illustrated in Figure 10 for this purpose. The message handler can be represented in its functionality by several finite state machines or finite state automats i.e., finite automats, so-called finite state machines (FSM). Thereby at least three finite state machines and in a special design, four finite state machines, are provided. A first finite state machine is the IOBF-FSM and is indicated with 501 (input/out buffer state machine). This IOBF-FSM could also be partitioned into two finite state machines IBF-FSM (input buffer FSM) and OBF-FSM (output buffer FSM) per transfer direction with regard to the input buffer memory and to the output buffer memory, with which a maximum of five finite state machines (IBF-FSM, OBF-FSM, TBF1-FSM, TBF2-FSM, AFSM) would be conceivable. Provision of a common IOBF-FSM is, however, preferable. An at least second finite state machine is partitioned here into two blocks 502 and 503 in the course of the preferred exemplary embodiment and serves the two channels A and B with regard to memory 205 and 206, as per the description for Figure 2. A finite state machine can thereby be provided in order to serve both channels A and B or even, as in the preferred design, one finite state machine TBF1-FSM designated 502 (transient buffer (206 RAM A) state machine) for channel A and a TBF2-FSM designated 503 (transient buffer 2 (205, RAM B) state machine) for channel B. An arbiter finite state machine, the so-called AFSM that is designated 500, serves to control access by the three finite state machines 501 - 503 in a preferred exemplary embodiment. Date (KD and/or D) are transferred in a clock pulse generated by a clock pulse agent such as e.g., a VCO (voltage controlled oscillator), an oscillator quartz etc or a clock pulse adapted from this in the communication module. The clock pulse T can thereby be generated in the module or externally e.g., be provided as a bus clock pulse. This arbiter finite state machine AFSM 500 alternately allows access to the message RAM to one of the three finite state machines 501 - 503 respectively, particularly for a clock pulse period T i.e., time available is divided amongst these calling finite state automats corresponding to the access requirements of individual finite state automats 501, 502, 503. If an access request takes place from only one finite state machine then this one will receive 100% of the access time i.e., all clock pulses T. Should access request take place from two finite state machines then each finite state machine will receive 50% of the access time. In conclusion, should an access request take place from all three finite state automats then each of the finite state machines will receive 1/3 of the access time. Band breadth respectively available is thus optimally used. The first finite state machine designated 501 i.e., IOBF-FSM, executes the following actions, if required: Data transfer from input buffer memory 201 to selected message object in message RAM 300. Data transfer from selected message object in message RAM 300 to output buffer memory 202. The finite state machine for channel A 502 i.e., TBF1-FSM executes the following actions: Data transfer from selected message object in message RAM 300 to buffer memory 206 of channel A. Data transfer from buffer memory 206 to selected message object in message RAM 300. Search for matching message object in message RAM, whereby a search is made in the context of acceptance filtering when receiving the message object (receive buffer) for storing a message received on channel A and when transmitting the next message object to be transmitted on channel A (transmit buffer). Analogous to this is the action by TBF2-FSM i.e., of the finite state machine for channel B in block 503. This executes data transfer from a selected message object in the message RAM 300 to the buffer memory 205 of channel B and data transfer from buffer memory 205 to the selected message object in message RAM 300. The search function too is, analogous to TBF1-FSM, for a matching message object in the message RAM, whereby a search is made in the context of acceptance filtering when receiving the message object (receive buffer) for storing a message received on channel B and when transmitting the next message or message object to be transmitted on channel B (transmit buffer). Process flows and the transfer paths are illustrated once again in Figure 11. The three finite state machines 501 - 503 control the respective data transfers between the individual parts. 102 thereby again represents the host-CPU, 201 the input buffer memory and 202 the output buffer memory. Message RAM is represented by 300 and the two buffer memories for channels A and B by 206 and 205. The interface elements 207 and 208 are also illustrated. The first finite state automat IOBF-FSM designated 501, controls the data transfer Z1A and Z1B i.e., from the input buffer memory 201 to the message RAM 300 and from the message RAM 300 to the output buffer memory 202. Data transfer thus takes place through the data bus with a word breadth of, for example, 32 bits whereby any other bit number is also possible. The same applies to the transfer Z2 between the memory RAM and the buffer memory 206. This data transfer is controlled by TBF1-FSM i.e. 502, the finite state machine for channel A. Transfer Z3 between message RAM 300 and buffer memory 205 is controlled by finite state automat TBF2-FSM i.e., 503. Here too, data transfer takes place through the data bus with, for example, a word breadth of 32 bits, whereby here too, any other bit number is possible. The transfer of a complete message object through the transfer paths mentioned normally requires several clock pulse periods T. A division of the transfer time relating to the clock pulse periods T thus takes place through an arbiter i.e., the AFSM 500. The data paths in Figure 11 between these are thus represented by memory components monitored by the message handler. In order to ensure data integrity of the message object stored in the message RAM, data should be simultaneously exchanged only on one of the paths illustrated i.e. Z1A and Z1B as well as Z2 and Z3 advantageously at the same time. An example in Figure 12 illustrates how the available system clock pulse T can be divided by the arbiter, i.e., the AFSM 500 amongst three requesting finite state automats. In Phase 1 access requests take place from the finite state automat 501 and the finite state automat 502 i.e. the entire time is divided in each case by half between the two requesting finite state automats. Relating to the clock pulse periods in Phase 1, this signifies that the finite state automat 501 has access in clock pulse periods T1 and T3 and finite state automat 502 in clock pulse periods T2 and T4. In Phase 2 access takes place only through the finite state machine 501 so that all three clock pulse periods i.e. 100% of the access time from T5 to T7 is allotted to IOBF-FSM. Access requests of all three finite state automats 501 to 503 take place in Phase 3 so that a three-way division of the entire access time takes place. The arbiter AFSM then divides the access time, for example, in such a manner that the finite state machine 501 has access in the clock pulse periods T8 and T11, the finite state machine 502 has access in the clock pulse periods T9 and T12, and finite state machine 503 has access in clock pulse periods T10 and T13. Access in Phase 4 finally takes place through two finite state automats 502 and 503 on both channels A and B of the communication module so that access division takes place of clock pulse periods T14 and T16 to finite state machine 502 and of T15 and T17 to finite state machine 503. The arbiter finite state automat AFSM 500 thus ensures that in a case when more than one of the three finite state machines makes an access request to the message RAM 300, access is divided clock pulse-wise and alternating between the requesting finite state machines. This course of action ensures the integrity of the message objects stored in the message RAM i.e., the data integrity. If, for example, the host-CPU 102 wants to read a message object through the output buffer memory 202 while a received message is being written in this message object, then either the old status or the new status is read out subject to which request was started first, without both accesses to the message object in the message RAM themselves colliding. The process described enables the host-CPU to read or to write any message object in message RAM during running operation without the selected message object having to be locked (buffer locking) for the duration of the host-CPU access by the user at data exchange on both channels of the FlexRay bus. The integrity of data stored in the message RAM is thus Claims 1. FlexRay communication module (100) with which to couple a FlexRay communication interface (101) to a user (102) assigned to the FlexRay communication module in a FlexRay network through which messages are transmitted, characterised in that, the FlexRay communication module (100) contains the following components: a first configuration (105) for storing at least one part of the transmitted messages and a second configuration (104) for connecting the first configuration (105) to the user (102) as well as a third configuration (103) for connecting the FlexRay communication interface (101) to the first configuration (105). 2. FlexRay communication module (100) according to Claim 1, characterised in that, the first configuration (105) contains a message handler (200) and a message RAM (300). 3. FlexRay communication module (100) according to Claim 1, characterised in that, the first configuration (105) contains a message RAM (300), whereby the message RAM is partitioned into a header segment (HS) and a data segment (DS). 4. FlexRay communication module (100) according to Claim 1, characterised in that, the second configuration (104) contains an input buffer memory (201) and an output buffer memory (202). 5. FlexRay communication module (100) according to Claim 4, characterised in that, the input buffer memory (202) is partitioned into a partial buffer memory (701) and a non-addressable memory (700), whereby access to the partial buffer memory and the non-addressable memory can be interchanged. 6. FlexRay communication module (100) according to Claim 4, characterised in that, the input buffer memory (201) is partitioned into a partial buffer memory (400) and a non-addressable memory (401) whose contents can be interchanged. 7. FlexRay communication module (100) according to Claim 4, characterised in that, the output buffer memory (202) is partitioned into a partial buffer memory (701) and a non-addressable memory (700), whereby access to the partial buffer memory and the non- addressable memory is interchanged. 8. FlexRay communication module (100) according to Claim 4, characterised in that, the output buffer memory (202) is partitioned into a partial buffer memory (701) and a non-addressable memory (700) whose contents can be interchanged. 9. FlexRay communication module (100) according to one of Claims 5 to 8, characterised in that, each input buffer memory (400, 401) and each output buffer memory (700, 701) is designed in such a manner that a data segment and a header segment of two FlexRay messages can be stored. 10. FlexRay communication module (100) according to Claim 1, characterised in that, the second configuration (104) contains an interface module which comprises a user-specific partial module (204) and a user-independent partial module (203). 11. FlexRay communication module (100) according to Claim 1, characterised in that, the third configuration (103) is partitioned into a first interface module (207) and a second interface module (208) and into two data paths with two data directions respectively. 12. FlexRay communication module (100) according to Claim 1, characterised in that, the third configuration (103) contains a first buffer memory (206) and a second buffer memory (205) and is divided into two data paths with two data directions respectively. 13. FlexRay communication module (100) according to Claim 12, characterised in that, each of the two buffer memories (205, 206) is designed in such a manner that a data segment of two FlexRay messages can be stored. 14. FlexRay communication module (100) according to Claim 11, characterised in that, each of the interface modules (207, 208) contains a shift register and a FlexRay protocol finite state machine. Dated this 5 day of February 2007

Full Text

FLEXRAY COMMUNICATION MODULE Prior Art
The invention is with regard to a FlexRay communication module with which to couple a FlexRay communications interface to a user assigned to the FlexRay communication module in the FlexRay network, through which messages are transmitted.
Networking of control units, sensors and actuating elements with the help of a communication system and that of a bus system i.e., of a communications interface, has increased dramatically in recent years in the construction of modem motor vehicles or even in machine construction, particularly in the field of machine tools as well as in automation. Synergetic effects can thus be achieved through distribution of functions across several control units. One is hereby talking about distributed systems. Communication between different stations takes place increasingly through a bus system i.e., a communication system. Communication transactions on the bus systems, accessing and receiving mechanisms as well as error management are regulated by a protocol. An established protocol in this connection is the FlexRay protocol of which FlexRay protocol specification v2.0 forms the basis. FlexRay is a quick, deterministic and error-tolerant bus system, particularly for application in a motor vehicle. The FlexRay protocol functions according to the process of time division multiple access (TDMA), whereby fixed time slots are allocated to the components i.e., the users and/or to the messages to be transmitted, in which they have exclusive access to the communications interface. The time slots are thereby repeated in a fixed cycle so that, that point in time at which a message is transmitted through the bus, can be predicted precisely and bus access takes place in a deterministic manner. In order to optimally use the band breadth for message transmission on the bus system, FlexRay sub-divides the cycles into a static and a dynamic

part. The fixed time slots are thereby located at the beginning of a bus cycle in the static part. Time slots are dynamically assigned in the dynamic part in which exclusive bus access is only possible for a short time in each case, so-called mini slots. Only when bus access takes place within a mini slot, is the time slot extended by the required time. The band breadth is thus only used up when it is actually required. FlexRay thereby communicates through two physically separated cables with a data rate of a maximum of 10 Mbyte/s each. The two channels thereby correspond to the physical layer, particularly of the OSI (open system architecture) layer model. These now mainly serve the redundant and therewith error-tolerant transmission of messages but can, however, also transmit diverse messages which would then result in doubling the data rate. FlexRay can, however, also be operated with low data rates.
In order to implement synchronous functions and optimise the band breadth through short intervals between two messages, the components distributed in the communication network i.e., the user, requires a common time basis, a so-called global time. For clock synchronisation, synchronisation communication is transmitted in the static part of the cycle whereby the local time of a component is corrected in such a manner, corresponding to the FlexRay specification, by means of a specific algorithm that all local clocks run synchronous to a global clock.
A FlexRay hub or FlexRay user or host contains a user-processor i.e., the host processor, a FlexRay controller or communications controller as well as a bus guardian in the case of bus monitoring. The host processor i.e., the user processor thereby supplies and processes data that is transmitted via the FlexRay communications controller. Messages and/or message objects can be configured for communication in a FlexRay network with e.g. up to 254 data bytes.

The objective of the invention is now to provide a FlexRay communication module that optimally supports communication in a FlexRay network.
Advantage of the Invention
This objective is met by a FlexRay communications module with which to couple a FlexRay communication interface as a physical layer to a user assigned to the FlexRay communication module in a FlexRay network through which messages are transmitted. The FlexRay communication module thereby advantageously contains a first configuration for storing at least one part of the transmitted messages and a second configuration for connecting the first configuration to the user, as well as a third configuration for connecting the FlexRay communication interface i.e., the physical layer, to the first configuration.
The first configuration, thereby, advantageously contains a message handler and a message RAM, whereby the message handler takes control with regard to the data path of the first and second configuration related to a data access with regard to the message RAM. The message RAM of the first configuration is advantageously divided into a header segment and a data segment.
The second configuration advantageously contains an input buffer memory and an output buffer memory for connecting to the host i.e., the FlexRay user and/or the host processor, whereby either the input buffer memory or the output buffer memory or, at best, both memories are respectively divided in a preferred design into a partial buffer memory and a non-addressable memory that can each only be alternatively read and/or written, whereby data integrity is ensured. The alternate reading and/or writing of the respective partial buffer memory and associated non-addressable memory can be advantageously achieved through interchanging the respective access or through interchanging the memory content.

It is thus of advantage if each partial buffer memory and each non-addressable memory is designed in such a manner that a data region and/or a header region each of two FlexRay messages can be stored.
For problem-free customisation to different users or hosts, the second configuration contains an interface module that is composed of a user-specific partial module and a user-independent partial module, so that only the user-specific partial module need be modified for user customisation and the flexibility of the FlexRay communication module is overall increased. The partial modules can thereby also be respectively implemented within one interface module in the software i.e., each partial module can be implemented as a software function.
Corresponding to the redundant transmission paths in the case of FlexRay, the third configuration advantageously contains a first interface module and a second interface module and is, for its part, divided into two data paths with two data directions respectively. The third configuration advantageously also contains a first and a second buffer memory too in order to carry the two data paths and the, in each case, two data direction computation. Thus, here too, the first and second buffer memories are designed in such a manner that at least one data segment each of two FlexRay messages can be stored. Each interface module of the third configuration advantageously contains a shift register and a FlexRay protocol finite state machine.
The FlexRay protocol specification, v2.0 in particular, can be completely supported by the FlexRay communication module in accordance with the invention and up to e.g., 64 messages and/or message objects can be configured therewith. A flexible configurable message RAM thereby results for storing a varying number of message objects, subject to the size of the respective data field and data segment of the message respectively. Messages or message objects that have data fields of different lengths can thus be

advantageously configured. The message RAM is thus beneficially designed as FIFO (first in, first out), so that a configurable receiving FIFO emerges. Each message and each message object respectively in memory can be configured as a receive buffer, transmit buffer or as a part of the configurable receiving-FIFOs. Acceptance filtering on Frame ID, Channel ID and cycle counter in the FlexRay network is similarly possible. Network management is thus supported in an advantageous manner. Apart from this, maskable module interrupts are provided in a beneficial manner.
Other advantages and beneficial designs emerge from the features of the claims as well as from the description.
Drawing
The invention is described in greater detail using the following figures in the drawings.
Figure 1 is, thereby, a schematic illustration of the communications module and its connection to the physical layer i.e., the communications interface and the communications or host user.
Figure 2 is a detailed presentation of a specific design of a communication module from Figure 1 as well as its interface.
The structure of the message RAM is illustrated in Figure 3.
Figures A to 6 schematically describe the architecture and the process of data access in the direction of user to message RAM.

Figures 7 to 9 schematically describe the architecture and the process of data access in the direction of message RAM to user.
The message handler and the finite state machines contained therein are schematically presented in Figure 10.
Figure 11 once again illustrates the components of the communications module as well as the user and the corresponding data paths controlled by the message handler.
Figure 12 describes access distribution based on the data paths in Figure 11.
The invention is described in greater detail below by means of the exemplary embodiments.
Exemplary Embodiments
Figure 1 is a schematic illustration of a FlexRay communication module 100 for connecting a user or host 102 to a FlexRay communications interface 101 i.e., the physical layer of FlexRay. For this purpose, the FlexRay communication module 100 is connected through an interface 107 to the user and user processor 102 respectively and through an interface 106 to the communications interface 101. For problem-free connection based, on the one hand, on transmission times and on the other on data integrity, three configurations are basically schematically differentiated in the FlexRay communication module. The first configuration 105 thereby serves for storing of at least one part of the messages to be transmitted, a clipboard in particular. A second configuration 104 is switched to between user 102 and this first configuration 105 through interfaces 107 and 108. Similarly, a third configuration 103 is switched to between user 101 and the first configuration 105 through interfaces 106 and 109

through which very flexible input and output of data as part of messages, particularly FlexRay messages, in and/or from the first configuration 105 can be achieved with guarantee of data integrity at optimal speed.
This communication module 100 is presented once again in detail in a preferred design in Figure 2. Also presented in detail are the respective interfaces 106 to 109. The second configuration 104 thereby contains a receive buffer memory or an input buffer memory 201 (input buffer IBF), and a despatch buffer memory or output buffer memory 202 (output buffer OBF) as well as an interface module comprising two parts 203 and 204, whereby one partial module 203 is user-independent and the second partial module 204 is user-specific. The user-specific module 204 (customer CPU interface CIF) connects one user-specific host CPU 102 i.e., a client-specific user, to the FlexRay communication module. A bi-directional data line 216, an address line 217 as well as a control input 218 is provided for this. Also provided is an interrupt output 219. The user-specific partial module 204 is connected to a user-independent partial module 203 (generic CPU interface, GIF) i.e., the FlexRay communication module or the FlexRay-IP-module possesses a generic i.e., general, CPU interface to which a large number of varying client-specific host CPUs can attach themselves through corresponding user-specific partial modules i.e., customer CPU interfaces CIF. Thereby, subject to the user, only partial module 204 need be varied, which means a significantly lower complexity.
The receive buffer memory or an input buffer 201, and a despatch buffer memory or output buffer 202 can be designed in a memory module or even in the separated memory modules. The input buffer 201 thereby serves intermediate storage of messages for transmission to the message RAM 200. The input buffer is thereby advantageously designed in such a manner that it can store two complete messages comprising respectively of a header segment, particularly with configuration data and a data segment or payload segment. The input

buffer is thereby designed to have two parts (partial buffer memory and non-addressable memory) whereby transmission between user CPU 102 and the message RAM 200 is speeded up by alternately writing the two parts of the input buffer and by access change respectively. Despatch buffer memory or output buffer OBF similarly serves intermediate storage of messages for transmission from message RAM 200 to user CPU 102. The output buffer 202 is thereby also designed in such a manner that two complete messages comprising a header segment, particularly with configuration data and a data segment or payload segment, can be stored. Here too, the output buffer 202 is sub divided into two parts, a partial buffer memory and a non-addressable memory, whereby here too transmission between user and/or host CPU 102 and the message RAM 200 can be speeded up by alternative reading of both parts and/or through access change. This second configuration 104, comprising blocks 201 to 204 is connected to the first configuration 105 as illustrated.
Configuration 105 comprises a message handler (MHD) 200 and a message RAM 300. The message handler monitors and/or controls data transfer between the input buffer 201 as well as the output buffer 202 and the message RAM 300. The same similarly monitors and/or controls data transmission in the other direction through the third configuration 103. Message RAM is preferably designed as a single-ported RAM. This RAM stores messages and message objects respectively i.e., the actual data together with configuration and status data. The precise structure of the message RAM 300 is illustrated in greater detail in Figure 3.
The third configuration 103 comprises blocks 205 to 208. Corresponding to both channels of the FlexRay physical layer, this configuration 103 is divided into two data paths each with two data directions. This is apparent by interfaces 213 and 214 wherein the two data directions for channel A, RxA and TxA for receiving (RxA) and sending (TxA) as well as for channel B, RxB and TxB are presented.

An optional, bi-directional control input is indicated with interface 215. Connecting the third configuration 103 takes place through a first buffer memory 205 for channel B and a second buffer memory 206 for channel A. These two buffer memories (transient buffer RAMs: RAM A and RAM B) serve as intermediate storage for data transmission from and/or to the first configuration 105. Corresponding to both channels, these two buffer memories 205 and 206 are respectively connected to an interface module 207 and 208, which contain the FlexRay protocol controller or bus protocol controller comprising a send/receive shift register and the FlexRay protocol finite state machine. The two buffer memories 205 and 206 thus serve as intermediate storage for data transmission between the shift registers of the interface modules or FlexRay protocol controller 207 and 208 and the message RAM 300. Here too the data fields, i.e. the payload segment or data segment of two FlexRay messages are stored in an advantageous manner through each buffer memory 205 and 206.
The global time unit (GTU), which is illustrated by 209 in the communication module 100, is responsible for representing the global time period in FlexRay ie., the micro tick |iT and the macro tick MT. Similarly the error-tolerant clock synchronisation of the cycle counter and monitoring of temporal intervals in static and dynamic segments are regulated by the global time unit 209.
Block 210 represents the general system universal control (SUC) through which the operation modi of the FlexRay communication controller can be monitored and controlled. Wakeup, start up, re-integration and/or integration, normal operation and passive operation are a part of this.
Block 211 represents the network and error management (NEM) as described in the FlexRay protocol specification v2.0. In conclusion, block 212 represents the interrupt control (INT), which manages the status and error interrupt flags and monitors and/or controls the interrupt outputs 219 to user CPU 102. Apart from

this, block 212 contains an absolute and a relative timer and an internal clock respectively with which to create the time interrupts.
Message objects and message buffer respectively can be configured with up to 254 data bytes for communication in a FlexRay network. The message RAM 300 is, in particular, a message RAM which can store up to a maximum of 64 message objects, for example. All functions that concern the handling and managing respectively of messages are implemented by the message handler 200. These are e.g., acceptance filtering, transfer of messages between the two FlexRay protocol controller blocks 207 and 208 and the message RAM 300 as well as control of the sending sequence and the availability of configuration data and status data respectively.
An external CPU i.e., an external processor of the user processor 102 can directly access the register of the FlexRay communication module with the user-specific part 204 through the user interface. A plurality of registers is used thereby. These registers are used in order to configure and to control the FlexRay protocol controller i.e., the interface modules 207 and 208, the message handler (MHD) 200, the global time unit (GTU) 209, the general system universal controller (SUC) 210, the network and error management unit (NEM) 211, the interrupt controller (INT) 212 as well as access to the message RAM 300 and, similarly, to indicate the corresponding status. At least parts of this register are explained in greater detail in Figures 4 to 6 and 7 to 9. This type of described FlexRay communication module, in accordance in with invention, enables a simple conversion of the FlexRay specification v2.0 through which an ASIC or a micro controller with corresponding FlexRay functionality can be simply generated.
Partitioning of the message RAM 300 is described in Figure 3. For the functionality of a FlexRay communication controller, required in accordance with

FlexRay protocol specifications, a message RAM is required to make available messages to be transmitted (transmit buffer) as well as for the storing of error-free, received messages (receive buffer). A FlexRay protocol permits messages with a data segment i.e., a payload segment of 0 to 254 bytes. As illustrated in Figure 2, the message RAM is part of the FlexRay communication module 100. The process described below as well as the corresponding message RAM describe the storing of messages to be transmitted as well as of received messages, particularly by using a random access memory (RAM), whereby the mechanism in accordance with the invention enables storing of a pre-determined size of a variable number of messages in the message RAM. The number of storable messages is thus subject to the size of the data segment of the individual messages through which the size of the memory required can be minimised on the one hand without having to reduce the size of the data segment of messages and on the other hand, an optimal utilisation of the memory takes place. This variable partitioning of a memory RAM, particularly a RAM-based message memory, for a FlexRay communication controller is described in greater detail.
As an example, a message RAM for implementation is now pre-set (m, n as natural numbers) with a fixed word length of n bits, for example, 8, 16, 32 etc. as well as a pre-determined memory depth of n words. The message RAM 300 is thus partitioned into two segments, a header segment HS and a data segment DS (payload section, payload segment). One header segment HB and one data segment DB per message is thus created. Header segments HBO, HB1 to HBk and data segments DBO, DB1 to DBk are thus created for messages 0, 1 to k (k as a natural number). A differentiation is thus made between first and second data in a message, whereby the first data corresponds to configuration data and/or status data with regard to the FlexRay message and is respectively stored in a header segment HB (HBO, HB1, ..., HBk). The second data, which corresponds to the actual data that is to be transmitted, is correspondingly stored

in data segments DB (DBO, DB1, ., DBk). Thus a first data volume (measured in bit, byte or words) per message emerges for the first data and a second data volume (also measured in bit, byte or words) for the second data of a message, whereby the second data volume per message can be different. Partitioning into a header segment HS and data segment DS is now variable in the message RAM 300 i.e. no default limits exist between the segments. Partitioning into a header segment HS and data segment DS is, in accordance with the invention, subject to the number k of messages as well as to the second data volume i.e., the volume of actual data, of a message and/or of all k messages put together. In accordance with the invention, a data pointer DPO, DP1 to DPk respectively is now directly allocated to the configuration data KDO, KD1 to KDk of the respective message. A fixed number of words, here two, is allocated to each header segment HBO, HB1 to HBk in a special design so that a configuration date KD (KDO, KD1, ..., KDk) and a data pointer DP (DPO, DP1, .., DPk) are always stored together in a header segment HB. Data segment DS for storing the actual message data DO, D1 to Dk attaches itself to this header segment HS with the header segments HB whose size and/or first data volume is subject to the number k of the messages to be stored. With regard to its data volume, this data segment (or data section) is subject to respective data volumes of message data stored, here, e.g., six words in DBO, one word in DB1 and two words in DBk. The respective data pointers DPO, DP1 to DPk thus always point to the beginning i.e., to the start address of the respective data segment DBO, DB1 to DBk in which data DO, D1 to Dk of the respective messages 0, 1 to k are stored. Partitioning of the memory RAM into a header segment HS and a data segment DS is thus variable and dependent upon the number of messages itself as well as the respective data volume of a message and therewith the total two data volumes. The header segment will become smaller if fewer messages are configured and the segments that free up in the memory RAM can be used as an add-on for the data segment DS for storing of data. This variability ensures an optimal storage utilisation whereby using smaller memories is also possible. The

free data segment FDS, especially its size, likewise subject to the combination of the number k of stored messages and the respective second data volume of messages, is thus minimal and can even become 0.
Apart from using data pointers, it is also possible to store the first and second data, i.e., the configuration data KD (KDO, KD1, .., KDk) and the actual data D (D =, D1, ..., Dk) in a default sequence so that the sequence of the header segments HBO to HBk in the header segment HS and the sequence of data segments DBO to DBk in data segment DS are respectively identical. In this case, one data pointer could in fact even be dispensed with.
In a special design, an error-identifier, especially a parity-bit-generator element and an error identification verifier, especially a parity-bit-verifying-element is allocated to the message RAM in order to ensure the correctness of data stored in HS and DS in that a check sum can also be stored, especially as a parity-bit, per word or per segment (HB and/or DB). Other monitoring identifiers e.g., a CRC (cycle redundancy check) or even more powerful identifiers such as ECC (error code correction) are conceivable. The following are the advantages when compared to a pre-determined partitioning of the memory RAM:
During programming, the user can decide whether he would like to use a larger number of messages with a small data field or whether he would like to use a smaller number of messages with a large data field. Storage space is optimally utilised when configuring messages that have a data segment of varying sizes. The user has the possibility of using a data storage segment collectively for different messages.
While implementing the communication controller at an integrated circuit, the size of the memory RAM can be customised to the requirements of the application by

aligning the memory depth of the used storage without modifying the other functions of the communication controller.
Furthermore, host-CPU access i.e., writing and reading of configuration data and/or status data and of actual data, through buffer memory configuration 201 and 202 is described in greater detail using Figures 4 to 6 as well as 7 to 9. The objective thereby is to create a coupling with regard to data transmission in such a manner that data integrity can be ensured and high transmission speed can be simultaneously guaranteed. Control of these procedures takes place through the message handler 200 which is described later in greater detail in Figures 10, 11 and 12.
Write-access to message RAM 300 by the host-CPU of user-CPU 102 through the input buffer memory 201 is first described in greater detail in Figures 4, 5, and 6. In this connection, Figure 4 illustrates the communication module 100 once again, whereby only those parts of the communication module 100 that are relevant here are shown for reasons of clarity. This, for one, is the message handler 200, responsible for controlling process flows as well as two control registers 403 and 404 which, as illustrated, can be located outside the message handler 200 in the communication module 100 or can also be contained in the message handler 200 itself. 403 thereby represents the input buffer command request register and 404 the input buffer command mask register. Write access of host-CPU 102 to the message RAM 300 thus take place through an interconnected input buffer 201. This input buffer 201 is now designed to be partitioned and/or doubled, namely as a partial buffer memory 400 and a non-addressable memory 401 allocated to the partial buffer memory. Thus, as described below, continuous access takes place by the host-CPU 102 to messages and/or message objects, respective data of the message RAM 300 therewith ensuring data integrity and faster transmission. Access control takes place through the input buffer command request register 403 and through the

input buffer command mask register 404. The respective bit locations in 403 are presented here, for example, for a breadth of 32 bits in register 403 with numbers from 0 to 31. The same applies to register 404 and bit locations 0 to 31 in 404.
In accordance with the invention, bit locations 0 to 5, 15, 16 to 21 and 31 of register 403, for example, now receive a special function with regard to process flow control. Identifier IBRH (input buffer request host) can thus be entered in bit locations 0 to 5 of register 403 as a message identifier. Similarly, identifier IBRS (input buffer request shadow) can be entered in bit locations 16 to 21 of register 403. Likewise, IBSYH in register location 15 of 403 and IBSYS in register location 31 of 403 can be entered as access identifiers. Locations 0 to 2 of register 404 are also perfect, whereby other identifiers are entered as data identifiers in 0 and 1 with LHSH (load header section host) and LDSH (load data section host). These data identifiers here are in the simplest form viz., designed in each case as one bit. A start identifier is written with STRXRH (set transmission X request host) in bit location 2 of register 404.
Process flow of write access to the message RAM through the input buffer is described below.
The host-CPU writes the data of the message to be transferred in the input buffer 201. The host-CPU can, thereby, only write the configuration data and header data KD of a message for the header segment HS of the message RAM or only the actual data D of a message to be transferred for the data segment DS of the message RAM or both. Which part of a message i.e., configuration data and/or the actual data is to be transferred is determined by the special data identifiers LHSH and LDSH in the input buffer command mask register 404. Thus, whether the header data i.e., the configuration data KD gets transferred is determined by LHSH (load header section host), while the LDSH (load data section host) determines whether the data D is to be transferred. Since the input buffer

memory 201 is designed with two parts, one part being the buffer memory 400 and the other a non-addressable memory 401 associated with the same, and a two-way access should take place, two other data identifier segments are provided as a counterpart to LHSH and LDSH that are related to the non-addressable memory 401. These data identifiers in bit locations 16 and 17 of register 404 are termed LHSS (load header section shadow) and LDSS (load data section shadow). The transfer procedure with regard to the non-addressable memory 401 is thus controlled by these.
If the start bit and/or the start identifier STXRH (set transmission X request host) is now placed in bit location 2 of the input buffer command mask register 404, a transmission request is automatically set for the corresponding message object after completed transfer of the respective configuration data and/or actual data to be transferred to the memory RAM i.e., automatic transmission of a transferring message object is controlled, especially started, using this start identifier STXRH.
The start identifier STXRS (set transmission X request shadow ), which, for example, is contained in bit location 18 of the input buffer command mask register 404 and is designed as a bit here too in the simplest case, is the counterpart to this corresponding to the non-addressable memory. The function of STXRS is analogous to the function of STXRH, only related to the non-addressable memory 1.
If the host-CPU 102 writes the message identifier, particularly the number of the message object in the message RAM 300 to which data of the input buffer memory 201 is to be transferred, in bit locations 0 to 5 of the input buffer command request register 403 i.e., according to IBRH, the partial buffer memory
400 of the input buffer memory 201 and the associated non-addressable memory
401 are interchanged and/or respective access by host-CPU 102 and memory
RAM 300 to the two partial memories 400 and 401 is interchanged, as indicated

by the semi-circuiar arrow. Data transfer i.e., data transmission to the message RAM is also thereby started, for example. Data transfer to the message RAM 300 itself takes place from the non-addressable memory 401. Register segments IBRH and IBRS are simultaneously interchanged. LHSH and LDSH are similarly interchanged with LHSS and LDSS and STXRH with STXRS. IBRS thus indicates the identifier of the message i.e., the number of the message object for which a transfer i.e., a transfer from the non-addressable memory 401, is in progress and/or which message object i.e., which segment in the message RAM, was the last to receive data (KD and/or D) from the non-addressable memory 401. The identifier (here 1 bit once again, for example) IBSYS (input buffer busy shadow) in bit location 31 of the input buffer command request register 403 indicates whether a transfer is currently taking place, involving the non-addressable memory 401. Thus, for example, when IBSYS=1, a transfer is just being made from the non-addressable memory 401 and when IBSYS =1, it is not. This bit IBSYS is, for example, set by writing IBRH i.e., bit locations 0 to 5 in register 403 in order to indicate that a transfer between the non-addressable memory 401 and the memory RAM 300 is underway. IBSYS is re-set upon completion of this data transfer to the message RAM 300.
While data transfer from the non-addressable memory 401 is taking place, the host-CPU 102 can write the next message to be transferred in the input buffer memory and/or in the partial buffer memory 400. The identifier can be further refined with the help of another access identifier IBSYH (input buffer busy host) for example, in bit location 15 of register 403. If the host-CPU 102 is writing IBRH, i.e., the bit locations 0 to 5 of register 403 while a transfer between the non-addressable memory 401 and the memory RAM is taking place i.e., IBSYS = 1, then IBSYH is set in the input buffer command request register 403. As soon as the current transfer is concluded, the requested transfer (request through STXRH; refer above) is started and the IBSYH bit is re-set. The IBSYS bit remains set during the entire time in order to indicate that data is being

transferred to the message RAM. All utilized bits of all exemplary embodiments can, thereby, also be designed as identifiers with more than one bit. Of advantage is the one-bit solution on grounds of storage and processing economy.
The mechanism thus described permits the host-CPU 101 to continuously transfer data to the message object located in the message RAM and comprising a header segment HB and data segment DB, provided that the access speed of the host-CPU 102 to the input buffer memory is less than or equal to the internal data transfer rate of the FlexRay-IP-module i.e., of the communication module 100.
In Figures 7, 8 and 9, read access to the message RAM 300 by the host-CPU or user-CPU 102 through the despatch buffer memory or output buffer memory 202 is now described in greater detail. For this purpose, Figure 7 presents the communication module 100 once again, whereby here too only the relevant parts of the communication module 100 are shown for reasons of clarity. This is, for one, the message handler 200 responsible for process flow control as well as two control registers 703 and 704 which, as illustrated, can be housed outside the message handler 200 in the communication module 100 or can even be contained in the message handler 200 itself. 703, thereby, represents the output buffer command request register and 704 the output buffer command mask register. Read-access by host-CPU 102 to the message RAM 300 thus takes place through the interconnected output buffer 202. This output buffer 202 is now also designed to be partitioned and/or doubled, namely as a partial buffer memory 701 and a non-addressable memory 700, allocated to the partial buffer memory. Thus, as described below, continuous access by the host-CPU 102 to messages and/or message objects, respective data of the message RAM 300 takes place and data integrity and faster transmission in the opposite direction, now from the message RAM to the host, are therewith ensured. Access control

takes place through the output buffer command request register 703 and through the input buffer command mask register 704. The respective bit locations in 703 are also represented in register 703 with numbers of 0 to 31 here, for example, for a breadth of 32 bits. The same applies to register 704 and bit locations 0 to 31 in 704.
In accordance with the invention, bit locations 0 to 5, 8 and 9, 15 and 16 to 21 of register 703, for example, now receive a special function with regard to process flow control of the read access. Identifier OBRS (output buffer request shadow) can thus be entered in bit locations 0 to 5 of register 703. Similarly, identifier OBRH (output buffer request host) can be entered in bit locations 16 to 21 of register 703. An identifier OBSYS (output buffer busy shadow) can be entered as access identifier in bit location 15 of register 703. Locations 0 and 1 of the output buffer command mask register 704 are also perfect, whereby other identifiers are entered as data identifiers in bit locations 0 and 1 with RDSS (read data section shadow) and RHSS (read header section shadow). Other data identifiers are, for example, provided in bit locations 16 and 17 with RDSH (read data section host) and RHSH (read header section host). Here too these data identifiers are designed in the simplest form viz., designed as one bit in each case. A start identifier REQ is entered in bit location 9 of register 703. Furthermore a switching identifier VIEW is provided that is, for example, entered in bit location 8 of register 703.
The host-CPU 102 requests for data of a message object from the message RAM 300 by writing the identifier of the required message i.e., particularly the number of the required message object, according to OBRS i.e., in bit locations 0 to 5 of register 703. The host-CPU can, as in the opposite direction, hereby also either read only the status and configuration data respectively and header data KD of a message i.e., from a header segment or only the actual data D of a message to be transferred i.e., from the data segment, or read both. Which part

of the data i.e., from the header segment and/or data segment, is to be transferred is hereby determined by RHSS and RDSS, comparable to the opposite direction. This means that RHSS indicates whether the header data is to be read and RDSS indicates whether the actual data is to be read.
A start identifier serves to start the transfer from the memory RAM to the non-addressable memory 700. This means that if, as in the simplest case, one bit is used as an identifier, transfer from the message RAM 300 to the non-addressable memory 700 is started by setting bit REQ in bit location 9 in the output buffer command request register 703. The current transfer is again indicated by an access identifier, here again in the simplest case by a bit OBSYS in register 703. In order to avoid collisions, it is of advantage if bit REQ is only set when OBSYS is not set, i.e., when no transfer is currently taking place. Message transfer between the message RAM 300 and the non-addressable memory 700 then takes place here too. The actual process flow could now be controlled and take place on the one hand comparable to the opposite direction as described below in Figures 4, 5, and 6 (complementary register allocation) or, however, be re-set in a variation by an additional identifier viz., a switching identifier VIEW in bit location 8 of register 703. This means bit OBSYS is re-set after conclusion of the transfer and by setting the bit VIEW in the output buffer command request register 703, the partial memory 701 and the associated non-addressable memory 700 get interchanged and/or the access to the same gets interchanged and host-CPU 102 can now read the message object requested for from the message RAM i.e., the corresponding message from the partial buffer memory 701. Thereby, here too, register cells OBRS and OBRH can be interchanged comparable with the opposite transfer direction in Figures 4 to 6. Similarly RHSS and RDSS are interchanged for RHSH and RDSH. A provision can be made here too as a protective mechanism that bit VIEW is only set when OBSYS is not set i.e., when no transfer is currently taking place.

Read access by host-CPU 102 to the message RAM 300 thus take place through an interconnected output buffer memory 202. Like the input buffer memory, this output buffer memory too is designed doubled and/or with two parts in order to ensure continuous access by host-CPU 102 to the message objects that are stored in the message RAM 300. Here too the advantage of high data integrity and accelerated transfer is achieved.
Utilising the described input and output buffers ensures that a host-CPU can uninterruptedly access the message RAM despite the internal module latency time.
In order to safeguard this data integrity, the data transfer, particularly forwarding in the communication module 100, is undertaken by the message handler 200 (MHD). The message handler 200 is illustrated in Figure 10 for this purpose. The message handler can be represented in its functionality by several finite state machines or finite state automats i.e., finite automats, so-called finite state machines (FSM). Thereby at least three finite state machines and in a special design, four finite state machines, are provided. A first finite state machine is the IOBF-FSM and is indicated with 501 (input/out buffer state machine). This IOBF-FSM could also be partitioned into two finite state machines IBF-FSM (input buffer FSM) and OBF-FSM (output buffer FSM) per transfer direction with regard to the input buffer memory and to the output buffer memory, with which a maximum of five finite state machines (IBF-FSM, OBF-FSM, TBF1-FSM, TBF2-FSM, AFSM) would be conceivable. Provision of a common IOBF-FSM is, however, preferable. An at least second finite state machine is partitioned here into two blocks 502 and 503 in the course of the preferred exemplary embodiment and serves the two channels A and B with regard to memory 205 and 206, as per the description for Figure 2. A finite state machine can thereby be provided in order to serve both channels A and B or even, as in the preferred design, one finite state machine TBF1-FSM designated 502 (transient buffer (206

RAM A) state machine) for channel A and a TBF2-FSM designated 503 (transient buffer 2 (205, RAM B) state machine) for channel B.
An arbiter finite state machine, the so-called AFSM that is designated 500, serves to control access by the three finite state machines 501 - 503 in a preferred exemplary embodiment. Date (KD and/or D) are transferred in a clock pulse generated by a clock pulse agent such as e.g., a VCO (voltage controlled oscillator), an oscillator quartz etc or a clock pulse adapted from this in the communication module. The clock pulse T can thereby be generated in the module or externally e.g., be provided as a bus clock pulse. This arbiter finite state machine AFSM 500 alternately allows access to the message RAM to one of the three finite state machines 501 - 503 respectively, particularly for a clock pulse period T i.e., time available is divided amongst these calling finite state automats corresponding to the access requirements of individual finite state automats 501, 502, 503. If an access request takes place from only one finite state machine then this one will receive 100% of the access time i.e., all clock pulses T. Should access request take place from two finite state machines then each finite state machine will receive 50% of the access time. In conclusion, should an access request take place from all three finite state automats then each of the finite state machines will receive 1/3 of the access time. Band breadth respectively available is thus optimally used.
The first finite state machine designated 501 i.e., IOBF-FSM, executes the following actions, if required:
Data transfer from input buffer memory 201 to selected message object in message RAM 300.
Data transfer from selected message object in message RAM 300 to output buffer memory 202.

The finite state machine for channel A 502 i.e., TBF1-FSM executes the following actions:
Data transfer from selected message object in message RAM 300 to
buffer memory 206 of channel A.
Data transfer from buffer memory 206 to selected message object in
message RAM 300.
Search for matching message object in message RAM, whereby a
search is made in the context of acceptance filtering when receiving
the message object (receive buffer) for storing a message received on
channel A and when transmitting the next message object to be
transmitted on channel A (transmit buffer).
Analogous to this is the action by TBF2-FSM i.e., of the finite state machine for channel B in block 503. This executes data transfer from a selected message object in the message RAM 300 to the buffer memory 205 of channel B and data transfer from buffer memory 205 to the selected message object in message RAM 300. The search function too is, analogous to TBF1-FSM, for a matching message object in the message RAM, whereby a search is made in the context of acceptance filtering when receiving the message object (receive buffer) for storing a message received on channel B and when transmitting the next message or message object to be transmitted on channel B (transmit buffer).
Process flows and the transfer paths are illustrated once again in Figure 11. The three finite state machines 501 - 503 control the respective data transfers between the individual parts. 102 thereby again represents the host-CPU, 201 the input buffer memory and 202 the output buffer memory. Message RAM is represented by 300 and the two buffer memories for channels A and B by 206 and 205. The interface elements 207 and 208 are

also illustrated. The first finite state automat IOBF-FSM designated 501, controls the data transfer Z1A and Z1B i.e., from the input buffer memory 201 to the message RAM 300 and from the message RAM 300 to the output buffer memory 202. Data transfer thus takes place through the data bus with a word breadth of, for example, 32 bits whereby any other bit number is also possible. The same applies to the transfer Z2 between the memory RAM and the buffer memory 206. This data transfer is controlled by TBF1-FSM i.e. 502, the finite state machine for channel A. Transfer Z3 between message RAM 300 and buffer memory 205 is controlled by finite state automat TBF2-FSM i.e., 503. Here too, data transfer takes place through the data bus with, for example, a word breadth of 32 bits, whereby here too, any other bit number is possible. The transfer of a complete message object through the transfer paths mentioned normally requires several clock pulse periods T. A division of the transfer time relating to the clock pulse periods T thus takes place through an arbiter i.e., the AFSM 500. The data paths in Figure 11 between these are thus represented by memory components monitored by the message handler. In order to ensure data integrity of the message object stored in the message RAM, data should be simultaneously exchanged only on one of the paths illustrated i.e. Z1A and Z1B as well as Z2 and Z3 advantageously at the same time.
An example in Figure 12 illustrates how the available system clock pulse T can be divided by the arbiter, i.e., the AFSM 500 amongst three requesting finite state automats. In Phase 1 access requests take place from the finite state automat 501 and the finite state automat 502 i.e. the entire time is divided in each case by half between the two requesting finite state automats. Relating to the clock pulse periods in Phase 1, this signifies that the finite state automat 501 has access in clock pulse periods T1 and T3 and finite state automat 502 in clock pulse periods T2 and T4. In Phase 2 access takes place only through the finite state machine 501 so that all three clock pulse

periods i.e. 100% of the access time from T5 to T7 is allotted to IOBF-FSM. Access requests of all three finite state automats 501 to 503 take place in Phase 3 so that a three-way division of the entire access time takes place. The arbiter AFSM then divides the access time, for example, in such a manner that the finite state machine 501 has access in the clock pulse periods T8 and T11, the finite state machine 502 has access in the clock pulse periods T9 and T12, and finite state machine 503 has access in clock pulse periods T10 and T13. Access in Phase 4 finally takes place through two finite state automats 502 and 503 on both channels A and B of the communication module so that access division takes place of clock pulse periods T14 and T16 to finite state machine 502 and of T15 and T17 to finite state machine 503.
The arbiter finite state automat AFSM 500 thus ensures that in a case when more than one of the three finite state machines makes an access request to the message RAM 300, access is divided clock pulse-wise and alternating between the requesting finite state machines. This course of action ensures the integrity of the message objects stored in the message RAM i.e., the data integrity. If, for example, the host-CPU 102 wants to read a message object through the output buffer memory 202 while a received message is being written in this message object, then either the old status or the new status is read out subject to which request was started first, without both accesses to the message object in the message RAM themselves colliding.
The process described enables the host-CPU to read or to write any message object in message RAM during running operation without the selected message object having to be locked (buffer locking) for the duration of the host-CPU access by the user at data exchange on both channels of the FlexRay bus. The integrity of data stored in the message RAM is thus
Claims
1. FlexRay communication module (100) with which to couple a
FlexRay communication interface (101) to a user (102) assigned to
the FlexRay communication module in a FlexRay network through
which messages are transmitted, characterised in that, the FlexRay
communication module (100) contains the following components:
a first configuration (105) for storing at least one part of the
transmitted messages and
a second configuration (104) for connecting the first
configuration (105) to the user (102) as well as
a third configuration (103) for connecting the FlexRay
communication interface (101) to the first configuration
(105).
2. FlexRay communication module (100) according to Claim 1,
characterised in that, the first configuration (105) contains a
message handler (200) and a message RAM (300).
3. FlexRay communication module (100) according to Claim 1,
characterised in that, the first configuration (105) contains a
message RAM (300), whereby the message RAM is partitioned into
a header segment (HS) and a data segment (DS).
4. FlexRay communication module (100) according to Claim 1,
characterised in that, the second configuration (104) contains an
input buffer memory (201) and an output buffer memory (202).
5. FlexRay communication module (100) according to Claim 4,
characterised in that, the input buffer memory (202) is partitioned

into a partial buffer memory (701) and a non-addressable memory (700), whereby access to the partial buffer memory and the non-addressable memory can be interchanged.
6. FlexRay communication module (100) according to Claim 4,
characterised in that, the input buffer memory (201) is partitioned
into a partial buffer memory (400) and a non-addressable memory
(401) whose contents can be interchanged.
7. FlexRay communication module (100) according to Claim 4,
characterised in that, the output buffer memory (202) is partitioned
into a partial buffer memory (701) and a non-addressable memory
(700), whereby access to the partial buffer memory and the non-
addressable memory is interchanged.
8. FlexRay communication module (100) according to Claim 4,
characterised in that, the output buffer memory (202) is partitioned
into a partial buffer memory (701) and a non-addressable memory
(700) whose contents can be interchanged.
9. FlexRay communication module (100) according to one of Claims 5
to 8, characterised in that, each input buffer memory (400, 401) and
each output buffer memory (700, 701) is designed in such a
manner that a data segment and a header segment of two FlexRay
messages can be stored.
10. FlexRay communication module (100) according to Claim 1,
characterised in that, the second configuration (104) contains an
interface module which comprises a user-specific partial module
(204) and a user-independent partial module (203).

11. FlexRay communication module (100) according to Claim 1,
characterised in that, the third configuration (103) is partitioned into
a first interface module (207) and a second interface module (208)
and into two data paths with two data directions respectively.
12. FlexRay communication module (100) according to Claim 1,
characterised in that, the third configuration (103) contains a first
buffer memory (206) and a second buffer memory (205) and is
divided into two data paths with two data directions respectively.
13. FlexRay communication module (100) according to Claim 12,
characterised in that, each of the two buffer memories (205, 206) is
designed in such a manner that a data segment of two FlexRay
messages can be stored.
14. FlexRay communication module (100) according to Claim 11,
characterised in that, each of the interface modules (207, 208)
contains a shift register and a FlexRay protocol finite state
machine.
Dated this 5 day of February 2007

Documents:

512-abstract image.jpg

512-CHENP-2007 FORM-1 13-11-2013.pdf

512-CHENP-2007 OTHER PATENT DOCUMENT 13-11-2013.pdf

512-CHENP-2007 OTHERS 13-11-2013.pdf

512-CHENP-2007 POWER OF ATTORNEY 13-11-2013.pdf

512-CHENP-2007 AMENDED CLAIMS 13-11-2013.pdf

512-CHENP-2007 AMENDED PAGES OF SPECIFICATION 13-11-2013.pdf

512-CHENP-2007 EXAMINATION REPORT REPLY RECEIVED 13-11-2013.pdf

512-CHENP-2007 FORM-3 13-11-2013.pdf

512-CHENP-2007 CORRESPONDENCE OTHERS 28-05-2013.pdf

512-chenp-2007-abstract.pdf

512-chenp-2007-claims.pdf

512-chenp-2007-correspondnece-others.pdf

512-chenp-2007-description(complete).pdf

512-chenp-2007-drawings.pdf

512-chenp-2007-form 1.pdf

512-chenp-2007-form 3.pdf

512-chenp-2007-form 5.pdf

512-chenp-2007-pct.pdf

« Previous Patent

Next Patent »

Patent Number

257996

Indian Patent Application Number

512/CHENP/2007

PG Journal Number

48/2013

Publication Date

29-Nov-2013

Grant Date

26-Nov-2013

Date of Filing

05-Feb-2007

Name of Patentee

ROBERT BOSCH GmbH

Applicant Address

POSTFACH 30 02 20, D-70442 STUTTGART,

Inventors:

#	Inventor's Name	Inventor's Address
1	HORTWICH, FLORIAN	LERCHENSTRASSE 17/1, 72762 REUTLINGEN,
2	HORST, CHRISTIAN	ROBERT-WOERNER-STRASSE 28/3, 72144 DUSSLINGEN, GERMANY
3	BAILER, FRANZ	ZIEGELHUETTESTRASSE 84, 72770 REUTLINGEN, GERMANY

PCT International Classification Number

H04L 12/40

PCT International Application Number

PCT/EP05/53083

PCT International Filing date

2005-06-29

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	102004038212.3	2004-08-05	Germany