Title of Invention	MESSAGE ADMINISTRATOR AND METHOD FOR CONTROLLING ACCESS OF DATA OF THE MESSAGE MEMORY OF A COMMUNICATION MUDULE
Abstract	Process for control of access to data of a message RAM and message handler (200) of a communication module (100) with a message RAM (300) in which data input or output takes place during access, whereby the message RAM (300) is connected to a first buffer memory configuration (205, 206) and to a second buffer memory configuration (201, 202) and data access takes place via the first or the second buffer memory configuration, whereby at least one first finite state machine (502, 503) is provided in the message handler (200), which controls access to the message RAM through the first buffer memory configuration (205, 206) and at least one second finite state machine (501) is provided which controls access through the second buffer memory configuration (201, 202), whereby the at least one first finite state machine and the second finite state machine make access requests and a third finite state machine is provided which assigns access to the message RAM to at least one first and to the second finite state machine, subject to their access requests. (Figure 10)

Title of Invention

MESSAGE ADMINISTRATOR AND METHOD FOR CONTROLLING ACCESS OF DATA OF THE MESSAGE MEMORY OF A COMMUNICATION MUDULE

Abstract

Process for control of access to data of a message RAM and message handler (200) of a communication module (100) with a message RAM (300) in which data input or output takes place during access, whereby the message RAM (300) is connected to a first buffer memory configuration (205, 206) and to a second buffer memory configuration (201, 202) and data access takes place via the first or the second buffer memory configuration, whereby at least one first finite state machine (502, 503) is provided in the message handler (200), which controls access to the message RAM through the first buffer memory configuration (205, 206) and at least one second finite state machine (501) is provided which controls access through the second buffer memory configuration (201, 202), whereby the at least one first finite state machine and the second finite state machine make access requests and a third finite state machine is provided which assigns access to the message RAM to at least one first and to the second finite state machine, subject to their access requests. (Figure 10)

Full Text	MESSAGE HANDLER AND PROCESS FOR CONTROL OF ACCESS TO DATA PERTAINING TO A MESSAGE RAM OF A COMMUNICATION MODULE The invention emanates from a message handler and a process with which to control access to data pertaining to a message RAM of a communication module in accordance with the preamble of independent claims. Networking of control units, sensors and actuators with the help of a communication system and of a bus system i.e., with a communications interface, has increased dramatically in recent years in the construction of modern 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 of distributed systems. Communication between different stations thus increasingly takes place through a bus system i.e., a communications system. Communication transactions on the bus systems, accessing and receiving mechanisms as well as error management are regulated by a protocol. A protocol established for this purpose is the CAN protocol or also the TTCAN protocol as well as the FlexRay protocol, whereby, the FlexRay protocol specification v2.0 forms the basis at present. FlexRay is thus a quick, deterministic and error-tolerant bus system, especially for use in a motor vehicle. The FlexRay protocol works according to the process of Time Division Multiple Access (TDMA), whereby the components i.e., users and/or the messages to be transmitted are allocated fixed time slots in which they have exclusive access to the communications interface. Comparably, this can also be implemented in TTCAN. 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 if it is actually required. FlexRay thereby communicates through two physically separated cables with a data rate of a maximum of 10 MB each per second. 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, require a common time basis, a so-called global time. Synchronisation communication in the static part of the cycle is transmitted for clock synchronisation, whereby the local time of a component is corrected in such a manner with the help of a specific algorithm corresponding to the FlexRay specification that all local clocks run synchronous to a global clock. This synchronisation takes place comparably even in a TTCAN network. 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. A communication module, particularly a communications controller, is employed in order to now transmit these messages and message objects respectively between the physical layer i.e., the communication interface and the host processor. The objective of the invention now is to control data transmission in such a manner that data integrity is ensured and transmission speed is optimised. Advantages of the Invention The invention emanates from a message handler of a communication module with a message RAM in which data input or output takes place during access and from a process with which to control access to data of the message RAM. The message RAM is thereby connected to a first buffer memory configuration and to a second buffer memory configuration, whereby data access takes place via the first or second buffer memory configuration, whereby the message handler advantageously contains at least one first finite state machine which controls access to the message RAM via the first buffer memory configuration and the message handler contains at least one second finite state machine which controls access via the second buffer memory configuration, whereby the at least one first finite state machine and the at least one second finite state machine execute access requests and a third finite state machine is provided which allocates access to the message RAM to the at least one first and second finite state machines, subject to their access requests. This means the invention describes control of a process and a device for data transfer between a message RAM and input and output buffers as well as between message RAM and send and receive units to the communication bus in such a manner that the required data integrity and high transmission speed of messages to be stored is ensured. Data is appropriately controlled by the message administrator and is transmitted through the first buffer memory configuration in two data paths with two data directions respectively, whereby the first buffer memory configuration contains a first buffer memory for a first data path and a second buffer memory for a second data path and the data paths are each provided a first finite state machine so that two finite state machines result for the first buffer memory configuration, whereby each of the two first finite state machines controls access to the message RAM via a buffer memory each. Clock pulse agents are appropriately provided through which data is transmitted in a pre-determined clock pulse period, whereby the third finite state machine allocates clock pulse periods in succession to each first finite state machine and each second finite state machine, subject to their access requests. It is of advantage that the entire access time is apportioned equally by the third finite machine, subject to the number of simultaneous access requests and corresponding to the number, whereby always only one access demand is concurrently permitted per finite state machine amongst which the clock pulse periods are divided. The process and the message handler described as well as a corresponding communication module with this type of a message handler enables the host CPU to read or to write any message objects i.e., any message in the message RAM, during ongoing operation without the selected message object having to be locked for the duration of the host-CPU access by the user at data exchange on both channels of the FlexRay bus i.e., of the data exchange at the physical layer. Integrity of data stored in the message RAM is simultaneously ensured through clock pulse-wise interlocking of access. Other advantages and beneficial designs emerge from the description as well as from the features of the claims. Drawing The invention is described in greater detail by means of 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 4 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 exemplary embodiments. Exemplary Embodiments Figure 1 schematically illustrates 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 one 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 i.e. payioad 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 contains 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 indicated by 209 in the communication module 100, is responsible for representing the global time period in FlexRay i.e., the micro tick µT 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 of FlexRay 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 handier (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 minimized on the one hand without having to reduce the size of the data segment of messages and on the other hand, an optimal utilization of the memory takes place. This variable partitioning of a message RAM, particularly a RAM-based message memory, for a FlexRay communication controller is described now 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 m 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 DP0, 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 message 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 message RAM can be used as an add-on for the data segment DS for storing of data. This variability ensures an optimal storage utilization 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. A data pointer could in fact, even be dispensed with, if need be. 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 therewith the advantages when compared to a pre-determined partitioning of the message 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. Available storage space is optimally utilized 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 message RAM can be customized 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 now 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 message RAM 300 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 message RAM 300 to the two partial memories 400 and 401 is interchanged, as indicated by the semi-circular arrow. Data transfer i.e., data transmission to the message RAM 300 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 =0, 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 message 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 message 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 as message identifier 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 message 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. Utilizing 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. Data (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 message 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 simultaneously ensured by the clock pulse-wise interlocking of access and the transfer speed is also increased by utilizing the full band breadth. Claims 1. Message handler (200) of a communication module (100) with a message RAM (300) in the case of which data input or output takes place during access, whereby the message RAM (300) is connected to a first buffer memory configuration (205, 205) and to a second buffer memory configuration (201, 202) and access to data takes place through the first or the second buffer memory configurations, characterised in that, - at least one first finite state machine (502, 503) is provided in the message handler (200) which controls access to the message RAM through the first buffer memory configuration (205, 206) and at least - one second finite state machine (501) is provided in the message handler (200) which controls access through the second buffer memory configuration (201, 202), whereby the at least one first finite state machine and the second finite state machine make access requests and a third finite state machine is provided in the message handler (200) that assigns access to the message RAM to the at least one first and second finite state machine, subject to their access requests. 2. Message handler (200) according to Claim 1, characterised in that, data is transferred through the first buffer memory configuration (205, 206) in two data paths with two data directions respectively and the first buffer memory configuration (205, 206) contains a first buffer memory (206) for a first data path and a second buffer memory (205) for a second data path and one first finite state machine (502, 503) is provided for each data path, whereby each of the two first finite state machines controls access to the message RAM through a buffer memory each. 3. Message handler (200) according to Claim 1 or 2, characterised in that, clock pulse agents are provided through which data is transmitted in a predetermined clock pulse period (T) and the third finite state machine (500) assigns clock pulse periods (T1 - T17) to each first finite state machine (502, 503) and each second finite state machine (501), subject to their access requests. 4. Message handler (200) according to Claim 1 or 2, characterised in that, an entire access time is apportioned equally by the third finite machine (500), subject to the number of simultaneous access requests and corresponding to the number, whereby always only one access demand is concurrently permitted per finite state machine. 5. Communication module with a message handler according to Claim 1. 6. Process for control of data access of a message RAM (300) of a communication module by a message handler (200), whereby data input or output takes place during access, whereby the message RAM is connected to a first buffer memory configuration and to a second buffer memory configuration and access to data takes place through the first or the second buffer memory configuration, characterised in that, at least one first finite state machine is provided in the message handler which controls access to the message RAM through the first buffer memory configuration as a first access path and - a second finite state machine is provided in the message handier which controls access through the second buffer memory configuration as a second access path, whereby data can be accessed only on one of the access paths at the same time. 7. Process according to Claim 6, characterised in that, data is transmitted via the first buffer memory configuration in two data paths with two data directions respectively and the first buffer memory configuration contains a first buffer memory for a first data path and the second buffer memory for a second data path and each data path is provided with a first finite state machine respectively, whereby each of the two first finite state machines controls access to the message RAM through a buffer memory each whereby a third access path emerges and here too data can be simultaneously accessed only on one of the access paths. Dated this 5 day of February 2007

Full Text

MESSAGE HANDLER AND PROCESS FOR CONTROL OF ACCESS TO DATA PERTAINING TO A MESSAGE RAM OF A COMMUNICATION MODULE
The invention emanates from a message handler and a process with which to control access to data pertaining to a message RAM of a communication module in accordance with the preamble of independent claims.
Networking of control units, sensors and actuators with the help of a communication system and of a bus system i.e., with a communications interface, has increased dramatically in recent years in the construction of modern 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 of distributed systems. Communication between different stations thus increasingly takes place through a bus system i.e., a communications system. Communication transactions on the bus systems, accessing and receiving mechanisms as well as error management are regulated by a protocol. A protocol established for this purpose is the CAN protocol or also the TTCAN protocol as well as the FlexRay protocol, whereby, the FlexRay protocol specification v2.0 forms the basis at present. FlexRay is thus a quick, deterministic and error-tolerant bus system, especially for use in a motor vehicle. The FlexRay protocol works according to the process of Time Division Multiple Access (TDMA), whereby the components i.e., users and/or the messages to be transmitted are allocated fixed time slots in which they have exclusive access to the communications interface. Comparably, this can also be implemented in TTCAN. 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 if it is actually required. FlexRay thereby communicates through two physically separated cables with a data rate of a maximum of 10 MB each per second. 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, require a common time basis, a so-called global time. Synchronisation communication in the static part of the cycle is transmitted for clock synchronisation, whereby the local time of a component is corrected in such a manner with the help of a specific algorithm corresponding to the FlexRay specification that all local clocks run synchronous to a global clock. This synchronisation takes place comparably even in a TTCAN network.
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. A communication module, particularly a communications controller, is employed in order to now transmit these messages and message objects

respectively between the physical layer i.e., the communication interface and the host processor.
The objective of the invention now is to control data transmission in such a manner that data integrity is ensured and transmission speed is optimised.
Advantages of the Invention
The invention emanates from a message handler of a communication module with a message RAM in which data input or output takes place during access and from a process with which to control access to data of the message RAM. The message RAM is thereby connected to a first buffer memory configuration and to a second buffer memory configuration, whereby data access takes place via the first or second buffer memory configuration, whereby the message handler advantageously contains at least one first finite state machine which controls access to the message RAM via the first buffer memory configuration and the message handler contains at least one second finite state machine which controls access via the second buffer memory configuration, whereby the at least one first finite state machine and the at least one second finite state machine execute access requests and a third finite state machine is provided which allocates access to the message RAM to the at least one first and second finite state machines, subject to their access requests.
This means the invention describes control of a process and a device for data transfer between a message RAM and input and output buffers as well as between message RAM and send and receive units to the communication bus in such a manner that the required data integrity and high transmission speed of messages to be stored is ensured.

Data is appropriately controlled by the message administrator and is transmitted through the first buffer memory configuration in two data paths with two data directions respectively, whereby the first buffer memory configuration contains a first buffer memory for a first data path and a second buffer memory for a second data path and the data paths are each provided a first finite state machine so that two finite state machines result for the first buffer memory configuration, whereby each of the two first finite state machines controls access to the message RAM via a buffer memory each.
Clock pulse agents are appropriately provided through which data is transmitted in a pre-determined clock pulse period, whereby the third finite state machine allocates clock pulse periods in succession to each first finite state machine and each second finite state machine, subject to their access requests.
It is of advantage that the entire access time is apportioned equally by the third finite machine, subject to the number of simultaneous access requests and corresponding to the number, whereby always only one access demand is concurrently permitted per finite state machine amongst which the clock pulse periods are divided.
The process and the message handler described as well as a corresponding communication module with this type of a message handler enables the host CPU to read or to write any message objects i.e., any message in the message RAM, during ongoing operation without the selected message object having to be locked for the duration of the host-CPU access by the user at data exchange on both channels of the FlexRay bus i.e., of the data exchange at the physical layer. Integrity of data stored in the message RAM is simultaneously ensured through clock pulse-wise interlocking of access.

Other advantages and beneficial designs emerge from the description as well as from the features of the claims.
Drawing
The invention is described in greater detail by means of 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 4 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 exemplary embodiments.
Exemplary Embodiments
Figure 1 schematically illustrates 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 one 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 i.e. payioad 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 contains 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 indicated by 209 in the communication module 100, is responsible for representing the global time period in FlexRay i.e., the micro tick µT 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 of FlexRay 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 handier (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 minimized on the one hand without having to reduce the size of the data segment of messages and on the other hand, an optimal utilization of the memory takes place. This variable partitioning of a message RAM, particularly a RAM-based message memory, for a FlexRay communication controller is described now 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 m 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 DP0, 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 message 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 message RAM can be used as an add-on for the data segment DS for storing of data. This variability ensures an optimal storage utilization 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. A data pointer could in fact, even be dispensed with, if need be.

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 therewith the advantages when compared to a pre-determined partitioning of the message 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. Available storage space is optimally utilized 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 message RAM can be customized 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 now 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 message RAM 300 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 message
RAM 300 to the two partial memories 400 and 401 is interchanged, as indicated
by the semi-circular arrow. Data transfer i.e., data transmission to the message
RAM 300 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 =0, 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 message 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 message 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 as message identifier 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 message 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.
Utilizing 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. Data (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 message 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 simultaneously ensured by the clock pulse-wise interlocking of access and the transfer speed is also increased by utilizing the full band breadth.
Claims
1. Message handler (200) of a communication module (100) with a
message RAM (300) in the case of which data input or output takes
place during access, whereby the message RAM (300) is connected to
a first buffer memory configuration (205, 205) and to a second buffer
memory configuration (201, 202) and access to data takes place
through the first or the second buffer memory configurations,
characterised in that,
- at least one first finite state machine (502, 503) is provided in the
message handler (200) which controls access to the message
RAM through the first buffer memory configuration (205, 206) and
at least
- one second finite state machine (501) is provided in the message
handler (200) which controls access through the second buffer
memory configuration (201, 202), whereby the at least one first
finite state machine and the second finite state machine make
access requests and
a third finite state machine is provided in the message handler (200) that assigns access to the message RAM to the at least one first and second finite state machine, subject to their access requests.
2. Message handler (200) according to Claim 1, characterised in that,
data is transferred through the first buffer memory configuration (205,
206) in two data paths with two data directions respectively and the
first buffer memory configuration (205, 206) contains a first buffer
memory (206) for a first data path and a second buffer memory (205)
for a second data path and one first finite state machine (502, 503) is

provided for each data path, whereby each of the two first finite state machines controls access to the message RAM through a buffer memory each.
3. Message handler (200) according to Claim 1 or 2, characterised in that, clock pulse agents are provided through which data is transmitted in a predetermined clock pulse period (T) and the third finite state machine (500) assigns clock pulse periods (T1 - T17) to each first finite state machine (502, 503) and each second finite state machine (501), subject to their access requests.
4. Message handler (200) according to Claim 1 or 2, characterised in that, an
entire access time is apportioned equally by the third finite machine (500),
subject to the number of simultaneous access requests and corresponding
to the number, whereby always only one access demand is concurrently
permitted per finite state machine.
5. Communication module with a message handler according to Claim 1.
6. Process for control of data access of a message RAM (300) of a
communication module by a message handler (200), whereby data input
or output takes place during access, whereby the message RAM is
connected to a first buffer memory configuration and to a second buffer
memory configuration and access to data takes place through the first or
the second buffer memory configuration, characterised in that,
at least one first finite state machine is provided in the message handler which controls access to the message RAM through the first buffer memory configuration as a first access path and

- a second finite state machine is provided in the message handier which controls access through the second buffer memory configuration as a second access path, whereby data can be accessed only on one of the access paths at the same time.
7. Process according to Claim 6, characterised in that, data is transmitted via the first buffer memory configuration in two data paths with two data directions respectively and the first buffer memory configuration contains a first buffer memory for a first data path and the second buffer memory for a second data path and each data path is provided with a first finite state machine respectively, whereby each of the two first finite state machines controls access to the message RAM through a buffer memory each whereby a third access path emerges and here too data can be simultaneously accessed only on one of the access paths.
Dated this 5 day of February 2007

Documents:

496-abstract image.jpg

496-CHENP-2007 CORRESPONDENCE OTHERS 26-07-2011.pdf

496-CHENP-2007 AMENDED PAGES OF SPECIFICATION 21-10-2011.pdf

496-CHENP-2007 AMENDED CLAIMS 21-10-2011.pdf

496-CHENP-2007 FORM-1 21-10-2011.pdf

496-CHENP-2007 FORM-3 21-10-2011.pdf

496-CHENP-2007 OTHER PATENT DOCUMENT 21-10-2011.pdf

496-CHENP-2007 POWER OF ATTORNEY 21-10-2011.pdf

496-CHENP-2007 EXAMINATION REPORT REPLY RECEIVED 21-10-2011.pdf

496-chenp-2007-abstract.pdf

496-chenp-2007-claims.pdf

496-chenp-2007-correspondnece-others.pdf

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

496-chenp-2007-drawings.pdf

496-chenp-2007-form 1.pdf

496-chenp-2007-form 3.pdf

496-chenp-2007-form 5.pdf

496-chenp-2007-pct.pdf

« Previous Patent

Next Patent »

Patent Number

252514

Indian Patent Application Number

496/CHENP/2007

PG Journal Number

21/2012

Publication Date

25-May-2012

Grant Date

21-May-2012

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	HARTWICH, 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
4	IHLE, MAQRKUS	REUTLINGER STRASSE 10, 72127 JETTENBURG, GERMANY

PCT International Classification Number

G06F 13/16

PCT International Application Number

PCT/EP05/53074

PCT International Filing date

2005-06-29

PCT Conventions:

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