CN100367257C - SDRAM Controller for Parallel Processor Architecture - Google Patents

Abstract

A parallel, hardware-based multithreaded processor is described. The processor includes a general purpose processor that coordinates system functions and a plurality of microengines that support multiple hardware threads. The processor also includes a memory control system having a 1 st memory controller that sorts memory pointers based on whether the memory pointers point to even banks or odd banks and a 2 nd memory controller that optimizes the memory pointers based on whether the memory pointers point to read pointers or write pointers.

Description

SDRAM Controller for Parallel Processor Architecture

technical field

The invention relates to a memory controller, in particular to such a controller for a parallel processor.

Background technique

Parallel processing is an efficient form of concurrent event information processing in computational processing. In contrast to serial processing, parallel processing requires many programs to be executed simultaneously in the computer. In the case of parallel processing, parallel operations involve doing more than one thing at the same time. Unlike the serial paradigm, where all tasks are performed serially at one station, or pipeline machines, where tasks are performed at dedicated stations, parallel processing employs multiple stations, each capable of performing all tasks. That is, typically all stations or multiple stations are working simultaneously and independently on the same or common elements of the problem. Some problems are amenable to parallel processing.

Memory systems used in parallel processing tasks can be inefficient.

Contents of the invention

According to one aspect of the present invention, a memory controller for a random access memory includes an address and command queue module for holding an address and command queue holding memory pointers from a plurality of micro control units. The storage controller also includes a first read/write queue module for maintaining a first read/write queue, the first read/write queue maintains a memory pointer from the computer bus, and the storage controller also includes a module for maintaining the first read/write queue. A 2nd read/write queue module of 2 read/write queues that holds memory pointers from the core processor. The memory controller also includes a control logic module having an arbiter that detects the fullness of each queue and the status of pending memory pointers to select a memory pointer from one of the queues.

According to yet another aspect of the invention, the controller has a control logic module responsive to a link bit which, when set, allows special processing of contiguous memory pointers. The link bit also controls the arbiter, causing the arbiter to select the functional unit that previously requested the bus. Setting the link bit will control the arbiter such that the arbiter holds the memory pointer from the current queue when the optimized memory bit is also set.

One or more aspects of the invention may provide one or more of the following advantages.

The controller uses memory pointer sorting when optimizing memory bit settings. Memory pointer classification is based on bank pointers that enable one bank to hide precharge from another. Specifically, if the memory system is organized into an odd memory bank and an even memory bank, and the memory controller works in the odd memory bank, the memory controller can start precharging the even memory bank. Precharge is enabled if the memory pointer alternates between odd and even banks.

Additionally, other optimizations are available. For example, merge optimization, open page optimization, chaining, and refresh mechanisms can be used. In the case of merge optimization, operations that can be merged are merged before memory access, while in the case of open page optimization, the open page of the memory is no longer accessed by checking the address. open.

Another feature of the controller is that the controller uses a "link bit" in addition to the settable optimized memory bit when storing a memory pointer in the queue. Setting the link bit means that special processing of contiguous memory pointers is enabled. Setting the link bit will control the arbiter so that the arbiter selects the functional unit that previously requested the memory bus.

Description of drawings

Figure 1 is a block diagram of a communications system employing a hardware-based multithreaded processor.

FIG. 2 is a specific block diagram of the hardware-based multi-thread processor in FIG. 1 .

FIG. 3 is a block diagram of microengine functional units used in the hardware-based multithreaded processor of FIGS. 1 and 2 .

FIG. 3A is a block diagram of the microengine pipeline in FIG. 3 .

FIG. 3B is a schematic diagram showing the format of a context switch instruction.

Fig. 3C is a block diagram showing the general register address arrangement.

Figure 4 is a block diagram of a memory controller for enhanced bandwidth operation used in a hardware-based multi-threaded processor.

FIG. 4A is a flow chart showing the arbitration strategy of the SDRAM controller in FIG. 4 .

Figure 4B is a timing diagram illustrating the benefits of optimizing the SDRAM controller.

Figure 5 is a block diagram of a memory controller for latency-limited operations as used in a hardware-based multithreaded processor.

Figure 5A is a timing diagram showing the benefits of optimizing the SRAM controller.

FIG. 6 is a block diagram of the communication bus interface of the processor in FIG. 1 .

Detailed ways

Architecture

Referring to FIG. 1 , a communication system 10 includes a parallel, hardware-based multithreaded processor 12 . The hardware-based multithreaded processor 12 is connected to a bus, such as a PCI bus 14 , a memory system 16 and a second bus 18 . System 10 is especially useful for tasks that can be broken down into parallel subtasks or functions. In particular, hardware multi-threaded processor 12 is useful for tasks that are bandwidth oriented rather than latency oriented. The hardware multi-thread processor 12 has multiple microengines 22, respectively equipped with multiple hardware-controlled threads that can act on a task simultaneously and independently.

Hardware multithreading processor 12 also includes a central controller 20 that facilitates loading microcode control over other resources of hardware multithreading processor 12 and performs other general computer type functions, such as handling protocols, exceptions, and microcode Additional support for packet processing when the engine sends out data packets for more detailed processing under conditions such as boundary status. In one embodiment, the processor 20 is based on a StrongArm ^T (Arm is a trademark of Arm Limited, UK) architecture. The general-purpose microprocessor 20 has an operating system. Through the operating system, the processor 20 can invoke functions to operate on the microengines 22a-22f. Processor 20 may utilize any supported operating system, preferably a real-time operating system. For core processors implemented in the StrongArm architecture, operating systems such as Microsoft NT Real Time, VXWorks, and μCUS and freeware operating systems available from the Internet are available.

The hardware multi-thread processor 12 also includes a plurality of functional microengines 22a-22f. These functional microengines (microengines) 22a-22f each hold a plurality of program counters in terms of hardware and their associated states. In fact, each microengine 22a-22f can make corresponding multiple groups of threads work at the same time, and only one real operation at any time.

In one embodiment, there are 6 micro-engines 22a-22f. As shown in the figure, each micro-engine 22a-22f can process 4 hardware threads. The six microengines 22a-22f operate with shared resources including the memory system 16 and the bus interfaces 24 and 28. Memory system 16 includes a controller 26a for synchronous dynamic random access memory (SDRAM) and a controller 26b for static random access memory (SRAM). SDRAM memory 16a and SDRAM controller 26a are typically used to process large amounts of data, such as network payloads from network data packets. SRAM controller 26b and SRAM memory 16b enable low latency, fast access tasks in networked embodiments, such as accessing lookup tables, memory of core processor 20, and the like.

Six microengines 22a-22f access SDRAM16a or SRAM16b according to data characteristics. Therefore, SRAM stores and reads short-latency and small-bandwidth data, while SDRAM stores and reads large-bandwidth data whose latency is not important. The microengines 22a-22f can execute memory pointer instructions to the SDRAM controller 26a or the SRAM controller 26b.

The advantage of hardware multithreading can be illustrated by memory accesses of SRAM or SDRAM. For example, a microengine's access to SRAM requested by thread 0 will cause SRAM controller 26b to initiate access to SRAM memory 16b. The SRAM controller controls arbitration of the SRAM bus, accesses SRAM 16, reads data from SRAM 16b, and returns data to requesting microengines 22a-22b. During SRAM access, if the microengine (such as 22a) has only one operational thread, the microengine will sleep until data is returned from SRAM. By employing hardware context switching within each microengine 22a-22f, the hardware context switching enables other contexts with unique program counters to execute within that same microengine. Thus, while a first thread (eg, thread 0) waits for the read data to return, another thread, eg, thread 1, can function. During execution, thread 1 may access SDRAM memory 16a. While thread 1 is running on the SDRAM unit and thread 0 is running on the SRAM unit, new threads such as thread 2 can be run live in the microengine 22a. Thread 2 may run for some time until the thread needs to access memory or perform some other long-latency operation, such as accessing a bus interface. Therefore, processor 12 can make bus operation, SRAM operation and SDRAM operation all be completed at the same time, or by a microengine 22a to operate on it, complete or working bus operation, SRAM operation and SDRAM operation, and make another Threads can be used to handle more work in the datapath.

Hardware context switching also synchronizes task completion. For example, two threads may hit the same shared resource such as SRAM at the same time. When each independent functional unit such as FBUS (F bus) interface 28, SRAM controller 26a and SDRAM 26b completes the task requested by one of the microengine thread contexts, it will report a sign of notification completion operation. When the microengine receives the sign, it can judge which thread to open.

An example of utilizing a hardware multithreaded processor is as a network processor. As a network processor, the hardware multi-thread processor 12 interfaces with network devices such as media access controllers (eg 10/100BaseT8 MAC 13a or Gigabit Ethernet 13b). Typically acting as a network processor, the hardware multi-thread processor 12 can be used as an interface to any type of communication device or to send and receive large amounts of data. Communication system 10, functioning in a networking application, may receive multiple network data packets from devices 13a and 13b, process the data packets in parallel. Each network data packet may be independently processed using a hardware multithreaded processor 12 .

Another example application of the processor 12 is as an add-on processor for a print engine or as a processor for a storage subsystem (ie, RAID disk storage). Yet another application is as a pairing engine. For example, in the securities industry, the advent of electronic trading requires electronic matching engines to match buy-side and sell-side orders. These and other parallel tasks can be accomplished on system 10 .

Processor 12 includes a bus interface 28 for connecting the processor to second bus 18 . In one embodiment, a bus interface 28 connects the processor 12 with a so-called FBUS 18 (FIFO bus). The FBUS interface 28 is responsible for controlling the processor 12 and for interfacing it with the FBUS 18 . FBUS18 is a 64-bit wide FIFO bus used to interface with Media Access Controller (MAC) devices.

Processor 12 includes a second interface (eg, PCI bus interface 24 ) that connects other system components residing on PCI bus 14 to processor 12 . PCI bus interface 24 provides a high-speed data path 24a to memory 16, such as SDRAM memory 16a. Through this access, data can be transferred from SDRAM 16a via PCI bus 14 through direct memory access (DMA) transfers. The hardware multi-thread processor 12 supports image transfer. The hardware multithreading processor 12 can use multiple DMA channels, so if one target of the DMA transfer is busy, another DMA channel can take over the PCI bus to transfer information to another target to keep the processor 12 efficient. In addition, the PCI bus interface also supports target and host operations. A target operation is one in which a slave device on bus 14 accesses an SDRAM instance through read and write slaves to that operation. During host operation, the processor core 20 directly receives and sends data to the PCI interface 24 .

Each functional unit is connected to one or more internal buses. As will be explained below, the internal bus is a 32-bit dual bus (that is, one bus is used for reading and the other is used for writing). The structure of the hardware multi-thread processor 12 is also configured such that the sum of the bandwidths of the internal buses in the processor 12 is greater than the bandwidth of the external bus connected to the processor 12 . The processor 12 includes an internal core processor bus, such as an ASB bus (Advanced System Bus), which connects the processor core to the storage controllers 26a, 26b and the ASB decoder 30, which will be described later. The ASB bus is a subset of the so-called AMBA bus used with the Strong Arm processor core. Processor 12 also includes a dedicated bus 34 connecting the microengine unit to SRAM controller 26b, ASB converter 30 and FBUS interface 28. A memory bus 38 connects the memory controllers 26a, 26b to the bus interfaces 24, 28 and to the memory system 16 including flash ROM 16c for boot operations and the like.

Referring to FIG. 2, each microengine 22a-22f includes an arbiter that checks flags to determine available worker threads. Any thread from any microengine 22a-22f can access SDRAM controller 26a, SRAM controller 26b or FBUS interface 28. Memory controllers 26a and 26b respectively include a plurality of queues to store pending memory pointer requests. These queues maintain the order of memory pointers or arrange memory pointers to optimize memory bandwidth. For example, if thread 0 is independent or unrelated to thread 1, there is no reason why threads 1 and 0 cannot complete their memory pointers to SRAM cells out of order. Microengines 22a-22f issue memory pointer requests to memory controllers 26a and 26b. Microengines 22a-22f flood memory subsystems 26a and 26b with enough memory pointer operations that memory subsystems 26a and 26b become a bottleneck for processor 12 operations.

If memory subsystem 16 is filled with essentially independent memory requests, processor 12 may perform memory pointer sorting. This memory pointer classification improves the achievable memory bandwidth. As described below, memory pointer sorting reduces dead time or voiding when accessing SRAM. By pointing the memory pointer to the SRAM, the current direction of the signal line is switched between reading and writing, resulting in cavitation or dead time waiting for the current on the conductor connecting the SRAM 16b and the SRAM controller 26b to stabilize.

That is, drivers driving current on the bus need to stabilize before changing state. Therefore, the repetitive cycle of reading followed by writing will reduce the peak bandwidth. Memory pointer sorting allows organizing pointers to memory such that long strings of reads are followed by long strings of writes. This can be used to minimize the dead time of the pipeline to effectively achieve close to the maximum available bandwidth. Pointer sorting helps maintain parallel hardware context threads. For SDRAM, pointer sorting allows one bank to hide precharge from another bank. Specifically, if the memory system 166 is organized into an odd bank and an even bank, and the processor operates on the odd bank, the memory controller can initiate precharging on the even bank. Precharge is possible if the memory pointer alternates between odd and even banks. Processor 12 improves SDRAM bandwidth by arranging the sequence of memory pointers to alternately access relative banks. Additionally, other optimizations may be employed. For example, mergeable operations can be used: merge optimization where merge before memory accesses, open page optimization where memory open pages are not reopened by checking addresses, chaining and flushing mechanisms which will be described below.

The FBUS interface 28 supports receive and transmit flags for each port supported by the MAC device, and also supports interrupt flags to indicate when service is guaranteed. The FBUS interface 28 also includes a controller 28a that processes incoming packet headers from the FBUS 18 . Controller 28a extracts the header of the packet and does a microprogrammable source/sink/protocol hash lookup in SRAM (for address smoothing). If the hash is not successfully resolved, the packet header is sent to processor core 20 for additional processing. The FBUS interface 28 supports the following internal data transactions:

FBUS unit (shared bus SRAM) to/from microengine

FBUS unit (via dedicated bus) Write from SDRAM unit

FBUS unit (via MBUS) read to SDRAM

FBUS18 is a standard industry bus that includes, for example, a 64-bit wide data bus, address sideband control, and read/write control. The FBUS interface 28 can input a large amount of data using a series of input and output FIFOs 29a-29b. The microengines 22a-22f obtain data from the FIFOs 29a-29b, and instruct the SDRAM controller 26a to transfer the data in the receiving FIFOs, which have obtained data from devices on the bus 18, into the FBUS interface 28. The data may be sent to SDRAM memory 16a via direct memory access via memory controller 26a. Similarly, the microengine can move data from SDRAM26a to interface 28 to FBUS18 via FBUS interface 28.

Distribute data functions among microengines. SRAM26a, SDRAM26b, and FBUS28 are connected via command requests. Command requests can be memory requests or FBUS requests. For example, a command request can move data from a register located in the microengine 22a to a shared resource, such as an SDRAM location, an SRAM location, flash memory, or a MAC address. These commands are sent to each functional unit and shared resource. However, shared resources need not maintain local caches of data. Conversely, shared resources access distributed data located inside the microengine. This allows microengines 22a-22f to access data locally, rather than arbitrating access on the bus, risking contention for the bus. Utilizing this feature, the blocking period for waiting for data to arrive inside the microengines 22a-22f is 0.

Data buses such as ASB bus 30, SRAM bus 34, and SDRAM bus 38 connecting these resources (eg, memory controllers 26a and 26b) have sufficient bandwidth so that there is no internal blocking. Therefore, to avoid blocking, the processor 12 has a bandwidth requirement of at least twice the maximum bandwidth of the internal bus provided per functional unit. For example, SDRAM can operate at 83MHz on a 64-bit wide bus. The SRAM data bus may have separate read and write buses, for example, a 32-bit wide read bus operating at 166 MHz and a 32-bit wide write bus operating at 166 MHz. In other words, 64-bit operating at 166Mhz is actually twice the bandwidth of SDRAM.

Core processor 20 can also access shared resources. Core processor 20 communicates directly via bus 32 with SDRAM controller 26a, bus interface 24, and SRAM controller 26b. However, to access the microengines 22a-22f and the transfer registers of any of the microengines 22a-22f, the core processor 24 accesses the microengines 22a-22f on the bus 34 via the ASB converter 30. ASB converter 30 may physically reside at FBUS interface 28, but is logically different. The ASB converter 30 performs address conversion between the FBUS microengine transmission register location and the core processor address (ie ASB bus), so that the core processor 20 can access the registers belonging to the microengines 22a-22c.

While microengines 22 may exchange data with register sets as described below, scratch memory 27 is also provided to enable microengines to write data to this memory for other microengines to read. The scratch pad 27 is connected to the bus 34 .

Processor core 20 includes a RISC core 50 implemented in a 5-stage pipeline that performs single-cycle shifts of 1 operand or 2 operands in a single cycle, multiplication support, and 32-bit barrel shift support. This RISC core 50 has the standard Strong Arm ^T architecture, but is implemented with a 5-stage pipeline for performance reasons. The processor core 20 also includes a 16K byte instruction cache 52 , an 8K byte data cache 54 and a prefetch stream cache 56 . Core processor 20 performs arithmetic operations in parallel with memory writes and instruction reads. The core processor 20 forms an interface with other functional units via the ASB bus stipulated by ARM. The ASB bus is a 32-bit bidirectional bus 32 .

micro engine

Referring to FIG. 3 , an example of microengines 22 a - 22 f is shown, such as microengine 22 f . The microengine includes control memory 70 which in one embodiment includes here up to 1024 words (32 bits per word) of RAM. The RAM stores a microprogram. The microprogram can be loaded by the core processor 20 . Microengine 22f also includes controller logic 72 . The controller logic includes an instruction decoder 73 and program counter (PC) units 72a-72d. Four microprogram counters 72a to 72d are maintained by hardware. The microengine 2f also contains context event switching logic 74 . The context event logic 74 receives messages from each of shared resources such as SRAM 26a, SDRAM 26b or processor core 20, control and status registers (e.g.: Sequence Number#Event Response SEQ_#_EVENT_RESPONSE, FBI Event Response FBI_EVENT_RESPONSE, SRAM Event Response SRAM_EVENT_RESPONSE, SDRAM Event response SDRAM_EVENT_RESPONSE and ASB event response ASB_EVENT_RESPONSE). These messages provide information on whether the requested functionality is complete. Depending on whether the function requested by the thread is completed and whether the signal transmission is completed, the thread needs to wait for the completion signal, and if the thread can work, the thread is placed on the available thread list (not shown). Microengine 22a may have up to, for example, 4 threads available. In addition to executing all event signals locally in the thread, the microengine 22 also uses the global signaling state. With this signaling status, an execution thread can broadcast the signaling status to all microengines 22 . After receiving the request feasible signal, all any threads in the microengine can branch according to these signaling states. These signaling states can be used to determine the availability of a resource or the suitability of a resource to provide a service.

Context event logic 74 has arbitration for 4 threads. In one embodiment, arbitration is a round robin mechanism. Other techniques including priority queuing or weighted fair queuing may be used. The microengine 22f also includes an execution box (EBOX) data path 76, which contains an arithmetic logic unit 76a and a general purpose register set 76b. The arithmetic logic unit 76a performs arithmetic and logic functions and shift functions. The register group 76b has a large number of general-purpose registers. As will be illustrated in FIG. 3B, in this embodiment, the first group (group A) has 64 general-purpose registers, and the second group (group B) also has 64. These general-purpose registers form a window (described later) so that they are relatively and absolutely addressable.

The microengine 22f also includes a write transfer register stack 78 and a read transfer stack 80 . These registers are also windowed so that they are relatively and absolutely addressable. The write data for the resource is located in the write transfer register stack 78 . The read register stack 80 is used for data returned from shared resources. Event signals from shared resources such as SRAM controller 26a, SDRAM controller 26b, or core processor 20, respectively, are provided to contextual event arbitrator 74 in series or in parallel with the arrival of data, alerting threads that data is available or that data has been sent. Transfer register banks 78 and 80 are both connected to execution box (EBOX) 76 by a data path. In one embodiment, there are 64 read transfer registers and 64 write transfer registers.

As shown in FIG. 3A , the microengine data path maintains a 5-stage micropipeline 82 . The pipeline includes lookup microinstruction word 82a, forming register file address 82b, reading operand from register file 82c, ALU or shift or compare operation 82d and writing result back to register 82e. By providing a write-back data bypass to the ALU/shifter unit, the microengine can perform simultaneous reads and writes to the register file, completely hiding write operations, assuming registers are implemented as register files rather than RAM.

The SDRAM interface 26a sends a signal back to the requesting microengine on the read data indicating whether a parity error occurred on the read request. When the microengine uses any data sent back, the microcode of the microengine is responsible for checking the SDRAM read parity flag. When checking the flag, if the flag is set, the branch action clears it. The parity flag is sent only when SDRAM is enabled for parity, which is protected by parity. The microengine and the PCI unit are the only requesters to notify parity errors. Thus, if the processor core 20 or the FIFO requires parity protection, the microengine helps as requested. Microengines 22a-22f support conditional branching. The branch decision result is the worst case of the conditional branch execution time (not including the transfer) when the previous micro-control instruction sets the condition code. Table 1 shows this waiting time as follows:

|1|2|3|4|5|6|7|8|

--------------+----+---+---+----+----+----+----+-- --+

Micro storage lookup |n1|cb|n2|XX|b1|b2|b3|b4|

Register address generation||n1|cb|XX|XX|b1|b2|b3|

register file lookup|||n1|cb|XX|XX|b1|b2|

ALU/shifter/cc||||n1|cb|XX|XX|b1|

write back |||m2||n1|cb|XX|XX|

in,

nx is a pre-branch microword (n1 is set to cc)

cb is conditional branch

bx is the post-branch microword

xx is an abnormal micro character

As shown in Table 1, the condition code n1 is not set until cycle 4, and branch judgment can be made. In this example, cycle 5 is used to search for the branch path. Because the microengine must absorb operations n2 and n3 (2 microwords immediately after the branch) in the pipeline before the branch path fills the pipeline with operation b1, it brings a 2-cycle branch waiting time loss. If no branch is made, microwords will not be absorbed, and execution will continue as usual. The microengine has several mechanisms for reducing or eliminating effective branch latency.

The microengine supports delayed branching. Delayed branching is when the microengine allows 1 or 2 microwords to occur after the branch and before the branch is implemented (i.e. the branch action is "delayed" in time). Therefore, branch latency can be hidden if useful work can be found to fill up the cycles wasted after branch microwords. The following shows a branch delayed by 1 cycle, where n2 is allowed to be executed after cb and before b1:

|1|2|3|4|5|6|7|8|

--------------+----+----+----+----+----+----+----+ ----+

Micro storage lookup |n1|cb|n2|XX|b1|b2|b3|b4|

Register address generation ||n1|cb|n2|XX|b1|b2|b3|

register file lookup|||n1|cb|n2|XX|b1|b2|

ALU/shifter/cc||||n1|cb|n2|XX|b1|

Write back |||||n1|cb|n2|XX|

A 2-cycle delayed branch is shown below, where both n2 and n3 are allowed to complete before the branch to b1 occurs. Note that a 2-cycle branch delay is allowed only when the condition code is set in the microword before branching.

|1|2|3|4|5|6|7|8|9|

--------------+----+----+----+----+----+----+----+ ----+----+

Micro storage lookup |n1|cb|n2|n3|b1|b2|b3|b4|b5|

Register address generation||n1|cb|n2|n3|b1|b2|b3|b4|

register file lookup|||n1|cb|n2|n3|b1|b2|b3|

ALU/shifter/cc||||n1|cb|n2|n3|b1|b2|

write back |||||n1|cb|n2|n3|b1|

The microengine also supports condition code evaluation. If the condition code of the decision branch before the branch is set to 2 or more microwords, since the branch decision can be made 1 cycle earlier, the waiting time of 1 cycle can be eliminated as follows:

|1|2|3|4|5|6|7|8|

--------------+----+----+----+----+----+----+----+ ----+

Micro storage lookup |n1|n2|cb|XX|b1|b2|b3|b4|

Register address generation||n1|n2|cb|XX|b1|b2|b3|

register file lookup|||n1|n2|cb|XX|b1|b2|

ALU/shifter/cc||||n1|n2|cb|XX|b1|

Write back |||||n1|n2|cb|XX|

In this example, n1 sets the condition code, and n2 does not set the condition code. Therefore, the branch decision can be made in cycle 4 instead of cycle 5 to eliminate the 1-cycle branch latency. In the following example, a 1-cycle delay is combined with condition code early setting to completely hide branch latency:

|1|2|3|4|5|6|7|8|

--------------+----+----+----+----+----+----+----+

Micro storage lookup |n1|n2|cb|n3|b1|b2|b3|b4|

Register address generation||n1|n2|cb|n3|b1|b2|b3|

register file lookup|||n1|n2|cb|n3|b1|b2|

ALU/shifter/cc||||n1|n2|cb|n3|b1|

write back |||||n1|n2|cb|n3|

Among them, the condition code cc is set 2 cycles before the 1-cycle delay branch.

In the case that the condition code cannot be set in advance (that is, when the condition code is set in the microword before the branch), the microengine supports branch guessing that tries to reduce the exposed branch waiting time left by 1 cycle. By "guessing" a branch path or a serial path, the microsequencer prefetches a guess path1 before knowing exactly which path to execute. If the guess is correct, the 1-cycle branch waiting time is eliminated as follows:

|1|2|3|4|5|6|7|8|

--------------+----+----+----+----+----+----+----+ ----+

Micro storage lookup |n1|cb|n1|b1|b2|b3|b4|b5|

Register address generation ||n1|cb|XX|b1|b2|b3|b4|

register file lookup|||n1|cb|XX|b1|b2|b3|

ALU/shifter/cc||||n1|cb|XX|b1|b2|

Write back |||||n1|cb|XX|b1|

Where guessing branches and also branches. If the microcode guesses the wrong branch, the microengine still wastes 1 cycle:

|1|2|3|4|5|6|7|8|

--------------+----+----+----+----+----+----+----+ ----+

Micro storage lookup |n1|cb|n1|XX|n2|n3|n4|n5|

Register address generation||n1|cb|n1|XX|n2|n3|n4|

register file lookup|||n1|cb|n1|XX|n2|n3|

ALU/shifter/cc||||n1|cb|n1|XX|n2|

Write back |||||n1|cb|n1|XX|

where the guess is branched but not branched.

However, when the microcode guesses not to branch, the latency penalty is distributed differentially.

There is no wasted cycle for guessing not to branch and not branching, as follows:

|1|2|3|4|5|6|7|8|

--------------+----+----+----+----+----+----+----+ ----+

Micro storage lookup |n1|cb|n1|n2|n3|n4|n5|n6|

Register address generation||n1|cb|n1|n2|n3|n4|n5|

register file lookup|||n1|cb|n1|n2|n1|b4|

ALU/shifter/cc||||n1|cb|n1|n2|n3|

write back |||||n1|cb|n1|n2|

However, for guessing not branching but branching, there are 2 wasted cycles as follows:

|1|2|3|4|5|6|7|8|

--------------+----+----+----+----+----+----+----+ ----+

Micro storage lookup |n1|cb|n1|XX|b1|b2|b3|b4|

Register address generation||n1|cb|XX|XX|b1|b2|b3|

register file lookup|||n1|cb|XX|XX|b1|b2|

ALU/shifter/cc||||n1|cb|XX|XX|b1|

Write back |||||n1|cb|XX|XX|

The microengine can combine branch guessing and 1-cycle branch delay to further improve results. For branching on guess plus 1-cycle delayed branching and also branching, the result is:

|1|2|3|4|5|6|7|8|

--------------+----+----+----+----+----+----+----+ ----+

Micro storage lookup |n1|cb|n2|b1|b2|b3|b4|b5|

Register address generation||n1|cb|n2|b1|b2|b3|b4|

register file lookup|||n1|cb|n2|b1|b2|b3|

ALU/shifter/cc||||n1|cb|n2|b1|b2|

write back |||||n1|cb|n2|b1|

In the above case, by executing n2 and correctly guessing the branch direction, the 2-cycle branch latency is hidden. If the microcode guesses incorrectly, the 1-cycle wait time is still exposed as follows:

|1|2|3|4|5|6|7|8|9|

--------------+----+----+----+----+----+----+----+ ----+----+

Micro storage lookup |n1|cb|n2|XX|n3|n4|n5|n6|n7|

Register address generation||n1|cb|n2|XX|n3|n4|n5|n6|

register file lookup|||n1|cb|n2|XX|n3|n4|n5|

ALU/shifter/cc||||n1|cb|n2|XX|n3|n4|

Write back |||||n1|cb|n2|XX|n3|

Among them, the branch is guessed plus 1 cycle delay but the branch is not taken.

If the microcode guesses correctly and does not branch, the pipeline proceeds in normal undisturbed case order. The microcode incorrectly guesses not to branch, and the microengine exposes 1 cycle of unproductive execution as follows:

|1|2|3|4|5|6|7|8|9|

--------------+----+----+----+----+----+----+----+ ----+----+

Micro storage lookup |n1|cb|n2|XX|b1|b2|b3|b4|b5|

Register address generation||n1|cb|n2|XX|b1|b2|b3|b4|

register file lookup|||n1|cb|n2|XX|b1|b2|b3|

ALU/shifter/cc||||n1|cb|n2|XX|b1|b2|

Write back |||||n1|cb|n2|XX|b1|

where the guess does not branch but does branch, and

nx is a pre-branch microword (n1 is set to cc)

cb is conditional branch

bx is the post-branch microword

xx is an abnormal micro character

In the case of a branch instruction, since the branch address is not known until the end of the cycle in which the branch exists in the ALU stage, the resulting latency of 3 extra cycles is as follows:

|1|2|3|4|5|6|7|8|9|

--------------+----+----+----+----+----+----+----+ ----+----+

Micro storage lookup |n1|jp|XX|XX|XX|j1|j2|j3|j4|

Register address generation||n1|jp|XX|XX|XX|j1|j2|j3|

register file lookup|||n1|jp|XX|XX|XX|j1|j2|

ALU/shifter/cc||||n1|jp|XX|XX|XX|j1|

Write back |||||n1|jp|XX|XX|XX|

context switch

Referring to FIG. 3B , there is shown the format of a context switch instruction. A context switch is a special form of branching that causes the selection of a different context (and its associated PC). Context switches also introduce some branch latency. Consider the following context switch:

|1|2|3|4|5|6|7|8|9|

--------------+----+----+----+----+----+----+----+ ----+----+

Micro Storage Lookup |o1|ca|br|n1|n2|n3|n4|n5|n6|

Register address generation||o1|ca|XX|n1|n2|n3|n4|n5|

register file lookup |||o1|ca|XX|n1|n2|n3|n4|

ALU/shifter/cc||||o1|ca|XX|n1|n2|n3|

write back |||||o1|ca|XX|n1|n2|

in,

ox is the old context stream

br is the branch microword in the old context

ca is context re-arbitration (causing context switching)

nx is the new context stream

XX is an abnormal micro character

In context switching, cause the "br" microword exception to avoid the control and timing complications that would result from retaining the correct old context PC.

0, 1, or 2-cycle branch delay modes can be selected for conditional branches that operate according to the ALU condition code set on the microword before the branch. All other branches (including context re-arbitration) can select 0 or 1 cycle branch delay mode. The architecture can be designed so that the context arbitration microword is within the branch delay window of the preceding branch, diverted, or the microword is made an illegal option. That is to say, in some embodiments, due to the above-mentioned reasons, it will cause excessive complexity to save the old context PC, and context switching is not allowed during branch transitions in the pipeline. The architecture can also be designed so that branches, transitions, or context arbitration microwords within the branch delay window of preceding branches are illegal to avoid complex and unpredictable branch behavior.

Each microengine 22a-22f supports multi-threaded execution of 4 contexts. One reason for this is so that 1 thread can start executing right after another thread posts a memory pointer, and have to wait until that pointer is complete before doing any more work. This performance is critical to maintaining efficient execution of the microengine hardware due to significant memory latencies. In other words, if only one thread is supported, the microengine will idle a large number of cycles, waiting for the pointer to return, thereby reducing the total computing throughput. Multi-threaded execution enables microengines to hide memory latencies by performing useful independent work across multiple threads. 2 synchronization mechanisms are provided so that a thread can issue a SRAM or SDRAM pointer, and when that access is complete, then synchronize with the next point in time.

One mechanism is immediate synchronization. In immediate synchronization, the microengine releases the pointer and immediately swaps out the context. The context is signaled when the corresponding pointer is complete. Once signaled, the context is switched back to execute when a context switch event occurs and it is its turn to act. Thus, from a single-context instruction stream perspective, a microword is not executed after the memory pointer is issued until the pointer is complete.

The second mechanism is delayed synchronization. In delayed synchronization, after the microengine releases the pointer, it continues to perform some other useful work that has nothing to do with the pointer. Over time, it becomes necessary to synchronize the thread execution flow with the completion of the posted pointer before further work. At this point, the synchronization microword is executed, the current thread is swapped out, and the pointer is swapped back when it completes after some time, or the current thread continues because the pointer has been completed. Delay synchronization is achieved with the following 2 different signaling schemes.

If the memory pointer is associated with a transfer register, a signal that triggers the thread is generated when the valid bit of the corresponding transfer register is set or deasserted. For example, when the valid bit of register A is set, the SRAM read signal of storing data in transfer register A is issued. If the memory pointer is associated with the transmit FIFO or receive FIFO, rather than the transmit register, a signal is generated in SDRAM controller 26a when the access is complete. Only one signal state per context is maintained in the microengine scheduler, so there can only be one pending signal in this scheme.

There are at least 2 general operating paradigms by which microcontroller microprogramming can be designed. One is to optimize the overall microcontroller computational throughput and overall memory bandwidth at the expense of a thread execution latency. This paradigm may make sense when the system has multiple microengines executing multiple threads per microengine on unrelated data packets.

The second paradigm is to optimize microengine execution latency at the expense of overall microengine computational throughput and overall memory bandwidth. This paradigm involves executing threads with real-time constraints governing some work that must absolutely be done by some specified time. This constraint requires that optimizations for single-threaded execution be prioritized over other considerations such as memory bandwidth or overall computational throughput. A real-time thread implies a single microengine executing only one thread. The goal is for a single implementation thread to execute as quickly as possible, and multi-threaded execution hinders this performance, so multi-threading is not handled.

The 2 paradigms code significantly differently in terms of issuing memory pointers and context switches. In the real-time case, the goal is to issue as many memory pointers as quickly as possible, so that the memory latency introduced by these pointers is minimized. As many pointers as possible have been released as early as possible, and the goal is for the microengine to perform as many calculations as possible in parallel with the pointers. The calculation flow corresponding to real-time optimization is:

o) Post memory pointer 1

o) Release memory pointer 2

o) Release memory pointer 3

o) Do work unrelated to memory pointers 1, 2, 3

o) Synchronize with completion of memory pointer 1

o) do work that depends on memory pointer 1 and has nothing to do with memory pointers 2 and 3

o) Publish new memory pointers based on previous work

o) Synchronize with completion of memory pointer 2

o) do work that depends on memory pointers 1 and 2 and has nothing to do with memory pointer 3

o) Publish new memory pointers based on previous work

o) Synchronize with completion of memory pointer 3

o) do work that depends on all 3 pointers being done

o) Publish new memory pointers based on previous work

Conversely, optimization for throughput and bandwidth takes a different approach. Single-threaded execution latencies are not considered for microengine computational throughput and overall memory bandwidth. To achieve this, the goal is to evenly space the memory pointers across the microprogram for each thread. This will provide an even flow of memory pointers to the controllers of SRAM and SDRAM, and maximize the probability that a thread will always be available to hide the memory latency associated with swapping out another thread.

Register File Address Type

Referring to FIG. 3C , the two register address spaces that exist are locally accessible registers and globally accessible registers accessible to all microengines. The general purpose registers (GRP) are organized into 2 separate groups (Group A and Group B) whose addresses are word-for-word interleaved such that Group A registers have LSB=0 and Group B registers have LSB=1. Each group can read and write 2 different words in this group at the same time.

Throughout Bank A and Bank B, the register set 76b is also organized into four windows 76b ₀ -76b ₃ of 32 registers that are relatively addressable per thread. Thus, thread 0 finds its register 0 at 77a (register 0), thread 1 its register 0 at 77b (register 32), thread 2 its register 0 at 77c (register 64), and thread 3 its register 0 at 77d (register 96). Its register 0. Relative addressing is supported so that multiple threads can use exactly the same control memory and location, but access different register windows and perform different functions. Register window addressing and register bank addressing are used only in microengine 22f to provide the necessary read bandwidth with dual port RAMS.

These windowed registers need not hold data between context switches, eliminating the usual pushes and pushes to the context switch file or stack. Here context switching has 0 cycle overhead for changing from one context to another. Relative register addressing divides the register set into windows that span the address width of the general register set. Relative addressing allows access to any window relative to the starting point of the window. Absolute addressing is also supported within this architecture, where any thread can access any absolute register by providing the exact address of the register.

Addressing of the general register 48 can occur in two ways, depending on the microword format. These two methods are absolute and relative. In absolute mode, directly specify the addressing of the register address in the 7-bit source segment (a6~a0 or b6~b0):

7 6 5 4 3 2 1 0

+…+…+…+…+…+…+…+…+

A GPR: |a6|0|a5|a4|a3|a2|a1|a0|a6＝0

B GPR: |b6|1|b5|b4|b3|b2|b1|b0|b6＝0

SRAM/ASB: |a6|a5|a4|0|a3|a2|a1|a0|a6=1, a5=0, a4=0

SDRAM: |a6|a5|a4|0|a3|a2|a1|a0|a6＝1，a5＝0，a4＝1

Directly specify the register address in the 8-bit sink segment (d7～d0):

7 6 5 4 3 2 1 0

+…+…+…+…+…+…+…+…+

A GPR: |d7|d6|d5|d4|d3|d2|d1|d0|d7＝0，d6＝0

B GPR: |d7|d6|d5|d4|d3|d2|d1|d0|d7＝0，d6＝1

SRAM/ASB: |d7|d6|d5|d4|d3|d2|d1|d0|d7＝1，d6＝0，d5＝0

SDRAM: |d7|d6|d5|d4|d3|d2|d1|d0|d7＝1，d6＝0，d5＝1

If <a6:a5>=1, 1, <b6:b5>=1, 1 or <d7:d6>=1, 1, the low-end bits are transformed into context-relative address fields (described below). When the A and B absolute fields specify non-relative A or B source addresses, only the lower half of the SRAM/ASB and SDRAM address spaces can be addressed. In fact, SRAM/SDRAM in absolute read mode has an effective address space. However, since this restriction does not apply to the sink segment, the full address space is available for writing SRAM/SDRAM.

In the relative mode, the addressing of the specified address is offset within the context space specified by the 5-bit source segment (a4~a0 or b4~b0):

7 6 5 4 3 2 1 0

+…+…+…+…+…+…+…+…+

A GPR: |a4|0|Context|a2|a1|a0|a4＝0

B GPR: |b7|1|Context|b2|b1|b0|b4＝0

SRAM/ASB: |ab4|0|ab3|context|b1|ab0|ab4=1, ab3=0

SDRAM: |ab4|0|ab3|Context|b1|ab0|ab4＝1，ab3＝1

Or offset the addressing of the specified address in the context space specified by the 6-bit sink segment (d5~d0):

7 6 5 4 3 2 1 0

+…+…+…+…+…+…+…+…+

A GPR: |d5|d4|context d2|d1|d0|d5＝0，d4＝0

B GPR: |d5|d4|context|d2|d1|d0|d5＝0，d4＝1

SRAM/ASB: |d5|d4|d3|context|d1|d0|d5=1, d4=0, d3=0

SDRAM: |d5|d4|d3|context|d1|d0|d5＝1，d4＝0，d3＝1

If <d5:d4>=1,1, the sink address cannot find a valid register, so the sink operand is not written back.

The following registers are globally accessible from the microengine and memory controller:

hash unit register

Notes and Shared Registers

Receive FIFO and Receive Status FIFO

Send FIFO

Transmit Control FIFO

Drive microengines without interruption. Each microflow is executed to completion, a new flow is selected according to the status signaled by other devices in the processor 12 .

Referring to FIG. 4, the SDRAM memory controller 26a includes a memory pointer queue 90 where memory pointer requests arrive from each microengine 22a-22f. The memory controller 26a includes an arbiter 91 that selects the next microengine pointer request to any functional unit. Assuming that a microengine makes an access request, the request will come to the internal address and command queue 90 of the SDRAM controller 26a. If the access request has a set of bits called "optimized storage bits," an incoming pointer request is classified as either an even-group queue 90a or an odd-group queue 90b. If the memory pointer request does not have a memory optimization bit set, the system setting goes to an ordered queue 90c. The SDRAM controller 26 is a resource shared by the FBUS interface 28 , the core processor 20 and the PCI interface 24 . SDRAM controller 26 also maintains a state machine for performing read-modify-write automation. SDRAM controller 26 also byte-aligns SDRAM data requests.

Command queue 90c maintains the ordering of pointer requests from the microengine. From a sequence of odd and even group pointers, the signal may be required to return a signal only when the sequence of memory pointers to both even and odd groups is complete. If the SDRAM storage controller 26a classifies memory pointers into odd group pointers and even group pointers, and the memory pointer leaks out of one of the groups (such as even group) before the odd group, but the signal is positive on the last even pointer, it is conceivable to store Controller 26a may signal back to the microengine that the memory request has been completed, even if the odd set of pointers is not serviced. This phenomenon can cause a coherence problem. This can be avoided by providing an ordered queue 90c so that the microengine can let only the last memory pointer of the plurality of pending memory pointers signal completion.

SDRAM controller 26a also includes a high priority queue 90d. In the high-priority queue 90d, the input memory pointers from one microengine directly enter the high-priority queue, and work with a higher priority than other memory pointers in other queues. Even group queue 90a, odd group queue 90b, command queue 90c and high priority queue 90d, all of which are implemented in one RAM structure. The structure is logically divided into 4 different windows, each window has its own head and tail pointer respectively. Since the fill and drain operations are only a single input and a single output, they can be placed in the same RAM structure to increase the RAM structure density.

SDRAM controller 26a also includes core bus interface logic or ASB bus 92 . ASB bus interface logic 92 forms the interface between core processor 20 and SDRAM controller 26a. The ASB bus is a bus that includes a 32-bit data path and a 28-bit address path. Data is accessed to memory through MEM ASB data devices 98 (eg, buffers). The MEM ASB data device 98 is a write data queue. If there is data coming in from the core processor 20 via the ASB interface 92, the data can be stored in the MEM ASB device 98 and then moved from the MEM ASB device 98 to the SDRAM memory 16a via the SDRAM interface 110. Although not shown, the same queue structure can be provided for readout. SDRAM controller 26a also includes an engine 97 that pulls in data from the microengine and the PCI bus.

Additional queues include a PCI address queue 94 and an ASB read/write queue 96 which hold several requests. The memory request is sent to the SDRAM interface 110 via the multiplexer 106 . The multiplexer 106 is controlled by the SDRAM arbiter 91, which detects the fullness of each queue and the request status, and determines the priority from the detected situation according to the programmable value stored in the priority service control register 100.

Once control of the multiplexer 106 selects a memory pointer request, the memory pointer request is sent to a decoder 108 to decode it and generate an address. The decoded address is sent to SDRAM interface 110, which is decomposed into row address and column address strobe signals to access SDRAM 16a, and data is read or written to bus 112 via data line 16a. In one embodiment, the bus 112 is actually two separate buses rather than a single bus. The separate bus will include a read bus connected to the distributed microengines 22a-22f and a write bus connected to the distributed microengines 22a-22f.

The SDRAM controller 26a is characterized in that, when storing the memory pointer in the queue 90, in addition to setting the optimized storage bit, there is also a "link bit". The link bit allows special handling of contiguous memory pointers when it is set. As noted above, arbiter 12 controls which microengine is selected to provide memory pointer requests to queue 90 (FIG. 4) on the command bus. An assertion of the link bit will control the arbiter to select the functional unit that previously requested the bus, since setting the link bit indicates that the microengine issued a link request.

When the link bit is set, contiguous memory pointers are received in queue 90 . Since contiguous memory pointers are multiple memory pointers from a single thread, these contiguous memory pointers are typically stored in sorted queue 90c. To provide synchronization, the memory controller 26a need only signal the end of the linked memory pointer when done. But in optimized memory linking, (eg when the optimized store bit and the link bit are set) the memory pointers go into different banks, and it is possible to complete one of the memory banks issuing the signal "done" before the other banks are fully exposed, This destroys coherence. Therefore, the controller 110 maintains a memory pointer from the current queue with the link bit.

Referring to FIG. 4A, a flow representation of the arbitration strategy in SDRAM controller 26a is shown. The arbitration policy favors link microengine memory requests. Processing 115 begins with a check 115a of the linked microengine memory pointer request. Process 115 stays on the link request until the link bit is cleared. The process checks for ASB bus request 115b followed by PCI bus request 115c, high priority queue traffic 115d, relative group request 115e, ordered queue request 115f, and same group request 115g. Complete services are provided for link requests, while services 115b-115d are provided in a cyclical order. Only when services 115a-115d are fully leaked does the process proceed to the processing of services 115e-115g. The linked microengine memory pointer request is set when the previous SDRAM memory request has the link bit set. When the link bit is set, the arbitration engine again only serves the same queue until the link bit is cleared. When ASB is in the waiting state, it brings serious performance loss to the Strong Arm core, so the priority of ASB is higher than that of PCI. Because of PCI latency requirements, PCI takes precedence over microengines. But for other buses, this arbitration priority may be different.

As shown in Figure 4B, typical memory timings without and with active memory optimization are shown. It will be appreciated that optimized utilization of available memory maximizes bus utilization, thereby hiding latency inherent in actual SDRAM devices. In this example, 14 cycles are available for non-optimized accesses and 7 cycles for optimized accesses.

Referring to FIG. 5, the memory controller 26b of the SRAM is shown. The memory controller 26b includes an address and command queue 120 . Memory controller 26a (FIG. 4) has a memory optimized queue based on odd and even packets, and memory controller 26b optimizes according to the type of memory operation (ie, read or write). Address and command queues 120 include a high priority queue 120a, a read queue 120b that functions as a master memory pointer implemented by the SRAM, and an ordered queue 120c that typically includes all SRAM reads and writes to be non-optimized. Although not shown, the address and command queue 120 may also include a write queue.

SRAM controller 26b also includes core bus interface logic, ASB bus 122 . ASB bus interface logic 122 forms the interface between core processor 20 and SRAM controller 26b. The ASB bus is a bus including a 32-bit data path and a 28-bit address path. Data is accessed to memory through MEM ASB data devices 128 (eg, buffers). The MEM ASB data device 128 is a write data queue. If there is incoming data from the core processor 20 through the ASB interface 122, the data can be stored in the MEM ASB device 128 and then moved from the MEM ASB device 128 to the SRAM memory 16b through the SRAM interface 140. Although not shown, the same queue structure can be provided for readout. The SRAM controller 26b also includes an engine 127 that pulls in data from the microengine and the PCI bus.

Memory requests are sent to SDRAM interface 140 via multiplexer 126 . The multiplexer 126 is controlled by the SDRAM arbiter 131, which detects the fullness and request status of each queue, and determines the priority from the detected situation according to the programmable value stored in the priority service control register 130. Once control of the multiplexer 126 selects a memory pointer request, the memory pointer request is sent to a decoder 138 to decode it and generate an address. The SRAM cell holds control of the memory-mapped off-chip SRAM and expansion ROM. The SRAM controller 26b can address, for example, 16 Mbytes, while, for example, the 8 Mbytes map for the SRAM 16b is reserved for dedicated functions, including console port memory for the MAC devices 13a, 13b through the boot space of the flash ROM 16. accesses; and accesses to associated (RMON) counters. SRAM is used for local lookup tables and queue management functions.

SRAM controller 26b supports the following transactions:

Microengine requests (via dedicated bus) to/from SRAM

Core processor (via ASB bus) to/from SRAM.

SRAM controller 26b performs memory pointer sorting to minimize latency (cavitation) in the pipeline from SRAM interface 140 to memory 16b. The SRAM controller 26b sorts the memory pointers according to the read function. A void can be 1 cycle or 2 cycles, depending on the type of memory device used.

SRAM controller 26b includes a lock lookup device 142, which is an 8-entry address content addressable memory for lookups for sense locks. Each location includes a valid bit that is checked by subsequent read-lock requests. The address and command queue 120 also includes a read lock invalidation queue 120d. The queue 120d is used to hold read memory pointer requests that are invalidated due to a lock on a portion of the memory. That is to say, the read lock request of the memory request issued by one of the microengines is processed in the address and control queue 120 . This memory request will be run against either the sort queue 120c or the read queue 120b and will be identified as a read lock request. Controller 26b will access lock lookup device 142 to determine whether the memory location is locked. If the storage location was locked by any previous read lock request, the storage lock request will be invalidated and placed in the read lock invalidation queue 120d. If it is unlocked or 142 indicates that the address is not locked, the SRAM interface 140 will use the address of the memory pointer to perform a conventional SRAM address read/write request to the memory 16b. Command controller and address generator 138 will also input the lock into lock lookup device 142 so that subsequent read lock requests will find the memory location locked. After the lock needs to be completed, the storage location is unlocked by operating the micro-control instructions in the program. This position is unlocked by clearing the valid bit in CAM. After unlocking, read lock invalidation queue 120d becomes the highest priority queue, giving all queued read locks lost a chance to issue a memory lock request.

As shown in FIG. 5A, shown are typical timings for SRAM without and with effective memory optimization. It can be known that group reading and writing improves the cycle time by eliminating dead cycles.

Referring to FIG. 6, shown is the communication between the microengine 22 and the FBUS interface logic (FBI). The FBUS interface 28 in the network application can perform header processing on incoming data packets from the FBUS 18 . A key function performed by the FBUS interface 28 is the extraction of the data packet header and the lookup of the microprogrammable source/sink/protocol hash in the SRAM. If the hash cannot be successfully resolved, the data packet header is promoted to the core processor 28 for more advanced processing.

FBI 28 includes transmit FIFO 182, receive FIFO 183, hash unit 188 and FBI control and status register 189. These four units communicate with the microengine 22 through time multiplexed access to the SRAM bus 28 connected to the transfer registers 78, 80 in the microengine. That is to say, all the sending and receiving communications to the microengine pass through the transfer registers 78 and 80 . The FBUS interface 28 includes a push state machine 200 for pushing data into the transfer registers during the time periods when the SRAM does not use the SRAM data bus (partial bus 38) and a push state machine 200 for reading data from the transfer registers in the corresponding microengines. Pull state machine 202 .

The hash unit includes a pair of FIFOs 18a, 188b. The hash unit determines that the FBI 28 received an FBI hash request. The hash unit 188 obtains the hash key from the calling microengine 22 . After the key is read and hashed, the index number is sent back to the calling microengine 22. Under a single FBI hash request, make up to 3 hashes. Both buses 34 and 38 are unidirectional: SDRAM push/pull data bus and S-bus push/pull data bus. Each of the above buses requires control signals that provide read/write control to the transfer registers of the appropriate microengine 22 .

Transfer registers usually require protection of their context controls to ensure correct readout. Specifically, if thread 1 provides data to SDRAM 16a with the write transfer register, thread 1 must wait until the signal returned by SDRAM controller 16a shows that this register has been promoted and can be reused before rewriting this register. Each write does not need to indicate that the signal returned by the destination that has completed the function is because if the thread writes to the same command queue of the destination with multiple requests, the command is guaranteed to be completed in the command queue, so only The last command needs to signal back to this thread. But if the thread uses multiple command queues (instructions and reads), these command requests must be decomposed into separate context tasks in order to hold instructions through context switching. The special case presented at the beginning of this section concerns certain types of operations that employ an unsolicited push (PUSH) of FBI to transfer registers for FBUS status information. In order to protect read/write decisions for transfer registers, the FBI provides a dedicated push protection signal when setting these dedicated FBI push operations.

Any microengine 22 using the FBI unsolicited push method must test the protection flag before accessing the FBUS interface/microengine that the transfer register agrees to. If the flag is not positive, the microengine can access the transfer register. If the flag is positive, the context should wait N cycles before accessing the register. This count is determined a priori based on the number of push registers plus the front-end protection window. The basic idea is that the microengine must test this flag and then quickly move the data it wishes to read from the read transmit register to the GPR in consecutive cycles, so the push engine does not conflict with the microengine read.

Claims (17)

1. A controller for a random access memory used in a parallel processing system, comprising:

an address and command queue module for holding address and command queues for holding memory pointers from a plurality of micro control functional units;

a1 st read/write queue module to hold a1 st read/write queue, the 1 st read/write queue to hold a memory pointer from a computer bus;

a2 nd read/write queue module to hold a2 nd read/write queue, the 2 nd read/write queue to hold a memory pointer from a core processor;

a control logic module including an arbiter that detects fullness of each queue and status of pending memory pointers to select a memory pointer from one of the queues, wherein the control logic module is responsive to an optimized stored bit and a chaining bit, and the setting of the chaining bit controls the arbiter such that when the optimized stored bit is also set, the arbiter holds the memory pointer from the current queue.

2. The controller for a random access memory used in a parallel processing system of claim 1 further comprising a priority traffic control register, the control logic module further selecting one of the queues to provide a next memory pointer based on a programmable value stored in the priority traffic control register.

3. The controller for a random access memory used in a parallel processing system according to claim 1, wherein the address and command queue module comprises:

a high priority queue module to maintain a high priority queue of memory pointers from high priority tasks.

4. The controller for a random access memory used in a parallel processing system according to claim 1, wherein the address and command queue module comprises:

an even group queue module that maintains an even group queue;

an odd group queue module that maintains an odd group queue;

wherein the memory pointers are classified into odd group pointers and even group pointers.

5. The controller as recited in claim 4, wherein the controller checks the optimized memory pointer bits for a memory pointer request, and if the optimized memory pointer bits are set, the controller classifies the memory pointer request as an even array queue or an odd array queue.

6. The controller for a random access memory used in a parallel processing system according to claim 5, wherein the address and command queue module comprises:

an order queue module for maintaining an order queue, and

if the memory pointer request does not set the optimized memory pointer position, the controller stores the memory pointer request in the sorting queue.

7. The controller for a random access memory in a parallel processing system according to claim 1, wherein the address and command queue module is implemented in a single memory structure and comprises:

the sorting queue module is used for storing a sorting queue of the memory pointer;

the even group queue module is used for storing an even group queue of the memory pointer;

the odd group queue module is used for storing an odd group queue of the memory pointer;

a high priority queue module for maintaining a high priority queue of memory pointers, and

the memory structure is partitioned into 4 different queue areas, each with its own head and tail pointers.

8. The controller for a random access memory used in a parallel processing system of claim 7 further comprising an insert queue control logic module and an dequeue arbitration logic module for controlling the address and command queue modules, wherein the insert queue control logic module and the dequeue arbitration logic module control insertion and dequeue of memory pointers in the address and command queues.

9. The controller for a random access memory used in a parallel processing system according to claim 1, further comprising:

a command controller and address generator responsive to addresses from selected memory pointers in one of said queues for generating addresses and commands to control the memory interface, said memory interface responsive to the generated addresses and commands for generating memory control signals.

10. The controller as recited in claim 1, wherein said control logic module is responsive to a chaining bit in a request for a memory pointer, said chaining bit being set to allow exclusive processing of contiguous memory pointers.

11. The controller of claim 10, wherein the setting of the chaining bit controls the arbiter to select the micro control function unit that previously requested the bus, the setting of the chaining bit indicating that the micro control function unit issued the chaining request.

12. A controller for a random access memory for use in a parallel processing system as recited in claim 1, wherein the control logic block is responsive to an optimized memory bit and a chaining bit, and wherein the setting of the chaining bit controls the arbiter such that when the optimized memory bit is also set, the arbiter holds the memory pointer from the current queue until the chaining bit is cleared.

13. The controller for a random access memory for use in a parallel processing system of claim 1 wherein the memory pointer requests from the same micro-control functional unit having the chaining bit set is a chained memory pointer request, the arbiter enforcing an arbitration policy on the chained memory pointer requests.

14. The controller for a random access memory for use in a parallel processing system as set forth in claim 13, wherein the arbiter implements an arbitration policy that services chained memory pointer requests until the chaining bits are cleared.

15. The controller for a random access memory for use in a parallel processing system of claim 1 wherein the arbiter implements an arbitration policy initiated by examining linked memory pointer requests.

16. The controller for a random access memory of a parallel processing system as recited in claim 15, wherein the arbitration policy enables chained memory requests to be fully serviced.

17. The controller for a random access memory of a parallel processing system as set forth in claim 15, wherein when the link bit is set, the arbitration policy re-services the same queue until the link bit is cleared.

Images