[ae68ff0] | 1 | @c |
---|
[1b03eed] | 2 | @c COPYRIGHT (c) 1988-2007. |
---|
[ae68ff0] | 3 | @c On-Line Applications Research Corporation (OAR). |
---|
| 4 | @c All rights reserved. |
---|
| 5 | @c |
---|
[139b2e4a] | 6 | @c $Id$ |
---|
| 7 | @c |
---|
[ae68ff0] | 8 | |
---|
| 9 | @chapter Multiprocessing Manager |
---|
[20515fc] | 10 | |
---|
[169502e] | 11 | @cindex multiprocessing |
---|
| 12 | |
---|
[ae68ff0] | 13 | @section Introduction |
---|
| 14 | |
---|
| 15 | In multiprocessor real-time systems, new |
---|
| 16 | requirements, such as sharing data and global resources between |
---|
| 17 | processors, are introduced. This requires an efficient and |
---|
| 18 | reliable communications vehicle which allows all processors to |
---|
| 19 | communicate with each other as necessary. In addition, the |
---|
| 20 | ramifications of multiple processors affect each and every |
---|
| 21 | characteristic of a real-time system, almost always making them |
---|
| 22 | more complicated. |
---|
| 23 | |
---|
| 24 | RTEMS addresses these issues by providing simple and |
---|
| 25 | flexible real-time multiprocessing capabilities. The executive |
---|
| 26 | easily lends itself to both tightly-coupled and loosely-coupled |
---|
| 27 | configurations of the target system hardware. In addition, |
---|
| 28 | RTEMS supports systems composed of both homogeneous and |
---|
| 29 | heterogeneous mixtures of processors and target boards. |
---|
| 30 | |
---|
| 31 | A major design goal of the RTEMS executive was to |
---|
| 32 | transcend the physical boundaries of the target hardware |
---|
| 33 | configuration. This goal is achieved by presenting the |
---|
| 34 | application software with a logical view of the target system |
---|
| 35 | where the boundaries between processor nodes are transparent. |
---|
| 36 | As a result, the application developer may designate objects |
---|
| 37 | such as tasks, queues, events, signals, semaphores, and memory |
---|
| 38 | blocks as global objects. These global objects may then be |
---|
| 39 | accessed by any task regardless of the physical location of the |
---|
| 40 | object and the accessing task. RTEMS automatically determines |
---|
| 41 | that the object being accessed resides on another processor and |
---|
| 42 | performs the actions required to access the desired object. |
---|
| 43 | Simply stated, RTEMS allows the entire system, both hardware and |
---|
| 44 | software, to be viewed logically as a single system. |
---|
| 45 | |
---|
| 46 | @section Background |
---|
| 47 | |
---|
[169502e] | 48 | @cindex multiprocessing topologies |
---|
| 49 | |
---|
[ae68ff0] | 50 | RTEMS makes no assumptions regarding the connection |
---|
| 51 | media or topology of a multiprocessor system. The tasks which |
---|
| 52 | compose a particular application can be spread among as many |
---|
| 53 | processors as needed to satisfy the application's timing |
---|
| 54 | requirements. The application tasks can interact using a subset |
---|
| 55 | of the RTEMS directives as if they were on the same processor. |
---|
| 56 | These directives allow application tasks to exchange data, |
---|
| 57 | communicate, and synchronize regardless of which processor they |
---|
| 58 | reside upon. |
---|
| 59 | |
---|
| 60 | The RTEMS multiprocessor execution model is multiple |
---|
| 61 | instruction streams with multiple data streams (MIMD). This |
---|
| 62 | execution model has each of the processors executing code |
---|
| 63 | independent of the other processors. Because of this |
---|
| 64 | parallelism, the application designer can more easily guarantee |
---|
| 65 | deterministic behavior. |
---|
| 66 | |
---|
| 67 | By supporting heterogeneous environments, RTEMS |
---|
| 68 | allows the systems designer to select the most efficient |
---|
| 69 | processor for each subsystem of the application. Configuring |
---|
| 70 | RTEMS for a heterogeneous environment is no more difficult than |
---|
| 71 | for a homogeneous one. In keeping with RTEMS philosophy of |
---|
| 72 | providing transparent physical node boundaries, the minimal |
---|
| 73 | heterogeneous processing required is isolated in the MPCI layer. |
---|
| 74 | |
---|
| 75 | @subsection Nodes |
---|
| 76 | |
---|
[169502e] | 77 | @cindex nodes, definition |
---|
| 78 | |
---|
[ae68ff0] | 79 | A processor in a RTEMS system is referred to as a |
---|
| 80 | node. Each node is assigned a unique non-zero node number by |
---|
| 81 | the application designer. RTEMS assumes that node numbers are |
---|
[169502e] | 82 | assigned consecutively from one to the @code{maximum_nodes} |
---|
| 83 | configuration parameter. The node |
---|
[ae68ff0] | 84 | number, node, and the maximum number of nodes, maximum_nodes, in |
---|
| 85 | a system are found in the Multiprocessor Configuration Table. |
---|
| 86 | The maximum_nodes field and the number of global objects, |
---|
| 87 | maximum_global_objects, is required to be the same on all nodes |
---|
| 88 | in a system. |
---|
| 89 | |
---|
| 90 | The node number is used by RTEMS to identify each |
---|
| 91 | node when performing remote operations. Thus, the |
---|
| 92 | Multiprocessor Communications Interface Layer (MPCI) must be |
---|
| 93 | able to route messages based on the node number. |
---|
| 94 | |
---|
| 95 | @subsection Global Objects |
---|
| 96 | |
---|
[169502e] | 97 | @cindex global objects, definition |
---|
| 98 | |
---|
[ae68ff0] | 99 | All RTEMS objects which are created with the GLOBAL |
---|
| 100 | attribute will be known on all other nodes. Global objects can |
---|
| 101 | be referenced from any node in the system, although certain |
---|
| 102 | directive specific restrictions (e.g. one cannot delete a remote |
---|
| 103 | object) may apply. A task does not have to be global to perform |
---|
| 104 | operations involving remote objects. The maximum number of |
---|
| 105 | global objects is the system is user configurable and can be |
---|
| 106 | found in the maximum_global_objects field in the Multiprocessor |
---|
| 107 | Configuration Table. The distribution of tasks to processors is |
---|
| 108 | performed during the application design phase. Dynamic task |
---|
| 109 | relocation is not supported by RTEMS. |
---|
| 110 | |
---|
| 111 | @subsection Global Object Table |
---|
| 112 | |
---|
[169502e] | 113 | @cindex global objects table |
---|
| 114 | |
---|
[ae68ff0] | 115 | RTEMS maintains two tables containing object |
---|
| 116 | information on every node in a multiprocessor system: a local |
---|
| 117 | object table and a global object table. The local object table |
---|
| 118 | on each node is unique and contains information for all objects |
---|
| 119 | created on this node whether those objects are local or global. |
---|
| 120 | The global object table contains information regarding all |
---|
| 121 | global objects in the system and, consequently, is the same on |
---|
| 122 | every node. |
---|
| 123 | |
---|
| 124 | Since each node must maintain an identical copy of |
---|
| 125 | the global object table, the maximum number of entries in each |
---|
| 126 | copy of the table must be the same. The maximum number of |
---|
| 127 | entries in each copy is determined by the |
---|
| 128 | maximum_global_objects parameter in the Multiprocessor |
---|
| 129 | Configuration Table. This parameter, as well as the |
---|
| 130 | maximum_nodes parameter, is required to be the same on all |
---|
| 131 | nodes. To maintain consistency among the table copies, every |
---|
| 132 | node in the system must be informed of the creation or deletion |
---|
| 133 | of a global object. |
---|
| 134 | |
---|
| 135 | @subsection Remote Operations |
---|
| 136 | |
---|
[169502e] | 137 | @cindex MPCI and remote operations |
---|
| 138 | |
---|
[ae68ff0] | 139 | When an application performs an operation on a remote |
---|
| 140 | global object, RTEMS must generate a Remote Request (RQ) message |
---|
| 141 | and send it to the appropriate node. After completing the |
---|
| 142 | requested operation, the remote node will build a Remote |
---|
| 143 | Response (RR) message and send it to the originating node. |
---|
| 144 | Messages generated as a side-effect of a directive (such as |
---|
| 145 | deleting a global task) are known as Remote Processes (RP) and |
---|
| 146 | do not require the receiving node to respond. |
---|
| 147 | |
---|
| 148 | Other than taking slightly longer to execute |
---|
| 149 | directives on remote objects, the application is unaware of the |
---|
| 150 | location of the objects it acts upon. The exact amount of |
---|
| 151 | overhead required for a remote operation is dependent on the |
---|
| 152 | media connecting the nodes and, to a lesser degree, on the |
---|
| 153 | efficiency of the user-provided MPCI routines. |
---|
| 154 | |
---|
| 155 | The following shows the typical transaction sequence |
---|
| 156 | during a remote application: |
---|
| 157 | |
---|
| 158 | @enumerate |
---|
| 159 | |
---|
| 160 | @item The application issues a directive accessing a |
---|
| 161 | remote global object. |
---|
| 162 | |
---|
| 163 | @item RTEMS determines the node on which the object |
---|
| 164 | resides. |
---|
| 165 | |
---|
| 166 | @item RTEMS calls the user-provided MPCI routine |
---|
| 167 | GET_PACKET to obtain a packet in which to build a RQ message. |
---|
| 168 | |
---|
| 169 | @item After building a message packet, RTEMS calls the |
---|
| 170 | user-provided MPCI routine SEND_PACKET to transmit the packet to |
---|
| 171 | the node on which the object resides (referred to as the |
---|
| 172 | destination node). |
---|
| 173 | |
---|
| 174 | @item The calling task is blocked until the RR message |
---|
| 175 | arrives, and control of the processor is transferred to another |
---|
| 176 | task. |
---|
| 177 | |
---|
| 178 | @item The MPCI layer on the destination node senses the |
---|
| 179 | arrival of a packet (commonly in an ISR), and calls the |
---|
[75e22db] | 180 | @code{@value{DIRPREFIX}multiprocessing_announce} |
---|
| 181 | directive. This directive readies the Multiprocessing Server. |
---|
[ae68ff0] | 182 | |
---|
| 183 | @item The Multiprocessing Server calls the user-provided |
---|
| 184 | MPCI routine RECEIVE_PACKET, performs the requested operation, |
---|
| 185 | builds an RR message, and returns it to the originating node. |
---|
| 186 | |
---|
| 187 | @item The MPCI layer on the originating node senses the |
---|
[75e22db] | 188 | arrival of a packet (typically via an interrupt), and calls the RTEMS |
---|
| 189 | @code{@value{DIRPREFIX}multiprocessing_announce} directive. This directive |
---|
[ae68ff0] | 190 | readies the Multiprocessing Server. |
---|
| 191 | |
---|
| 192 | @item The Multiprocessing Server calls the user-provided |
---|
| 193 | MPCI routine RECEIVE_PACKET, readies the original requesting |
---|
| 194 | task, and blocks until another packet arrives. Control is |
---|
| 195 | transferred to the original task which then completes processing |
---|
| 196 | of the directive. |
---|
| 197 | |
---|
| 198 | @end enumerate |
---|
| 199 | |
---|
| 200 | If an uncorrectable error occurs in the user-provided |
---|
| 201 | MPCI layer, the fatal error handler should be invoked. RTEMS |
---|
| 202 | assumes the reliable transmission and reception of messages by |
---|
| 203 | the MPCI and makes no attempt to detect or correct errors. |
---|
| 204 | |
---|
| 205 | @subsection Proxies |
---|
| 206 | |
---|
[169502e] | 207 | @cindex proxy, definition |
---|
| 208 | |
---|
[ae68ff0] | 209 | A proxy is an RTEMS data structure which resides on a |
---|
| 210 | remote node and is used to represent a task which must block as |
---|
| 211 | part of a remote operation. This action can occur as part of the |
---|
[75e22db] | 212 | @code{@value{DIRPREFIX}semaphore_obtain} and |
---|
| 213 | @code{@value{DIRPREFIX}message_queue_receive} directives. If the |
---|
[ae68ff0] | 214 | object were local, the task's control block would be available |
---|
| 215 | for modification to indicate it was blocking on a message queue |
---|
| 216 | or semaphore. However, the task's control block resides only on |
---|
| 217 | the same node as the task. As a result, the remote node must |
---|
| 218 | allocate a proxy to represent the task until it can be readied. |
---|
| 219 | |
---|
| 220 | The maximum number of proxies is defined in the |
---|
| 221 | Multiprocessor Configuration Table. Each node in a |
---|
| 222 | multiprocessor system may require a different number of proxies |
---|
| 223 | to be configured. The distribution of proxy control blocks is |
---|
| 224 | application dependent and is different from the distribution of |
---|
| 225 | tasks. |
---|
| 226 | |
---|
| 227 | @subsection Multiprocessor Configuration Table |
---|
| 228 | |
---|
| 229 | The Multiprocessor Configuration Table contains |
---|
| 230 | information needed by RTEMS when used in a multiprocessor |
---|
| 231 | system. This table is discussed in detail in the section |
---|
| 232 | Multiprocessor Configuration Table of the Configuring a System |
---|
| 233 | chapter. |
---|
| 234 | |
---|
| 235 | @section Multiprocessor Communications Interface Layer |
---|
| 236 | |
---|
| 237 | The Multiprocessor Communications Interface Layer |
---|
| 238 | (MPCI) is a set of user-provided procedures which enable the |
---|
| 239 | nodes in a multiprocessor system to communicate with one |
---|
| 240 | another. These routines are invoked by RTEMS at various times |
---|
| 241 | in the preparation and processing of remote requests. |
---|
| 242 | Interrupts are enabled when an MPCI procedure is invoked. It is |
---|
| 243 | assumed that if the execution mode and/or interrupt level are |
---|
| 244 | altered by the MPCI layer, that they will be restored prior to |
---|
| 245 | returning to RTEMS. |
---|
| 246 | |
---|
[169502e] | 247 | @cindex MPCI, definition |
---|
| 248 | |
---|
[ae68ff0] | 249 | The MPCI layer is responsible for managing a pool of |
---|
| 250 | buffers called packets and for sending these packets between |
---|
| 251 | system nodes. Packet buffers contain the messages sent between |
---|
| 252 | the nodes. Typically, the MPCI layer will encapsulate the |
---|
| 253 | packet within an envelope which contains the information needed |
---|
| 254 | by the MPCI layer. The number of packets available is dependent |
---|
| 255 | on the MPCI layer implementation. |
---|
| 256 | |
---|
[169502e] | 257 | @cindex MPCI entry points |
---|
| 258 | |
---|
[ae68ff0] | 259 | The entry points to the routines in the user's MPCI |
---|
| 260 | layer should be placed in the Multiprocessor Communications |
---|
| 261 | Interface Table. The user must provide entry points for each of |
---|
| 262 | the following table entries in a multiprocessor system: |
---|
| 263 | |
---|
| 264 | @itemize @bullet |
---|
| 265 | @item initialization initialize the MPCI |
---|
| 266 | @item get_packet obtain a packet buffer |
---|
| 267 | @item return_packet return a packet buffer |
---|
| 268 | @item send_packet send a packet to another node |
---|
| 269 | @item receive_packet called to get an arrived packet |
---|
| 270 | @end itemize |
---|
| 271 | |
---|
[169502e] | 272 | A packet is sent by RTEMS in each of the following situations: |
---|
[ae68ff0] | 273 | |
---|
| 274 | @itemize @bullet |
---|
| 275 | @item an RQ is generated on an originating node; |
---|
| 276 | @item an RR is generated on a destination node; |
---|
| 277 | @item a global object is created; |
---|
| 278 | @item a global object is deleted; |
---|
| 279 | @item a local task blocked on a remote object is deleted; |
---|
| 280 | @item during system initialization to check for system consistency. |
---|
| 281 | @end itemize |
---|
| 282 | |
---|
| 283 | If the target hardware supports it, the arrival of a |
---|
| 284 | packet at a node may generate an interrupt. Otherwise, the |
---|
| 285 | real-time clock ISR can check for the arrival of a packet. In |
---|
[75e22db] | 286 | any case, the |
---|
| 287 | @code{@value{DIRPREFIX}multiprocessing_announce} directive must be called |
---|
[ae68ff0] | 288 | to announce the arrival of a packet. After exiting the ISR, |
---|
| 289 | control will be passed to the Multiprocessing Server to process |
---|
| 290 | the packet. The Multiprocessing Server will call the get_packet |
---|
| 291 | entry to obtain a packet buffer and the receive_entry entry to |
---|
| 292 | copy the message into the buffer obtained. |
---|
| 293 | |
---|
| 294 | @subsection INITIALIZATION |
---|
| 295 | |
---|
| 296 | The INITIALIZATION component of the user-provided |
---|
[75e22db] | 297 | MPCI layer is called as part of the @code{@value{DIRPREFIX}initialize_executive} |
---|
[ae68ff0] | 298 | directive to initialize the MPCI layer and associated hardware. |
---|
| 299 | It is invoked immediately after all of the device drivers have |
---|
| 300 | been initialized. This component should be adhere to the |
---|
| 301 | following prototype: |
---|
| 302 | |
---|
[61389eac] | 303 | @ifset is-C |
---|
[adee5979] | 304 | @findex rtems_mpci_entry |
---|
[ae68ff0] | 305 | @example |
---|
| 306 | @group |
---|
| 307 | rtems_mpci_entry user_mpci_initialization( |
---|
| 308 | rtems_configuration_table *configuration |
---|
| 309 | ); |
---|
| 310 | @end group |
---|
| 311 | @end example |
---|
[61389eac] | 312 | @end ifset |
---|
| 313 | |
---|
| 314 | @ifset is-Ada |
---|
| 315 | @example |
---|
[1b03eed] | 316 | NOT SUPPORTED FROM Ada BINDING |
---|
[61389eac] | 317 | @end example |
---|
| 318 | @end ifset |
---|
[ae68ff0] | 319 | |
---|
| 320 | where configuration is the address of the user's |
---|
| 321 | Configuration Table. Operations on global objects cannot be |
---|
| 322 | performed until this component is invoked. The INITIALIZATION |
---|
| 323 | component is invoked only once in the life of any system. If |
---|
| 324 | the MPCI layer cannot be successfully initialized, the fatal |
---|
| 325 | error manager should be invoked by this routine. |
---|
| 326 | |
---|
| 327 | One of the primary functions of the MPCI layer is to |
---|
| 328 | provide the executive with packet buffers. The INITIALIZATION |
---|
| 329 | routine must create and initialize a pool of packet buffers. |
---|
| 330 | There must be enough packet buffers so RTEMS can obtain one |
---|
| 331 | whenever needed. |
---|
| 332 | |
---|
| 333 | @subsection GET_PACKET |
---|
| 334 | |
---|
| 335 | The GET_PACKET component of the user-provided MPCI |
---|
| 336 | layer is called when RTEMS must obtain a packet buffer to send |
---|
| 337 | or broadcast a message. This component should be adhere to the |
---|
| 338 | following prototype: |
---|
| 339 | |
---|
[61389eac] | 340 | @ifset is-C |
---|
[ae68ff0] | 341 | @example |
---|
| 342 | @group |
---|
| 343 | rtems_mpci_entry user_mpci_get_packet( |
---|
| 344 | rtems_packet_prefix **packet |
---|
| 345 | ); |
---|
| 346 | @end group |
---|
| 347 | @end example |
---|
[61389eac] | 348 | @end ifset |
---|
| 349 | |
---|
| 350 | @ifset is-Ada |
---|
| 351 | @example |
---|
[1b03eed] | 352 | NOT SUPPORTED FROM Ada BINDING |
---|
[61389eac] | 353 | @end example |
---|
| 354 | @end ifset |
---|
[ae68ff0] | 355 | |
---|
| 356 | where packet is the address of a pointer to a packet. |
---|
| 357 | This routine always succeeds and, upon return, packet will |
---|
| 358 | contain the address of a packet. If for any reason, a packet |
---|
| 359 | cannot be successfully obtained, then the fatal error manager |
---|
| 360 | should be invoked. |
---|
| 361 | |
---|
| 362 | RTEMS has been optimized to avoid the need for |
---|
| 363 | obtaining a packet each time a message is sent or broadcast. |
---|
| 364 | For example, RTEMS sends response messages (RR) back to the |
---|
| 365 | originator in the same packet in which the request message (RQ) |
---|
| 366 | arrived. |
---|
| 367 | |
---|
| 368 | @subsection RETURN_PACKET |
---|
| 369 | |
---|
| 370 | The RETURN_PACKET component of the user-provided MPCI |
---|
| 371 | layer is called when RTEMS needs to release a packet to the free |
---|
| 372 | packet buffer pool. This component should be adhere to the |
---|
| 373 | following prototype: |
---|
| 374 | |
---|
[61389eac] | 375 | @ifset is-C |
---|
[ae68ff0] | 376 | @example |
---|
| 377 | @group |
---|
| 378 | rtems_mpci_entry user_mpci_return_packet( |
---|
| 379 | rtems_packet_prefix *packet |
---|
| 380 | ); |
---|
| 381 | @end group |
---|
| 382 | @end example |
---|
[61389eac] | 383 | @end ifset |
---|
| 384 | |
---|
| 385 | @ifset is-Ada |
---|
| 386 | @example |
---|
[1b03eed] | 387 | NOT SUPPORTED FROM Ada BINDING |
---|
[61389eac] | 388 | @end example |
---|
| 389 | @end ifset |
---|
[ae68ff0] | 390 | |
---|
| 391 | where packet is the address of a packet. If the |
---|
| 392 | packet cannot be successfully returned, the fatal error manager |
---|
| 393 | should be invoked. |
---|
| 394 | |
---|
| 395 | @subsection RECEIVE_PACKET |
---|
| 396 | |
---|
| 397 | The RECEIVE_PACKET component of the user-provided |
---|
| 398 | MPCI layer is called when RTEMS needs to obtain a packet which |
---|
| 399 | has previously arrived. This component should be adhere to the |
---|
| 400 | following prototype: |
---|
| 401 | |
---|
[61389eac] | 402 | @ifset is-C |
---|
[ae68ff0] | 403 | @example |
---|
| 404 | @group |
---|
| 405 | rtems_mpci_entry user_mpci_receive_packet( |
---|
| 406 | rtems_packet_prefix **packet |
---|
| 407 | ); |
---|
| 408 | @end group |
---|
| 409 | @end example |
---|
[61389eac] | 410 | @end ifset |
---|
| 411 | |
---|
| 412 | @ifset is-Ada |
---|
| 413 | @example |
---|
[1b03eed] | 414 | NOT SUPPORTED FROM Ada BINDING |
---|
[61389eac] | 415 | @end example |
---|
| 416 | @end ifset |
---|
[ae68ff0] | 417 | |
---|
| 418 | where packet is a pointer to the address of a packet |
---|
| 419 | to place the message from another node. If a message is |
---|
| 420 | available, then packet will contain the address of the message |
---|
| 421 | from another node. If no messages are available, this entry |
---|
| 422 | packet should contain NULL. |
---|
| 423 | |
---|
| 424 | @subsection SEND_PACKET |
---|
| 425 | |
---|
| 426 | The SEND_PACKET component of the user-provided MPCI |
---|
| 427 | layer is called when RTEMS needs to send a packet containing a |
---|
| 428 | message to another node. This component should be adhere to the |
---|
| 429 | following prototype: |
---|
| 430 | |
---|
[61389eac] | 431 | @ifset is-C |
---|
[ae68ff0] | 432 | @example |
---|
| 433 | @group |
---|
| 434 | rtems_mpci_entry user_mpci_send_packet( |
---|
| 435 | rtems_unsigned32 node, |
---|
| 436 | rtems_packet_prefix **packet |
---|
| 437 | ); |
---|
| 438 | @end group |
---|
| 439 | @end example |
---|
[61389eac] | 440 | @end ifset |
---|
| 441 | |
---|
| 442 | @ifset is-Ada |
---|
| 443 | @example |
---|
[1b03eed] | 444 | NOT SUPPORTED FROM Ada BINDING |
---|
[61389eac] | 445 | @end example |
---|
| 446 | @end ifset |
---|
[ae68ff0] | 447 | |
---|
| 448 | where node is the node number of the destination and packet is the |
---|
| 449 | address of a packet which containing a message. If the packet cannot |
---|
| 450 | be successfully sent, the fatal error manager should be invoked. |
---|
| 451 | |
---|
| 452 | If node is set to zero, the packet is to be |
---|
| 453 | broadcasted to all other nodes in the system. Although some |
---|
| 454 | MPCI layers will be built upon hardware which support a |
---|
| 455 | broadcast mechanism, others may be required to generate a copy |
---|
| 456 | of the packet for each node in the system. |
---|
| 457 | |
---|
[adee5979] | 458 | @c XXX packet_prefix structure needs to be defined in this document |
---|
| 459 | Many MPCI layers use the @code{packet_length} field of the |
---|
| 460 | @code{@value{DIRPREFIX}packet_prefix} portion |
---|
[ae68ff0] | 461 | of the packet to avoid sending unnecessary data. This is especially |
---|
| 462 | useful if the media connecting the nodes is relatively slow. |
---|
| 463 | |
---|
| 464 | The to_convert field of the MP_packet_prefix portion of the packet indicates |
---|
[adee5979] | 465 | how much of the packet (in @code{@value{DIRPREFIX}unsigned32}'s) may require |
---|
| 466 | conversion in a heterogeneous system. |
---|
[ae68ff0] | 467 | |
---|
| 468 | @subsection Supporting Heterogeneous Environments |
---|
| 469 | |
---|
[169502e] | 470 | @cindex heterogeneous multiprocessing |
---|
| 471 | |
---|
[ae68ff0] | 472 | Developing an MPCI layer for a heterogeneous system |
---|
| 473 | requires a thorough understanding of the differences between the |
---|
| 474 | processors which comprise the system. One difficult problem is |
---|
| 475 | the varying data representation schemes used by different |
---|
| 476 | processor types. The most pervasive data representation problem |
---|
| 477 | is the order of the bytes which compose a data entity. |
---|
| 478 | Processors which place the least significant byte at the |
---|
| 479 | smallest address are classified as little endian processors. |
---|
| 480 | Little endian byte-ordering is shown below: |
---|
| 481 | |
---|
| 482 | |
---|
| 483 | @example |
---|
| 484 | @group |
---|
| 485 | +---------------+----------------+---------------+----------------+ |
---|
| 486 | | | | | | |
---|
| 487 | | Byte 3 | Byte 2 | Byte 1 | Byte 0 | |
---|
| 488 | | | | | | |
---|
| 489 | +---------------+----------------+---------------+----------------+ |
---|
| 490 | @end group |
---|
| 491 | @end example |
---|
| 492 | |
---|
| 493 | Conversely, processors which place the most |
---|
| 494 | significant byte at the smallest address are classified as big |
---|
| 495 | endian processors. Big endian byte-ordering is shown below: |
---|
| 496 | |
---|
| 497 | @example |
---|
| 498 | @group |
---|
| 499 | +---------------+----------------+---------------+----------------+ |
---|
| 500 | | | | | | |
---|
| 501 | | Byte 0 | Byte 1 | Byte 2 | Byte 3 | |
---|
| 502 | | | | | | |
---|
| 503 | +---------------+----------------+---------------+----------------+ |
---|
| 504 | @end group |
---|
| 505 | @end example |
---|
| 506 | |
---|
| 507 | Unfortunately, sharing a data structure between big |
---|
| 508 | endian and little endian processors requires translation into a |
---|
| 509 | common endian format. An application designer typically chooses |
---|
| 510 | the common endian format to minimize conversion overhead. |
---|
| 511 | |
---|
| 512 | Another issue in the design of shared data structures |
---|
| 513 | is the alignment of data structure elements. Alignment is both |
---|
| 514 | processor and compiler implementation dependent. For example, |
---|
| 515 | some processors allow data elements to begin on any address |
---|
| 516 | boundary, while others impose restrictions. Common restrictions |
---|
| 517 | are that data elements must begin on either an even address or |
---|
| 518 | on a long word boundary. Violation of these restrictions may |
---|
| 519 | cause an exception or impose a performance penalty. |
---|
| 520 | |
---|
| 521 | Other issues which commonly impact the design of |
---|
| 522 | shared data structures include the representation of floating |
---|
| 523 | point numbers, bit fields, decimal data, and character strings. |
---|
| 524 | In addition, the representation method for negative integers |
---|
| 525 | could be one's or two's complement. These factors combine to |
---|
| 526 | increase the complexity of designing and manipulating data |
---|
| 527 | structures shared between processors. |
---|
| 528 | |
---|
| 529 | RTEMS addressed these issues in the design of the |
---|
| 530 | packets used to communicate between nodes. The RTEMS packet |
---|
| 531 | format is designed to allow the MPCI layer to perform all |
---|
| 532 | necessary conversion without burdening the developer with the |
---|
| 533 | details of the RTEMS packet format. As a result, the MPCI layer |
---|
| 534 | must be aware of the following: |
---|
| 535 | |
---|
| 536 | @itemize @bullet |
---|
| 537 | @item All packets must begin on a four byte boundary. |
---|
| 538 | |
---|
| 539 | @item Packets are composed of both RTEMS and application data. |
---|
| 540 | All RTEMS data is treated as thirty-two (32) bit unsigned |
---|
[f331481c] | 541 | quantities and is in the first @code{@value{RPREFIX}MINIMUM_UNSIGNED32S_TO_CONVERT} |
---|
[ae68ff0] | 542 | thirty-two (32) quantities of the packet. |
---|
| 543 | |
---|
| 544 | @item The RTEMS data component of the packet must be in native |
---|
| 545 | endian format. Endian conversion may be performed by either the |
---|
| 546 | sending or receiving MPCI layer. |
---|
| 547 | |
---|
| 548 | @item RTEMS makes no assumptions regarding the application |
---|
| 549 | data component of the packet. |
---|
| 550 | @end itemize |
---|
| 551 | |
---|
| 552 | @section Operations |
---|
[20515fc] | 553 | |
---|
[ae68ff0] | 554 | @subsection Announcing a Packet |
---|
| 555 | |
---|
[75e22db] | 556 | The @code{@value{DIRPREFIX}multiprocessing_announce} directive is called by |
---|
[ae68ff0] | 557 | the MPCI layer to inform RTEMS that a packet has arrived from |
---|
| 558 | another node. This directive can be called from an interrupt |
---|
| 559 | service routine or from within a polling routine. |
---|
| 560 | |
---|
| 561 | @section Directives |
---|
| 562 | |
---|
| 563 | This section details the additional directives |
---|
| 564 | required to support RTEMS in a multiprocessor configuration. A |
---|
| 565 | subsection is dedicated to each of this manager's directives and |
---|
| 566 | describes the calling sequence, related constants, usage, and |
---|
| 567 | status codes. |
---|
| 568 | |
---|
[169502e] | 569 | @c |
---|
| 570 | @c |
---|
| 571 | @c |
---|
[ae68ff0] | 572 | @page |
---|
| 573 | @subsection MULTIPROCESSING_ANNOUNCE - Announce the arrival of a packet |
---|
| 574 | |
---|
[169502e] | 575 | @cindex announce arrival of package |
---|
| 576 | |
---|
[ae68ff0] | 577 | @subheading CALLING SEQUENCE: |
---|
| 578 | |
---|
[61389eac] | 579 | @ifset is-C |
---|
[169502e] | 580 | @findex rtems_multiprocessing_announce |
---|
[ae68ff0] | 581 | @example |
---|
| 582 | void rtems_multiprocessing_announce( void ); |
---|
| 583 | @end example |
---|
[61389eac] | 584 | @end ifset |
---|
| 585 | |
---|
| 586 | @ifset is-Ada |
---|
| 587 | @example |
---|
[1b03eed] | 588 | NOT SUPPORTED FROM Ada BINDING |
---|
[61389eac] | 589 | @end example |
---|
| 590 | @end ifset |
---|
[ae68ff0] | 591 | |
---|
| 592 | @subheading DIRECTIVE STATUS CODES: |
---|
| 593 | |
---|
| 594 | NONE |
---|
| 595 | |
---|
| 596 | @subheading DESCRIPTION: |
---|
| 597 | |
---|
| 598 | This directive informs RTEMS that a multiprocessing |
---|
| 599 | communications packet has arrived from another node. This |
---|
| 600 | directive is called by the user-provided MPCI, and is only used |
---|
| 601 | in multiprocessor configurations. |
---|
| 602 | |
---|
| 603 | @subheading NOTES: |
---|
| 604 | |
---|
| 605 | This directive is typically called from an ISR. |
---|
| 606 | |
---|
| 607 | This directive will almost certainly cause the |
---|
| 608 | calling task to be preempted. |
---|
| 609 | |
---|
| 610 | This directive does not generate activity on remote nodes. |
---|