111111
`
`1111111111111111111111111111111111111111111111111111111111111111111111111111
`US 20020073243Al
`
`(19) United States
`(12) Patent Application Publication
`Staiger
`
`(10) Pub. No.: US 2002/0073243 Al
`Jun. 13, 2002
`(43) Pub. Date:
`
`(54)
`
`INTERCOMMUNICATION PREPROCESSOR
`
`(30)
`
`Foreign Application Priority Data
`
`(75)
`
`Inventor: Dieter E. Staiger, Weil im Schoenbuch
`(DE)
`
`Correspondence Address:
`IBM CORPORATION
`INTELLECTUAL PROPERTY LAW DEPT.
`P.O. BOX 218 - 39-254
`YORKTOWN HEIGHTS, NY 10598 (US)
`
`(73)
`
`Assignee: International Business Machines Cor(cid:173)
`poration
`
`(21)
`
`Appl. No.:
`
`10/004,471
`
`(22)
`
`Filed:
`
`Dec. 4, 2001
`
`execution time
`--1------~
`
`1 302
`ip_EU
`
`Dec. 9, 2000
`
`(DE) ........................................ 00127047.9
`
`Publication Classification
`
`(51)
`Int. Cl? ....................................................... G06F 9/00
`(52) U.S. CI. ........................... 709/313; 709/250; 709/100
`
`(57)
`
`ABSTRACT
`
`The present invention relates to a method for communicat(cid:173)
`ing with remote units over at least one data network and with
`at least one dedicated CPU. The message processing device
`according to the present invention includes a first execution
`unit for receiving a message to be processed and determin(cid:173)
`ing the kind of treatment to be performed with the received
`message, a second execution unit for performing the deter(cid:173)
`mined treatment, and a third execution unit for presenting
`the result of the message processing to be forwarded to a
`destination unit.
`
`304
`
`exe-
`proc.
`
`ip_EU
`
`310/
`
`I ETR (n)
`
`I dp EU(1)
`I dp EU (2)
`I dp EU (3)
`I dp_ EU_!_ml
`
`I
`
`release
`state 1
`
`process
`state 3
`
`process
`state3
`
`load ETR
`
`process state 1
`
`load ETR
`~
`pr.state 1
`I
`
`l'rL..-...1"
`
`~
`
`I·~
`
`"""' ·~
`
`process state 2
`
`process state 2
`
`)
`
`f
`306
`
`J
`
`I
`J
`J
`
`J
`
`11
`
`8
`
`
`
`PAGE 1 OF 17
`
`BMW EXHIBIT 1004
`
`

`

`Patent Application Publication
`
`Jun. 13, 2002 Sheet 1 of 8
`
`US 2002/0073243 A1
`
`I 102
`
`J
`
`I 112
`
`J
`
`108
`
`[~=}=~~c::> 110
`
`107
`
`1-1--
`
`FIG. 1
`
`I
`
`239
`
`246
`\
`
`230
`I
`
`_ _.j ~.f
`r-2-3 -8 - , , .. _ , .
`
`l1Q
`
`~-~LJI-f ~ rv
`I I-f 244 J ~ • ....___ • .,..._..,,......
`I
`1~.-_ __ _ __ __,T I
`7~__ _____ _...J1
`r
`
`1-
`
`1-f-
`
`r....
`214
`
`I
`202
`
`(_
`
`215
`
`L-
`
`216
`
`203
`
`\
`204
`
`FIG. 2
`
`211
`
`PAGE 2 OF 17
`
`

`

`Patent Application Publication
`
`Jun. 13, 2002 Sheet 2 of 8
`
`US 2002/0073243 Al
`
`execution time 1 302
`ip_EU
`
`304
`
`exe-
`p roc.
`
`ip_EU
`
`310/
`
`I ETR (n)
`
`I dp EU (1)
`I dp EU (2)
`I dp EU (3)
`I dp_ EU (m)
`
`I
`
`release
`state 1
`
`process
`state 3
`
`process
`state 3
`
`load ETR
`
`process state 1
`
`load ETR
`pr.state 1
`I
`
`..
`
`.. c---J-
`
`I
`
`J
`J
`J
`
`_,..,_
`w.:~
`
`""'-
`
`-~
`
`process state 2
`
`process state 2
`
`1\
`
`30 8
`
`)
`
`I
`306
`
`FIG. 3
`
`PAGE 3 OF 17
`
`

`

`Patent Application Publication
`
`Jun. 13, 2002 Sheet 3 of 8
`
`US 2002/0073243 Al
`
`403
`I
`
`Bus
`Adapter
`2
`
`~
`
`r
`
`404
`I
`
`Bus
`Adapter
`3
`
`'
`
`r
`
`~
`
`410
`
`405
`i
`Bus
`Adapter
`n
`;
`
`407
`408
`I
`I
`IR~ CPU I~ CPUs
`Adapter
`Adapter
`n
`1
`'
`
`r_
`
`r
`\
`422
`
`402
`I
`Bus
`Adapter
`1
`
`~
`
`r message
`
`4\12
`!Interrupt l
`monitor f
`
`414
`any
`IRQ
`?
`
`y
`
`n
`
`~
`
`r
`
`initializing
`process
`
`\
`
`416
`
`monitor
`
`monitor
`
`t
`__., dynamic
`process
`execution
`
`418
`
`"
`
`FIG. 4
`
`presentation process
`execution
`
`\20
`4
`
`PAGE 4 OF 17
`
`

`

`Patent Application Publication
`
`Jun. 13, 2002 Sheet 4 of 8
`
`US 2002/0073243 Al
`
`n
`
`512
`
`y
`
`510
`
`start max.
`msg. delay
`timer
`
`ini_EU
`ready
`
`set
`ini_EU#
`busy
`
`(1)
`access
`IPP-transitio
`n
`storage
`(2) ... - - i+--<
`allocate ETR
`
`516
`
`y
`
`timeout
`
`508
`
`518
`
`y
`
`526
`
`n
`
`528
`
`FIG. 5
`
`PAGE 5 OF 17
`
`

`

`Patent Application Publication
`
`Jun. 13, 2002 Sheet 5 of 8
`
`US 2002/0073243 Al
`
`600
`
`602
`
`monitor ETR
`(round robbing
`......------.-. or interrupt 14----+-------.
`on change)
`
`611
`
`614
`
`(1)
`allocate REG
`space
`(2)
`label REG
`privatI public
`
`608
`
`610
`
`612
`
`(1)
`allocate
`ETRTask
`(2)
`set ETR fla~
`'in process
`®
`process-
`respective to
`ETR task
`
`FIG. 6
`
`PAGE 6 OF 17
`
`

`

`Patent Application Publication
`
`Jun. 13, 2002 Sheet 6 of 8
`
`US 2002/0073243 Al
`
`702
`
`704
`
`processing
`procedure I resource
`requirements
`
`y
`
`scan Register-Pool
`for specific
`ID-process
`pending
`
`y
`
`710
`
`712
`
`(1)
`allocate REG
`(Register-pool)
`(2)
`label REG
`content
`=public
`
`(1)
`store time stamp
`(2)
`store msg. data
`
`note
`
`FIG. 7
`
`708
`
`(1)
`new msg. data
`V (log. or)
`stored REG data
`store update to REG
`& get time stamp
`(2)
`compare time
`stamp to predifined
`message
`occurance time-limit
`(parameter (tr))
`
`y
`
`718
`
`set ETR flag
`'processed'
`
`note
`
`PAGE 7 OF 17
`
`

`

`Patent Application Publication
`
`Jun. 13, 2002 Sheet 7 of 8
`
`US 2002/0073243 Al
`
`806
`
`n
`
`820
`
`clear I release
`processed
`ETR
`
`assemble CPU
`message
`(data+ I D)
`y
`
`814
`
`810
`
`n
`
`822
`
`824
`
`assemble BA
`message
`(data+ fD)
`y
`
`present
`message to
`send-buffer
`of respective
`SA-controllers
`
`818
`
`y
`
`FIG. 8
`
`PAGE 8 OF 17
`
`

`

`Patent Application Publication
`
`Jun. 13, 2002 Sheet 8 of 8
`
`US 2002/0073243 Al
`
`900
`
`\
`
`j31 ..
`
`21 1120 ..
`
`~41113 4-11jj10 .- 8117 ..
`
`data-bits
`oj
`
`11
`
`I D-translation
`
`7 Destination
`
`3 Op-Code 3 Filter
`
`8 Parameter pointer
`
`A_O
`A_1
`
`"'""
`
`A_2
`
`!
`!
`!
`1
`1
`~:::~ 1~-----~-------11f----+--l ---~-1 ----~I
`
`... ...,
`
`/:.:
`
`Bus Destination Field
`
`\20 19 18 17 16 15 14\
`0 n n n n n 1
`n n n n
`1 n
`0
`n n n 1 n n
`0
`0 n n 1 n n n
`0 n 1 n n n n
`0 1 n n n n n
`1 X X X X x\x
`
`BA1
`BA2
`BA3
`BA4
`
`CPU 1
`CPUn
`
`skip
`
`'</
`data Op-Code
`!13 12 11 I
`0 0
`0
`0
`0
`1
`0 1 0
`0 1 1
`1 X X
`
`copy
`
`or
`
`xor
`
`and
`
`apply
`parameter
`
`Message Filter Op-Code
`\10 09 osi
`0 0 0
`0
`0 1
`0 1 0
`0 1 1
`1 X X
`
`time stamp
`count stamp
`
`DR-frame
`instant trans!.
`
`apply
`parameter
`
`\ 920
`
`\ 910
`
`FIG. 9
`
`PAGE 9 OF 17
`
`

`

`US 2002/0073243 Al
`
`Jun. 13,2002
`
`1
`
`INTERCOMMUNICATION PREPROCESSOR
`
`TECHNICAL FIELD
`
`[0001] The present invention relates to a method and a
`circuit arrangement for communication within and across
`networks. Particularly, the present invention relates to a
`method and device for communicating with remote units
`over at least one data network and with at least one dedicated
`CPU (central processing unit).
`
`BACKGROUND ART
`
`[0002] Computer systems of all different sizes, from
`embedded systems over personal computer and workstations
`to even large scale computer systems, are typically con(cid:173)
`nected to one or more networks. Through the networks the
`computer systems are able to collect information from
`different mostly remote systems for further computation.
`The information might contain parameters describing the
`state of operation of the remote systems which are meant to
`be controlled or monitored by the computer system receiv(cid:173)
`ing the information.
`
`[0003] An Electronic Control Unit (ECU) in a modem
`automobile is an example for such an arrangement. The
`ECU may be connected to a plurality of real-time networks,
`e.g., several individual CAN (Controller Area Network)
`busses or other multiple purpose networks, like multimedia(cid:173)
`networks, such as MOST (Media Oriented Systems Trans(cid:173)
`port), i.e., an optical bus system used in automobiles, or
`IEEE1394 (Firewire ).
`
`[0004] During operation, the ECU executes an application
`program for controlling the remote systems. At the same
`time, it has to monitor the various busses and networks in
`order to select and retrieve such information from the data
`being transmitted which contains parameters required for the
`application programs in progress. Commonly, multiple bus(cid:173)
`ses are directly attached to a Central Processing Unit (CPU)
`included in the ECU. Monitoring the busses, selecting and
`retrieving the information of interest causes a processing
`load of momentous significance for the overall performance
`of the ECU.
`
`[0005] The processing load is particularly generated by
`routing, gateway, bus bridge and filtering functions which
`have to be performed by the ECU concurrently to the
`execution of the application program.
`
`[0006] Typically, in smaller computers and embedded
`systems the processing load generated by routing, gateway,
`bus bridge and filtering functions should be minor, leaving
`the majority of computing performance to the target appli(cid:173)
`cation that has been assigned to the specific CPU in the first
`place.
`
`[0007] As opposed to local area networks (LAN), such as
`Ethernet, real-time bus systems, like the CAN bus system,
`are transporting a comparable small amount of data per data
`packet. This feature is significant to ensure the real-time
`capability of the bus system, i.e., the capability of a system
`to respond to stimuli within some small upper limit of
`response time, typically milliseconds or microseconds.
`However, real-time bus systems allow to transmit a compa(cid:173)
`rable high amount of data packets within a given period of
`time. Thus, real time bus systems generate a very high
`interrupt rate for a CPU connected to it, which needs to
`
`select and retrieve relevant data packets. As an example,
`four independent CAN bus systems attached to a processing
`system using a Power PC 403 CPU running at 50 MHz, may
`cause a interrupt rate inducing a CPU load well above 50%
`utilization in average, that is only caused by interrupts
`triggered by the CAN bus systems.
`
`[0008]
`In state of the art devices, standard computing
`systems, such as single or multiple (parallel) processors,
`implemented following the RISC (Reduced Instruction Set
`Computer) or CISC (Complex Instruction Set Computer)
`architecture, are used to perform intercommunication appli(cid:173)
`cations and tasks.
`
`[0009] Although state of the art computing systems might
`be used for the intercommunication applications and tasks,
`providing sufficient processing performance becomes a seri(cid:173)
`ous issue, in case multiple bus adapters are connected via the
`computing system. Calculating the worst-case interrupt rate
`produced by, e.g., four 1 Mbps (megabits per second)
`bus-adapters may reach a interrupt rate per second far
`beyond the computing capabilities a present standard pro(cid:173)
`cessor can provide.
`
`[0010] The fact that a comparable high amount of data
`packets has to be dealt with influences significantly the
`demand on performance for processing systems in the area
`of intercommunication applications. Put into practice, the
`aforementioned circumstance is leading to an increasing
`demand on processing capabilities in contrast to the require(cid:173)
`ments defined by the other applications which are executed
`on the computing system.
`
`[0011] To overcome the shortage of computing capabili(cid:173)
`ties the system clock frequency could be doubled. As a result
`of that, the power dissipation typically doubles as well,
`causing problems, e.g., with respect of cooling the system.
`Another solution could be found by adding more processors
`to the system. All performance demanding bus related tasks
`could be executed on an additional processor within the
`system. This, however, results in higher manufacturing
`costs, since an additional processor has to be provided.
`
`[0012] Another method used by real-time bus controllers
`are so called "filter register." Filter register are comple(cid:173)
`mented by hardware comparators allowing to bring some
`'relief' for the CPU(s) by reducing the interrupt rate and
`reducing time consuming message address compare opera(cid:173)
`tions. The message IDs to be filtered are stored in specific
`registers, e.g., 16 identifiers, and are compared with the
`messages approaching on the bus. Only messages having
`matching identifiers are forwarded to the CPU. From U.S.
`Pat. No. 5,832,397 an integrated communications apparatus
`is known for use in a vehicle control system for monitoring
`and controlling operational status of a plurality of vehicle
`systems, each vehicle system having a local control unit for
`controlling operation thereof, said local control units being
`accessible by means of a data communication line, said
`integrated communications apparatus comprising: at least
`one memory unit, a central processing unit for receiving and
`processing signals transmitted from said local control units,
`which signals are indicative of operational status of said
`plurality of vehicle systems, according to control programs
`stored in one of said at least one memory unit, and for
`generating control signals for transmission to said plurality
`of vehicle systems by means of said data communication
`line, and a programmable subprocessor for controlling com-
`
`PAGE 10 OF 17
`
`

`

`US 2002/0073243 Al
`
`Jun. 13,2002
`
`2
`
`munications between said central processing unit and said
`local control units by means of said data communication
`line, according to at least one of said control programs stored
`in one of said at least one memory unit.
`
`OBJECT OF THE INVENTION
`
`[0013] Starting from this, the object of the present inven(cid:173)
`tion is to provide a method and a device that improves the
`data processing between at least one network and at least one
`CPU.
`
`SUMMARY OF THE INVENTION
`
`[0014] The foregoing object is achieved by a method and
`a system as laid out in the independent claims. Further
`advantageous embodiments of the present invention are
`described in the sub claims and are taught in the following
`description.
`[0015] The method focuses on message processing in a
`system for communicating with remote units over at least
`one data network and with at least one dedicated CPU. First,
`a message to be processed is received and it is determined
`the kind of treatment to be performed with the received
`message. Then message specific information specifying the
`contents of the received message and the determined treat(cid:173)
`ment of a received message are stored into a first set of
`registers. In the following the first set of registers is moni(cid:173)
`tared in order to start processing a message once a process
`execution unit is available for processing. Then the deter(cid:173)
`mined treatment gets performed. Meanwhile, the first set of
`registers are monitored in order to start presenting the result
`of the message processing once the processing of the mes(cid:173)
`sage is complete. Finally, the result of the message process(cid:173)
`ing is presented to be forwarded to a destination unit.
`[0016] The message processing device according to the
`present invention for communicating with remote units over
`at least one data network and with at least one dedicated
`CPU includes a first execution unit for receiving a message
`to be processed and determining the kind of treatment to be
`performed with the received message, a second execution
`unit for performing the determined treatment, and a third
`execution unit for presenting the result of the message
`processing to be forwarded to a destination unit.
`[0017]
`In further embodiments, the second execution unit
`additionally comprises one or all of the following features:
`a first set of registers for storing message specific inform a(cid:173)
`tion specifying the data contents and the determined treat(cid:173)
`ment of a received message, at least one process execution
`unit having access to the first set of registers for performing
`the determined treatment and/or a second set of registers
`being connected the at least one process execution unit for
`storing information needed by the process execution unit.
`The device might be configured to monitor the first set of
`registers in order to start processing a message once a
`process execution unit is available for processing and or to
`monitor the first set of registers in order to start presenting
`the result of the message processing once the processing of
`the message is complete.
`[0018] Preferably, the device is integrated in an intercom(cid:173)
`munication processing system for communication within
`and across networks. The system further comprises a switch(cid:173)
`board device for providing a communication connection to
`
`the at least one data network and to the at least one dedicated
`CPU, whereby the switchboard comprises a multiplexer on
`one hand connected to the first and third execution unit and
`on the other hand being prepared to be connected to several
`bus adapters and the CPUs and/or an interrupt bus on one
`hand connected to the first execution unit and on the other
`hand being prepared to be connected to several bus adapters
`and the CPUs.
`[0019] An advantage of the method and device according
`to the present invention is relieving a processing unit com(cid:173)
`municating with multiple networks from a high interrupt rate
`induced by the amount of data packets being transmitted
`over the networks.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0020] The above, as well as additional objectives, fea(cid:173)
`tures and advantages of the present invention, will be
`apparent in the following detailed written description.
`
`[0021] The novel features of the invention are set forth in
`the appended claims. The invention itself, however, as well
`as a preferred mode of use, further objectives, and advan(cid:173)
`tages thereof, will best be understood by reference to the
`following detailed description of an illustrative embodiment
`when read in conjunction with the accompanying drawings,
`wherein:
`
`[0022] FIG. 1 shows a high level block diagram of an
`intercommunication preprocessor according to the present
`invention;
`[0023] FIG. 2 shows a high level block diagram of an
`intercommunication preprocessor according to the present
`invention;
`
`[0024] FIG. 3 shows a diagram illustrating concurrent
`process execution according to the present invention;
`
`[0025] FIG. 4 shows a flow chart illustration the message
`processing of an intercommunication preprocessor accord(cid:173)
`ing to the present invention;
`
`[0026] FIG. 5 shows a flow chart illustration the message
`processing in an initializing process of the message process(cid:173)
`ing as illustrated in FIG. 4;
`[0027] FIG. 6 shows a flow chart illustrating the message
`processing in an dynamic process of the message processing
`as illustrated in FIG. 4;
`
`[0028] FIG. 7 shows a flow chart illustrating the message
`processing of an execution unit process of the message
`processing as illustrated in FIG. 6;
`[0029] FIG. 8 shows a flow chart illustrating the message
`processing of a presentation process of the message pro(cid:173)
`cessing as illustrated in FIG. 4;
`
`[0030] FIG. 9 shows a table depicting the organization of
`information stored in the intercommunication preprocessor
`storage sub system.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`[0031] FIG. 1 shows a high level block diagram of an
`intercommunication preprocessor 100 according to
`the
`present invention. The intercommunication preprocessor
`
`PAGE 11 OF 17
`
`

`

`US 2002/0073243 Al
`
`Jun. 13,2002
`
`3
`
`100 (IPP) performs three different kinds of processes, each
`of which is executed on a separate execution unit.
`
`[0032] The first kind of process is called "initializing
`process. " It analyses an incoming message, illustrated as
`block 102 in FIG. 1, and determines its further processing
`based on configuration data dedicated to the intercommu(cid:173)
`nication preprocessor 100 and information encoded in the
`incoming data, as it will be explained in greater detail later
`on. The initializing process (IP) is performed by an IP
`execution unit 104.
`
`[0033] After the initializing process, the message is sub(cid:173)
`ject of the second process that is called "dynamic process".
`The dynamic process (DP) performs the task which has been
`determined by the initializing process. As indicated by
`staggered boxes 106, 107 and 108, three DP execution units
`are provided to perform the dynamic process. This is done
`sequentially or concurrently depending on the tasks to be
`performed. All tasks to be performed on one incoming
`message which can be split into subtasks that can be
`performed concurrently are marked accordingly. Later, dur(cid:173)
`ing the dynamic process more than one execution units
`might be used to perform the tasks in parallel. Hence, the
`topology of the present intercommunication preprocessor
`100 is not limited either to parallel computing or sequential
`computing, it is able to perform either way depending on the
`actual task to be executed.
`
`[0034]
`In other words, in differentiation to known state of
`the art processor topologies, the intercommunication pre(cid:173)
`processor architecture is not identifiable operating in a fixed
`processor architecture. It rather is triggered by the respective
`job to be executed. Thus, the logical intercommunication
`preprocessor system architecture is continuously adjusting
`its processor topology dynamically to the actual require(cid:173)
`ments.
`
`[0035] The third kind of process is called "presentation
`process." The presentation process (PP) is performed on a
`dedicated PP execution unit 110 which monitors the
`dynamic processes executed on the multiple DP execution
`units. After the completion of the tasks performed during the
`dynamic process the PP execution unit outputs a message
`112 as a result of the computation of the incoming message
`102.
`
`[0036] With reference now to FIG. 2, there is depicted a
`high level block diagram of an intercommunication prepro(cid:173)
`cessor 200 according to the present invention. The shown
`intercommunication preprocessor 200 is connected to a
`switchboard 201 which is designed to connect four indi(cid:173)
`vidual CAN-busses 202 to 205 and in addition a first and a
`second independent CPU 207 and 208. The first and the
`second CPU 207 and 208 are providing connections to first
`and second additional bus systems 210 and 211, respec(cid:173)
`tively. The additional first and second bus systems 210 and
`211 might be different from each other and formed by, e.g.,
`a FireWire system, i.e., a high performance serial bus
`specified according to IEEE 1394, or any other kind of
`multimedia bus, such as, e.g., MOST (Media Oriented
`Systems Transport).
`
`[0037] Connecting up to four CAN busses and one or two
`CPUs together represents a typical network requirement
`used in modem automobiles. However, the intercommuni(cid:173)
`cation preprocessor according to the present invention is
`
`neither limited to this particular bus systems, the specific
`number of busses nor to the number of CPUs connected to
`it.
`
`[0038] Each of the four CAN-busses 202 to 205 is con(cid:173)
`nected to a respective bus adapters 214 to 217. The bus
`adapters 214 to 217 might be formed by standardized CAN
`controllers providing connections to the respective CAN(cid:173)
`busses 202 to 205 via CAN-Cor CAN-E physical layers. On
`one hand, each bus adapter 214 to 217 has got a connection
`to an interrupt request bus 220. On the other hand, each bus
`adapter 214 to 217 possess a connection to a multiplexer
`222. The connections to the multiplexer 222, however,
`might be formed by a bus providing a sets of conductors,
`such as wires, PCB (printed circuit board) tracks or connec(cid:173)
`tions in an integrated circuit, to connect the bus adapters 214
`to 217 with the multiplexer 222.
`
`[0039] Corresponding to the four bus adapters 214 to 217,
`both CPUs 207 and 208 are as well connected to the
`interrupt bus 220 and to the multiplexer 222. The multi(cid:173)
`plexer 222 further shows a connection to a control engine
`224 of a IP (initializing process) execution unit 226 and to
`an transmission unit 228, which is included in a PP (pre(cid:173)
`sentation process) execution unit 230. A controller 232
`controls the multiplexer 222 in response to control signals
`transmitted over dedicated control signal lines received by
`the first CPU 207, the second CPU 208 and the transmission
`unit 228, respectively. The arrangement as drawn above
`enables the multiplexer to provide connections from the bus
`adapters 214 to 217 and the CPUs 207 and 208 to either to
`control engine 224 or the transmission unit 228.
`
`[0040] The IP execution unit 226 further comprises an IPP
`preset interface 234 and an IPP storage sub system 236. The
`IPP preset interface 234 can be initialized by the first CPU
`207 and is able to exchange control information with the
`control engine 224, whereas the IPP storage sub system 236
`is provided for storing control information needed for the
`computation of messages received from either one of the bus
`adapters 214 to 217 or one of the CPUs 207 and 208.
`
`[0041] Besides having a connection to the multiplexer
`222, the control engine 224 is connected to the interrupt bus
`220 and further possesses a connection to execution tag
`registry 238 which is included in a DP (dynamic process)
`execution unit 239 and store data needed for the computa(cid:173)
`tion of the received messages. The execution tag registry
`238 itself is connected to a first, a second and a third
`execution unit 240 to 244 which can access a register pool
`246 for storing data and for exchanging data among the
`execution units 240 to 244. It is acknowledged that the
`number of execution units is not limited to three, there might
`be any number of execution units provided in the intercom(cid:173)
`munication preprocessor according to the present invention.
`
`[0042] From the execution tag registry 238 information
`can be transferred through a dedicated data link to the
`transmission unit 228. From there the information can either
`be supplied to the multiplexer 222 or directly to the first or
`second CPU 207 and 208.
`
`In other words, the PP execution unit 230 is con(cid:173)
`[0043]
`tinuously monitoring and interpreting the execution tag
`registry 238. As soon as particular data field is decoded to a
`notification having the meaning 'overall process complete',
`the PP execution unit will be triggered and a special 'Pre-
`
`PAGE 12 OF 17
`
`

`

`US 2002/0073243 Al
`
`Jun. 13,2002
`
`4
`
`sentation Processing' procedure will be initiated in order to
`complete the overall process function.
`
`[0044] The Presentation Process procedure is defined by
`an overall system specification. However, typical jobs are
`functions like: getting or generating a destination message
`address, getting and assembling a new message from the
`data being the result of the processing of a message, issuing
`the new message to a specified target system and/or trans(cid:173)
`mitting the message to register files or a FIFO (first-in
`first-out queue) or priority sorting the individual exit mes(cid:173)
`sage queues.
`
`[0045] Complex Presentation Processing functions can be
`organized by using process driven topology to build up an
`very effective system.
`
`[0046] The execution tag registry is accompanying an
`intercommunication preprocessor process until its comple(cid:173)
`tion. During this time, it is continuously being updated by
`feedback. The number of dynamic processes having the state
`"pending" may increase and decrease during the entire
`intercommunication preprocessor process. At the time, all
`execution flags within the execution tag registry are cleared
`and the Presentation Process will take over to finalize the
`overall IPP process. A post execution unit will take over the
`result contained in the execution tag registry and the data
`generated by the last finalized DP execution unit.
`
`[0047] Then, it will use this information to assemble a new
`message. The execution tag registry as well as the last DP
`execution unit will be unloaded and released.
`
`[0048] The PP execution unit 230 will finalize the message
`and push the 'resulting' message into an output pipeline. An
`invalid message may be dismissed or rejected at this point of
`time upon software control according to a specification in an
`intercommunication preprocessor configuration register.
`Upon specific intercommunication preprocessor system
`requirements, the PP execution unit can perform a 'priority
`sort' on the messages stored in the output pipeline. Imme(cid:173)
`diately hereafter, a request to the respective bus adapter or
`an interrupt to the CPU will be issued. The respective bus
`adapter will start and execute the arbitration and will clear
`the corresponding output pipe upon the reception of a
`successful transmission message or, in case of the CPU, a
`interrupt service routine completed message.
`
`[0049] The pipe overflow handling is defined in an inter(cid:173)
`communication preprocessor system configuration registers.
`In case of a pipe overflow the intercommunication prepro(cid:173)
`cessor could stop initializing execution units and issue an
`interrupt to CPU notifying the CPU of the overflow condi(cid:173)
`tion.
`
`[0050] The controller 232, the multiplexer 222 and the
`interrupt bus 220 are forming the switchboard 201. The
`switchboard 201 is a functional extension to the actual
`intercommunication preprocessor allowing to improve the
`advantageous system characteristic. The switchboard 201
`hardware function is inserted between the intercommunica(cid:173)
`tion preprocessor, the CPUs 207 and 208 and the diverse bus
`adapters 214 to 217 as shown in FIG. 2.
`
`[0051] The switchboard 201 is a multiplexing scheme
`controlled either by one of the CPUs 207 and 208 or the
`intercommunication preprocessor 200. This allows the
`CPUs 207 and 208 to use the functionality of the intercom-
`
`munication preprocessor 200. For example, a message gen(cid:173)
`erated by one of the CPUs 207 and 208 has to be broadcasted
`to several CAN busses 202 to 205 identically. In this case,
`the message is multiplexed by the switchboard 201 to the
`intercommunication preprocessor 200, then, the intercom(cid:173)
`munication preprocessor 200 processes the message and
`initiates immediate distribution. This procedure significantly
`saves time, since the intercommunication preprocessor 200,
`specialized to operate this tasks, will require only a fraction
`of processing time in comparison to a master CPU formed
`by one of the CPUs 207 and 208. Furthermore, the master
`CPU only has to execute one single message operation, in
`case the message needs to be computed before forwarding,
`which saves processing time as well.
`
`[0052] FIG. 3 shows a diagram illustrating concurrent
`process execution according to the present invention. The
`x-axis 302 illustrates the progress in time, whereas they-axis
`304 illustrates the seizure of the intercommunication pre(cid:173)
`processor resources, namely, the one of the DP execution
`units and storage space in the execution tag registry, as
`described with reference to FIG. 2.
`
`[0053] A rectangular frame 306 encloses one storage space
`in the execution tag registry ETR(n) and all DP execution
`units which are involved in the processing of one particular
`incoming message, whereby the letter "n" denotes that a
`random storage space of the execution tag registry might be
`used. Correspondingly, the numbering of the DP execution
`units "1", "2", "3" and "m" illustrates that there are up to
`"m" DP execution units, whereby "m" is an integer number
`greater than three. However, it is acknowledged that the
`number of parallel DP execution units can be chosen in
`accordance with the actual performance needs, without
`departing from the underlying idea of the present invention.
`
`[0054] After one incoming message has been processed,
`another incoming message can be computed by using the
`same storage space of the execution tag registry. At the same
`time, different other messages can be processed by using
`different storage spaces in the execution tag registry, as
`indicated by the second staggered rectangular frame 308.
`However, typically more than two messages are processed
`concurrently.
`
`[0055] The processing of an incoming message by the DP
`execution units gets initiated by the IP execution unit (of
`FIG. 2) as denoted by the arrow 310. The IP execution unit
`allocates a storage space of the execution tag registry and
`stores all information needed by the DP execution units to
`perform the specified treatment on the incoming message.
`After the initialization, the IP execution unit immediately
`processes the next incoming message available. Correspond(cid:173)
`ingly, the IP execution unit allocates another storage space
`of the execution tag registry and stores all information
`needed by the DP execution units to perform the specified
`treatment on the next incoming message.
`
`[0056] After the initializing process (process state 1) the
`particular storage space of the execution tag registry stays
`allocated until the processing of the message is complete. In
`the example shown in FIG. 3, three different DP execution
`units start processing the inco