text:
US 6633971 B2 Abstract A method for forwarding data within a pipeline of a pipelined data processor having a plurality of execution pipeline stages where each stage accepts a plurality of operand inputs and generates a result. The result generated by each execution pipeline stage is selectively coupled to an operand input of one of the execution pipeline stages.
Claims(24) 1. A method for forwarding data within a pipeline of a pipelined data processor comprising the steps of:
providing a plurality of execution pipeline stages where each stage accepts a plurality of operand inputs and generates a result;
copying the results generated by each execution pipeline stage to an entry of a single pipefile, the entry corresponding to the execution pipeline stage; and
selectively coupling the result generated by each execution pipeline stage to an operand input of one of the execution pipeline stages.
2. The method of
3. The method of
4. The method of
5. The method of
6. A data processor comprising:
a plurality of execution pipeline stages where each stage accepts a plurality of operand inputs and generates a result;
a results bus directly distributing the generated results from each of the execution pipeline stages throughout the plurality of pipeline stages;
a pipefile coupled to the results bus to selectively receive the generated results; and
a multiplexor associated with each execution pipeline stage operative to selectively couple the results bus to an operand input of the associated execution pipeline stages.
7. The data processor of
8. The data processor of
9. The data processor of
a pipefile coupled to the results bus and operative to store the data on the result bus at substantially the same time that the multiplexor selectively couples the result bus to an operand input.
10. A method of forwarding data between multiple execution stages forming an execution pipeline of a data processor, comprising the steps of:
applying multiple operands of an instruction to the execution pipeline to produce a result from each of the multiple execution stages;
each of the multiple execution stages producing a result;
selectively coupling the result from each of the multiple execution stages to an entry of a pipefile corresponding to such execution stage;
selectively coupling the result from each of the multiple execution stages to a register in a general register file; and
selectively coupling an entry of the pipefile and a register in the general register file to a first one of the multiple execution stages of the execution pipeline.
11. The method of
12. The method of
13. A method of forwarding data between multiple execution stages forming an execution pipeline of a data processor, comprising the steps of:
providing multiple operands to the execution pipeline for performing an operation whereby each of the multiple execution stages produces a result;
copying the result produced by each of the multiple execution stages to a corresponding entry of a single pipefile; and
selectively coupling the content of the single pipefile to each of the multiple execution stages.
14. The method of
15. A data processor, including:
an execution pipeline, comprising a plurality of execution stages, including a first execution stage, coupled to receive operands of an instruction for performing operations dictated by said instruction;
a single pipefile coupled to receive output from the execution stages; and
a memory coupled via the pipefile to each of the plurality of execution stages for receiving and storing a result at a memory entry corresponding to such execution stage.
16. The data processor of
17. The data processor of
18. The data processor of
19. The data processor of
20. An execution pipeline of a data processor, including
a plurality of serial connected pipeline execution stages, including an input pipeline execution stage that receives one or more operands for performing an operation, each of the plurality of pipeline execution stages having a result output directly coupled to an input of each of the other of the plurality of pipeline execution stages, each result output further selectively coupled to a pipefile.
21. The execution pipeline of
22. The execution pipeline of
23. A method of forwarding result data between a plurality of serial connected execution stages of an execution pipeline of a data processor, including the steps of:
providing one or more operands to a first one of the plurality of execution stages, the each execution stages operating to perform an operation and to produce a result;
selectively coupling the result produced by each execution stage to a corresponding entry of a pipefile and to a register of a register file for storage; and
selectively coupling an entry of the pipefile and a register of the register file to an input of each of the execution stages.
24. The method of
Description 1. Field of the Invention The present invention relates in general to microprocessors and, more particularly, to a system, method, and mechanism providing data forwarding in a pipeline processor. 2. Relevant Background Computer programs comprise a series of instructions that direct a data processing mechanism to perform specific operations on data. These operations including loading data from memory, storing data to memory, adding, multiplying, and the like. Data processors, including microprocessors, microcontrollers, and the like include a central processing unit (CPU) comprising one or more functional units that perform various tasks. Typical functional units include a decoder, an instruction cache, a data cache, an integer execution unit, a floating point execution unit, a load/store unit, and the like. A given program may run on a variety of data processing hardware. Early data processors executed only one instruction at a time. Each instruction was executed to completion before execution of a subsequent instruction was begun. Each instruction typically requires a number of data processing operations and involves multiple functional units within the processor. Hence, an instruction may consume several clock cycles to complete. In serially executed processors each functional unit may be busy during only one step, and idle during the other steps. The serial execution of instructions results in the completion of less than one instruction per clock cycle. As used herein the term �data processor� includes complex instruction set computers (CISC), reduced instruction set computers (RISC) and hybrids. A data processor may be a stand alone central processing unit (CPU) or an embedded system comprising a processor core integrated with other components to form a special purpose data processing machine. The term �data� refers to a digital or binary information that may represent memory addresses, data, instructions, or the like. In response to the need for improved performance several techniques have been used to extend the capabilities of these early processors including pipelining, superpipelining, and superscaling. Pipelined architectures attempt to keep all the functional units of a processor busy at all times by overlapping execution of several instructions. Pipelined designs increase the rate at which instructions can be executed by allowing a new instruction to begin execution before a previous instruction is finished executing. A simple pipeline may have only five stages whereas an extended pipeline may have ten or more stages. In this manner, the pipeline hides the latency associated with the execution of any particular instruction. The goal of pipeline processors is to execute multiple instructions per cycle (IPC). Due to pipeline hazards, actual throughput is reduced. Pipeline hazards include structural hazards, data hazards, and control hazards. Structural hazards arise when more than one instruction in the pipeline requires a particular hardware resource at the same time (e.g., two execution units requiring access to a single ALU resource in the same clock cycle). Data hazards arise when an instruction needs as input the output of an instruction that has not yet produced that output. Control hazards arise when an instruction changes the program counter (PC) because execution cannot continue until the target instruction from the new PC is fetched. When hazards occur, the processor must stall or place �bubbles� (e.g., NOPs) in the pipeline until the hazard condition is resolved. This increases latency and decreases instruction throughput. As pipelines become longer, the likelihood of hazards increases. Hence, an effective mechanism for handling hazard conditions is important to achieving the benefits of deeper pipelines. Another goal of many processors is to control the power used by the processor. Many applications, particularly those directed at mobile or battery operated environments, require low power usage. The execution pipelines of a computer consume a significant amount of power. Power consumption is largely caused by moving data between registers, files, and execution units. As data paths become wider, the power consumed to move the data increases. Hence, in order to execute instructions efficiently at a high throughput within a pipeline it is important to coordinate and control the flow of instructions, operations, and data within the execution pipeline. The order and manner in which the operands and results of these instructions are made available to each other within the execution pipeline is of critical importance to the throughput of the pipeline. Briefly stated, the present invention involves A method for forwarding data within a pipeline of a pipelined data processor having a plurality of execution pipeline stages where each stage accepts a plurality of operand inputs and generates a result. The result generated by each execution pipeline stage is selectively coupled to an operand input of one of the execution pipeline stages. The present invention also involves a data processor having a plurality of execution pipeline stages where each stage accepts a plurality of operand inputs and generates a result. A results bus distributes the generated results from each of the execution pipeline stages throughout the plurality of pipeline stages. A multiplexor associated with each execution pipeline stage operative to selectively couple the results bus to an operand input of the associated execution pipeline stages. The foregoing and other features, utilities and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention as illustrated in the accompanying drawings. FIG. 1 shows in block diagram form a computer system incorporating an apparatus and system in accordance with the present invention; FIG. 2 shows a processor in block diagram form incorporating the apparatus and method in accordance with the present invention; FIG. 3 illustrates a CPU core useful in the implementation of the processor and system shown in FIG. 1 and FIG. 2 in accordance with the present invention; FIG. 4 shows an instruction fetch unit in which features of the present invention are embodied in a particular implementation; FIG. 5 illustrates an exemplary execution pipeline in accordance with a specific embodiment of the present invention; FIG. 6 illustrates comparative pipeline timing for the execution pipeline shown in FIG. 5; FIG. 7A and FIG. 7B show exemplary a snapshot register entries in accordance with embodiments of the present invention; and FIG. 8 shows an operand multiplexing mechanism in accordance with an embodiment of the present invention; and FIG. 9 schematically illustrates internal operand forwarding mechanism in accordance with the present invention. The present invention involves data forwarding in a pipeline data processor such as an embedded processor, a microprocessor, or microcontroller. Data forwarding involves making internal data objects and results generated by instructions that have not yet completed execution available for use by other instructions. This process involves both detecting when data forwarding will be possible and then configuring the execution pipeline stage hardware to use data forwarded from other pipeline stage result(s) rather than from instruction-specified registers and resources. In particular, data forwarding is used to detect and avert hazard conditions that might stall or slow the pipeline, and configure data paths to forwards operands efficiently amongst execution units, handle exception conditions efficiently and precisely, and similar control operations. Any system is usefully described as a collection of processes or modules communicating via data objects or messages as shown in FIG. 1. The modules may be large collections of circuitry whose properties are somewhat loosely defined, and may vary in size or composition significantly. The data object or message is a communication between modules that make up the system. To actually connect a module within the system it is necessary to define an interface between the system and the component module. The present invention is illustrated in terms of a media system 100 shown in FIG. 1. Media processor 100 comprises, for example, a �set-top box� for video processing, a video game controller, a digital video disk (DVD) player, and the like. Essentially, system 100 is a special purpose data processing system targeted at high throughput multimedia applications. Features of the present invention are embodied in processor 101 that operates to communicate and process data received through a high speed bus 102, peripheral bus 104, and memory bus 106. Video controller 105 receives digital data from system bus 102 and generates video signals to display information on an external video monitor, television set, and the like. The generated video signals may be analog or digital. Optionally, video controller may receive analog and/or digital video signals from external devices as well. Audio controller 107 operates in a manner akin to video controller 105, but differs in that it controls audio information rather than video. Network I/O controller 109 may be a conventional network card, ISDN connection, modem, and the like for communicating digital information. Mass storage device 111 coupled to high speed bus 102 may comprise magnetic disks, tape drives, CDROM, DVD, banks of random access memory, and the like. A wide variety of random access and read only memory technologies are available and are equivalent for purposes of the present invention. Mass storage 111 may include computer programs and data stored therein. In a particular example, high speed bus 102 is implemented as a peripheral component interconnect (PCI) industry standard bus. An advantage of using an industry standard bus is that a wide variety of expansion units such as controller's 105, 107, 109 and 111 are readily available. Peripherals 113 include a variety of general purpose I/O devices that may require lower bandwidth communication than provided by high speed bus 102. Typical I/O devices include read only memory (ROM) devices such as game program cartridges, serial input devices such as a mouse or joystick, keyboards, and the like. Processor 101 includes corresponding serial port(s), parallel port(s), printer ports, and external timer ports to communicate with peripherals 113. Additionally, ports may be included to support communication with on-board ROM, such as a BIOS ROM, integrated with processor 101. External memory 103 is typically required to provide working storage for processor 101 and may be implemented using dynamic or static RAM, ROM, synchronous DRAM, or any of a wide variety of equivalent devices capable of storing digital data in a manner accessible to processor 101. Processor 101 is illustrated in a greater detail in the functional diagram of FIG. 2. One module in a data processing system is a central processor unit (CPU) core 201. The CPU core 201 includes, among other components execution resources (e.g., arithmetic logic units, registers, control logic) and cache memory. These functional units, discussed in greater detail below, perform the functions of fetching instructions and data from memory, preprocessing fetched instructions, scheduling instructions to be executed, executing the instructions, managing memory transactions, and interfacing with external circuitry and devices. CPU core 201 communicates with other components shown in FIG. 2 through a system bus 202. In the preferred implementation system bus 202 is a high-speed network bus using packet technology and is referred to herein as a �super highway�. Bus 202 couples to a variety of system components. Of particular importance are components that implement interfaces with external hardware such as external memory interface unit 203, PCI bridge 207, and peripheral bus 204. The organization of interconnects in the system illustrated in FIG. 2 is guided by the principle of optimizing each interconnect for its specific purpose. The bus system 202 interconnect facilitates the integration of several different types of sub-systems. It is used for closely coupled subsystems which have stringent memory latency/bandwidth requirements. The peripheral subsystem bus 204 supports bus standards which allow easy integration of hardware of types indicated in reference to FIG. 1 through interface ports 213. PCI bridge 207 provides a standard interface that supports expansion using a variety of PCI standard devices that demand higher performance that available through peripheral port 204. The system bus 202 may be outfitted with an expansion port which supports the rapid integration of application modules without changing the other components of system 101. External memory interface 203 provides an interface between the system bus 202 and the external main memory subsystem 103 (shown in FIG. 1). The external memory interface comprises a port to system bus 202 and a DRAM controller. The CPU core 201 can be represented as a collection of interacting functional units as shown in FIG. 3. These functional units, discussed in greater detail below, perform the functions of fetching instructions and data from memory, preprocessing fetched instructions, scheduling instructions to be executed, executing the instructions, managing memory transactions, and interfacing with external circuitry and devices. A bus interface unit (BIU) 301 handles all requests to and from the system bus 202 and external memory. An instruction flow unit (IFU) 303 is the front end of the CPU pipe and controls fetch, predecode, decode, issue and branch operations in the preferred embodiment. In accordance with the preferred embodiment, IFU 303 includes a pipe control unit 401 (shown in FIG. 4) that implements features of the present invention. However, it is contemplated that the inventive features of the present invention may be usefully embodied in a number of alternative processor architectures that will benefit from the performance features of the present invention. Accordingly, these alternative embodiments are equivalent to the particular embodiments shown and described herein. An execution unit (IEU) 305 handles all integer and multimedia instructions. The main CPU datapath includes an instruction cache unit (ICU) 307 implements an instruction cache (Icache not shown) and an instruction translation lookaside buffer (ITLB, not shown). Load store unit (LSU) 309 handles all memory instructions. A data cache control unit (DCU) 311 includes a data cache (Dcache, not shown) and a data translation lookaside buffer (DTLB, not shown). Although the present invention preferably uses separate data and instruction caches, it is contemplated that a unified cache can be used with some decrease in performance. In a typical embodiment, the functional units shown in FIG. 2, and some or all of cache memory 105 may be integrated in a single integrated circuit, although the specific components and integration density are a matter of design choice selected to meet the needs of a particular application. FIG. 4 shows hardware resources within IFU 303 including a pipe control unit 401 in accordance with the present invention. FIG. 4 shows a simplified IFU block diagram with the internal blocks as well as the external interfacing units. As shown in FIG. 4, IFU 303 can be divided into the following functional blocks according to their functions: the instruction cache control unit (ICC) 413, the fetch unit (FE) 403, the branch unit (BR) 411, the decode unit 405, the pipe control unit 401, and the operand file unit comprising register file 407 and pipe file 409. IFU 303 functions as the sequencer of the CPU core 201 in accordance with the present invention. It coordinates the flow of instructions and data within the core 201 as well as merges the external events with the core internal activities. Its main functions are to fetch instructions from ICU 307 using fetch unit 403 and decode the instructions in decoder 405. IFU 303 checks for instruction inter-dependency, reads the operands from the register file 407 and sends the decoded instructions and the operands to the execution units (e.g., IEU 305, and LSU 309). In addition, IFU 303 couples to BIU 301 on instruction cache misses to fill the instruction cache within ICU 307 with the missing instructions from external memory. Because of the sequencing role within the CPU core 201, IFU 303 interfaces with almost every other functional unit. The interface between IFU 303 and BIU 301 initiates the loading of instructions into the instruction cache. The interface between IFU 303 and ICU 307 provides the flow of instructions for execution. The interface between IFU 303 and IEU 305 and LSU 309 provides the paths for sending/receiving instructions, operands, results, as well as the control signals to enable the execution of instructions. In addition to these interfaces, IFU 303 may also receive external interrupt signals from an external interrupt controller (shown in FIG. 2), which samples and arbitrates external interrupts. IFU 303 will then arbitrate the external interrupts with internal exceptions and activates the appropriate handler to take care of the asynchronous events. Pipe file 409 operates to collect results from the execution units, and writes them back to the register file 407. Once instructions are decoded, pipe control unit 401 monitors their execution through the remaining pipe stages. The main function of pipe control unit 401 is to ensure that instructions are executed smoothly and correctly that (i) instructions will be held in the decode stage until the source operands are ready or can be ready when needed, (ii) that synchronization and serialization requirements imposed by the instruction as well as internal/external events are observed, and (iii) that data operands/interim results are forwarded correctly. To simplify the pipe control logic, the pipe control unit 401 makes several observations and assumptions with respect to instruction execution. One of the assumptions is that none of IEU 305 instructions can cause an exception and all of them flow through the pipe stages deterministically. This assumption allows the pipe control unit 401 to view IEU 305 as a complex data operation engine that doesn't need to know where the input operands are coming from and where the output results are going to. All the data forwarding and hazard detection logic can then be lumped into the pipe control unit 401 using the same simple mechanism. To accommodate for the non-deterministic operations in the LSU 309, some modifications are then made to this simple mechanism. The modifications, however, are specifically targeted at the idiosyncrasies of the LSU pipeline, and should cause minimal overhead. Another major function of the pipe control unit 401 is to handle non-sequential events such as instruction exceptions, external interrupts, resets, etc. Under normal execution condition, this part of the pipe control unit 401 is always in the idle state. It wakes up when an event occurs. The pipe control unit 401 receives the external interrupt/reset signals from the external interrupt controller (shown in FIG. 2). It receives internal exceptions from many parts of the CPU core 201. In either case, the pipe control unit 401 will clean up the pipeline, and then informs the branch unit 411 to save the core state and branches to the appropriate handler. When multiple exceptions and interrupt occur simultaneously, the pipe control unit 401 arbitrates between them according to the architecturally defined priority. The pipe control unit 401 also looks at internal configuration and control registers to determine whether and when an interrupt or exception should be blocked. The operand file unit implements the architecturally defined general purpose register file 407. In addition, it also implements a limited version of a reorder buffer called �pipe file� 409 for storing and forwarding interim results that are yet to be committed to architectural registers. Because CPU core 201 is principally directed at in-order execution, there is only a small window of time that execution results may be produced out-of-order. The present invention takes advantage of this property and implements a simplified version of the reorder buffer that allows interim results to be forwarded as soon as they are produced, while avoiding the expensive tag passing/matching mechanism usually associated with a reorder buffer. The operand file implements the data path portion of this pipe file. The control is implemented in the pipe control unit 401. FIG. 5 and FIG. 6 illustrate an example execution pipeline in accordance with the present invention. The particular example is a scalar (i.e., single pipeline), single issue machine. The implementation in FIG. 5 and FIG. 6 includes three execution stages. Many instructions however execute in a single cycle. The present invention implements features to enable comprehensive forwarding within the pipeline to achieve a high instruction throughput. In the pre-decode stage 503 the instruction cache access which was initiated in the previous cycle is completed and the instruction is returned to IFU 303 where it can be latched by mid-cycle. An instruction may spend from 1 to n cycles in stage 503 depending on downstream pipeline instructions. In the second half of stage 503, some pre-decoding of the instruction will be carried out. Decode stage 505 handles the full instruction decode, operand dependency checks and register file read and instruction issue to the execution units. The first execution stage 507 implements the execution of all single cycle integer instructions as well as the address calculation for memory and branch instructions. The second execution stage 509 implements the second cycle of execution for all multicycle integer/multimedia instructions. Additionally it corresponds to a second cycle for load instructions. The third execution stage 511 implements the third cycle of execution for multicycle integer/multimedia instructions and a completion cycle for load instructions. Writeback stage 513 is where architectural state modified by an instruction (e.g general purpose register, program counter etc.) is updated. The exception status of the instruction arriving in this stage or any external exception can prevent the update in this stage. The pipe control unit 401 performs a number of operations in handling the instruction flow. An important feature of the pipe control unit 401 is the pipeline snapshot file 415 (shown in FIG. 4) implemented within pipe control unit 401. Snapshot file 415 may be implemented as a lookup table having a table entry 701 (shown in FIG. 7) corresponding to each execution stage in the pipeline. The snapshot file 415 provides a central resource for all pipeline control operations such as dependency checks, operand forwarding, exception handling, and the like. In a particular implementation, snapshot file 415 includes four entries corresponding to the three execution pipeline stages and the write back pipeline stage. FIG. 7A and FIG. 7B show exemplary snapshot files 701 and 702 indicating entries holding metadata describing the instruction execution state at the corresponding pipe stage. As instructions move from one stage to another, their associated snapshot entry moves to the corresponding snapshot entry 701 or 702. The contents of each snapshot entry 701 may be varied to meet the needs of a particular application. The specific examples shown in FIG. 7 correspond to pipeline control operations described hereinbelow. The essential functionality of examples 701 and 702 are similar although the implementation of that essential functionality differs between the examples. In comparing the examples, snapshot file 701 does not include a �STAGE� entry as that is implied by the index of the entry whereas example 702 includes an explicit STAGE entry. The single STAGE_RDY entry of FIG. 7B is implemented using three separate entries (E1_RESULT, E2_RESULT and E3_RESULT) in the example of FIG. 7A. The fields have the function generally described in the figures and additional or fewer fields may be added to meet the needs of a particular application. In operation, the snapshot register may be used by the pipeline control 401 to perform a number of parallel checks to classify the instruction currently being processed by the decoder 405. For example, the three potential operand register fields of the instruction word are checked against the existing pipe snapshot to detect data dependency, forwarding dependence, write-after-write hazard, and write-after-write for an accumulating-type instruction. Data dependency checking is performed by comparing the operand register specifiers of the instruction in decode against the register destinations marked to be written by each subsequent pipeline stage. If there is a match and the data will not be ready in this stage then there is a true data dependency that is resolved by, for example, stalling the instruction currently within the decode stage. Similarly, forwarding dependency checking is performed by comparing Rdest to determine if the result upon which the decoder instruction depends will be ready in the matched stage (forward from the result bus) or a previous stage (implying forward from the pipefile). A write-after-write hazard is indicated when an operand register specifier matches on more than one entry. In this case, the dependency can be resolved if the data can be forwarded from the correct (i.e., earlier) conflicting pipeline stage. Accordingly, pipe control can determine to control the forwarding from the earlier stage which matches. Using the same mechanism, the pipe control unit 401 can easily generate control for the internal forwarding of the IEU 305 by simply extending the metadata contained in snapshot files 701 and 702. When there is an instruction of the IEU-internal forwarding class (e.g., an accumulating-type instruction) in the first or second execution stages 507 or 509, the register destination of this instruction is checked against the register destination of an earlier instruction in the third execution stage 511. If a match is found and the instruction in the third execution stage 511 is of the same class, the pipe control unit 401 will generate the proper internal forwarding select signals to forward the third stage result to the first or second stage 507 or 509. For a hazard to actually be detected one of the source registers of the instruction must be valid and must match against a valid register destination in the snapshot file. Hazard detection of the preferred implementation only detects general purpose register dependencies. Though the snapshot file also stores control register destinations, these are not marked as valid and therefore do not show up in the dependency checks. However, alternative implementations could implement control checks using snapshot files 701 and 702 by adding one additional field. Under normal conditions once an instruction has been issued to an execution unit its entry will progress through each stage of the snapshot file on each clock edge. At the beginning of each execution stage the control for writing the result to the pipefile is generated. This is determined by checking the E1_RESULT, E2_RESULT, and E3_RESULT fields of the current execution stage. For example, if E1_RESULT field is set for the instruction executing in the EXE_1 stage 507, the result from EXE_1 stage 507 will then be written into the pipefile entry indexed by the PIPE_FILE_ENTRY field. Similarly, the result from the EXE_2 and EXE_3 stages will be written into the pipefile 409 when the E2_RESULT and E3_RESULT fields of the corresponding snapshot file entries are set. The write into pipefile 409 will occur even if the EXCEPTION field in snapshot file 702 is set. This is to allow transportation data for exceptions back to the branch unit. Once an instruction reaches write-back, the rdest_valid field also determines if the contents of the pipefile is written back to the architectural register file. Once in write-back, if no exception has occurred, the instruction has completed. An important feature of the present invention involves handling internal operand forwarding within the pipeline. Because the snapshot entry 701 indicates which pipe stage will produce a result to the pipefile 409, subsequent instructions can reliably use the interim result from the pipefile 409 before it is committed to architectural state. By enabling operand bypass between stages a significant percentage of data hazards can be avoided. This process is called internal operand forwarding. When decode indicates that it has a valid instruction the pipe control block determines from the instruction code the source of the operands for the instruction. The present invention enables an operand can be sourced from, for example: Register operands; Indirectly forwarded operands through the three pipefile entries; Directly forwarded operands from the result busses of the associated with the instruction execution pipe stages; The extended immediate field from the instruction; The program counter; The contents of an instruction address register (IAR); The contents of a control register; and A tied low constant field; The above gives up to 12 possible sources of input to some operand. FIG. 8 illustrates an exemplary operand multiplexing (�muxing�) mechanism that enables rich sharing of operands within the pipeline. The mechanism shown in FIG. 8 is distributed throughout pipe control unit 401 as described below. The operand multiplexor mechanism of FIG. 8 produces three choices (e.g., IFU_SRC1, IFU_SRC2, IFU_SRC3) for the source operands provided to the first execution stage 507. Each execution stage produces a result (labeled EXE_1, EXE_2, and EXE_3 in FIG. 8) that may be used as a source operand input to the first execution stage 507. Execution stage 507 is associated with a multiplexors 809 a-809 c for selecting up to three source operands from those available. The specific examples given herein are for purposes of explanation and understanding, and are not a limitation on the actual implementation. It should also be understood that execution stage 507, 509 and 511 shown in FIG. 8 are representative of all of the hardware resources used in that execution stage as defined by the processor microarchitecture. An execution stage is physically implemented using the hardware resources such as those shown in FIG. 3. The outputs of multiplexors 809 are physically coupled to each of the hardware resources that will use the source operands during its operation. The multiplexing of these operand sources in the particular example is distributed in the following way: The program counter (PC), instruction address registers, and control register contents are pre-muxed in the branch unit using multiplexors 801 and 803. All these inputs are available at the start of the cycle. The decode constant extracted from the instruction and possibly tied high zeroes are pre-muxed in the decode stage using multiplexor 811. The outputs of the pipefile 409 are muxed with the program counter data and decode constant data respectively in multiplexors 805 and 813. The register file contents are muxed with the pipefile outputs using multiplexors 807, 815, and 821 to produce source operands which are distributed down the execution datapath (IFU_SRC1, IFU_SRC2, IFU_SRC3 in FIG. 8). Forwarding of completing results is done locally within the execution datapath. As the result is being driven back up the datapath from the various stages of execution (imu_result_exl,_ex2 and _ex3), the result taps back into the multiplexors 809 at the input to the execution sub-units. The result is also driven back up to the pipefile 409 for ultimate storage in the register file 407. Pipe control unit 401 controls the selection of the multiplexor 809 latches. The LSU ex3 result is muxed with the output of the IEU ex3 result (from the multiplier). Internally IEU 305 multiplexes several results into the IEU_EXE3 result. In general, all results produced in pipe stage 511 are multiplexed onto EXE_3 result bus line. This is also controlled by the pipe control unit 401. In this manner, pipe control unit 401 generates the control signals for multiplexors and execution stage resources. This enables the source operand inputs used by each execution stage to be selected from among a plurality of possible inputs. Of particular significance is that each source operand can be forwarded from the interim results stored in the pipefile if valid results are available in the pipefile. This is useful in handling data hazards in a manner that limits the need to stall the pipeline or fill the pipeline with bubbles while data dependencies resolve. The particular choice and distribution of operand sources can include more or fewer sources to meet the needs of a particular application and unless specified otherwise herein the examples are provided for example purposes only. FIG. 9 schematically illustrates the execution stages of a pipeline and the operand sources for each stage. Each execution stage (EXE_1, EXE_2 and EXE_3) may generate a result. The specific stage that generates a result for any given instruction will vary from instruction-to-instruction, but is preferably indicated in the �stage_rdy� field of the snapshot file entry 702 or the E1_RESULT, E2_RESULT and E3_RESULT fields described hereinbefore. Each source operand can be taken from the execution unit's own result output. FIG. 9 shows an operand bus comprising IFU_SRCI, IFU_SRC2 and IFU_SRC3 (determined as shown in FIG. 8) and a results bus 906 comprising EXE_1_RESULT, EXE_2_RESULT and EXE_3_RESULT. The results bus 906 carries results to appropriate entries in pipefile 409. In the embodiment shown in FIG. 9 each execution stage corresponds to a specific entry in the pipe file 409 (e.g., EXE_2 corresponds to pipefile entry 409A, EXE_3 stage 509 corresponds to entry 409B). Results are written from the result bus into pipefile 409 according to the �stage_rdy�value in the snapshot register (FIG. 7A) or the El RESULT through E3_RESULT entries (FIG. 7B) as described hereinbefore. Pipefile 409A takes the EXE_1 result and can forward its contents when the instruction that produces the result is in the EXE_2 stage. Similarly, pipefile entry 409B takes the EXE_2 result and 409C takes the EXE_3 result respectively. Otherwise, results are moved sequentially from entry 409A to 409B to 409C. Entry 409C corresponds to the write back pipe stage. Assuming the snapshot register entry 701 corresponding to the instruction in the write back stage is valid and does not indicate an exception, the value stored in pipefile stage 409 is copied to the appropriate register in register file 407. Significantly, the operands for each execution stage can be selected from either the operand bus or the results bus. Hence, a result that is ready in EXE_1 will be driven onto the EXE_1_RESULT line and can be used as an operand on the following cycle in the second and third execution stages before being written to either register file 407 or the pipefile 409. Similarly, a result determined in EXE_3 can be used on the next clock cycle as an operand for an instruction executing in the first execution stage (EXE_1). This enables the instruction to be issued to EXE_1 without delays or pipeline bubbles normally associated with waiting for the EXE_3_RESULT to be written out to a register or rename register. Furthermore, execution stage 507 can use its own output as well as the outputs of stages 509 and 511 as an operand for the next cycle. This is done, for example, by selecting EXE_1_RESULT, EXE_2_RESULT or EXE_3_RESULT as one of its operand inputs. This is particularly useful for accumulate-type operations where the destination register is used in a series of instructions to hold an accumulating result. Without this feature, pipeline bubbles would likely be inserted between accumulate instructions thereby reducing throughput significantly. Using this feature, the decoder can issue accumulating type instructions one-after-another. The results are coupled to a corresponding selector unit 901. Each selector selectively couples the result to one of the result bus lines. Each selector is controlled by, for example, the pointer value (labeled POINTER_1, POINTER_2 and POINTER_3 in FIG. 9) corresponding to that pipe stage. The pointer values are determined from the PIPE_FILE_ENTRY and E1_RESULT, E2_RESULT and E3_RESULT fields of snapshot entry 701. Alternatively, the pointer value 903 may be stored in the snapshot file entry 701 as described hereinbefore, or may be stored in a separate register that operates in a manner such that the pointer value remains associated with a particular instruction as the instruction moves through the pipeline. The result is written to the specified pipefile entry 409 a-409 c. Pipefile 409 preferably comprises dual ported memory structure so that the contents of any entry 409 a-409 c can be written to and/or read out at any time. The memory within pipefile 409 is typically implemented using CMOS or BiCMOS static random access memory (SRAM) technology using four or more transistors per stored bit. A multiplexor set 903 selectively couples the data stored in pipefile entries 409 a-409 c to appropriate lines on a pipefile bus 904. The pipefile bus 904 provides values to the multiplexing mechanism shown in FIG. 8, for example. Multiplexor set 903 is controlled by pipe control unit 401 to couple appropriate bus lines to corresponding entries 409 a-409 c in pipefile 409. As a particular example, assume an instruction that generates its result in EXE_1 and the pointer values are set such that the EXE_1 result is written to pipefile entry 409 b. From pipefile entry 409 b the result can be multiplexed, onto any of the IFU_SRC lines by appropriate settings in multiplexor set 903. On the next pipe cycle, the example instruction will move to pipe stage EXE_2, while pipefile entry 409 b remains unchanged. In this manner, a result needs only be written to the results bus one time while remaining continuously available for forwarding while the instruction remains in the pipeline the hundreds of transistors used to store the value in entry 409 b do not have to be switched until after the value is written back and the pipe file entry is reassigned to an instruction in the decoder. It is contemplated that the functionality of multiplexor 903 may be implemented in a variety of ways depending on the level of operand forwarding needed in a particular implementation. For example, if operand forwarding from the pipefile is not needed, there would be no corresponding need to generate the PIPEFILE_SCR1, PIPEFILE_SCR2 and PIPEFILE_SCR3 lines. The writeback line is controlled by the writeback stage pointer and selects one of the pipefile entries for writeback to an architectural register in register file 407. A particular example involves execution of accumulate type instructions. Consider a series of instructions such as: MAC a, b, x MAC c, d, x MAC e, f, x where MAC is a �multiply accumulate� instruction that computes the multiple of the first and second operands and accumulates the product with a value stored in a third specified register. Prior implementations would force the MAC c, d, x instruction to wait until the first MAC instruction completed so that the accumulate register (x in the example) is stored in a register or rename register. However, in the present invention, the decode unit is aware that the MAC c, d, x instruction will not need the x register value until the third pipestage. By enabling the third pipestage to accept its own result as an input for the next instruction in that pipestage, the x register value will be immediately available to the subsequent instructions. Hence, the MAC instructions can be streamed one after the other into the pipeline without bubbles. While the invention has been particularly shown and described with reference to a preferred embodiment thereof, it will be understood by those skills in the art that various other changes in the form and details may be made without departing from the spirit and scope of the invention. The various embodiments have been described using hardware examples, but the present invention can be readily implemented in software. For example, it is contemplated that a programmable logic device, hardware emulator, software simulator, or the like of sufficient complexity could implement the present invention as a computer program product including a computer usable medium having computer readable code embodied therein to perform precise architectural update in an emulated or simulated out-of-order machine. Accordingly, these and other variations are equivalent to the specific implementations and embodiments described herein. Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Rotate |


text:
WEBSTA - Instagram Web Viewer
Mama to 2 kooks. Wife of a wonderful, silly man. Crafter. Thrifter. I hope in The Lord who blesses and sustains me.
New Message
The user you are sending this message to is not on Websta. To receive your message, send a request to use Websta Messages. The request will appear as a comment on his/her latest post.
You need to be following heidijo to like or comment.

subset: commoncrawl


text:
Just wanted to say that I love MJM Magic. I have bought several things from them and they continue to deliver with great customer service. One of the...Read More ->
I'm very happy with this services and I like it mooooore its safety and fast. I dont forget this site and i will order from it all the time...Read More ->


text:
Eric Bachelart has elected to take a hiatus from the IZOD IndyCar series in order to concentrate on a possible championship in the American Le Mans Series. Last year they came close to the P2 title.
Conquest team stayed busy during the series break running a car in both the Indianapolis 500 and the 24 Hours of Le Mans.
Conquest Endurance press release


text:
US 6909720 B1 Abstract A communication node contains intelligence for directing both internet protocol (IP) packets and Asynchronous Transfer Mode (ATM) cells toward their destinations. The ATM cells and IP packets may be received within a common data stream. The respective devices process the ATM cells and IP packets to direct the cells and packets to the proper output ports towards their destinations. The device is capable of performing policing and quality of service (QOS) processing on both the ATM cells and the IP packets.
Claims(11) 1. A device for directing data toward destinations, comprising:
an input interface configured to:
receive a non-Asynchronous Transfer Mode (ATM) data stream from a single port, the non-ATM data stream including synchronous optical network (SONET) frames,
identify ATM cells and Internet Protocol (IP) packets within the non-ATM data stream, and
forward the ATM cells and IP packets;
a SONET deframer configured to deframe the SONET frames in the non-ATM data stream;
an IP packet forwarding facility configured to:
receive IP packets from the input interface, and
forward the IP packets toward their destinations; and
an ATM cell switching facility, the ATM cell switching facility being separate from the IP forwarding facility and being configured to:
receive ATM cells from the input interface, and
switch the ATM cells toward their destinations.
2. The device of
3. The device of
4. The device of
5. The device of
6. In a device for directing input data traffic received on input ports to output ports, a method comprising:
receiving a non-Asynchronous Transfer Mode (ATM) data stream at one of the input ports;
identifying Internet Protocol (IP) packets and ATM cells in the received non-ATM data stream;
directing an identified IP packet that is received on the one input port to at least one of the output ports based on an IP lookup operation; and
directing an identified ATM cell that is received on the one input port to at least one of the output ports based on an ATM lookup operation,
wherein the device includes a Synchronous Optical Network (SONET) deframer and wherein the SONET deframer is used to deframe any SONET frames in the non-ATM data stream received at the one input port.
7. The method of
8. A device for directing both Internet Protocol (IP) packets containing address information identifying destinations and Asynchronous Transfer Mode (ATM) cells containing address information identifying destination toward their destinations, comprising:
input ports for receiving streams of input data, at least one of the streams of input data including a non-ATM stream of input data, the non-ATM stream of input data including an OC-48 data stream;
output ports for outputting streams of data;
line cards for directing input data received at the input ports to the output ports, each said line card including:
a device configured to identify IP packets and ATM cells in the streams of input data;
an IP packet forwarding facility for directing the identified IP packets to the output ports based on the address information contained in the IP packets; and
an ATM cell forwarding facility for directing the identified ATM cells to the output ports based on the address information contained in the ATM cells.
9. The device of
10. The device of
11. The device of
Description This application claims the benefit of priority under 35 U.S.C. 119(e) to U.S. Provisional Application Ser. No. 60/090,028, filed Jun. 19, 1998, and is related to U.S. patent application Ser. No. 09/237,128, filed Jan. 25, 1999, and entitled �NETWORK PACKET FORWARDING LOOKUP WITH A REDUCED NUMBER OF MEMORY ACCESSES,� U.S. patent application Ser. No. 09/336,090, filed Jun. 18, 1999, and entitled �AN INTERCONNECT NETWORK FOR OPERATION WITHIN A COMMUNICATION NODE,� U.S. patent application Ser. No. 09/336,311, filed Jun. 18, 1999, and entitled �A QUALITY OF SERVICE FACILITY IN A DEVICE FOR PERFORMING IP FORWARDING AND ATM SWITCHING,� and U.S. patent application Ser. No. 09/335,947, filed Jun. 18, 1999, and entitled �METHOD AND SYSTEM FOR ENCAPSULATING/DECAPSULATING DATA ON A PER CHANNEL BASIS IN HARDWARE�. The entire contents of each of said application is hereby incorporated by reference. The present invention relates generally to switching nodes and more particularly to a single device for performing IP forwarding and ATM switching. In conventional systems, computer networks typically have been viewed as being divisible into several layers. The Open Systems Interconnection (OSI) reference model was established by the International Standards Organization (ISO). The OSI reference model defines a computer network as having seven layers ranging from a physical layer to an application layer. A number of different protocols have developed for use at the respective layers of a computer network. The Asynchronous Transfer Mode (ATM) protocol is a layer 2 protocol. Layer 2 is the data link layer and is responsible for transmitting chunks of information over a data link. The Internet Protocol (UP) is an example of a layer 3 protocol. Layer 3 is the network layer, which is responsible for enabling any pair of systems in the computer network to communicate with each other. In conventional systems, ATM networks had been viewed as separate universes from IP networks. ATM networks work well for a subset of services, and IP networks work well for a different subset of services. Given that neither IP nor ATM offer a complete multiservice solution, many service providers choose to operate dual networks. IP networks supports applications such as Internet access and virtual private networks, whereas ATM networks supports frame relay, virtual private networks, circuit emulation, private branch exchange (PBX) and other applications where reliability and quality of the service (QOS) are a priority. The present invention provides a device that not only can perform IP packet forwarding and routing but can also perform ATM switching and routing. The device of the present invention allows a network developer to not commit exclusively to a single protocol; rather the device of the present invention allows the developer to support a number of different protocols within a single device. The device of the present invention provide a true multi-source capability. The device is capable of handling ATM, IP packet over SONET and the routing of IP packets over ATM. In accordance with one aspect of the present invention, a device for directing input data towards destinations includes an IP packet forwarding facility for forwarding IP packets in input data towards their destinations. The device also includes an ATM cell switching facility for switching ATM cells in the input data towards their destinations. The input data may include synchronous optical network (SONET) frames. In accordance with another aspect of the present invention, an apparatus for directing input towards destinations includes input ports for receiving input and output ports for outputting data. The apparatus also includes a director which is coupled to a selected one of the input ports for directing the input to the output ports. The director directs layer 2 data units encapsulated by an OSI layer 2 protocol to the output ports based on address information in the layer 2 data units. The director also directs layer 3 data units encapsulated by an OSI layer 3 protocol to the output ports based on address information in the layer 3 data units. The layer 2 protocol may be the ATM protocol and the layer 3 protocol may be IP. In accordance with a further aspect of the present invention, a method is performed in a device for directing input data traffic received on input ports to output ports. An IP lookup is provided for identifying where to direct an IP packet that was received on a selected input port. An ATM lookup is provided for identifying where to direct an ATM cell that is received on the selected input port. A unit of input data is received by the selected input port. If the unit of data is an ATM cell, the ATM lookup is used to identify which of the output ports to direct the unit of data. Where the unit of data is an IP packet, the IP lookup is uses to identify the output port towards which to direct the unit of data. In accordance with a further aspect of the present invention, a device is provided for directing both IP packets containing address information identifying destinations and ATM cells containing address information identifying destinations toward their destination. The device includes input ports for receiving streams of input data and output ports for outputting streams of data. The device also includes line cards for directing input data received at the input ports to the output ports. Each line card includes an IP packet forwarding facility of directing IP packets in the input data to the output ports based on the address information contained in the IP packets. Each line card additionally includes an ATM cell forwarding facility for directing ATM cells in the input data to the output ports based on the address information contained in the ATM cells. The device may include an interconnect for interconnecting line cards to facilitate communication among the line cards. A multiplexer may be positioned before select one of the input ports to multiplex data streams into a single input data stream. The input data may be received as an OC-48 data stream. An illustrative embodiment of the present invention will be described below relative to the following drawings: The illustrative embodiment of the present invention provides a single device for performing both internet protocol (IP) forwarding/routing and asynchronous transfer mode (ATM) switching/routing. The single device contains both an IP packet forwarding facility and an ATM switching facility. In this context, �forwarding� refers to the passing of packets between a source port and one or more destination ports in a communication node, such as a switch, a router or a switch/router. �Routing� refers to the accumulation of topology information to provide information to a forwarding table or similar structure by a communication node that is used for directing input data toward a destination. �Switching� refers to the directing of packets or other modularized information through intermediary switching nodes to connect a sender with a receiver in a connection-oriented environment. The illustrative embodiment eliminates the need for having separate switches and routers. The device employed in the illustrative embodiment can handle both ATM cells and IP packets in a single device and also can handle IP packets carried by ATM cells. The device may be employed in IP networks, such as the internet, intranet or extranet, or more traditional switching environments, such as virtual private networks (VPNs), private data networks. The device supports routing of IP packets over a SONET (Synchronous Optical Network), the routing of IP packets over ATM and pure ATM switching. More generally, the illustrative embodiment eliminates the separation between layer 2 devices and layer 3 devices so that layer 2 data units and layer 3 data units may be directed toward their destinations by a single device. The illustrative embodiment employs a switch/router suitable for use in a communications network such as a computer network or a telephone network. The switch/router includes input ports for receiving input data traffic and output ports for directing the input data traffic towards destinations. Each input data port is tied to a communications line, such as a fiber optic line. Similarly, each-output port is tied, likewise, to a communication line (e.g. a fiber optic line). An ATM cell forwarding facility and an IP packet forwarding facility are provided for each input port. The ATM cell forwarding facility determines, for each ATM cell received by the input port, which output port to use for outputting the ATM cell. The IP packet forwarding facility determines, for each IP packet received by the input port, which output port to use for outputting the IP packet. Hence, each input port may receive both ATM cells and IP packets and the switch/rates will properly direct the AMT cells and IP packets. The discussion below summrarizes the architecture and operation of the switch/routes device of the illustrative embodiment.
As can be seen in the above-identified table, OC-48 is one of the specified line rates. In the capacity column of the table, references are made to DS-1 and DS-3 rates. These are SONET/SDH capacities expressed in terms of line rates in the Plesiochronous Digital Hierarchy (PDH) of digital signal speeds that is used to classify capacities of lines or trunks. The fundamental speed level in the DS hierarchy is DS-0, which corresponds to 64 kilobits per second. DS-1 corresponds to 1.54 megabits per second, and DS-3 corresponds to 44.736 mbps. The switching shelf 10 also contains switching module cards 18 that occupy 3 slots. Switching module cards 18 are printed circuit boards that provide switching capacity to facilitate communication between line cards. The switching module cards 18 form the core of the �interconnect,� which will described in more detail below. Switch resource modules 16 occupy the remaining two slots in the switching shelf 10. These modules 16 manage board level status information for the switching shelf 10. As was mentioned above, additional switching shelves 10 may be employed in the device to increase the switching capacity of the device. The device of the illustrative embodiment provides a channelized SONET/SDH mode of operation, such that each OC-48 line card module can be configured for DS-3, OC-3 and OC-12 or OC-48 tributary configuration. Those skilled in the art will appreciate that the depiction of the line card 59 shown in The line cards 53 may have SONET multiplexers, such as multiplexers 50 and 52 positioned at the input of the input ports for the line cards to multiplex the incoming tributary data streams into OC-48 data streams. In the example depicted in An example is helpful to illustrate data flow through the components depicted in FIG. 4. Suppose that four OC-12 data streams are multiplexed into a single OC-48 input data stream at the input port for line card 59. The receive ASIC 70 on line card 59 determines how to direct ATM cells and/or IP packets in the input data stream. The data is passed over the interconnect 62 to a destination line card, such as line card 53. The transmit ASIC 64 on the line card 53 packages the data (i.e. encapsulates) in a format that is appropriate for the destination. The data is then sent out over the output ports. A multiplexer 50 may multiplex the output data from the OC-48 stream coming out of the line card onto a physical OC-12 port. The illustrative embodiment leverages the infrastructure of SONET/SDH to support multiple data encapsulations. It is presumed that the incoming data is encoded in a SONET format. The resulting data in the respective tributaries may be in any of a number of different formats. The receive ASIC 70 delineates this data (step 112 in The data may also be encapsulated in a point-to-point protocol (PPP) frame 222, such as shown in FIG. 13. PPP is a layer two protocol that is built on top of a restrictive subset of the standard high level data link control (HDLC) protocol. The PPP frame 222 is delimited by flags 223 and 231. Each PPP frame 222 includes an address 224 and a control field 226 for holding flow control information. The PPP frame 222 contains an information section 228 and a PPP payload. The CRC field 230 identifies the variety of cyclic redundancy check that is used for the frame. The data may be encapsulated also in a frame relay (FR) frame 232 (FIG. 14). Each (FR) frame 232 includes a byte of flag information 234 and an address field 236 in the FR frame header. The frame relay frame 232 also contains an information field 238 that holds a payload and a frame check sequence octet 240 that holds information used to check whether the frame is properly received. Lastly, the frame relay frame 232 has a flag octet 242 at the end of it. Once the ATM cells are located, ATM cell input processing must be performed on each ATM cell (see steps 114 and 116 in FIG. 8). The ATM cell header 303 is sent to the ATM lookup engine 150 along with input port information (Step 260 in FIG. 16). The remaining 48 bytes of the ATM cell are sent to the receive FIFO 152 (Step 262 in FIG. 16). A payload type 304 is included in the header 303 and includes a three bit field that indicates whether the cell contains user information or contains associated layer management information. A cell loss priority bit 306 allows the specification of explicit loss priority for the cell. The header 303 of the ATM cell 290 also contains a header error control field 308 that is used by the physical layer of the network for bit errors in the cell header. As mentioned above, the ATM cell header 303 is sent to the ATM lookup engine 150 (step 260 in FIG. 16). The payload 310 is sent to the receive FIFO 152 (step 262 in FIG. 16). The ATM lookup engine 115 uses an ATM table 154 to perform a lookup to determine where to direct the ATM cell (step 264 in FIG. 16). The ATM lookup engine plays a role in both the policing (see 126 in The discussion below focuses first on the performance of the ATM lookup Step 264 in As shown in Each VCLUT entry 324, 326, or 328 contains a destination handle and other switching information, including information that is useful in performing policing. A destination handle is a composite data structure that holds useful information regarding where a cell should be directed so that the cell is properly output towards the desired destination. As will be explained in more detail below, the destination handle is used by the transmit ASIC 64 to determine where to send output (i.e. what output port should be utilized). The results of the ATM lookup is generally a destination handle. As mentioned above, the ATM lookup engine 150 also performs certain policing actions. For ATM cells, separate policers are implemented to monitor peak cell rate (PCR) and sustained cell rate (SCR), according to the traffic contract for the VC or VP. Each policer implements the generic cell rate algorithm (GCRA), that is defined in the UNI 4.0 specification. The PCR leaky bucket algorithm monitors the maximum cell rate within the tolerance permitted by the cell delay variation toleration (CDVT). The SCR leaky bucket algorithm monitors the average cell arrival rate over a period of time within the burst size permitted by the maximum burst size (MBS) and CDVT. SCR applies to VBR and UBR connections and is always less than the PCR. Traffic contracts are defined in accordance with the ATM forms traffic management 4.0 specification. The ATM cells that exceed the traffic contract are subject to policing, which can include marking or dropping the offending cells. Policing and QOS are described in more detail is copending application entitled �An Interconnect Network For Operation Within A Communication Node� [AGM-006] which is assigned to a common assignee and explicitly incorporated by reference herein. The results of the lookup 150 (i.e. destination handle) are sent to the CRC module 152 (step 266 in The decapsulation module 182 has a decapsulation table 184 that determines how data extracted from the receive data packet shall be encapsulated into the internal cells (i.e. ecanonical-format). For raw ATM cells, the payload of the ATM cells is combined with the header information and the destination handle to create the internal cell that is in sent over the interconnect 62. In step 118 of In order to understand how processing proceeds, it is helpful to consider the case where the PPP frame contains an IP packet. In such an instance, the receive ASIC 70 shreds the IP packet in the PPP frame into pseudo-ATM cells and sends the headers to the ATM lookup engine 150 and the data 48 data bytes to the receive FIFO 152. The PPP frame is aliased into ATM cells so that ATM lookup engine 150 is able to process them. Specifically, traffic coming over a PPP context has a VPI/VCI with a preconfigured value of 0/1. This value is inserted into the headers of the internal cells generated by the AAL5 segmented 148. The VPI/VCI value of 0/1 for the PPP context is configured as a circuit that is routed. For frame relay frames, the VPI/VCI is set according to the incoming DLCI value plus one. When processing incoming header data, the ATM lookup engine 150 returns either a destination handle or a placeholder destination handle. The placeholder destination handles are an indication that the incoming header is for an IP packet and requires further IP processing. The presence of the placeholder destination handle output causes the header information to be placed in the pending cells queue 166. The ATM lookup 150 determines whether the cell is for the first cell of an IP packet (step 412 in FIG. 20). If the cell is not the first, no further input processing is required. If, however, it is determined that the cell is first cell for an IP packet, the IP header information is located in the payload of the first cell which is available to the first cell decapsulation module 170 (step 414 in FIG. 20). The 48 bytes of data for the cell are sent from the receive FIFO space 152 to the first cell decapsulation module 170 as well (step 416 in FIG. 20). The first cell decapsulation module 170 decapsulates the information contained in the first cell is payload to send appropriate information to the IP lookup module 174 and the data is sent to the parking lot (step 418 in FIG. 20). The first cell decapsulation module 120 uses a decapsulation table 171 to identify how to decapsulate the cell. The IP lookup module 174 performs both forwarding lookup 132 ( The header data 430 includes flags 170, including a DF flag and a MF flag. The DF (�don't fragment�) flag indicates whether a datagram that is carried at least in part by the packet is to be fragmented. The MF (�more fragment�) flag identifies whether there are more fragments or whether the packet holds the last fragment of the datagram. The fragment offset field 444 holds an offset value that identifies the offset in which the fragment belongs to the reassembled packet. The time to live field 446 identifies the time period for which the packet is valid and after which the packet should be discarded. The protocol field 448 holds a value that allows the network layer of the destination end node to know which protocol that is running at the end node should receive the packet. A header checksum field 450 is provided. A source address field 452 and a destination address field 454 are provided to hold a source address from which the packet originated and a destination for which the packet is to be forwarded respectively. The source port field 456 identifies a source port and destination port field 458 identifies a destination port for the packet. The IP lookup module 174 uses a number of tables (see Route Table 176 in The IP lookup module 174 uses lookup arrays 482 containing lookup elements. The IP lookup module 174 may also use a SANET 484 or DANET 486. The SANET is a data structure that holds a number of structures for respective source addresses that are being exploited for quality of service (QOS) processing and type of service (TOS) processing. DANET 486 holds DANET structures that contain information regarding destination addresses that identifies the next hop for IP packets. The route table 176 contains multiple lookup tables. In particular, a tree of lookup arrays is provided. The first level of the tree is a single lookup array that is indexed by the first two bytes of the destination IP address for an IP packet. The second level of the tree contains lookup arrays indexed by the third bytes of the destination IP address. The third level of the tree contains lookup arrays that are index by the final byte of the destination IP address. By using this tree structure, the illustrative embodiment is able to decrease the number of memory access required and to increase the speed with which IP lookup occurs. After the instruction has been accessed in the interface structure (see step 460 in FIG. 24), an entry is accessed in the first lookup array and processed (step 462 in FIG. 24). The instruction tells the IP lookup module 174 what to do next. For example, the instruction may instruct the IP lookup module 174 to access an element in a second lookup table. Alternatively, the instruction may direct the IP lookup module 174 to use a destination handle contained within a particular DANET structure. If the entry in the first lookup array does not complete (i.e. identify a DANET structure to use) the process (see step 464 in FIG. 24), an entry is accessed in the second lookup array and processed (step 466 in FIG. 24). If the processing of this entry in the second lookup array does not complete the lookup (see step 468 in FIG. 24), an entry in the third lookup array is accessed and processed (step 470 in FIG. 24). If the instructions in the lookup arrays direct the use of an identified DANET structure in forwarding the packet, that structure is utilized (step 472 in FIG. 24). IP lookup is described in more detail in copending application entitled, �Network Packet Forwarding Lookup With A Reduced Number Of Memory Accesses,� Application No. 09/237,128, filed on Jan. 25, 1999, which is assigned to a common assignee with the present application and which is explicitly incorporated by reference herein. Policing of IP packets also occurs in the IP lookup module 174 (see 130 in FIG. 9). IP packets are classified into three bands: green, amber or red. Green implies that the traffic is within traffic limits. Amber implies that the traffic is over the traffic limits but under a predefined burst rate, and red implies that the traffic is over the burst rate. The policing may be used to mark the TOS bit in the IP header. In addition, the policer in the IP lookup module 174 generates a profile indicator value in a range of one to four that used in input to a random early discard (red) algorithm on the transmit ASIC 64. Each flow has an associated traffic profile that sets limits on how much traffic the flow is allowed to generate. The flow limit is enforced by a token bucket algorithm that allow brief bursts above the flow limit. The token bucket assigns incoming traffic to the appropriate band. Thus, the IP lookup engine performs both the policing function 130 ( The interconnect 62 delivers the internal cells to the transmit ASIC 64. The transmit ASIC is responsible for performing output processing (see 84 in A ticket manager 552 manages the distribution of tickets. The ticket manager 552 has access to a ticket free list memory 556 and accesses the memory 556 to provide the interconnect 62 a free ticket pool 550 of locations in the transmit data parking lot 546 that are available for use. The interconnect 62 chooses one of the free tickets and presents the ticket to the ticket manager 552. The interconnect 62 also asks for the data to be stored at the location identified by the ticket in the transmit data parking lot 546. The ticket manager 552 is provided with the destination handle (DH) for the internal cell and passes the DH to the cell chain manager 558. The cell chain manager 558 accumulates packets of cell chains. In the customary case, the cell chain manager 558 makes sure that all components (i.e. chunks of data) of an IP packet are available before the IP packet is transmitted. There may also be a cut-through case wherein this restriction is relaxed. The output queue manager provides scheduling for implementing QOS options. It manages various output queues which will be described in more detail below. The output queue manager 570 cooperates with a QOS table 574 and a calendar queue 572. The output data stream need not be a unicast data stream but rather may be a multicast data stream such that the same data stream is sent to multiple destinations. Component 564 in For each context there are eight queues, like those depicted in A calendar queue 540 is provided to shape or rate limit traffic. Data is regulated via the calendar queue 540 to be placed into the queues 620, 622, 624, 626, 628, 630, 632 and 634. If a cell or packet is to be shaped (i.e. output to QOS processing), then the cell or packet is passed through the calendar queue 540. As the calendar queue delays outgoing traffic beyond the configurable threshold, the traffic is dropped. After the shaping is complete, the cell or packet in the input queue is transmitted to the specified output queue. The calendar queue 540 is a ring structure with slots corresponding to future moments in time. The calendar queue 540 has enqueue and dequeue pointers that are based on time. The dequeue pointers advance according to a time schedule based on the width of a slot and the calendar ring. The enqueue pointer points to the last slot that can safely be queued before the dequeue pointer gets to it. The two pointer advance together. Data is queued based on a desired rate such that a �future time� is calculated for the item to be queued based on the last transmit time. The �future time� cannot be less than the time slot pointed to by the enqueue pointer. The calendar queue 540 relies on the QOS table 524 to configure the calendar queue appropriately for the QOS being used. The dequeue process for the calendar queue 540 is asynchronous relative to the enqueue process. The dequeue process removes all entries for the slot of the �current time� and advances the enqueue and dequeue pointers. The entries removed from the �current� slot� are placed into the queue specified by their QOS treatment. Thus, as shown in A queue scheduler 544 (in the output queue manager 570) is responsible for dequeueing data from the output queues 542. The queue scheduler 544 is provided within the output queue manager 570. The scheduler 544 implements both priority queueing and weighted round robin queueing. A programmable threshold divides priority queues from weighted round robin queues. The scheduler 544 first processes the priority queues, transmitting traffic in strict priority order. The rest of the queues are processed in weighted round robin order. The output queues are typically assigned to QOS classes, and the priority in weights on the queues configured accordingly. The priority threshold can be used to select priority queuing only or weighted round robin queuing only for all of the output queues 620, 622, 624, 626, 628, 630, 632, and 634. The output queue manager 570 passes a ticket list and a destination handle to the encapsulation selector 576. The encapsulation 576 selector then retrieves the appropriate data from the output queues 542. The encapsulation selector 576 passes the destination handle for the selected cells to the destination description manager 580. The destination description manager 580 works in conjunction with the encapsulation engine 590 to determine how to appropriately encapsulate the data that is to be output. The destination description manager 580 accesses encapsulation RAM 578 to obtain information regarding the appropriate encapsulation for the destination. The destination description manager 580 has a destination descriptor for the destination of the output data stream. The destination handle (which accompanies every cell) is used by the destination description manager 580 to locate a destination descriptor. The destination descriptor is a field found within the destination handle that contains all of the information necessary for reencapsulation of the cell (including partial cyclic redundancy checks and information regarding the length of the frame). The encapsulation engine 590 uses an encapsulation identifier from the destination descriptor to reference a table of encapsulation descriptors 592. The encapsulation descriptor contains a pattern to be inserted into the beginning of an outgoing frame that identifies the pattern encapsulation. The destination handle and data retrieved from the transmit data parking lot 546 of the appropriate encapsulations are gathered for ATM output. The resulting ATM cells are sent to ATM output module 594. The ATM output modules creates a correct AAL5 trailer and sets various bits in the cell. OAM 596 may be generated or outgoing OAM cells, generated by the LCP or forwarded from the receive ASIC 70, may need to be formatted. Tie resulting data is transmitted to the PLCP module 598. If no PLCP encapsulation is required, the cells pass through to the port transmit queue 600 without modification. Otherwise, the cells are encapsulated into PLCP frames by the PLCP module 598. IP packets are passed to the PPP/FR output module 604, which is responsible for creating PPP frames or FR frames for encapsulating the data. The resulting frames are passed through the port transmit queues 600. Certain packets my need to passed to the LCP. The LCP packet output 606 is passed through a LCP buffer 608 and ultimately passed onto the LCP. A SONET framer/physical interface 602 is provided for framing the data into SONET frames and for performing parallel to serial conversion. The SONNET framer/physical interface 602 provides a physical interface to the output lines. The resulting data is the output towards its descriptor. While the present invention has been described with reference to an illustrative embodiment thereof, those skilled in the art will appreciate the various changes in form and detail may be made without departing from the intended scope of the present invention as in the appended claims. Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Rotate |


text:
WELCOME TO THE HOMEPAGE OF.....THE OHIO STATE UNIVERSITY ALUMNI CLUB OF WEST MICHIGANHere you will find information relative to our club such as game watch information, cookouts, parties, charity events, links to 'All Things Ohio State', but most importantly, Fellow Buckeyes in West Michigan.For more Information from The Ohio State University Alumni Association, Click Here. Sweet SuiteOur OSU Alumni Club, once again, has been afforded the opportunity to use a "SWEET SUITE at the SCHOTT" for the OSU Men's Hockey Game vs. Minnesota at 6:00 p.m. on Saturday March 7, 2015. The Luxury Suite in The Schottenstein Center is allocated to our Club as a Fun Way to Fund Raise for our Scholarship Fund. We have 11 FREE Tickets available to be used for the Hockey Game that night - we only ask that you consider making a tax-deductible contribution to our OSU West MI Scholarship Fund. We also have 8 additional tickets available at $18 each. This event is open to our entire West Michigan Buckeye Nation - and is a great way for our families and parents of our West MI OSU students to watch some OSU Hockey action in a Private Suite at The Schott. This game on March 7 is also OSU Hockey Alumni Society Night at The Schott.
At this time - Please use this RSVP Link: and sign up for 2 tickets per family. If you need more than 2 - please add the number needed in the Comments Section of your RSVP reply - if there are extra tickets available - we will do our best to accommodate your needs.
The following day, Sunday, March 8, the Men's OSU Basketball team will play Wisconsin in the final game of the regular season before the Big Ten Tournament starts. This game is slotted for a 5:00 pm start and may have implications for Final Standings of The Big Ten Conference and Seedings for The Big Ten Tournament. Unfortunately, we do not have a group of tickets available for this game. The Newsletter is Here!The first newsletter of 2015 is here. Please take the time to read what has been going on, and what will be going on in 2015! Football Season 2014 Was GreatA big thank you to Buffalo Wild Wings for a championship season! Go Bucks! SHOUT OUTS & RECOGNITIONS Thank you to our November and December volunteers who helped with our Thank You Calls, Clubhouse Party at Craig's Cruisers, and the TV Pledge Phone Banks: Lisa Baber, Andrew Blum, Jane Bruns, Marie Byl, Marcia Deyoung,Tom Eggleston, Sonny Gordon, Tiffany Grantham, Oliver Hale, Trinity Jeffries, Jim Kirkwood, Dan LaVille, Tim McMorrow, Kate Nagengast, Barry Waters, Donna Waters! The Notre Dame Fan Club of West Michigan and The Ohio State Alumni Association ROCK! Do You Want to Become a Member of The Ohio State Alumni Club of West Michigan?Are you interested in joining your fellow Buckeyes here in the state up north? Down load our application form and send it in. For a low annual fee, you too can become a member of The Ohio State University Alumni Club of West Michigan. Click Here to get more information. If you choose to direct your OSUAA Sustaining Membership to our Club's Endownment Fund, you will receive a 20% discount on your local club dues. For more information, click here. To pay your dues, click here and select the "Buy Now" option. Are You an OSUAA Sustaining Member?Are you a member of one of the largest alumni associations in the world? If your answer was no, then it is time to join. Click Here to get information on becoming a member or to sign up! To earn the Sustaining Member level of membership (making you eligible for the football lottery, among other benefits), a graduate must make a gift or gifts either equal to or more than $75 to the Ohio State fund of his or her choice each year. These gifts are tax-deductible AND you may choose our Club's Endowed Scholarship Fund as the recipient of your Sustaining Membership Contribution of $75.00 or more. Search for West Michigan Alumni 607657 to locate our Club's endowment fund. The principal balance of our Club's Endowed Scholarship Fund will grow with each OSUAA Sustaining Membership Contribution that is earmarked for our Fund. For more information about our Club's Fund, click here |
Calendar |


text:
Here is a more recent study between One Touch Ultra and Freestyle Flash
A recent comparison study about 27 different blood glucose meters:
(a pdf file)
Some meters did very bad, check page number 10.
More than 40% of the evaluated BG monitoring systems did not fulfill the minimum accuracy
requirements of DIN EN ISO 15197:2003
I really love my Glucocard X-meter mini plus- meter. Arkray (the manufacturer
of X-meter) market it as +-15% accuracy, not the regular +-20%.
If that meter wouldn't be available, my next-in-the-line meter would be Accu-chek Aviva Nano.
No way I would use 1.0µl meters from Onetouch, I love the 0.3µl modern meters.
Melissa Lee
Emily Coles (Head of Communities, has type 1) Mila Ferrer Mike Lawson Corinna Cornejo Desiree Johnson (Administrative and Programs Assistant, has type 1) |
Lead Administrator
Brian (bsc) (has type 2) |
Lorraine (mother of type 1) |
Marie B (has type 1) |
DanP (has Type 1) |
Gary (has type 2) |
David (has type 2) |
This site complies with the HONcode standard for trustworthy health information: verify here.
© 2015 A community of people touched by diabetes, run by the Diabetes Hands Foundation.


text:
By PBN Staff
Twitter: @ProvBusNews
Mayor Jorge O. Elorza has appointed Army Col. Michael Borg as director of the Providence Emergency Management Agency and Office of Homeland Security.
Defense Industry
By PBN Staff
Twitter: @ProvBusNews
Banneker Industries will sponsor Rhode Island's Defense Innovation Days 2015 event, which will be held at the Marriott Newport in December.
By Lori Stabile
PBN Web Editor
Twitter: @loristabile
Raytheon Co. recently hosted a forum for commercial suppliers to identify ways to improve efficiencies in ship system integration at shipyards around the country and world.
Small Business
By Eli Sherman
PBN Staff Writer
Twitter: @Eli_Sherman
The U.S. Small Business Administration announced a partnership with the R.I. Commerce Corporation and its Procurement Techincial Assistance Center to offer Rhode Island small businesses free counseling and training programs on procurement procedures at the local, state and federal level.
Defense Industry
By PBN Staff
Twitter: @ProvBusNews
OM Group Inc. has completed its acquisition of Ener-Tek International Inc., which operates under the brand name Yardney Technical Products, according to a press release issued this week.
By Roger Runningen and Phil Mattingly
Bloomberg News
U.S. Defense Secretary Chuck Hagel is stepping down from his post after 21 months in office amid tension with the White House over strategy and the rise of new security challenges to the country.
Defense Industry
By PBN Staff
Twitter: @ProvBusNews
Capt. Howard Goldman will relieve Capt. Todd Cramer as commander of the Naval Undersea Warfare Center Division Newport during a change of command ceremony on Friday at 1 p.m.


text:
Related Businesses in category: Grocery Stores And Supermarkets
Array more
Search for Top Ten Grocery Stores. Find Expert Advice on About.com.
about.com/top ten grocery storesHere's Selected Special Offers! Find Out Grocery Store Weekly Ads
gmx.com/grocery store weekly adsFind Grocery Stores. Discover and Explore on Ask.com!
ask.com/find grocery storesGet Results for Grocery Ads. Important Consumer News & More!
grocery-ads.vibescaster.comLocal Sponsors
Search for Food Stores Supermarkets Look Up Quick Results Now!
wow.com/food stores supermarketsSave More Money And Print Coupons - Printable Coupons & Tips (Free)
couponinghub.com© 2015 Local Corporation - US Patent 7,231,405
Some data provided by Acxiom. Questions and Comments?


text:
Review Details
Aerostich Deerskin with Gauntlet Gloves
- Product Review (submitted on September 29, 2012):
Exactly what I expected, super soft but strong gloves. I bought 2 pair, once each for my son and myself. We broke them in by riding in heavy rain for several hours.
After drying out they were good as new.


text:
Environment in Africa
- Today
- Past 7 Days
- Past Month
- Past Year
- Specific Date Range
- Board Report (1)
- Brief (5)
- ESMAP Paper (1)
- Brief (1)
- Feature Story (41)
- Loans & Credits (27)
- Opinion (1)
- Press Release (80)
- Publication (1)
- Date
West Bank & Gaza - North Gaza Emergency Sewage Treatment (NGEST) Project [Third Additional Financing]
West Bank & Gaza - North Gaza Emergency Sewage Treatment (NGEST) Project [Third Additional Financing] Trust Fund Grant: US $3.0 million equivalentProject ID: P074595Project Description: The project... Show More +
Biodiversity: Sector Results Profile
Bank Group ContributionThe overall WB biodiversity portfolio of 245 projects in the ten years from FY2004 to 2013 included direct biodiversity commitments worth over US$ 1 billion. Of this, 27 percent... Show More +
World Bank Supports Improving Sanitation Services in Gaza to Address Health Issues and Water Pollution
Washington, April 14, 2014 – Two projects in the Gaza Strip will respond to health and environmental threats and provide long-term solutions to the treatment of sewage and solid waste. The US$13... Show More +
Environment: Sector Results Profile
Bank Group ContributionOver the past decade, the Bank (IBRD/IDA) committed funding for US$33 billion, from which IDA's contribution was US$7.7 billion (23 percent) to support investment in environment... Show More +
Sustainable Energy for All: Sector Results Profile
Bank Group ContributionSince 2008, the Bank Group has provided $48.6 billion for energy projects, with $24 billion from IBRD, and $11.4 billion from IDA. Of the total Bank Group financing, $12.4 billion—25.6... Show More +
Oceans: Sector Results Profile
Bank Group ContributionThe World Bank and Bank-managed trust funds are increasingly supporting initiatives to rebuild the ocean's natural capital. Many of the Bank's investments in the oceans over the... Show More +
Gaza - Solid Waste Management Project
Trust Fund Grant: US $10.0 million equivalent Project ID: P121648Project Description: The objective of this project aims to improve the solid waste disposal in Gaza governorates through the provision... Show More +
Water in the Arab world: From droughts to flood, building resilience against extremes
The Middle East and North Africa (MENA) is the most water scarce region in the world, and its water stress is likely to worsen. In 1950, per capita renewable water resources were four times greater than... Show More +
Natural Disasters in the Middle East and North Africa: A Regional Overview
The report Natural Disasters in MNA: A Regional Overview analyzes the risks the region faces and the measures and tools that the countries have adopted to enhance their preparedness. Developed by... Show More +
Yemen - Mocha Wind Park Project
Yemen - Mocha Wind Park Project IDA Grant: US $20.0 million equivalent Project ID: P146055Project Description: The objective of the project is to increase the supply of cost-effective electricity... Show More +
Morocco Takes the Long View on Green Growth
The World Bank Group is supporting Morocco's shift towards green growth through a range of operations in sectors such as water, energy, transport and agriculture. A recently approved US$300 million Development... Show More +
Jordan - Integrated Ecosystem Management in the Jordan Rift Valley Global Environment Facility (GEF) Project
The Integrated Ecosystem Management in the Jordan Rift Valley Global Environment Facility (GEF) Project for Jordan had an overall moderately satisfactory outcome, with... Show More +
Morocco - First Inclusive Green Growth Development Policy Loan
IBRD Loan: US $300.0 million equivalentTerms: Maturity = 29 years, Grace = 6.5 yearsProject ID: P127956Project Description: The development policy loan will promote revenue diversification in rural Morocco,... Show More +
Green Growth in Morocco will Protect the Environment and Create Jobs
WASHINGTON, December 19, 2013 – A US$300 million loan will promote revenue diversification in rural Morocco, improve the management of natural resources and encourage a shift towards low carbon growth.The... Show More +
Yemen - Water Sector Support Project : environmental assessment (Vol. 6 of 8) : Environment and social management plan (ESMP) for Am Qaid spate diversion works Wadi Khawrah in Shabwa governorate
The objective of the Water Sector Support Project for Yemen is to ensure coordination among all partners working in urban and rural water supply and sanitation sub-sectors,... Show More +
Morocco - First Inclusive Green Growth Development Policy Loan (DPL) Program
This program document presents the First Inclusive Green Growth Development Policy Loan (DPL) Program to the Kingdom of Morocco in the amount of EURO 219.7 million (US$300... Show More +
World Bank Supports Conservation of the Red Sea and Gulf of Aden
RIYADH, November 4, 2013 – A new project will improve the governance and management of marine environment of the Red Sea and Gulf of Aden. The US$3 million Red Sea and Gulf of Aden Strategic Ecosystem... Show More +
The Global Environment Facility (GEF) in MENA
Environmental stress is a serious concern in the Middle East and North Africa (MENA) region. Recent years have witnessed important changes that are pushing the boundaries... Show More +
World Bank and Djibouti Sign Agreement to Explore Geothermal Energy
WASHINGTON, October 13, 2013 – Financing agreements signed today between the World Bank Group and Djibouti will launch a project to tap into Djibouti's volcanic riches as a source of geothermal power.... Show More +
Iraq: Investing in Infrastructure and Institutions to Create an Environment for Sustainable Economic Revival and Social Progress
ChallengeAlthough limited data impedes knowledge of the full picture, poverty and human conditions in Iraq worsened in the 1990s and have not improved considerably in recent years. Iraq has a very... Show More +


text:
Hi: 10° Lo:2°
Arsenic and Old Lace
Palace Theatre, Redditch
Friday, March 30
THERE were lots of laughs at the Palace Theatre as All and Sundry performed Joseph Kesselring's classic Arsenic and Old Lace.
The play centres around drama critic Mortimer Brewster who, in between reviewing plays and trying to decide whether or not to marry the love of his life Elaine Harper, has to also deal with his two aunties Martha and Abby who have acquired a penchant for putting old men out of their misery.
The show enabled the audience to take a break from the doom and gloom of the petrol crisis and see a performance which was fuelled by plenty of energy, erraticness and enthusiasm.
This great script was really brought to life by another talented cast that took the writer's intended dramatic tension and used it to the full to create a hilarious night of entertainment.
Everyone played their part on the night but Barbara Treen and Mary Field excelled in their roles as twittering old aunties Martha and Abby. Their dead-pan approach showed perfectly the naivety and irony of their characters who, in their own little world, took a moral high ground on giving their victims a 'good
Christian burial' in the cellar and praising police for the good jobs they did in protecting them, despite being murderers.
That aspect, coupled with the brilliant Rory McGhie, who as favourite nephew Mortimer, was frantically running around trying to cover up the old dears' antics made this production. His comedy timing, erratic actions and mannerisms were immense - especially against the backdrop of the aunties' incessant ramblings.
Malcolm Berwick was suitably evil as prodigal baddie Jonathan and his side-kick, alcoholic surgeon Dr Einstein, was well-played by Roger Goddard.
And, if all that wasn't enough, Chris Hall was also fantastic as eccentric fantasist Teddy Brewster who believed he was American President Roosevelt. His brief appearances added even more laughs to the mix in what was a frantic comedy that you just could not take your eyes off for a minute.
Tristan Harris
1 Jewellery and metal detector stolen in Bromsgrove burglary
2 Jimmy The Whirlwind White showcased his snooker skills in Bromsgrove
3 Popular curate bids Bromsgrove farewell
4 Health secretary refuses to get involved in Alex crisis
5 NHS whistleblower to scrutinise performance of hospital trust
THERE will be plenty of special seasonal screenings
THERE will be plenty of festive fun at
Bromsgrove Operatic Society – Christmas Concert Catshill Methodist
DRAMA for children and their families is on
ROCK lovers can re-live the Queen experience with 'Mercury' one ...
RUFUS Wainwright performs Live at the RSC in Stratford on ...
Visit the Worcester Observer website for the latest.
THE REGAL will play host to bassist and composer Kyle ...