Title of Invention

PROCESS FOR STORING OF MESSAGES IN A MESSAGE RAM AND FOR A MESSAGE RAM

Abstract Process for storing of messages and for a message RAM in a communication module (100) for the storing of a number of messages, whereby first data (KDO, KD1, KDk) is contained with a first data volume and second data (DO, D1, Dk) with a second data volume in the messages to be stored, whereby the second data volume per message can be different and the message RAM (300) contains a header segment (HS) in which the first data (KDO, KD1, KDk) of the message is stored in a header region (HBO, HB1, HBk) each per message and the message RAM (300) contains a data segment (DS) in which the second data (DO, D1, Dk) of the message is stored in a data region (DBO, DB1, DBk) each per message, whereby the message RAM (300) is designed in such a manner that partitioning between the header segment (HS) and the data segment (DS) is variable, subject to the number (k) of messages and to the second data volume. (Figure 3)
Full Text

PROCESS FOR STORING OF MESSAGES IN A MESSAGE RAM AND FOR A MESSAGE RAM
Prior Art
The invention is with regard to a process for storing a number of messages in a message memory in a communication module as well as with regard to a communication module in accordance with features of independent claims established in prior art.
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 of such distributed systems 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. The protocol established for this purpose is the CAN protocol (Controller Area Network) or also TTCAN protocol as well as the FlexRay protocol, whereby, the FlexRay protocol specification v2.0 forms the basis at present. This 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. 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 now is to provide a message RAM for a communication module of a bus system, which will support transmission of message in an optimal manner.
Advantages of the Invention
A process for storing of messages in such a message RAM as well as a corresponding message RAM for storing of send and receive messages, especially using RAM (random access memory) is presented for this purpose in accordance with the invention. The number of messages that can be stored is thus subject to the size of the data segment of the messages. The invention now permits storing of a pre-determined size of a variable number of messages in a memory, especially in a RAM while at the same time minimising and optimally utilising the size of the required RAM without having to reduce the size of the data segment of messages.
A process for storing of messages and a message RAM in a communication module for storing a number of message is revealed for this purpose, whereby first data with a first data volume, so-called header data (i.e. status and configuration data) and second data with a second data volume (actual data to be sent) are contained in the messages to be stored. The second data volume per message can thus, as mentioned, be different whereby the message RAM advantageously contains a header section in which the first data of the message is stored in one header section per message and the message RAM further contain a data section in which the second data of the message is stored in one

data segment per message and the message RAM is arranged in such a manner that a variable division is created between the header section and the data section, subject to the number of messages and to the second data volume. The division especially of the RAM i.e., the message RAM, between header section or header segment and data section or data segment, is thus variable so that the header section is smaller when fewer messages are configured and the resulting freed up space in the message RAM can be utilised to store actual data to be transmitted.
In an advantageous design a pointer i.e., a so-called data pointer is provided per message in each header segment for this purpose through which a data section is specified in the data segment in that the data pointer particularly indicates the start address of the respective data segment.
In another design, the first and second data of messages are advantageously stored in a predetermined sequence in the message RAM so that the sequence of the header sections in the header segment and the sequence of the data section in the data segment are respectively identical and the associated data section in the data segment thus emerges from the position of the respective header section of a message in the header segment. The message RAM is thereby advantageously designed as FIFO in order to continue transmission of the message in the sequence of arrival.
In order to use storage space in the message RAM optimally, first data of the message is stored in one header section per message and stored with a preĀ¬determined first number of words that are fixed for each header section and are identical. The data pointer can thereby also be stored in a fixed, pre-determined number of words so that the same number of words result on the whole for each header section of the header segment and the size of the header segment

emerges only through the number of stored or messages to be sent by using a constant number of words on the whole.
The message RAM is appropriately designed with a pre-determined fixed word size for this purpose. It is particularly advantageous to have a sequenced header section and the data section and of advantage when variable division takes place by relocating this section's boundary.
For the purpose of error detection it can be advantageously provided that each data section comprises at least a pre-determined word size and that a control code is provided per word size in the data section, especially a parity bit and that a parity bit generator element and a parity bit check element are allocated to the message RAM in order to create the control code, especially the parity bit, and therewith check the accuracy of the stored data.
In a preferred design the message RAM in accordance with the invention is inserted in a FlexRay communication module, which is, in turn, located in a user of the FlexRay network i.e., in a control unit or is directly allocated to the same.
Thus, in accordance with the invention, diverse advantages emerge as a result of the variable division of the message RAM. The user can thus decide during programming whether he would like to use a larger number of messages with a smaller data field or a smaller number of messages with a larger data field. Available memory is optimally utilised in the case of configuration of a message with data sections of different sizes. The user has the possibility of using a data region collectively for different messages. The size of the message RAM can be exactly aligned to the requirements of the application by aligning the memory depth of the memory used, especially RAM, during implementation of the communication controller i.e., of the communication module, in an integrated

circuit without changing the other functions of the communication controller or communication module.
Other advantages and beneficial designs emerge from the features of the claims as well as from the description.
Drawing
The invention is described in greater detail 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 ie.,
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 handler (MHD) 200, the global time unit (GTU) 209, the general system universal controller (SUC) 210, the network and error management unit (NEM) 211, the interrupt controller (INT) 212 as well as access to the message RAM 300 and, similarly, to indicate the corresponding status. At least parts of this register are explained in greater detail in Figures 4 to 6 and 7 to 9. This type of described FlexRay communication module, in accordance in with invention, enables a simple conversion of the FlexRay specification v2.0 through which an ASIC or a micro controller with corresponding FlexRay functionality can be simply generated.
Partitioning of the message RAM 300 is described in Figure 3. For the functionality of a FlexRay communication controller, required in accordance with FlexRay protocol specifications, a message RAM is required to make available messages to be transmitted (transmit buffer) as well as for the storing of error-free, received messages (receive buffer). A FlexRay protocol permits messages with a data segment i.e., a payload segment of 0 to 254 bytes. As illustrated in Figure 2, the message RAM is part of the FlexRay communication module 100. The process described below as well as the corresponding message RAM

describe the storing of messages to be transmitted as well as of received messages, particularly by using a random access memory (RAM), whereby the mechanism in accordance with the invention enables storing of a pre-determined size of a variable number of messages in the message RAM. The number of storable messages is thus subject to the size of the data segment of the individual messages through which the size of the memory required can be minimised on the one hand without having to reduce the size of the data segment of messages and on the other hand, an optimal utilisation of the memory takes place. This variable partitioning of a 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 DPO, DP1 to DPk respectively is now directly allocated to the configuration data KDO, KD1 to KDk of the respective message. A fixed number of words, here two, is allocated to each header segment HBO, HB1 to HBk in a special design so that a configuration date KD (KDO, KD1, ..., KDk) and a data pointer DP (DPO, DP1, .:, DPk) are always stored together in a header segment HB. Data segment DS for storing the actual message data DO, D1 to Dk attaches itself to this header segment HS with the header segments HB whose size and/or first data volume is subject to the number k of the messages to be stored. With regard to its data volume, this data segment (or data section) is subject to respective data volumes of message data stored, here, e.g., six words in DBO, one word in DB1 and two words in DBk. The respective data pointers DPO, DP1 to DPk thus always point to the beginning i.e., to the start address of the respective data segment DBO, DB1 to DBk in which data DO, D1 to Dk of the respective messages 0, 1 to k are stored. Partitioning of the 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 utilisation whereby using smaller memories is also possible. The free data segment FDS, especially its size, likewise subject to the combination of the number k of stored messages and the respective second data volume of messages, is thus minimal and can even become 0.
Apart from using data pointers, it is also possible to store the first and second data, i.e., the configuration data KD (KDO, KD1, .., KDk) and the actual data D (D

=, D1, ..., Dk) in a default sequence so that the sequence of the header segments HBO to HBk in the header segment HS and the sequence of data segments DBO to DBk in data segment DS are respectively identical. 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 utilised when configuring messages that have a data segment of varying sizes. The user has the possibility of using a data storage segment collectively for different messages.
While implementing the communication controller at an integrated circuit, the size of the message RAM can be customised to the requirements of the application by aligning the memory depth of the used storage without modifying the other functions of the communication controller.
Furthermore, host-CPU access i.e., writing and reading of configuration data and/or status data and of actual data, through buffer memory configuration 201 and 202 is described in greater detail using Figures 4 to 6 as well as 7 to 9. The

objective thereby is to create a coupling with regard to data transmission in such a manner that data integrity can be ensured and high transmission speed can be simultaneously guaranteed. Control of these procedures takes place through the message handler 200 which is described later in greater detail in Figures 10, 11 and 12.
Write-access to message RAM 300 by the host-CPU of user-CPU 102 through the input buffer memory 201 is first described in greater detail in Figures 4, 5, and 6. In this connection, Figure 4 illustrates the communication module 100 once again, whereby only those parts of the communication module 100 that are relevant here are shown for reasons of clarity. This, for one, is the message handler 200, responsible for controlling process flows as well as two control registers 403 and 404 which, as illustrated, can be located outside the message handler 200 in the communication module 100 or can also be contained in the message handler 200 itself. 403 thereby represents the input buffer command request register and 404 the input buffer command mask register. Write access of host-CPU 102 to the message RAM 300 thus take place through an interconnected input buffer 201 This input buffer 201 is now designed to be partitioned and/or doubled, namely as a partial buffer memory 400 and a non-addressable memory 401 allocated to the partial buffer memory. Thus, as described below, continuous access takes place by the host-CPU 102 to messages and/or message objects, respective data of the message RAM 300 therewith ensuring data integrity and faster transmission. Access control takes place through the input buffer command request register 403 and through the input buffer command mask register 404. The respective bit locations in 403 are presented here, for example, for a breadth of 32 bits in register 403 with numbers from 0 to 31. The same applies to register 404 and bit locations 0 to 31 in 404.
In accordance with the invention, bit locations 0 to 5, 15, 16 to 21 and 31 of register 403, for example, now receive a special function with regard to process

flow control. Identifier IBRH (input buffer request host) can thus be entered in bit locations 0 to 5 of register 403 as a message identifier. Similarly, identifier IBRS (input buffer request shadow) can be entered in bit locations 16 to 21 of register 403. Likewise, IBSYH in register location 15 of 403 and IBSYS in register location 31 of 403 can be entered as access identifiers. Locations 0 to 2 of register 404 are also perfect, whereby other identifiers are entered as data identifiers in 0 and 1 with LHSH (load header section host) and LDSH (load data section host). These data identifiers here are in the simplest form viz., designed in each case as one bit. A start identifier is written with STRXRH (set transmission X request host) in bit location 2 of register 404.
Process flow of write access to the message RAM through the input buffer is described below.
The host-CPU writes the data of the message to be transferred in the input buffer 201. The host-CPU can, thereby, only write the configuration data and header data KD of a message for the header segment HS of the message RAM or only the actual data D of a message to be transferred for the data segment DS of the message RAM or both. Which part of a message i.e., configuration data and/or the actual data is to be transferred is determined by the special data identifiers LHSH and LDSH in the input buffer command mask register 404. Thus, whether the header data i.e., the configuration data KD, gets transferred is determined by LHSH (load header section host), while the LDSH (load data section host) determines whether the data D is to be transferred. Since the input buffer memory 201 is designed with two parts, one part being the buffer memory 400 and the other a non-addressable memory 401 associated with the same, and a two-way access should take place, two other data identifier segments are provided as a counterpart to LHSH and LDSH that are 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 LOSS (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
402 RAM 300 to the two partial memories 400 and 401 is interchanged, as indicated
403 by the semi-circular arrow. Data transfer i.e., data transmission to the message
404 RAM is also thereby started, for example. Data transfer to the message RAM
405 300 itself takes place from the non-addressable memory 401. Register segments
406 IBRH and IBRS are simultaneously interchanged. LHSH and LDSH are similarly
407 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 utilised 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.
Utilising the described input and output buffers ensures that a host-CPU can uninterruptedly access the message RAM despite the internal module latency time.
In order to safeguard this data integrity, the data transfer, particularly forwarding in the communication module 100, is undertaken by the message handler 200 (MHD). The message handler 200 is illustrated in Figure 10 for this purpose. The message handler can be represented in its functionality by several finite state machines or finite state automats i.e., finite automats, so-called finite state machines (FSM). Thereby at least three finite state machines and in a special design, four finite state machines, are provided. A first finite state machine is the IOBF-FSM and is indicated with 501 (input/out buffer state machine). This IOBF-FSM could also be partitioned into two finite state machines IBF-FSM (input buffer FSM) and OBF-FSM (output buffer FSM) per transfer direction with regard to the input buffer memory and to the output buffer memory, with which a maximum of five finite state machines (IBF-FSM, OBF-FSM, TBF1-FSM, TBF2-FSM, AFSM) would be conceivable. Provision of a common IOBF-FSM is, however, preferable. An at least second finite state machine is partitioned here into two blocks 502 and 503 in the course of the preferred exemplary embodiment and serves the two channels A and B with regard to memory 205 and 206, as per the description for Figure 2. A finite state machine can thereby be provided in order to serve both channels A and B or even, as in the preferred design, one finite state machine TBF1-FSM designated 502 (transient buffer (206 RAM A) state machine) for channel A and a TBF2-FSM designated 503 (transient buffer 2 (205, RAM B) state machine) for channel B.

An arbiter finite state machine, the so-called AFSM that is designated 500, serves to control access by the three finite state machines 501 - 503 in a preferred exemplary embodiment. 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 utilising the full band breadth.

Claims
1. Message RAM in a communication module (100) for storing of a
2. number of messages, whereby first data (KDO, KD1, KDk) is contained
3. with a first data volume and second data (DO, D1, Dk) with a second
4. data volume in the messages to be stored, whereby the second data
5. volume per message can be different and the message RAM (300)
6. contains a header segment (HS) in which the first data (KDO, KD1,
7. KDk) of message is stored in a header region each (HBO, HB1, Hbk)
8. per message and the message RAM (300) contains a data segment
9. (DS) in which the second data (DO, D1, Dk) of messages in a data
10. segment each (DB0, DB1, DBk) per messages is stored, whereby the
11. message RAM (300) is designed in such a manner that a partitioning
12. between the header segment (HS) and the data segment (DS) is
13. variable and is subject to the number (k) of messages and to the
14. second data volume.
15. Message RAM according to Claim 1, characterised in that, a data
16. pointer (DP0, DP1, DPk) per message is provided in the header
17. segment (HS) in each header region (HBO, HB1, HBk), using which a
18. data region (DB0, DB1, DBk) in data segment (DS) is determined.
19. Message RAM according to Claim 1, characterised in that, the first and
20. second data of messages are stored in a pre-determined sequence,
21. whereby the sequence of the header region (HBO, HB1, HBk) in the
22. header segment (HS) and the sequence of the data region (DB0, DB1,
23. DBk) in the data segment (DS) are respectively identical.
24. Message RAM according to Claim 1, characterised in that, the
25. message RAM is designed as a FIFO memory.

26. Message RAM according to Claim 1, characterised in that, the first
27. data (KDO, KD1, KDk) of the message is stored in a header region
28. (HBO, HB1, HBk) each per message and with an identical, pre-
29. determined first number of words for each header region (HBO, HB1,
30. HBk).
31. Message RAM according to Claim 1, characterised in that, the same is
32. designed with a pre-determined, fixed memory word length.
33. Message RAM according to Claim 1, characterised in that, the header
34. region (HS) and the data region (DS) are consecutive.
35. Message RAM according to Claim 1, characterised in that, a parity bit
36. generator element and a parity bit check element are allocated to the
37. same.
38. Message RAM according to Claim 1, characterised in that, each data
39. region comprises at least one pre-determined memory word length and
40. that a monitoring identifier, especially a parity bit, is provided in the
41. data region per memory word length.
42. FlexRay communication module with a message RAM according to
43. Claim 1.
44. Control unit with a FlexRay communication module, which contains a
45. message RAM according to Claim 1.
46. Process for storing a number of messages in a message RAM in a
47. communication module (100), whereby first data (KDO, KD1, KDk) is
48. contained with a first data volume and second data (DO, D1, Dk) with a

second data volume in the messages to be stored, whereby the second data volume per message can be different and the first data (KDO, KD1, KDk) is stored in a header segment (HS) of the message RAM in a header region (HBO, HB1, HBk) each per message and the second data (DO, D1, Dk) is stored in a data segment (DS) in a data region (DBO, DB1, DBk) each per message, whereby variable partitioning is executed between the header segment (HS) and the data segment (DS), subject to the number (k) of messages and to the second data volume.
Dated this 5 day of February 2007

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=I0NcniNC6ekkNNN31hsmnQ==&loc=egcICQiyoj82NGgGrC5ChA==


Patent Number 269583
Indian Patent Application Number 505/CHENP/2007
PG Journal Number 44/2015
Publication Date 30-Oct-2015
Grant Date 28-Oct-2015
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
PCT International Classification Number H04L 12/56
PCT International Application Number PCT/EP05/53057
PCT International Filing date 2005-07-29
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 102004038210.7 2004-08-05 Germany