U.S. patent application number 12/249786 was filed with the patent office on 2009-05-07 for registers for data transfers.
This patent application is currently assigned to Intel Corporation. Invention is credited to Matthew Adiletta, Debra Bernstein, Mark B. Rosenbluth, Hugh M. Wilkinson, III, GILBERT WOLRICH.
Application Number | 20090119671 12/249786 |
Document ID | / |
Family ID | 28674046 |
Filed Date | 2009-05-07 |
United States Patent
Application |
20090119671 |
Kind Code |
A1 |
WOLRICH; GILBERT ; et
al. |
May 7, 2009 |
REGISTERS FOR DATA TRANSFERS
Abstract
A system and method for employing registers for data transfer in
multiple hardware contexts and programming engines to facilitate
high performance data processing. The system and method includes a
processor that includes programming engines with registers for
transferring data from one of the registers residing in an
executing programming engine to a subsequent one of the registers
residing in an adjacent programming engine.
Inventors: |
WOLRICH; GILBERT;
(Framingham, MA) ; Rosenbluth; Mark B.; (Uxbridge,
MA) ; Bernstein; Debra; (Sudbury, MA) ;
Adiletta; Matthew; (Bolton, MA) ; Wilkinson, III;
Hugh M.; (Newton Center, MA) |
Correspondence
Address: |
FISH & RICHARDSON, PC
P.O. BOX 1022
MINNEAPOLIS
MN
55440-1022
US
|
Assignee: |
Intel Corporation
Santa Clara
CA
|
Family ID: |
28674046 |
Appl. No.: |
12/249786 |
Filed: |
October 10, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10116670 |
Apr 3, 2002 |
7437724 |
|
|
12249786 |
|
|
|
|
Current U.S.
Class: |
718/103 ;
711/108; 711/147; 711/E12.001; 712/220; 712/225; 712/E9.023;
712/E9.027; 718/100 |
Current CPC
Class: |
G06F 9/30101 20130101;
G06F 9/30123 20130101; G06F 9/3851 20130101; G06F 9/3012 20130101;
G06F 9/4843 20130101 |
Class at
Publication: |
718/103 ;
712/225; 712/220; 718/100; 711/147; 711/108; 712/E09.027;
712/E09.023; 711/E12.001 |
International
Class: |
G06F 9/46 20060101
G06F009/46; G06F 9/44 20060101 G06F009/44; G06F 15/00 20060101
G06F015/00; G06F 9/30 20060101 G06F009/30; G06F 12/00 20060101
G06F012/00 |
Claims
1-30. (canceled)
31. A processor comprising: multiple processing units; and a
register set configured and arranged to transfer information
between at least two of the processing units; where the register
set comprises multiple registers configured to be selected in a
first-in-first-out order by a ring operation performed with respect
to the multiple registers in the first-in-first-out order.
32. The processor of claim 31, further comprising: a Put register
to indicate a destination register in the multiple registers; and a
Get register to indicate a source register in the multiple
registers.
33. The processor of claim 31, where the multiple processing units
comprise programming engines arranged in a context pipeline
configured to execute multiple threads, the register set comprises
one of multiple register sets configured and arranged to transfer
information between programming engines, and at least one of the
multiple register sets comprises registers configured to be
selected by a context-relative operation.
34. The processor of claim 33, where the at least one of the
multiple register sets comprises the register set comprising the
multiple registers configured to be selected in the
first-in-first-out order by the ring operation.
35. The processor of claim 34, where the programming engines are
configured to support a functional pipeline, and the multiple
register sets are configured to support passing of a function in
the functional pipeline between the programming engines.
36. The processor of claim 35, where the functional pipeline
relates to network packet processing tasks, and the multiple
threads process network packets.
37. The processor of claim 35, where the programming engines
perform inter-thread signaling.
38. The processor of claim 34, where each programming engine
comprises a content addressable memory (CAM) to maintain context
information for the programming engine.
39. The processor of claim 31, where each of the multiple
processing units comprises a control store to hold a microprogram
for the processing unit to execute, and the processor further
comprises a processor core to load the microprogram into the
control store.
40. A method comprising: performing operations using multiple
processing units; and transferring information between at least two
of the processing units using a register set: where the
transferring comprises selecting registers of the register set in a
first-in-first-out order by a ring operation performed with respect
to the registers in the first-in-first-out order.
41. The method of claim 40, where the transferring comprises:
putting information into a destination register selected from the
registers based on a value stored in a Put register; and getting
information from a source register selected from the registers
based on a value stored in a Get register.
42. A system comprising: a shared memory; and a parallel,
hardware-based multithreaded network processor comprising a memory
controller, multiple processing units, and a register set
configured and arranged to transfer information between at least
two of the processing units, where the register set comprises
multiple registers configured to be selected in a
first-in-first-out order by a ring operation performed with respect
to the multiple registers in the first-in-first-out order.
43. The system of claim 42, the processor further comprising: a Put
register to indicate a destination register in the multiple
registers; and a Get register to indicate a source register in the
multiple registers.
44. The system of claim 42, where the multiple processing units
comprise programming engines arranged in a context pipeline
configured to execute multiple threads, the register set comprises
one of multiple register sets configured and arranged to transfer
information between programming engines, and at least one of the
multiple register sets comprises registers configured to be
selected by a context-relative operation.
45. The system of claim 44, where the at least one of the multiple
register sets comprises the register set comprising the multiple
registers configured to be selected in the first-in-first-out order
by the ring operation.
46. The system of claim 45, where the programming engines are
configured to support a functional pipeline, and the multiple
register sets are configured to support passing of a function in
the functional pipeline between the programming engines.
47. The system of claim 46, where the functional pipeline relates
to network packet processing tasks, and the multiple threads
process network packets.
48. The system of claim 46, where the programming engines perform
inter-thread signaling.
49. The system of claim 45, where each programming engine comprises
a content addressable memory (CAM) to maintain context information
for the programming engine.
50. The system of claim 42, where each of the multiple processing
units comprises a control store to hold a microprogram for the
processing unit to execute, and the processor further comprises a
processor core to load the microprogram into the control store.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation application and claims
priority to U.S. application Ser. No. 10/116,670, filed on Apr. 3,
2002 (issuing as U.S. Pat. No. 7,437,724), the content of which is
incorporated herein in its entirety.
BACKGROUND
[0002] Parallel processing is an efficient form of information
processing of concurrent events in a computing process. Parallel
processing demands concurrent execution of many programs, in
contrast to sequential processing. In the context of parallel
processing, parallelism involves doing more than one thing at the
same time. Unlike a serial paradigm where all tasks are performed
sequentially at a single station or a pipelined machine where tasks
are performed at specialized stations, with parallel processing,
many stations are provided, each capable of performing and carrying
out various tasks and functions simultaneously. A number of
stations work simultaneously and independently on the same or
common elements of a computing task. Accordingly, parallel
processing solves various types of computing tasks and certain
problems are suitable for solution by applying several instruction
processing units and several data streams.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] FIG. 1 is a block diagram of a processing system.
[0004] FIG. 2 is a detailed block diagram of the processing system
of FIG. 1 where one of the embodiments of the invention may be
advantageously practiced.
[0005] FIG. 3 is a block diagram of a functional pipeline unit of
the processing system of FIG. 1.
[0006] FIG. 4 is a block diagram illustrating details of the
processing system of FIG. 1 where one of the embodiments of the
invention may be advantageously practiced.
[0007] FIG. 5 is a simplified block diagram of a context pipeline
process.
[0008] FIG. 6 is a flowchart illustrating the process of a context
pipeline where one of the embodiments of the invention may be
advantageously practiced.
[0009] FIG. 7 is a flowchart illustrating the process of
determining the address of the Next Neighbor registers.
DESCRIPTION
Architecture
[0010] Referring to FIG. 1, a computer processing system 10
includes a parallel, hardware-based multithreaded network processor
12. The hardware-based multithreaded processor 12 is coupled to a
memory system or memory resource 14. Memory system 14 includes
dynamic random access memory (DPAM) 14a and static random access
memory 14b (SRAM) . The processing system 10 is especially useful
for tasks that can be broken into parallel subtasks or functions.
Specifically, the hardware-based multithreaded processor 12 is
useful for tasks that are bandwidth oriented rather than latency
oriented. The hardware-based multithreaded processor 12 has
multiple functional microengines or programming engines 16a-16h
(collectively, programming engines 16) each with multiple hardware
controlled threads that are simultaneously active and independently
work on a specific task.
[0011] The programming engines 16 each maintain program counters in
hardware and states associated with the program counters.
Effectively, corresponding sets of context or threads can be
simultaneously active on each of the programming engines 16 while
only one is actually operating at any one time.
[0012] In this example, eight programming engines 16a-16h are
illustrated in FIG. 1. Each programming engine 16a-16h processes
eight hardware threads or contexts. The eight programming engines
16a-16h operate with shared resources including memory resource 14
and bus interfaces (not shown). The hardware-based multithreaded
processor 12 includes a dynamic random access memory (DRAM)
controller 18a and a static random access memory (SRAM) controller
18b. The DRAM memory 14a and DRAM controller 18a are typically used
for processing large volumes of data, e.g., processing of network
payloads from network packets. The SRAM memory 14b and SRAM
controller 18b are used in a networking implementation for low
latency, fast access tasks, e.g., accessing look-up tables, memory
for the core processor 20, and the like.
[0013] The eight programming engines 16a-16h access either the DRAM
memory 14a or SRAM memory 14b based on characteristics of the data.
Thus, low latency, low bandwidth data are stored in and fetched
from SRAM memory 14b, whereas higher bandwidth data for which
latency is not as important, are stored in and fetched from DRAM
memory 14a. The programming engines 16 can execute memory reference
instructions to either the DRAM controller 18a or SRAM controller
18b.
[0014] The hardware-based multithreaded processor 12 also includes
a processor core 20 for loading microcode control for the
programming engines 16. In this example, although other types of
processor cores may be used in embodiments of this invention, the
processor core 20 is an XScale.TM. based architecture, designed by
Intel.RTM. Corporation, of Santa Clara, Calif.
[0015] The processor core 20 performs general-purpose computer type
functions such as handling protocols, exceptions, and extra support
for packet processing where the programming engines 16 pass the
packets off for more detailed processing such as in boundary
conditions.
[0016] The processor core 20 executes an operating system (not
shown). Through the operating system (OS), the processor core 20
can call functions to operate on the programming engines 16a-16h.
For the core processor 20 implemented as an XScale.TM.
architecture, operating systems such as Microsoft.RTM. NT real-time
of Microsoft.RTM. Corporation, of Seattle, Wash., VxWorks.RTM.
real-time operating system of WindRiver.RTM., of Alameda, Calif.,
or a freeware OS available over the Internet can be used.
[0017] Advantages of hardware multithreading can be explained by
SRAM or DRAM memory accesses. As an example, an SRAM access
requested by a context (e.g., Thread.sub.--0), from one of the
programming engines 16, e.g., programming engine 16a, will cause
the SRAM controller 18b to initiate an access to the SRAM memory
14b. The SRAM controller 18b accesses the SRAM memory 14b, fetches
the data from the SRAM memory 14b, and returns data to a requesting
programming engine 16.
[0018] During an SRAM access, if one of the programming engines
16a-16h has a single thread that could operate, that programming
engine would be dormant until data was returned from the SRAM
memory 14b.
[0019] By employing hardware context swapping within each of the
programming engines 16a-16h, the hardware context swapping enables
other contexts with unique program counters to execute in that same
programming engine. Thus, another thread e.g., Thread.sub.--1 can
function while the first thread, Thread.sub.--0, is awaiting the
read data to return. During execution, Thread.sub.--1 may access
the DRAM memory 14a. While Thread.sub.--1 operates on the DRAM
unit, and Thread.sub.--0 is operating on the SRAM unit, a new
thread, e.g., Thread.sub.--2 can now operate in the programming
engine 16. Thread.sub.--2 can operate for a certain amount of time
until it needs to access memory or perform some other long latency
operation, such as making an access to a bus interface. Therefore,
simultaneously, the multi-threaded processor 12 can have a bus
operation, an SRAM operation, and a DRAM operation all being
completed or operated upon by one of the programming engines 16 and
have one more threads or contexts available to process more
work.
[0020] The hardware context swapping also synchronizes the
completion of tasks. For example, two threads can access the shared
memory resource, e.g., the SRAM memory 14b. Each one of the
separate functional units, e.g., the SRAM controller 18b, and the
DRAM controller 18a, when they complete a requested task from one
of the programming engine threads or contexts reports back a flag
signaling completion of an operation. When the programming engines
16a-16h receive the flag, the programming engines 16a-16h can
determine which thread to turn on.
[0021] One example of an application for the hardware-based
multithreaded processor 12 is as a network processor. As a network
processor, the hardware-based multithreaded processor 12 interfaces
to network devices such as a Media Access Controller (MAC) device,
e.g., a 10/100 BaseT Octal MAC or a Gigabit Ethernet device
compliant with IEEE 802.3. In general, as a network processor, the
hardware-based multithreaded processor 12 can interface to any type
of communication device or interface that receives or sends large
amount of data. The computer processing system 10 functioning in a
networking application can receive network packets and process
those packets in a parallel manner.
Registers in Programming Engines
[0022] Referring to FIG. 2, one exemplary programming engine 16a
from the programming engines 16, is shown. The programming engine
16a includes a control store 30, which in one example includes a
RAM of 4096 instructions, each of which is 40-bits wide. The RAM
stores a microprogram that the programming engine 16a executes. The
microprogram in the control store 30 is loadable by the processor
core 20 (FIG. 1).
[0023] In addition to event signals that are local to an executing
thread, the programming engine 16a employs signaling states that
are global. With signaling states, an executing thread can
broadcast a signal state to all programming engines 16a-16h. Any
and all threads in the programming engines can branch on these
signaling states.
[0024] As described above, the programming engine 16a supports
multi-threaded execution of eight contexts. This allows one thread
to start executing just after another thread issues a memory
reference and must wait until that reference completes before doing
more work. Multi-threaded execution is critical to maintaining
efficient hardware execution of the programming engine 16a because
memory latency is significant. Multi-threaded execution allows the
programming engines 16 to hide memory latency by performing useful
independent work across several threads.
[0025] The programming engine 16a, to allow for efficient context
swapping, has its own register set, program counter, and context
specific local registers. Having a copy per context eliminates the
need to move context specific information to and from shared memory
and programming engine registers for each context swap. Fast
context swapping allows a context to perform computations while
other contexts wait for input-output (I/O), typically, external
memory accesses to complete or for a signal from another context or
hardware unit.
[0026] General Purpose Registers The programming engine 16a
executes the eight contexts by maintaining eight program counters
and eight context relative sets of registers. A number of different
types of context relative registers, such as general purpose
registers (GPRs) 32, inter-programming agent registers (not shown),
Static Random Access Memory (SRAM) input transfer registers 34,
Dynamic Random Access Memory (DRAM) input transfer registers 36,
SRAM output transfer registers 38, DRAM output transfer registers
40.
[0027] The GPRs 32 are used for general programming purposes. The
GPRs 32 are read and written exclusively under program control. The
GPRs 32, when used as a source in an instruction, supply operands
to an execution datapath 44.
[0028] The execution datapath 44 can take one or two operands,
perform an operation, and optionally write back a result. The
execution datapath 44 includes a content addressable memory (CAM)
45. Each entry of the CAM 45 stores a 32-bit value, which can be
compared against a source operand. All entries are compared in
parallel and the result of the lookup is a 6-bit value.
[0029] When used as a destination in an instruction, the GPRs 32
are written with the result of the execution datapath 44. The
programming engine 16a also includes I/O transfer registers 34, 36,
38 and 40 which are used for transferring data to and from the
programming engine 16a and locations external to the programming
engines 16a, e.g., the DRAM memory 14a, the SRAM memory 14b, and
the like.
Transfer Registers
[0030] The programming engine 16a also includes transfer registers
34, 36, 38 and 40. Transfer registers 34, 36, 38 and 40 are used
for transferring data to and from the programming engine 16a and
locations external to the programming engine, e.g., DRAMs, SRAMs
etc. There are four types of transfer registers as illustrated in
FIG. 2, namely, input transfer registers and output transfer
registers.
[0031] The input transfer registers, when used as a source in an
instruction, supply operands to the execution datapath 44, whereas
output transfer registers are written with the result from the
execution datapath 44 when utilized as a destination in an
instruction.
Local Control and Status Registers (CSRs)
[0032] Local control and status registers (CSRs) 37 are external to
the execution datapath 44 and hold specific purpose information.
They can be read and written by special instructions (local_csr_rd
and local_csr_wr) and are typically accessed less frequently than
datapath registers.
Next Neighbor Registers
[0033] The programming engine 16a also includes one hundred and
twenty eight (128) Next Neighbor (NN) registers, collectively
referred to as NN registers 35. Each NN Register 35, when used as a
source in an instruction, also supplies operands to the execution
datapath 44. Each NN register 35 is written either by an external
entity, not limited to, an adjacent programming engine, or by the
same programming engine 16a where each NN register 35 resides. The
specific register is selected by a context-relative operation where
the register number is encoded in the instruction, or as a ring
operation, selected via, e.g., NN_Put (NN write address) and NN_Get
(NN read address) in the CSR Registers.
[0034] NN_Put registers are used when the previous neighboring
programming engine executes an instruction with NN_Put as a
destination. The NN register selected by the value in this register
is written, and the value in NN_Put is then incremented (a value of
127 wraps back to 0). The value in this register is compared to the
value in NN_Get register to determine when to assert NN_Full and
NN_Empty status signals.
[0035] NN_Get registers are used when the NN register 35 is
accessed as a source, which is specified in the source field of the
instruction. The NN register selected by the value in this register
is read, and the value in NN_Put is then decremented (a value of
127 wraps back to 0). The value in this register is compared to the
value in the NN_Put register to determine when to assert NN_Full
and NN Empty status signals.
[0036] Specifically, when each NN register 35 is used as an origin
in an instruction, the instruction result data are sent out of the
programming engine 16a, typically to another, adjacent programming
engine. On the other hand, when the NN register 35 is used as a
destination in an instruction, the instruction result data are
written to the selected NN Register 35 in the programming engine
16a. The data are not sent out of the programming engine 16a as it
would be when each NN register 35 is used as a destination. Each NN
register 35 is used in a context pipelining method, as described
below.
[0037] A local memory 42 is also used. The local memory 42 includes
addressable storage located in the programming engine 16a. The
local memory 42 is read and written exclusively under program
control. The local memory 42 also includes variables shared by all
the programming engines 16. Shared variables are modified in
various assigned tasks during functional pipeline stages by the
programming engines 16a-16h, which are described next. The shared
variables include a critical section, defining the
read-modify-write times. The implementation and use of the critical
section in the computing processing system 10 is also described
below.
Functional Pipelining and Pipeline Stages
[0038] Referring to FIG. 3, the programming engine 16a is shown in
a functional pipeline unit 50. The functional pipeline unit 50
includes the programming engine 16a and a data unit 52 that
includes data, operated on by the programming engine, e.g., network
packets 54. The programming engine 16a is shown having a local
register unit 56. The local register unit 56 stores information
from the data packets 54.
[0039] In the functional pipeline unit 50, the contexts 58 of the
programming engines 16a, namely, Programming Engine 0.1 (PEO.1)
through Programming Engine 0.n (PEO.n), remain with the programming
engine 16a while different functions are performed on the data
packets 54 as time 66 progresses from time=0 to time=t. A
programming execution time is divided into "m" functional pipeline
stages or pipe-stages 60a-60m. Each pipeline stage of the pipeline
stages 60a-60m performs different pipeline functions 62a, 64, or
62p on data in the pipeline.
[0040] The pipeline stage 60a is, for example, a regular time
interval within which a particular processing function, e.g., the
function 62a is applied to one of the data packets 54. A processing
function 62 can last one or more pipelines stages 60. The function
64, for example, lasts two pipeline stages, namely pipeline stages
60b and 60c.
[0041] A single programming engine such as the programming engine
16a can constitute a functional pipeline unit 50. In the functional
pipeline unit 50, the functions 62a, 64, and 62p move through the
functional pipeline unit 50 from one programming engine (e.g.,
programming engine 16a), to another programming engine (e.g.,
programming engine 16b), as will be described next.
[0042] Referring to FIG. 4, the data packets 54 are assigned to
programming engine contexts 58 in order. Thus, if "n" threads or
contexts 58 execute in the programming engine 16a, the first
context 58, "PEO.1" completes processing of the data packet 54
before the data packets 54 from the "PEO.n" context arrives. With
this approach the programming engine 16b can begin processing the
"n+1" packet.
[0043] Dividing the execution time of the programming engine 16a,
for example, into functional pipeline stages 60a-60c results in
more than one of the programming engines 16 executing an equivalent
functional pipeline unit 70 in parallel. The functional pipeline
stage 60a is distributed across two programming engines 16a and
16b, with each of the programming engines 16a and 16b executing
eight contexts each.
[0044] In operation, each of the data packets 54 remains with one
of the contexts 58 for a longer period of time as more programming
engines 16 are added to the functional pipeline units 50 and 70. In
this example, the data packet 54 remains with a context sixteen
data packet arrival times (8 contexts.times.2 programming engines)
because context PE0.1 is not required to accept another data packet
58 until the other contexts 58 have received their data
packets.
[0045] In this example, function 62a of the functional pipeline
stage 60a can be passed from the programming engine 16a to the
programming engine 16b. Passing of the function 62a is accomplished
by using Next Neighbor registers, as illustrated by dotted lines
80a-80c in FIG. 4.
[0046] The number of functional pipeline stages 60a-60m is equal to
the number of the programming engines 16a and 16b in the functional
pipeline units 50 and 70. This ensures that a particular pipeline
stage executes in only one programming engine 16 at any one
time.
Context Pipelining
[0047] Each of the programming engine 16 supports multi-threaded
execution of eight contexts. One reason for this is to allow one
thread to start executing just after another thread issues a memory
reference and must wait until that reference completes before doing
more work. This behavior is critical to maintaining efficient
hardware execution of the programming engines 16a-16f because
memory latency is significant. Stated differently, if only a single
thread execution was supported, the programming engine would sit
idle for a significant number of cycles waiting for references to
complete and thereby reduce overall computational throughput.
Multi-threaded execution allows a programming engine to hide memory
latency by performing useful independent work across several
threads.
[0048] The programming engines 16a-16h (FIG. 1) each have eight
available contexts. To allow for efficient context swapping, each
of the eight contexts in the programming engine has its own
register set, program counter, and context specific local
registers. Having a copy per context eliminates the need to move
context specific information to/from shared memory and programming
engine registers for each context swap. Fast context swapping
allows a context to do computation while other contexts wait for
I/O, typically external memory accesses, to complete or for a
signal from another context or hardware unit.
[0049] Referring now to FIG. 5, the context for a specific assigned
task is maintained on the programming engines 16a-16c using CAM
45a-45c. The packets are processed in a pipelined fashion similar
to an assembly line using NN registers 35a-35c to pass data from
one programming engine to a subsequent, adjacent programming
engine. Data are passed from one stage 90a to a subsequent stage
90b and then from stage 90b to stage 90c of the pipeline, and so
forth. In other words, data are passed to the next stage of the
pipeline allowing the steps in the processor cycle to overlap. In
particular, while one instruction is being executed, the next
instruction can be fetched, which means that more than one
instruction can be in the "pipe" at any one time, each at a
different stage of being processed.
[0050] For example, data can be passed forward from one programming
engine 16 to the next programming engine 16 in the pipeline using
the NN registers 35a-35c, as illustrated by example in FIG. 5. This
method of implementing pipelined processing has the advantage that
the information included in CAM 45a-45c for each stage 90a-c is
consistently valid for all eight contexts of the pipeline stage.
The context pipeline method may be utilized when minimal data from
the packet being processed must advance through the context
pipeline.
[0051] Referring to FIG. 6, as described above, context pipelining
requires that the data resulting from a pipe stage, such as pipe
stage P, be sent to the next pipe stage, e.g., pipe stage P+1
(100). Then, Next Neighbor registers can be written from the ALU
output of the processing engine 16a in pipe stage P (102), and the
Next Neighbor registers can be read as a source operand by the next
programming engine 16b at the pipe stage P+1 (104).
[0052] Referring to FIG. 7, two processes may be used to determine
the address of the Next Neighbor registers to be written in the
programming engine 16b. In one process, each context of the
programming engine 16a may write to the same Next Neighbor
registers for the same context in programming engine 16b (200). In
another method, a write pointer register in the programming engine
16a and a read pointer register in the programming engine 16b may
be used (300) to implement an inter processing engine FIFO (302).
The values of write pointer register in the programming engine 16a
and the read pointer register in the programming engine 16b are
used to produce a full indication checked by the programming engine
16 before inserting data onto the FIFO (304), and an empty
indication may be used the programming engine 16b before removing
data from the FIFO (306). The FIFO Next Neighbor configuration may
provide the elasticity between contexts in the pipe stages P and
P+1. When a context in the pipe stage P+1 finds the Next Neighbor
FIFO is empty, that context can perform a No-op function, allowing
the pipe stage to maintain a predetermined execution rate or "beat"
even if the previous pipe stage may not be supplying an input at
this same rate.
OTHER EMBODIMENTS
[0053] In the examples described above in conjunction with FIGS.
1-7, the computer processing system 10 may implement programming
engines 16 using a variety of network processors.
[0054] It is to be understood that while the invention has been
described in conjunction with the detailed description thereof, the
foregoing description is intended to illustrate and not limit the
scope of the invention, which is defined by the scope of the
appended claims. Other aspects, advantages, and modifications are
within the scope of the following claims.
* * * * *