JP2005182791A - General purpose embedded processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an embedded processor architecture comprising a plurality of virtual processing units that each execute processes or threads (collectively, "threads"). <P>SOLUTION: One or more execution units, which are shared by the processing units, execute instructions from the threads. An event delivery mechanism delivers events such as, by way of non-limiting example, hardware interrupts, software-initiated signaling events ("software events") and memory events to respective threads without execution of the instructions. Each event can, per aspects of the invention, be processed by the respective threads without execution of the instructions outside that thread. The threads need not be constrained to execute on the same respective processing units during the lives of those threads, though in some embodiments, they can be so constrained. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  This application is filed in United States Patent No. 7, which is assigned to US Patent No. 7, which is assigned to US Patent No. 7, which is assigned to US Patent No. 7, which is assigned to US Patent No. 7, which is assigned to US Patent No. 7, which is assigned to US Patent No. 7, which is assigned to US Patent No. 7, which is assigned to US Patent No. 7 / No. And claims the benefit of its privilege right. The teachings of this application are incorporated herein by reference.

  The present invention relates to digital data processing, and more particularly to embedded processor architecture and operation. The present invention applies to high-definition television, gaming systems, digital video recorders, video and / or audio players, personal digital assistants, personal knowledge navigators, mobile phones, and other multimedia and non-multimedia devices.

  Prior art embedded processor-based or application systems typically (1) one or more general-purpose processors, such as ARM, MIP or x86 variants that handle user interface processing, high-level application processing, and operating system tasks. Are combined with (2) one or more digital signal processors (DSPs) including a media processor for handling specific interfaces or specific types of arithmetic operations within specific applications on a real-time / low-latency basis. Instead of, or in addition to, a DSP, for example, because the DSP cannot handle multiple activities at the same time or the DSP cannot meet the needs of specially specialized computing elements Application specific hardware is often provided to address dedicated needs that cannot be handled on a base.

  These prior art examples typically include a personal computer that combines a main processor with a separate graphics processor and a separate sound processor; typically a gaming system that combines a main processor and a separately programmed graphics processor; typically a general purpose processor A digital video recorder that combines a mpeg2 decoder chip and mpeg2 encoder chip and a special purpose digital signal processor; typically a digital that combines a general purpose processor, mpeg2 decoder chip and mpeg2 encoder chip, and a special purpose DSP or media processor TV; usually a processor for user interface and application processing and mobile phone GSM, CDMA or others Including mobile phones to combine the application-specific DSP for protocol processing.

  U.S. Pat. No. 6,408,381 discloses a pipeline processor that uses a snapshot file having entries indicating the state of instructions at various pipeline stages. As instructions move in the pipeline, the corresponding snapshot file entry is changed. By monitoring these files, the device can transfer intermediate results from one pipeline stage directly to another stage via, for example, an internal operand bus without first being stored in a register.

US Pat. No. 6,219,780 (Patent Document 2) discloses a technique related to improving the throughput of a computer with a plurality of execution units classified into clusters. This patent presents identifying a “consumer” command that is dependent on the result of a “producer” command. Thereafter, multiple copies of each producer instruction are executed, i.e., one copy for each cluster subsequently used to execute the dependent consumer instructions.
US Pat. No. 6,408,381 US Pat. No. 6,219,780

  The reason why a general prior art approach combines a general purpose processor with a DSP and / or application specific hardware is that multiple activities (eg, events or threads) need to be handled simultaneously on a real-time basis, where Thus, each activity requires a different type of computing element. Furthermore, prior art single processors do not have the capacity to handle all of the activities. In addition, some of these activities are of a nature such that prior art processors cannot properly handle two or more of these. This is especially true for real-time activity, and if not unavoidable, operating system intervention reduces the time performance to this.

  One problem with prior art approaches is the complexity of hardware design, which combines the complexity of software in programming and interfacing disparate computing elements. Another problem is that both hardware and software must be re-engineered for each application. Furthermore, prior art systems do not load balance. That is, capacity cannot be transferred from one hardware element to another.

  It is an object of the present invention to provide an improved apparatus and method for digital data processing. It is a further object of the present invention to provide such an apparatus and method that supports running multiple operations on a single processor, whether real-time or not, and to be able to work together. It is to provide a plurality of processors. A related object is to provide such an apparatus and method suitable for embedded environments or applications. Another related object is to provide such an apparatus and method that facilitates design, manufacture, time to market, cost and / or maintenance.

  Further objects of the present invention are present and future including, but not limited to, digital televisions, digital video recorders, video and / or audio players, personal digital assistants, personal knowledge navigators, and mobile phones, to name a few. It is to provide an improved apparatus and method of embedded (or other) processing that meets the calculation, size, power and cost requirements of the appliance.

  Yet another object is to provide an improved apparatus and method that supports various applications.

  Yet another object is to provide such an apparatus and method that is low cost, low power, and / or that supports fast and robust implementation on the market.

  These and other objects are achieved in one aspect by the present invention that provides an embedded processor comprising a plurality of processing units each executing a process or thread (collectively a “thread”). One or more execution units are shared by the processing units to execute instructions from the thread. The event delivery mechanism delivers events (hardware interrupts, software-initiated signaling events (including but not limited to “software events” and memory events) to each thread without executing instructions) Each event can be handled by the respective thread without executing instructions outside that thread.

  According to a related aspect of the invention, while threads are alive, these threads need not be forced to execute on their same processing unit. In yet another related aspect, the execution unit executes instructions from threads without needing to know which threads these instructions are from.

  In another aspect, the present invention provides the above embedded processor further comprising a pipeline control unit that initiates instructions from a plurality of threads for parallel execution on the plurality of execution units. The pipeline control unit may comprise a plurality of instruction queues, each associated with a respective one of the virtual processing units, from which instructions are dispatched. In addition to decoding instruction classes from the instruction queue, the pipeline control unit may be controlled by the virtual processing unit to access resources that provide source and destination registers for dispatched instructions.

  According to another related aspect, there is a branch execution unit among the plurality of execution units. This is responsible for any of instruction address generation, address translation and instruction fetch. The branch execution unit may further maintain the state of the virtual processing unit. This can be controlled by a pipeline control unit, which signals to the branch execution unit when each virtual processing unit instruction queue is empty.

  According to another aspect of the invention, the plurality of virtual processing units described above may execute on an embedded processor. On the other hand, in related aspects, these multiple virtual processing units may execute on multiple embedded processors.

  A further aspect of the invention provides an embedded processor comprising multiple processing units, each executing one or more threads, as described above. The event delivery mechanism delivers events to the respective threads with which the events are associated, as described above, without executing instructions. As described above, the processing unit may be a virtual processing unit. And, as described above, these can run on one or more embedded processors.

  As described above, embedded processors and systems can simultaneously execute multiple threads and handle multiple events with little or no latency and without operating system switching overhead. Threads can range from real-time video processing to Linux operating system functions, end-use applications. Thus, embedded processors and systems include, by way of non-limiting example, high definition digital television, gaming systems, digital video recorders, video and / or audio players, personal digital assistants, personal knowledge navigators, cell phones, and other multimedia. Having applications that support direct execution of various functions required for multimedia or other devices, such as devices and non-multimedia devices.

  In addition, as noted above, embedded processors and systems allow all functions to be single-ended without the need for an application specific hardware accelerator, application specific DSP, application specific processor, or other application specific hardware. Can be deployed and executed in any programming and execution environment. When multiple such embedded processors are added, they operate seamlessly, increasing the total capacity, including both more execution capacity and more parallel thread handling capacity. The addition of these processors is transparent in terms of both threads and events directed to specific threads. Load balancing is also partially transparent, based on how the processor processes and assigns threads.

  Another aspect of the present invention provides a digital data processing system that operates with the structure as described above and does not operate on an embedded platform.

  A further aspect of the invention provides a method for parallelizing the operation of a system as described above.

  These and other aspects of the invention are apparent in the drawings and detailed description that follow.

  The present invention may be more fully understood with reference to the drawings.

  An embedded processor according to the present invention comprises: A plurality of processing units each executing one or more processes or threads (collectively “threads”); One or more execution units shared by the plurality of processing units and communicatively connected to the plurality of processing units, wherein the execution unit executes instructions from the thread A unit; An event delivery mechanism for delivering the event to a respective thread with which the event is associated, wherein the event delivery mechanism is communicatively connected with the plurality of processing units, and ii executes each such event with an instruction And an event delivery mechanism for delivering to each of the threads, thereby achieving the above objective.

  The thread to which the event is delivered may process the event without executing instructions outside the thread.

  The events may include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.

  The execution unit may execute instructions from the thread without needing to know from which thread the instruction is.

  Each thread may or may not be forced to execute on the same processing unit while the thread is alive.

  At least one of the processing units may be a virtual processing unit.

  An embedded processor according to the present invention comprises: A plurality of virtual processing units, each executing one or more processes or threads (collectively “threads”), each thread forcing execution on the same processing unit while the thread is alive B. a plurality of virtual processing units that may or may not be forced; A plurality of execution units; A pipeline control communicatively connected to the plurality of processing units and the plurality of execution units, wherein the pipeline control is configured to Pipeline control for initiating instructions from a plurality of threads; An event delivery mechanism that is communicatively connected to the plurality of processing units and delivers the event to each thread with which the event is associated without execution of an instruction, wherein the event is a hardware interrupt, An embedded processor comprising an event delivery mechanism, including any of software initiated signaling events ("software events") and memory events; The thread to which the event is delivered processes the event without executing instructions outside the thread, thereby achieving the above objective.

  The pipeline control may include a plurality of instruction queues each associated with a respective virtual processing unit.

  The pipeline control may decode an instruction class from the instruction queue.

  The pipeline control may access a resource supply source and a destination register of the instruction dispatched from the instruction queue by the processing unit.

  The execution unit may include a branch execution unit responsible for any of instruction address generation, address translation, and instruction fetch.

  The branch execution unit may maintain the state of the virtual processing unit.

  The pipeline control may access the execution unit by the virtual processing unit.

  The pipeline control may signal a branch execution unit shared by the virtual processing unit when the instruction queue for each virtual processing unit becomes empty.

  The pipeline control may idle the execution unit.

  The plurality of execution units may include any of an integer unit, a floating unit, a branch unit, a comparison unit, and a memory unit.

  An embedded processor system according to the present invention comprises: A plurality of embedded processors; A plurality of virtual processing units executing on the plurality of embedded processors, each virtual processing executing one or more processes or threads (collectively “threads”), and each virtual processing unit comprising: C. a plurality of virtual processing units that may or may not be forced to execute on the same processing unit while the thread is alive; One or more execution units shared by the plurality of processing units and communicatively connected to the plurality of processing units, the execution unit executing instructions from the thread, the execution unit comprising: One or more execution units comprising any of an integer unit, a floating unit, a branch unit, a comparison unit, and a memory execution unit; An event delivery mechanism for delivering the event to a respective thread with which the event is associated, wherein the event delivery mechanism is communicatively connected with the plurality of processing units, and ii executes instructions for each such event. And an event delivery mechanism for delivering to the respective thread, thereby achieving the above object.

  The thread to which the event is delivered may process the event without executing instructions outside the thread.

  The events may include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.

  The branch unit may be responsible for fetching instructions to be executed for the thread.

  The branch unit may further be responsible for either instruction address generation or address translation.

  The branch unit may include a thread state storage device that stores a thread state for each of the virtual processing units.

  An embedded processor system according to the present invention comprises: A pipeline control communicatively connected to the plurality of processing units and the plurality of execution units, wherein the pipeline control is configured to A pipeline control for dispatching instructions from a plurality of threads; The pipeline control includes a plurality of instruction queues each associated with a respective virtual processing unit; Instructions fetched by the branch execution unit may be placed in the instruction queue associated with the respective virtual processing unit in which the corresponding thread is executed. One or more instructions may be fetched at some point for the thread for the purpose of keeping the instruction queue at an equal level.

  The pipeline control may dispatch one or more instructions from a given instruction queue at some point for execution.

  With the pipeline control, a number of instructions dispatched from a given instruction queue at a given time may be controlled by stop flags in the queue's instruction sequence.

  A plurality of instructions from one or more threads may be simultaneously activated by the pipeline control and executed by the execution unit.

  The embedded processor of the present invention includes A. A plurality of processing units, each executing one or more processes or threads (collectively “threads”), each thread being forced to execute on the same processing unit while the thread is alive B. a plurality of processing units, An event delivery mechanism for delivering the event to a respective thread with which the event is associated, wherein the event delivery mechanism is communicatively connected with the plurality of processing units, and ii executes each such event with an instruction And an event delivery mechanism for delivering to each of the threads, thereby achieving the above objective.

  The thread to which the event is delivered may process the event without executing instructions outside the thread.

  The events may include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.

  At least one of the processing units may be a virtual processing unit.

  An embedded processor system according to the present invention comprises: A plurality of embedded processors; A plurality of virtual processing units executing on the plurality of embedded processors, each virtual processing executing one or more processes or threads (collectively “threads”), and each virtual processing unit comprising: C. a plurality of virtual processing units that may or may not be forced to execute on the same processing unit while the thread is alive; An event delivery mechanism for delivering the event to a respective thread with which the event is associated, wherein the event delivery mechanism is communicatively connected with the plurality of processing units, and ii executes instructions for each such event. And an event delivery mechanism for delivering to the respective thread, thereby achieving the above object.

  The thread to which the event is delivered may process the event without executing instructions outside the thread.

  The events may include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.

  The method of embedded processing according to the present invention comprises: B. executing one or more processes or threads (collectively “threads”) on each of the plurality of processing units; C. executing instructions from the thread in one or more execution units shared by the plurality of processing units; Delivering the event to each thread with which the event is associated without executing the instruction, thereby achieving the above objective.

  It may include processing the event delivered by the thread without executing instructions outside the thread.

  The events may include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.

  In the one or more execution units, the step of executing an instruction from the thread may not require knowing from which thread the instruction is.

  Each thread may or may not be forced to execute on the same processing unit while the thread is alive.

  At least one of the processing units may be a virtual processing unit.

  The method of integration processing according to the present invention comprises A. Executing one or more processes or threads (collectively "threads") on each of a plurality of virtual processing units, each thread running on the same processing unit while the thread is alive B. Forced or not forced to perform steps; C. invoking instructions from a plurality of threads of the threads for simultaneous execution on a plurality of units of the execution units; Delivering the event to each thread with which the event is associated without executing an instruction, the event comprising a hardware interrupt, a software initiated signaling event ("software event") and a memory event A step comprising any of: Processing the event delivered by the thread without executing instructions outside the thread, thereby achieving the above objective.

  The step of activating may include the step of decoding an instruction class from the instruction queue.

  The initiating step may include controlling access by the virtual processing unit to a resource supply source and a destination register of the instruction dispatched from the instruction queue.

  A branch execution unit shared by all of the virtual processing units may be used to include any of the steps of instruction address generation, address translation, and instruction fetching.

  The branch execution unit may be used to maintain the state of the virtual processing unit.

  The execution unit may include any one of an integer unit, a floating unit, a branch unit, a comparison unit, and a memory unit.

  The method of embedded processing according to the present invention comprises: B. executing a plurality of virtual processing units on a plurality of embedded processors; Executing one or more processes or threads (collectively “threads”) on each of a plurality of virtual processing units, each thread being the same virtual processing unit and / or while the thread is alive Or forced or not forced to run on the same embedded processor; Executing instructions from the thread in one or more execution units shared by the plurality of processing units, the execution units comprising an integer unit, a floating unit, a branch unit, a comparison unit, and a memory execution A step comprising any of the units; Delivering the event to each thread with which the event is associated without executing the instruction, thereby achieving the above objective.

  It may include processing the event delivered by the thread without executing instructions outside the thread.

  The events may include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.

  The branch execution unit may be used to fetch an instruction to be executed for the thread.

  The branch execution unit may include a step of executing any one of instruction address generation and address translation.

  The method according to the invention comprises: B. dispatching instructions from a plurality of threads of the thread for simultaneous execution on a plurality of units of the execution unit; The dispatching step may include placing an instruction fetched for each respective thread in an instruction queue associated with the virtual processing unit in which the thread is executed.

  The dispatching step may include fetching one or more instructions at a point in time for a given thread for the purpose of keeping the instruction queue at an equal level.

  The dispatching step may include dispatching one or more instructions from a given instruction queue at a point in time for execution by the execution unit.

  With the pipeline control, a number of instructions dispatched from a given instruction queue at a given time may be controlled by stop flags in the queue's instruction sequence.

  The method according to the present invention may include the step of simultaneously invoking and executing a plurality of instructions from one or more threads.

  The method of embedded processing according to the present invention comprises: Executing one or more processes or threads (collectively “threads”) on each of a plurality of processing units, each thread executing on the same processing unit while the thread is alive Forced or not forced, step B. Delivering the event to each thread with which the event is associated without executing the instruction, thereby achieving the above objective.

  It may include processing the event delivered by the thread without executing instructions outside the thread.

  The events may include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.

  At least one of the processing units may be a virtual processing unit.

The method of embedded processing according to the present invention comprises: B. executing a plurality of virtual processing units on a plurality of embedded processors; Executing one or more processes or threads (collectively “threads”) on each of a plurality of virtual processing units, each virtual processing unit being the same virtual processing unit while the thread is alive And / or steps forced or not forced to run on the same embedded processor; and
C. Delivering the event to each thread with which the event is associated without executing the instruction, thereby achieving the above objective.

  The method according to the invention may process the event to which the thread is delivered without executing instructions outside the thread.

  The events may include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.

  FIG. 1 illustrates a processor module 5 that is constructed and operative in accordance with an embodiment of the present invention, and may be referred to as “SEP” herein and in the accompanying drawings. This module may provide the basis for a general purpose processor such as a PC, workstation, or mainframe computer (but the illustrated embodiment is utilized as an embedded processor).

  Module 5 may be used singly or in combination with one or more other such modules, the computing requirements being substantially parallel and multiple applications and / or instruction level parallel executing simultaneously Particularly suitable for devices or systems that benefit from sex. This may include devices or systems with real-time requirements, devices or systems running multimedia applications, and / or devices or systems with advanced computational requirements such as images, signals, graphics and / or network processing. This module is further suitable for integrating multiple applications on a single platform, for example when using applications simultaneously. This module can traverse devices and / or systems in which it is incorporated or otherwise embedded, and across networks (wired, wireless, etc.) or these devices and / or systems To provide seamless applications across other media. Furthermore, this module is suitable for peer-to-peer (P2P) applications and applications with user interactivity. The description so far is not intended to be an extensive list of applications and environments for which module 5 is suitable, but only an example.

  Examples of devices and systems in which the module 5 can be incorporated include, for example, a digital LCD-TV of the type shown in FIG. 24, for example, which is embodied in an SOC (system-on-a-chip) configuration. Is done. (Of course, the modules need not be incorporated on a single chip, but rather probably include multiple chips, one or more substrates, one or more devices housed separately, and / or combinations thereof. Can be embodied in any of the following form factors.) Further examples include digital video recorders (DVR) and servers, MP3 servers, mobile phones, still and video cameras (DVR), gaming platforms, universal network displays ( For example, a combination of a digital LCD-TV, a network information / Internet appliance, and a general purpose application platform), a G3 mobile phone, a personal digital assistant, and the like.

  Module 5 includes thread processing units (TPUs) 10-20, level one (L1) instruction and data caches 22, 24, level to (L2) cache 26, pipeline control 28 and execution (or functional units) 30-38, , An integer processing unit, a floating point processing unit, a comparison unit, a memory unit, and a branch unit. Units 10-38 are coupled as shown in the drawings and are not specifically described below.

  As an overview, TPUs 10-20 are virtual processing units that are physically implemented within processor module 5, each coupled together, and one (or more) process (s) and / or threads. Process the thread (s) (collectively, the thread (s)) at a given moment. The TPU has a state of each thread represented by a general-purpose register, a predicate register, and a control register. The TPU shares hardware such as activation and pipeline control that activates up to five instructions from any combination of each cycle of a thread. As shown in the drawings, the TPU further shares execution units 30-38 that execute the activated instructions independently without having to know from which thread the activated instructions are from. To do.

  As a further overview, the L2 cache 26 shown is shared by all of the thread processing units 10-20 and stores instructions and data in both internal (local) and external storage of the chip in which the module 5 is incorporated. To do. The L1 instruction cache 22 and data cache 24 shown are also shared by the TPUs 10-20 and mounted on a storage device that is local to the above-described chip (of course, in other embodiments, the level 1 and level 2 caches are It can be seen that it can be a different configuration (for example, completely local to module 5, completely external, or otherwise). ).

  The design of module 5 is scalable. Two or more modules 5 are ganged into a Soc or other configuration, which increases the number of active threads and overall processing power. Based on the threading model used by module 5 and described herein, the resulting increase in TPU is software transparent. The illustrated module 5 has six TPUs 10-20, but other embodiments may have a greater number (and of course, a smaller number) of TPUs. Further, additional functional units may be provided, for example, increasing the number of instructions activated per cycle from 5 to 10-15 or more. As will be apparent in the following description of the L1 and L2 cache structures, these two can be scaled.

The shown module 5 uses Linux as an application software environment. Along with multithreading, this allows real-time and non-real-time applications to run on one platform. This further enables leverage of open source software and applications to improve product functionality. Furthermore, this allows execution of applications by various providers.
(Multithread)
As mentioned above, TPUs 10-20 are virtual processing units that are physically implemented within a single processor module 5, each coupled together and one (or more) threads (at a given moment) Singular (s). A thread can embody a wide range of applications. Examples useful in digital LCD-TV include, for example, MPEG2 signal demultiplexing, MPEG2 video decoding, MPEG audio decoding, digital-TV user interface operations, operating system execution (eg, Linux). Of course, these and / or other applications may be useful in digital LCD TVs and various other devices and systems in which module 5 may be incorporated.

  The threads executed by the TPU are independent, but can communicate through memory and events. During each cycle of the processor module 5, instructions are launched from as many active execution threads as are necessary to utilize the execution units or functional units 30-38. In the illustrated embodiment, a round-robin protocol is imposed on each thread to ensure “fairness” in this regard (however, in other embodiments, privileged protocols or other protocols may be alternatively or additionally May be used). One or more system threads can run on the TPU (eg, to launch an application, facilitate thread activation, etc.), but no operating system intervention is required to run the active thread .

  The basic reason for supporting multiple active threads (virtual processors) per processor is as follows.

Multiple active threads per functional capability processor allow a single multi-threaded processor to replace multiple applications, media, signal processing and network processors. This further allows multiple threads corresponding to applications, images, signal processing and networking to operate and interoperate simultaneously with low latency and high performance. Context switch and interface overhead is minimized. Even within a single image processing application such as code in MP4, a thread can easily, for example, in a pipelined manner to prepare data for frame n + 1 while frame n is being created. Can operate simultaneously.

Multiple active threads per performance processor improve the performance of individual processors by making better use of functional units and allowing memory and other event latencies. It is not uncommon to achieve 2x performance improvements to run up to four threads simultaneously. The increase in power consumption and die size is not critical, thus improving performance, power and price performance per unit. Multiple active threads per processor further reduce performance degradation due to branching and cache misses by executing another thread during these events. In addition, this removes most of the context switch overhead and reduces the latency of real-time activity. In addition, this supports a general high performance event model.

Multiple active threads per implementation processor also provides simplification of the pipeline and the overall design. There is no need for complex branch predication. This is because another thread can operate. This reduces the cost of a single processor chip for multiple processor chips and reduces costs when other complexity is eliminated. Further, this improves the performance per unit power.

  FIG. 2 compares thread processing by a conventional superscalar processor with thread processing of the processor module 5 shown. Referring to FIG. 2A, in a superscalar processor, instructions from a single execution thread (indicated by diagonal stippling) are available based on the actual parallelism and dependencies in the code being executed. Scheduled dynamically to run on an execution unit. This means that on average, most execution units are not available during each cycle. As the number of execution units increases, the utilization rate typically decreases. Furthermore, the execution unit goes idle during the memory system and branch prediction miss / wait.

In contrast, referring to FIG. 2B, in module 5, instructions from multiple threads (shown in different stippling patterns) are executed simultaneously. In each cycle, the module 5 performs scheduling so as to optimally use execution unit resources that can use instructions from a plurality of threads. Thus, the overall utilization and performance of the execution unit is higher while at the same time being transparent to the software.
(Events and threads)
In the illustrated embodiment, events are hardware (or device) events such as interrupts, software events that are equal to device events but initiated by software instructions, and cache miss completion or memory producer-consumer (full -Empty) including memory events such as the result of the conversion. Hardware interrupts are typically translated into device events that are handled by idle threads (eg, target threads or target group threads). Software events can be used, for example, to allow one thread to wake up another thread directly.

  Each event binds to an active thread. If there is no specific thread binding, this binds to the default system thread that is always active in the illustrated embodiment. The thread then processes events appropriately, including scheduling a new thread on the virtual processor. In the absence of a particular thread binding, the target thread transitions from the idle state to the running state when a hardware or software event is delivered (with an event delivery mechanism, as described below). If the target thread is already active and running, the event is directed to the default system thread for handling.

  In the illustrated embodiment, the thread is a memory system stall (blockage for short), including cache misses and synchronization waits; branch miss prediction (very simply shut down); explicit (software or hardware) Waiting for events (generated by); as well as explicit blocking of application threads by system threads.

  In the preferred embodiment of the present invention, the events manipulate the events through the physical processor module 5 and the network that provide the basis for an efficient dynamic distributed execution environment. Thus, for example, a module 5 executing in a digital LCD-TV, or other device or system, executes threads and dynamically spreads over a network (wireless, privileged, etc.), or a server or other Use other media from (remote) devices. Thread and memory based events, for example, ensure that threads can run transparently on any module 5 that operates on that principle. This allows, for example, mobile devices to leverage the power of other network devices. This further allows transparent execution of peer-to-peer and multi-threaded applications on remote network devices. Advantages include improved performance, improved functionality, and reduced power consumption.

  Threads operate at two privilege levels: system and application. A system thread can access all the states of that thread and all other threads in the processor. An application thread can only access the unprivileged state corresponding to itself. By default, thread 0 operates with system privileges. Other threads can be configured for system privileges if they are created by system privilege threads.

  Referring to FIG. 3, in the illustrated embodiment, the thread states are as follows:

Idle state (or inactive)
The thread context is loaded into the TPU and the thread is not executing instructions. An idle thread transitions to an execution state when, for example, a hardware or software event occurs.

A wait state (or active, wait state thread context is loaded into the TPU, but is not currently executing an instruction. A wait thread can, for example, allow a memory instruction to continue, such as a cache operation. When an event that occurs but is awaited is completed, it transitions to an execution state.

Running state (or active, running state)
A thread context is loaded into the TPU and is currently executing instructions. For example, if a memory instruction has to wait for the cache to complete an operation that a cache miss or empty / fill (consumer-producer memory) instruction cannot complete, the memory instruction Transitions to a wait state. If an event instruction is executed, the thread transitions to the idle state.

  Threads disable threads without the thread enable bit (or flag or other indicator) associated with each TPU preventing software from loading and unloading threads to the TPU.

  The processor module 5 distributes the load across the active threads based on the availability of instructions to be executed. This module also attempts to keep the per-thread instruction queue uniformly full. Thus, a thread that remains active executes most instructions.

(Event)
FIG. 4 illustrates an event delivery mechanism in a system according to an embodiment of the invention. When an event is notified to a thread, this thread recognizes the event by pending execution (if currently in the running state) and executing a default event handler at virtual address 0x0, for example.

  In the illustrated embodiment, there are five event types that can be signaled to a particular thread.

示されたイベントキュー４０は、ハードウェアデバイスおよびソフトウェアベースのイベント命令（例えば、ソフトウェア「割り込み」）によって提供されたイベントを仮想スレッド数（ＶＴＮ）およびイベント数を含むタプルの形態で段階的に行う。

The illustrated event queue 40 steps through events provided by hardware devices and software-based event instructions (eg, software “interrupts”) in the form of a tuple containing a virtual thread number (VTN) and an event number. .

当然、ハードウェアデバイスおよびソフトウェア命令によって提供されたイベントは、他の形態で、および／または他の情報を含んで提供されてもよいことが分かる。

Of course, it will be appreciated that events provided by hardware devices and software instructions may be provided in other forms and / or including other information.

  The event tuples are then passed to the event-thread lookup table (also called event table or thread lookup table) 42 in the order received. This lookup table determines which TPU is currently handling each displayed thread. The event is then provided to the TPU (and thus its respective thread) via the event-thread delivery mechanism 44 in the form of a “TPU event” consisting of the number of events. If a thread handling a particular event has not yet been indicated, the corresponding event is passed to the default system thread that is active on one of the TPUs.

  The event queue 40 can be implemented in hardware, software, and / or a combination thereof. The embedded SoC (system-on-a-chip) implementation represented by module 5 is implemented as a series of gates and dedicated buffers that provide the necessary queuing functions. In alternative embodiments, this is accomplished with a software (or hardware) linked list, array, or the like.

  Table 42 establishes a mapping between the event number (eg, hardware interrupt) or event instruction provided by the hardware device and the preferred thread to signal that event. Possible cases are:

No event number entry: Signal to default system thread Provided to thread: Signal a specific number of threads if the thread is running, active or idle, otherwise signal to a specific system thread.

  Table 42 may be a dedicated or other single storage area and maintains an updated mapping of event threads. This table may further constitute a distributed or other plurality of storage areas. Regardless, the table 42 may be implemented in hardware, software, and / or a combination thereof. In the embedded SoC implementation represented by module 5, the table is implemented by a gate that performs a “hardware” lookup in a dedicated storage area (s) that maintains an updated event-red mapping. . This table may also be accessible to software by system level privileged threads that update mappings as new threads are loaded into and / or deactivated and unloaded from TPUs 10-20, for example. In the next embodiment, the table 42 is implemented by a software-based lookup of the storage area that maintains the mapping.

  The event-thread delivery mechanism 44 may also be implemented in hardware, software and / or combinations thereof. In the embedded SoC implementation represented by module 5, the mechanism 44 itself routes the signaled event to a TPU queue implemented as a series of gates and dedicated buffers 46-48 for the event to which queuing is delivered. Realized by a gate (and a latch). As described above, in an alternative embodiment, mechanism 44 is implemented in software (or other hardware structure) that provides the necessary functionality, and similarly, queues 46-48 are software (or hardware) links. This is realized by a list, an array or the like.

  A summary of the procedure for handling hardware and software events (ie, software initiated signaling events or “software interrupts”) in the illustrated embodiment is as follows.

  1. An event is signaled to the TPU that is currently executing the active thread.

  2. The TPU is pending execution of the active thread. The exception status, exception IP, and exception Mem address control register are set to indicate information corresponding to the event based on the type of event. All thread states are valid.

  3. The IPU starts executing the default event handler system privilege at virtual address 0x0, and event signaling is disabled for the corresponding thread unit. The GP registers 0 to 3 and the predicate registers 0 to 1 are used as scratch registers by the event handler and have system privileges. By convention, GP [0] is an event processing stack pointer.

  4). The event handler is reentrant and saves enough state to be able to re-enable event signaling to the corresponding thread execution unit.

  5. The event handler then processes the event. This can only post the event to the SW-based queue or take any other action.

  6). The event handler then restores the state and returns to the original thread execution.

  Memory related events are handled in a somewhat different manner. The pending (memory) event table (PET) 50 holds entries for memory operations (from memory reference instructions) that cause a thread to transition from an execution state to a wait state. The table 50 may be implemented like the event-thread lookup table 42 and holds pending memory operations that initiated the reference, state information, and thread ID addresses. If a memory operation corresponding to an entry in the PEI is complete and there is no other pending operation in the thread's PET, a PET event is signaled to the corresponding thread.

  The outline of the memory event processing according to the illustrated embodiment is as follows.

  1. An event is signaled to the unit that is currently executing the active thread.

  2. If the thread is active-waiting and the event is a memory event, the thread transitions to the active-execution state and continues execution with the current IP. Otherwise, the event is ignored.

As further shown in the drawings, in the illustrated embodiment, thread wait timeouts and thread exceptions are signaled directly to the thread and not passed through the event-thread delivery mechanism 44.
(trap)
The goal of multithreading and events is to ensure that a thread's normal program execution is not prevented. Events and interrupts that occur are handled by the appropriate thread waiting for the event. This is not possible and sometimes forced to interrupt normal processing. SEP supports a trap mechanism for this purpose. The list of actions based on event type is as follows, and the entire list of traps is listed in the system exception status register:

示されたプロセッサモジュール５は、トラップが発生した場合に以下のアクションをとる。

The indicated processor module 5 takes the following actions when a trap occurs.

1. 1. An IP (instruction pointer) specifying the next instruction to be executed is loaded into the exception IP register. 2. The privilege level is stored in bit 0 of the exception IP register. 3. The exception type is loaded into the exception status register. 4. If the exception is associated with a memory unit instruction, the memory address corresponding to the exception is loaded into the exception memory address register. The current privilege level is set in the system. 6. IP (instruction pointer) is cleared (to zero) Execution starts at IP0.

(Virtual memory and memory system)
The processor module 5 shown has a 64-bit virtual address (VA) space, a 64-bit system address (SA) (having different characteristics than a standard physical address), and a sparsely populated VA or SA. A virtual memory and memory system architecture having a segment model of virtual address translation to system address is utilized.

  All memory accessed by TPUs 10-20 is efficiently managed as a cache, but off-chip memory may utilize DDR DRAM or other forms of dynamic memory. Referring back to FIG. 1, in the illustrated embodiment, the memory system is configured with two logic levels. The level 1 cache is divided into a separate data cache 24 and instruction cache 22 with optimal latency and bandwidth. The level 2 cache 26 shown consists of an on-chip part and an off-chip part called extended level 2. Overall, a level 2 cache is a memory system of individual SEP processor (s) 5 and contributes to a distributed “all cache” memory system in an implementation in which multiple SEP processors 5 are used. Of course, it will be appreciated that these multiple processors need not physically share the same memory system, chip or bus, but may be connected, for example, via a network or other method.

FIG. 5 illustrates the VA to SA conversion used in the system shown, which is handled segment by segment, where (in the illustrated embodiment) the size of these segments is, for example, 2 It can vary and ^{24-2 48} bytes. The SA is cached in the memory system. Thus, the SA present in the memory system has an entry at one of the cache 22/24, 26 levels. SAs that are not present in the cache (and memory system) are virtually absent from the memory system. Thus, the memory system is sparsely populated in a software and OS specific manner at page (and subpage) granularity and without page table overhead on the processor.

  In addition to the above, the virtual memory and memory system architecture of the illustrated embodiment has the following additional features. These include distributed shared memory (DSM), file (DSF), object (DSO), peer-to-peer (DSP2P) direct support; scalable cache and memory system architecture; segments that can be shared between threads; lookups in parallel with tag access Therefore, it is a high-speed level 1 cache that does not involve complete virtual-physical address translation or the complexity of a virtual cache.

(Overview of virtual memory)
The virtual address in the system shown is a 64-bit address constructed by a memory reference and a branch instruction. Virtual addresses are translated segment by segment into a system that is used to access all system memory and IO devices. Each segment varies in size from 2 ²⁴ to 2 ⁴⁸ bytes. More specifically, referring to FIG. 5, using virtual address 50, entries are matched in segment table 52 in the manner shown in the drawing. When used in combination with the virtual address component identified in the drawing, the matched entry 54 identifies the corresponding system address. In addition, the matched entry 54 identifies the corresponding segment size and privilege. The system address then maps to system memory (in the illustrated embodiment, comprising ²⁶⁴ bytes filled separately). The illustrated embodiment allows address translation to be disabled by a thread with system privileges, in which case the segment table is bypassed and all addresses are rounded to low 32 bits.

  The segment table 52 shown comprises 16 to 32 entries per thread (TPU). This table may be implemented in hardware, software and / or combinations thereof. In the embedded SoC implementation represented by module 5, the table is implemented in hardware and a separate entry in memory is provided for each thread (eg, a separate table for each thread). A segment can be shared between two or more threads by setting up a separate entry for each thread that exhibits the same system address. For this purpose, other hardware or software structures may be used alternatively or additionally.

(Overview of cache memory system)
As described above, the level 1 cache is organized as a separate level 1 instruction cache 22 and 1 level 1 data cache 24 to maximize instruction and data bandwidth.

  Referring to FIG. 6, the on-chip L2 cache 26a includes a tag and a data portion. In the embodiment shown, this is a size of 5.1 Myte, 128 blocks, 16 way association. Each block stores 128 bytes of data or 16 extended L2 tags, and 64 kbytes are provided for storage in the extended L2 tags. The tag mode bit in the tag indicates that the data part is composed of 16 tags in the extended L2 cache.

  The extended L2 cache 26b is based on DDR DRAM as described above, but other memory types may be used. In the illustrated embodiment, the size is up to 1 gbyte, is 256-way associative, and has 16 kbyte pages and 128 byte subpages. For the configuration of 5 mbyte L2 cache 26a and 1 gbyte L2 extended cache 26b, only 12% of the on-chip L2 cache is required to fully describe the L2 extension. For larger on-chip L2 or smaller L2 expansion sizes, this percentage is lower. Aggregation of L2 cache (on-chip and expansion) constitutes a distributed SEP memory system.

  In the illustrated embodiment, both L1 instruction cache 22 and L1 data cache 24 are 8-way associative and have 32 kbytes and 128 byte blocks. As shown in the drawing, both level 1 caches are unique subsets of the level 2 cache. Level 2 cache is composed of on-chip and off-chip extended L2 cache.

  FIG. 7 shows the L2 cache 26 a and, in the example shown, the logic used to perform a tag lookup in the L2 cache 26 a and identify the data block 70 that matches the L2 cache address 78. In the illustrated embodiment, the logic comprises 16 cache tag array groups 72a-72p, corresponding tag comparison elements 74a-74p, and corresponding data array groups 76a-76p. As shown, these are combined to match the L2 cache address 78 against the group tag arrays 72a-72p and, as further shown, the data block 70 identified by the indicated data array group 76a-76p. select.

  Cache tag array groups 72a-72p, tag comparison elements 74a-74p, and corresponding data array groups 76a-76p may be implemented in hardware, software, and / or combinations thereof. In the embedded SoC implementation represented by module 5, these are implemented as shown in FIG. FIG. 19 shows cache tag array groups 72a-72p embedded in a 32x256 single port memory cell and data array groups 76a-76p incorporated in a 128x256 single port memory cell, all as shown. , Coupled with the current state control logic 190. As shown, this element then directs requests from the L1 instruction and data caches 22, 24 in a manner consistent with the state machine 192 that facilitates the operation of the L2 cache unit 26a. Coupled to a request queue 192 for buffering.

  The logic element 190 is further coupled to a DDR DRAM control interface 26c that provides an interface to the off-chip portion 26b of the L2 cache. Similarly, this includes a liquid crystal display (LCD), an audio output interface, a video input interface, a video output interface, a network interface (wireless, wired, etc.), a storage device interface, a peripheral interface (eg, USB, It is coupled to an AMBA interface 26d that provides an interface to components compatible with AMBA such as USB 2) and bus interfaces (PCI, ATA). DDR DRAM interface 26c and AMBA interface 26d are similarly coupled to L1 instruction and data cache interface 196 by L2 data cache bus 198 as shown.

  FIG. 8 similarly illustrates the logic used in the illustrated embodiment to perform a tag lookup in the L2 extended cache 26b and identify the data block 80 that matches the specified address 78. In the illustrated embodiment, the logic comprises data array groups 82a-82p, corresponding tag comparison elements 84a-84p, and tag latches 86. These are combined as shown, matching L2 cache address 78 to data array groups 72a-72p as shown, and matching corresponding portions of address 78 as shown further Select a tag from one of The physical page number from the matching tag is combined with the index portion of address 78, as shown, to identify data block 80 in off-chip memory 26b.

  Data array groups 82a-82p and tag comparison elements 84a-84p may be implemented in hardware, software and / or combinations thereof. In the embedded SoC implementation represented by module 5, these are implemented with gates and dedicated memory that provide the necessary lookup and tag comparison functions. For this purpose, other hardware or software structures may be used alternatively or additionally.

  Described below is pseudo code illustrating the L2 and L2E cache operations of the illustrated embodiment.

（スレッド処理ユニットの状態）
図９を参照して、示された実施形態は、６個までのアクティブスレッドをサポートする６個のＴＰＵを有する。各ＴＰＵ１０〜２０は、図９に示されるように、汎用レジスタと述語レジスタとコントロールレジスタとを備える。システムおよびアプリケーション特権レベルの両方のスレッドは、同じ状態を含むが、システム特権レベルにおいて（キーおよびそれぞれのスティプリングパターンによって示されるように）いくつかのスレッド状態情報のみが見られる。レジスタに加えて、各ＴＰＵは、ペンディングメモリイベントテーブル、イベントキュー、およびイベント−スレッドルックアップテーブルをさらに備えるが、これらのいずれも図９には示されていない。

(Thread processing unit status)
Referring to FIG. 9, the illustrated embodiment has six TPUs that support up to six active threads. As shown in FIG. 9, each TPU 10-20 includes a general-purpose register, a predicate register, and a control register. Both system and application privilege level threads contain the same state, but only some thread state information is seen at the system privilege level (as indicated by the key and the respective stippling pattern). In addition to the registers, each TPU further comprises a pending memory event table, an event queue, and an event-thread lookup table, none of which are shown in FIG.

  Depending on the embodiment, 48 (or less) to 128 (or more) general purpose registers (the illustrated embodiment has 128) and 24 (or less) to 64 (or more) (more than 32 illustrated embodiments). Predicate registers, 6 (below) to 256 (more) active threads (the illustrated embodiment has 8), and 16 (below) to 512 (more) entries (shown). The embodiment has 16 pending entries), multiple, preferably at least 2 (possibly fewer) pending memory events per thread, and 256 ( Event queue with 16 (or less) to 256 (or more) entries (32 in the example shown). There may be a bull.

(General-purpose register)
In the illustrated embodiment, each thread has up to 128 general purpose registers, depending on the implementation. General registers 3-0 (GP [3: 0]) are found at the system privilege level and can be used for event stack pointers and working registers in the early stages of event processing.

(Predication register)
The predicate register is part of the general SEP predication mechanism. Execution of each instruction is conditional based on the value of the reference predicate register.

  SEP provides up to 64 1-bit predicate registers as part of the thread state.

  Each predicate register holds a so-called predicate, which is set to 1 (true) or reset to 0 (false) based on the result of executing the compare instruction. . The predicate register 3-1 (PR “3: 1”) is seen at the system privilege level and can be used for working predicates in the early stages of event processing. The predicate register 0 is read-only and always reads 1, true. This is due to the command to make execution unconditional.

(Control register)
Thread status register

ID register

Instruction pointer register

実行されるべき次の命令の６４ビット仮想アドレスを特定する。

Specifies the 64-bit virtual address of the next instruction to be executed.

System exception status register

Application exception status register

System exception IP

命令のアドレスは、システム特権のシグナリングされた例外に対応する。ビット［０］は、例外の時点では特権レベルである。

The address of the instruction corresponds to a signaled exception for system privileges. Bit [0] is a privilege level at the time of the exception.

命令のアドレスは、シグナリングされた例外に対応する。ビット［０］は、例外の時点では特権レベルである。

The instruction address corresponds to the signaled exception. Bit [0] is a privilege level at the time of the exception.

Application exception IP

命令のアドレスは、アプリケーション特権のシグナリングされた例外に対応する。

The address of the instruction corresponds to a signaled exception of application privileges.

命令のアドレスは、シグナリングされた例外に対応する。ビット［０］は、例外の時点では特権レベルである。

The instruction address corresponds to the signaled exception. Bit [0] is a privilege level at the time of the exception.

Exception Mem address

メモリのアドレスは、シグナリングされた例外を参照する。メモリフォールとにのみ有効。実行状態レジスタがメモリリファレンスフォールトを示す場合、フィルを待つか、またはエンプティを待ちながら、ペンディングメモリ動作のアドレスを保持する。

The memory address refers to the signaled exception. Valid only for memory fall. If the execution status register indicates a memory reference fault, the pending memory operation address is held while waiting for a fill or waiting for an empty.

Instruction Seg table pointer (ISTP), Data Seg table pointer (DSTP)

ＩＳＴＥおよびＩＳＴＥレジスタによって利用され、読み出しまたは書き込みされるｓｔｅおよびフィールドを特定する。

Used by the ISTE and ISTE registers to identify the ste and field to be read or written.

Instruction segment table entry (ISTE), data segment table entry (DSTE)

読み出される場合、ＩＳＴＥレジスタによって特定されたＳＴＥは、宛先汎用レジスタに配置される。書き込まれる場合、ＩＳＴＥまたはＤＳＴＥによって特定されたＳＴＥは、汎用ソースレジスタから書き込まれる。セグメントテーブルエントリのフォーマットは、第６章（「変換テーブルの組織およびエントリの説明」と称される節において明確にされる。

When read, the STE specified by the ISTE register is placed in the destination general purpose register. When written, the STE specified by the ISTE or DSTE is written from the general source register. The format of the segment table entry is clarified in Chapter 6 (“Translation Table Organization and Entry Description”).

Instruction or data level 1 cache tag pointer (ICTP, DCTP)

ＩＣＴＥまたはＤＣＴＥによって読み出しまたは書き込みされる命令キャッシュタグエントリを特定する。

Identify an instruction cache tag entry that is read or written by ICTE or DCTE.

Instruction or data level 1 cache tag entry (ICTE, DCTE)

読み出される場合、ＩＣＴＰまたはＤＣＴＰレジスタによって特定されたキャッシュタグは、宛先汎用レジスタに配置される。書き込まれる場合、ＩＣＴＰまたはＤＣＴＰによって特定されたキャッシュタグは、汎用ソースレジスタから書き込まれる。キャッシュタグエントリのフォーマットは、第６章（「変換テーブルの組織およびエントリの説明」と称される節において明確にされる。

When read, the cache tag specified by the ICTP or DCTP register is placed in the destination general purpose register. When written, the cache tag specified by ICTP or DCTP is written from the general source register. The format of the cache tag entry is clarified in Chapter 6 (“Translation Table Organization and Entry Description”).

Event queue control register

イベントキューコントロールレジスタ（ＥＱＣＲ）は、イベントキューへの通常のアクセスおよびダイアグノスティックアクセス（ｄｉａｇｎｏｓｔｉｃ ａｃｃｅｓｓ）をイネーブルする。レジスタを使用するためのシーケンスは、レジスタ書き込みに続いてレジスタ読み出しである。ｒｅｇ＿ｏｐフィールドのコンテンツは、書き込み、および次の読み出しの動作を特定する。

The event queue control register (EQCR) enables normal access and diagnostic access to the event queue. The sequence for using the register is register read followed by register read. The contents of the reg_op field specify the write and next read operations.

Event-thread lookup table control

イベント−スレッドルックアップテーブルは、ハードウェアデバイスによって提供されたイベント数またはイベント命令と、好ましいスレッドとの間のマッピングを確立して、イベントをシグナリングする。テーブルにおける各エントリは、ビットマスク、およびイベントがマッピングされる対応するスレッドと共にイベント数を明確にする。

The event-thread lookup table establishes a mapping between the number of events or event instructions provided by the hardware device and the preferred thread to signal the event. Each entry in the table defines the number of events along with a bit mask and the corresponding thread to which the event is mapped.

（タイマおよび性能モニタ）
示された実施形態では、すべてのタイマおよび性能モニタレジスタは、アプリケーション特権でアクセス可能である。

(Timer and performance monitor)
In the illustrated embodiment, all timer and performance monitor registers are accessible with application privileges.

clock

Instruction executed

Thread execution clock

Timeout waiting counter

（仮想プロセッサおよびスレッドＩＤ）
示された実施形態では、各アクティブスレッドは、仮想プロセッサに対応し、かつ、８ビットアクティブスレッド数によって特定される（アクティブスレッド［７：０］）モジュール５は、１６ビットスレッドＩＤ（スレッド［１５：０］）をサポートし、スレッドの高速のロード（活性化）およびアンロード（不活性化）を可能にする。他の実施形態は、異なったサイズのスレッドＩＤをサポートし得る。
（スレッド−命令フェッチ抽象化）
上述のように、モジュール５のＴＰＵ１０〜２０は、Ｌ１命令キャッシュ２２、およびこれらのＴＰＵ内でアクティブのスレッドの任意の組み合わせから、各サイクルごとに５つまでの命令を起動するパイプラインコントロールハードウェアを共有する。図１０は、機能ユニット３０〜３８上で実行するためのこれらの命令をフェッチおよびディスパッチするために、モジュール５によって用いられるメカニズムの抽象化である。

(Virtual processor and thread ID)
In the illustrated embodiment, each active thread corresponds to a virtual processor and is identified by the number of 8-bit active threads (active thread [7: 0]). Module 5 has a 16-bit thread ID (thread [15 : 0]), allowing fast loading (activation) and unloading (deactivation) of threads. Other embodiments may support different sized thread IDs.
(Thread-instruction fetch abstraction)
As mentioned above, the TPUs 10-20 of module 5 are pipeline control hardware that launches up to five instructions per cycle from any combination of L1 instruction caches 22 and threads active within these TPUs. Share FIG. 10 is an abstraction of the mechanism used by module 5 to fetch and dispatch these instructions for execution on functional units 30-38.

  As shown in this figure, during each cycle, instructions are fetched from the L1 cache 22 and placed in the instruction queues 10a-20a associated with each respective TPU 10-20. In the illustrated embodiment, 3-6 instructions are fetched per single thread with the overall goal of keeping the thread queues 10a-20a at equal levels. In other embodiments, a different number of instructions may be fetched and / or different targets may be set to roughly fill the queue. Also during the fetch stage, module 5 (and in particular, for example, the event handling mechanism described above) recognizes events and the conversion of the corresponding thread from a wait state to an execution state.

  During the dispatch stage (running in parallel with the fetch and execute / retire stage), instructions from each of one or more execution threads consider the best use of their resources for that cycle Is dispatched to the functional units 30-38. These instructions can be from any combination of threads. The compiler uses, for example, a “stop” flag provided in the instruction set to identify boundaries between groups of instructions in a thread that can be invoked in a single cycle. In other embodiments, other protocols may be used, such as a protocol that prioritizes a specific thread, a protocol that ignores resource usage, and the like.

  During the execution and retirement phases (executed in parallel with the fetch and dispatch stages), multiple instructions are executed simultaneously from one or more threads. As described above, in the illustrated embodiment, up to five instructions are activated and executed every cycle, for example, by the integer unit, floating unit, branch unit, comparison unit, and memory function units 30-38. In other embodiments, more or fewer instructions may be invoked, for example, depending on the number and type of functional units and depending on the number of TPUs.

  When execution is complete, the instruction is retired. The result is written and the instruction is cleared from the instruction queue.

  On the other hand, if an instruction blocks, the corresponding thread is converted from an execution state to a wait state. If the condition that caused the block is resolved, the blocked instruction of the corresponding thread and then all subsequent instructions are restarted. FIG. 11 illustrates a three pointer queue management mechanism used in the illustrated embodiment to facilitate this.

  Referring to this figure, an instruction queue and a set of three pointers are maintained for each TPU 10-20. Only such a set of single queues 110 and 112-116 are shown here. The queue 110 holds the fetched, executed, and retired (or invalid) instructions of the associated TPU and, more specifically, the currently active thread in that TPU. As instructions are fetched, they are inserted at the head of the queue. This is specified by the insert (or fetch) pointer 112. The next instruction to execute is identified by the extract (or issue) pointer 114. The commit pointer 116 identifies the last instruction whose execution has been committed. If the instruction is blocked or otherwise aborted, the commit pointer 116 is rolled back, pushing the instruction between the commit pointer and the extract pointer into the execution pipeline. Conversely, if a branch is used, all queues are flushed and the pointer is reset.

Although queue 110 is shown as a circle, it will be appreciated that other configurations may be utilized. The queuing mechanism shown in FIG. 11 may be realized as shown in FIG. 12, for example. The instructions are stored in the dual port memory 120 or a series of registers (not shown). The write address at which each newly fetched instruction is stored is provided by fetch pointer logic 122 that generates successive addresses in memory 120 in response to a fetch command (eg, issued by pipeline control). The The issued instruction is obtained here from the other port shown at the bottom. The read address from which each instruction is obtained is supplied by issue / commit pointer logic 124. The logic responds to commit and issue commands (eg, issued by pipeline control) and generates and / or resets sequential addresses as appropriate.
(Processor module implementation)
FIG. 13 shows in particular the SoC implementation of the processor module 5 of FIG. 1 including logic for implementing the TPUs 10-20. As in FIG. 1, the implementation of FIG. 13 includes L1 and L2 caches 22-26 configured and operating as described above. Similarly, this implementation comprises functional units 30-34 each comprising an integer unit, a floating point unit and a comparison unit. Additional functional units may be provided alternatively or additionally. The logic for realizing the IPUs 10 to 20 includes a pipeline control 130, a branch unit 38, a memory unit 36, a register file 136, and a load-store buffer 138. The components shown in FIG. 13 are interconnected for control and information transfer as shown. The dashed line indicates the primary control, the solid line indicates the predicate value control, the thick solid line identifies the 64-bit data bus, and the thicker line identifies the 128-bit data bus. FIG. 13 represents one implementation of the processor module 5 according to the invention and it will be appreciated that other implementations may be implemented.
(Pipeline control unit)
In the illustrated embodiment, the pipeline control 130 includes a per-thread queue as previously described in connection with FIGS. 12, 15 or 18 instructions can be parameterized per thread. The control 130 picks up instructions from these queues on a round-robin basis (however, as described above, this can also be performed on other bases. This is the register file 136 (which is the source and destination of the instruction). And the sequence of access to the functional units 30 to 38. The pipeline control 130 decodes the basic instruction class from the per-thread queue and directs the instructions to the functional units 30 to 38. As described above, multiple instructions from one or more threads can be scheduled for execution by their functional units in the same cycle, and control 130 can further empty the per-thread configuration queue. Branching It is signaled to Tsu bets 38, and, when possible, for example, responsible for reducing the consumption of the user idling functional units at the base of each cycle.

  FIG. 14 is a block diagram of the pipeline control unit 130. The unit comprises a thread class queue control logic 140, a thread class (or per thread) queue 142 itself, an instruction dispatch 144, a longword decode unit 146, and functional unit queues 148a-148e that are mutually (and , Connected to other components of module 5. Thread class (per thread) queues are configured and operate as described above in connection with Figures 11-12. Controls the input side of these queues 142 and thus provides the insertion pointer function shown and described above in Figures 11 to 12. Control logic 140 further controls the input side of unit queues 148a-148e. Con It is responsible for rolling and interfacing with branch unit 38 to control instruction fetching, with respect to the latter, logic 140 may fetch instructions in the manner described above (eg, to compensate for a TPU that retires most instructions). Responsible for balancing.

  Instruction dispatch 144 evaluates and determines the scheduling of instructions available in each of the thread class queues on a cycle-by-cycle basis. As described above, in the illustrated embodiment, queues are handled on a round-robin basis, taking into account queues that retire instructions more quickly. Instruction dispatch 144 also controls the output side of thread class queue 142. In this regard, instruction dispatch 144 manages the extract and commit pointers already described in connection with FIGS. 11-12, which update the commit pointer when the instruction is retired, and the instruction is aborted. If it does (for example, due to a thread switch or an exception), it includes rolling back that pointer.

  The long word decode unit 146 decodes the instruction long word coming from the L1 instruction cache 22. In the illustrated embodiment, each such longword is decoded into an instruction. This can be parameterized to decode one or two longwords, decoded into three and six instructions, respectively. The decode unit 146 is further responsible for decoding the instruction class of each instruction.

  Unit queues 148a-148e queue actual instructions to be executed by functional units 30-38. Each queue is organized on a per-thread basis and remains consistent with the class queue. The unit queue is coupled to thread class queue control 140 and instruction dispatch 144 for control purposes, as described above. Instructions from queues 148a-148e are transferred to the corresponding pipelines 150a-150b and routed to the functional units themselves 30-38. The instruction is further passed to the register file pipeline 152.

  FIG. 15 is a block diagram of an individual unit queue such as 148a. This comprises one instruction queue 154a-154e per TPU. These are coupled to a thread class queue control 140 (labeled tcpqueue_ctl) and instruction dispatch 144 (labeled dispatch) for control purposes. These are further coupled to an instruction input longword decode unit 146 (labeled lwdecode) and a thread selection unit 156, as shown. This unit controls thread selection based on control signals provided by instruction dispatch 144 as shown. The output from unit 156 is routed to corresponding pipelines 150a-150e and register file pipeline 152.

  Referring again to FIG. 14, integer unit pipeline 150a and floating point unit pipeline 150b decode the appropriate instruction field for each functional unit. Each pipeline further measures the time of the command to the respective functional unit. Further, each pipeline 150a, 150b applies squashing to the respective pipeline based on branching or aborting. Furthermore, each applies a power down signal to the respective functional unit if it is not used during one cycle. The illustrated comparison unit pipeline 150c, branch unit pipeline 150d, and memory unit pipeline 150e provide similar functions to their respective functional units, the comparison unit 34, the branch unit 38, and the memory unit 36. Register file pipeline 150 also provides similar functionality for register file 136 as well.

  Returning now to FIG. 13, the branch unit 38 shown is responsible for instruction address generation and address translation, and instruction fetching. Furthermore, this maintains the state of the thread processing units 10-20. FIG. 16 is a block diagram of the branch unit 38. This includes control logic 160, thread state storage 162a-162e, thread selection 164, address adder 166, segment translation CAM connected to each other (and to other components of module 5) as shown in the figure. (Content addressable memory) 168.

  The control logic 160 drives the unit 38 based on the command signal from the pipeline control 130. This, as indicated, further takes as instructions the instruction cache 22 state and the L2 cache 26 acknowledgment. The logic 160 outputs thread switches to the pipeline control 130 and commands to the instruction cache 22 and L2 cache as shown. The thread state storage devices 162a to 162e store the thread states of the TPUs 10 to 20, respectively. Each of these TPUs maintains the general registers, predicate registers, and control registers shown in FIG. 3 and described above.

The address information obtained from the thread state store is routed to the thread selector as shown. The selector selects a thread address from that information and can perform address operations based on a control signal (shown) from the control 160. The address adder 166 increments the selected address based on the output of addressing information provided by the thread selector 164 and the register file (labeled register source), as shown, or Execute branch address calculation. Further, the address adder 166 outputs a branch result. The newly calculated address operates as described above in connection with FIG. 5, as described above, to generate a segment translation memory 168 that generates a translated instruction cache address for use with the next instruction fetch. Routed to.
(Functional unit)
Returning to FIG. 13, the memory unit 36 is responsible for executing memory reference instructions, including data cache 24 address generation and address translation. In addition, unit 36 maintains a pending (memory) event table (PET) 50 as described above. FIG. 17 is a block diagram of the memory unit 36. This comprises a control logic 170, an address adder 172, and a segment translation CAM 174 connected to each other (and to the other components of module 5) as shown in the figure.

  The control logic 170 drives the unit 36 based on the command signal from the pipeline control 130. This, as shown, also gets the data cache 22 state and the L2 cache 26 acknowledgment as inputs. Logic 170 outputs thread switches to pipeline control 130 and branch unit 38 and commands to data cache 24 and L2 cache, as shown. The address adder 172 increments the addressing information provided from the register file 136 or performs the necessary address calculations. The newly calculated address is routed to the segment translation memory 174. This memory operates as previously described in connection with FIG. 5 and generates a translation instruction cache address for use with data access. Although not shown in the drawings, the unit 36 also comprises PET as described above.

  FIG. 18 is a block diagram of a cache unit that implements either the L1 instruction cache 22 or the L2 data cache 24. This unit comprises 16 128x256 byte single port memory cells 180a-180p functioning as a data array along with 16 corresponding 32x56 byte dual port memory cells 182a-182p functioning as a tag array. These are coupled to the L1 and L2 address and data buses as shown. Control logic 184 and 186 are coupled to the memory cells and the L1 and L2 cache controls.

  Returning again to FIG. 13, register file 136 serves as a resource for all source and destination registers accessed by instructions executed by functional units 30-38. This register file is realized as shown in FIG. As shown here, to reduce delay and wire overhead, unit 136 is broken down into separate register files for each functional unit 30-38. In the illustrated embodiment, each instance provides 48 64-bit registers for each TPU. Other embodiments may vary depending on the number of registers allocated to the TPU, the number of TPUs, and the size of the registers.

  Each instance 200a-200e has five wire ports, as indicated by the arrows that enter the top of each instance, through which each of the functional units 30-38 writes output data simultaneously. Get (this ensures that the instance holds uniform data). Each provides a different number of read ports, as indicated by the arrows emanating from the bottom of each instance. Each functional unit acquires data via this port. Thus, as shown, the integer unit 30, the floating point unit 32, and the instance associated with the memory unit all have three read ports, and the instance associated with the compare unit 34 has two read ports. And the instance associated with the branch unit 38 has one port.

  Register file instances 200-200e may be optimized by reading all ports for a single thread in each cycle. Furthermore, the storage bit can be folded under the port access wire.

21 and 22 are block diagrams of the integer unit 30 and the comparison unit 34, respectively. FIG. 23A and FIG. 23B are block diagrams of the floating point unit 32 and the multiply-multiple-add unit used herein, respectively. The configuration and operation of these units will be apparent from the components, interconnections, and displays provided in the drawings.
(Consumer-Producer memory)
Prior art multiprocessor systems have very high synchronization overhead and programming difficulties to implement a data-based processing flow between threads or processors. The processor module 5 allows one thread to wait in a state where data is available and to wake up transparently if one thread indicates that data is available, as described above. A memory instruction is provided that allows this to be done easily. Such software-transparent consumer-producer memory operations allow parallel processing of higher performance fine-grained thread levels and consumer-producer programming styles with efficient data orientation.

  The illustrated embodiment provides “fill” memory instructions. This is used by a thread that is a data producer to load data into a selected memory location and associate a state at that location, ie, a “full” state. If the location is already in that state when the instruction is executed, execution is signaled.

  This embodiment further provides an “empty” instruction. This is used by the data consumer to obtain data from the selected location. If a location is associated with a full state, data is read from it (eg, in a designated register) and the instruction causes the location to be associated with an “empty” state. Conversely, if the location is not associated with a full state at the time that the empty instruction is being executed, the instruction may temporarily idle the thread that executed it (or active, in alternative embodiments, Transition to the non-execution state and once it is so associated, it transitions back to the active, execution state (and completes executing the empty instruction). By using empty instructions, it is possible to execute a thread when data is available with low overhead and software transparency.

  In the illustrated embodiment, there is a pending (memory) event table (PET) 50 that stores status information about memory locations that are the subject of fill and empty operations. This is the location address, the respective full or empty state, and the "consumer" of the data at these locations, i.e. the identity of the thread executing the empty instruction and waiting for the location to be filled Is provided. This pending event table may be useful, for example, in producing data that may be useful in signaling and tracking the cause of an exception (eg, when a continuous fill instruction is executed at a specific address and there is no empty instruction to intervene). It may further comprise identification information of the person.

  The data at each location is not stored in the PET 50 and remains in the cache and / or memory system itself, rather than data that is not subject to fill and / or empty instructions. In other embodiments, status information is stored in the memory system alongside the location to which it relates and / or in a separate table, linked list, etc.

  Thus, for example, if an empty instruction is executed on a given memory location, the PET is checked to determine if it has an entry indicating that the same location is currently full. If it has that entry, if it is full, the entry is changed to empty, moving data from the memory location to the register specified by the empty instruction, and is read.

  On the other hand, if there is no entry in the PeT for a given memory location when the empty instruction is being executed (or if any such entry indicates that the location is currently empty), there is an entry in the PET. Generated (or updated) to indicate that a given location is empty and the thread that executed the empty instruction is a consumer of any data that is then stored at that location by the fill instruction It shows that.

  When the fill instruction is next executed (possibly by another thread), the PET is checked to determine if it has an entry indicating that the same location is currently empty. When such an entry is found, its state is changed to full and the event delivery mechanism 44 (FIG. 4) is used to route the notification to the consumer thread identified in that entry. If the thread is active and is waiting in the TPU, the notification goes to the TPU, the thread enters the active, execution state, and re-executes its empty instruction (this time complete) (because the memory location is Because it ’s full here.) If the thread is idle, notification goes to the system thread (in any currently executing IPU), which causes the thread to be loaded into the active TPU that is running, thereby The instruction can be re-executed.

  In the illustrated embodiment, this use of PET for memory operations such as consumers / producers is done only with respect to selected memory instructions such as fill and empty, and more general loading and Not done with store memory instructions. Thus, for example, even when a load instruction is currently executed for a memory location that is the target of an empty instruction, the thread that executed the empty instruction is not notified, and the instruction is re-executed. Can be done. Other embodiments may differ in this regard.

  FIG. 24A shows three interdependent threads 230, 232 and 234. Synchronization and data conversion between these threads can be facilitated by fill and empty instructions according to the present invention. For example, the thread 230 is an MPEG2 demultiplexing thread 230 and is responsible for MPEG2 demultiplexing acquired from, for example, an MPEG2 source 236 such as a tuner or a streaming source. To continue the example, it is assumed that TPU 10 is active and running. The thread 232 is a video decoding step 1 thread, and is responsible for the first stage of decoding the video signal from the demultiplexed MPEG2 signal. It is assumed that the TPU is active and running. Thread 234 is the video decoding step 2 thread and is responsible for the second stage of decoding the video signal from the demultiplexed MPEG2 signal for output via the LCD interface 238 or other device. It is assumed that the TPU 14 is in an active and executing state.

  In order to accommodate data streaming from the source 236 in real time, each of the threads 230-234 continuously processes the data provided by its upstream source and thus does this in parallel with other threads. FIG. 24B illustrates the use of fill and empty instructions to facilitate this in a manner that ensures synchronization and facilitates data transfer between threads. Referring to the drawings, arrows 240a-240g indicate fill dependencies (fill) between threads, in particular between data locations written (filled) by one thread and read (emptied) by another thread. dependents). Thus, thread 230 processes the data destined for address A0, while thread 232 executes an empty instruction directed to that location, and thread 234 (thread 232 eventually fills) at address B0. Execute the directed empty instruction. As a result of the empty instruction, thread 232 enters a wait state (eg, active, non-executed, or idle) while waiting for the fill at location A0 to complete, and thread 234 waits for the fill at location B0 to complete. While waiting.

  When the fill of the A0 thread 230 is complete, the thread can process the data from A0 and the result is directed to B0 via the fill instruction. Thread 234 remains in a wait state and is still waiting for the fill to complete. Meanwhile, thread 230 begins processing data destined for address A1, and thread 232 executes an empty instruction and puts the thread in a wait state while waiting for A1's fill to complete.

  If thread 232 executes a fill request for B0, thread 234 is empty, allowing the thread to process data from B0, and the result is directed to C0, where it is displayed on the TV viewer. Are read out by an LCD interface (not shown). The three threads 230, 232, 234 continue processing and execute fill and empty instructions in this manner (as shown in the figure) until processing of the entire MPEG2 stream is complete.

Fill and empty instructions can be further understood by reviewing the instruction format.
(Empty)
Format: ps EMPTY cache threads dreg, breg, ireg {, stop}
Description: Empty instructs the memory system to check the status of the effective address. If the state is full, the empty instruction changes the state to empty and loads the value into dreg. If the state is already empty, the instruction waits until the instruction is full and the wait behavior is represented by the thread field.
(Operand and field)
The ps predicate source register specifies whether the instruction is being executed. If true, the instruction has been executed; otherwise, if it is false, the instruction has not been executed (no side effects)
stop 0 Indicates that the instruction group is not represented by this instruction.

1 Indicates that an instruction group is represented by this instruction.
thread 0 No unconditional thread switch
1 Unconditional thread switch
2 Conditional thread switch at stall (blocks thread execution)
3 Reserve cache 0 tbd with reuse cache hint
1 Read / write with reuse cache hint
2 tbd with a cache hint without reuse
3 Read / write im 0 address cache index without reuse Represents the index register (ireg) for address calculation
1 represents the index register of the ireg instruction that represents the disp for address calculation. Disp represents the base register of the instruction.
Format: ps FILL cache threads s1reg, breg, ireg {, stop}
Description: Register s1reg is written to a word in memory with an effective address. The effective address is calculated by adding breg (base register) and ireg (index register) or disp (displacement) based on the im (immediate storage) field. The effective address state is changed to full. If the state is already full, execution is signaled.
(Operand and field)
The ps predicate source register indicates whether the instruction is being executed. If true, the instruction is executed; otherwise, it is not executed (no side effects)
stop 0 Indicates that the instruction group is not represented by this instruction.

1 Indicates that an instruction group is represented by this instruction.
thread 0 No unconditional thread switch
1 Unconditional thread switch
2 Conditional thread switch at stall (blocks thread execution)
3 Reserve cache 0 tbd with reuse cache hint
1 Read / write with reuse cache hint
2 tbd with cache hint without reuse
3 Read / write im 0 address index register (ireg) for cache hints without reuse
1 Specify disp for address calculation Specify index register for ireg instruction Specify base register for breg instruction Specify 2's complement displacement constant (8 bits) for memory reference instruction Specify destination register for dreg instruction (software event) )
The processing of hardware and software events is more fully understood by reviewing their instruction format.
(Event)
Format: psEVENT s1reg {, stop}
Description: The event instruction polls the execution thread's event queue. If an event exists, the instruction completes with the event state loaded into the exception state register. If the event does not exist in the event queue, the thread transitions to the idle state.
(Operand and field)
The ps predicate source register specifies whether the instruction is being executed. If true, the instruction is executed; otherwise, it is not executed (no side effects)
stop 0 Indicates that the instruction group is not represented by this instruction.

1 Indicates that an instruction group is represented by this instruction.
Identify the register containing the first source operand of the s1reg instruction (SW event)
Format: ps SWEVENT s1reg {, stop}
Description: The SW event instruction enqueues an event into the event queue to be handled by the thread. See event format xxx.

(Operands and fields:
The ps predicate source register specifies whether the instruction is being executed. If true, the instruction is executed; otherwise, it is not executed (no side effects)
stop 0 Indicates that the instruction group is not represented by this instruction.

1 Indicates that an instruction group is represented by this instruction.
Identify the register containing the first source operand of the s1reg instruction (CTLLFLD)
Format: ps Ct1Fld ti cfield, {, stop}
Description: The control field instruction changes the control field specified by cfield. Other fields in the control register are not changed.

(Operand and field)
The ps predicate source register specifies whether the instruction is being executed. If true, the instruction is executed; otherwise, it is not executed (no side effects)
stop 0 Indicates that the instruction group is not represented by this instruction.

1 Indicates that an instruction group is represented by this instruction.
ti 0 Indicates access to this thread control register
1 cfield indicating access to the control register of the thread specified by IDt_indirect field (thread indirection)
cfield [4: 0] Control field Privilege

（デバイス内蔵プロセッサモジュール５）
図２５は、ＳｏＣフォーマットに組み込まれた本発明によるデジタルＬＣＤ−ＴＶサブシステム２４２のブロック図である。このサブシステム２４２は、上述のように構成され、例えば、上述のように、ＭＰＥＧ２信号多重分離、ＭＰＥＧ２ビデオデコーディング、ＭＰＥＧオーディオデコーディング、デジタルＴＶユーザインターフェースオペレーション、およびオペレーティングシステムの実行（例えば、Ｌｉｎｕｘ）、プロセッサモジュール５を提供するスレッドを同時に実行するように動作するプロセッサモジュール５を備える。モジュール５は、上述のように、Ｌ２キャッシュ２６のオフチップ部分を備えるＤＤＲ ＤＲＡＭフラッシュメモリに結合される。このモジュールは、ＡＭＢＡＡＨＢバス２４４へのインターフェース（図示せず）を備え、これを介して、デジタルＬＣＤ−ＴＶのコンポーネントにインターフェース、すなわち、ビデオ入力インターフェース、ビデオ出力インターフェース、オーディオ出力インターフェースおよびＬＣＤインターフェースを提供する「インテレクチャルプロパティ」または「ＩＰ」２４６と通信する。当然、ＡＨＢバス５等を介してモジュール５に結合される他のＩＰが、追加的または代替的に提供されてもよい。例えば、図面において、示されたモジュール５は、デジタルＬＣＤ−ＴＶがソース信号を取得および／またはコントロールされる、ＤＭＡエンジン２４８、高速Ｉ／Ｏデバイスコントローラ２５０および低速デバイスコントローラ２５２（ＡＰＢブリッジ２５４を介する）等の選択的ＩＰと通信する。

(Device built-in processor module 5)
FIG. 25 is a block diagram of a digital LCD-TV subsystem 242 according to the present invention incorporated in the SoC format. The subsystem 242 is configured as described above, for example, as described above, MPEG2 signal demultiplexing, MPEG2 video decoding, MPEG audio decoding, digital TV user interface operations, and operating system execution (eg, Linux And a processor module 5 that operates to simultaneously execute threads that provide the processor module 5. Module 5 is coupled to a DDR DRAM flash memory comprising the off-chip portion of L2 cache 26 as described above. This module has an interface (not shown) to the AMBAAHB bus 244, through which it provides interfaces to digital LCD-TV components: video input interface, video output interface, audio output interface and LCD interface Communicate with "Intelligent Properties" or "IP" 246. Of course, other IPs coupled to the module 5 via the AHB bus 5 or the like may be additionally or alternatively provided. For example, in the drawing, the module 5 shown is a DMA engine 248, a high speed I / O device controller 250 and a low speed device controller 252 (via an APB bridge 254) in which the digital LCD-TV acquires and / or controls the source signal. ) And other selective IP.

  FIG. 26 is a block diagram of a digital LCD-TV or other application subsystem 256 according to the present invention, which is again embodied in SoC format. The subsystem shown is configured as described above except that it is shown with APB and AHB / APB instead of the specific IP shown in FIG. Depending on the application needs, device 258 may comprise a video input interface, a video output interface, an audio output interface, an LCD interface, etc., as in the implementation described above.

  The illustrated subsystem further interfaces with a plurality of modules 5, eg, a portion of the off-chip L2 cache 26 b utilized by module 5, preferably coupled via the interconnects that form it. -20 (or more) modules. The interconnect may be in the form of a ring interconnect (R1) comprising a shift register bus shared by module 5 and more specifically by L2 cache 26. Alternatively, this may be another form of interconnection, such as proprietary, that facilitates the rapid movement of data within the combined memory system of module 5. Regardless of this, the L2 cache is preferably coupled so that the L2 cache of any one module 5 contributes not only to the memory system of the individual processors, but also to all the distributed all cache memory systems of the processor modules Is done. Of course, as described above, the modules 5 need not physically share the same memory system, chip or bus, but instead may be connected via a network or the like.

  So far, apparatus, systems and methods have been described that meet the desired objectives. It will be apparent that the embodiments described herein are illustrative of the invention and that other embodiments, including modifications, are within the scope of the invention.

FIG. 1 illustrates a processor module constructed and operative in accordance with an embodiment of the present invention. FIG. 2 compares thread processing by a conventional superscalar processor with thread processing by a processor module constructed and operative in accordance with an embodiment of the present invention. FIG. 3 illustrates possible states of threads executing in a virtual processing unit (or thread processing unit (TPU)) in a processor configured and operating in accordance with an embodiment of the present invention. FIG. 4 illustrates an event delivery mechanism in a processor module constructed and operative in accordance with an embodiment of the present invention. FIG. 5 illustrates a virtual address mechanism for system address translation in a configured and operating system according to an embodiment of the present invention. FIG. 6 illustrates a level 1 and level 2 cache configuration in a system configured and operative in accordance with an embodiment of the present invention. FIG. 7 illustrates L2 cache and logic used to perform tag lookups in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 8 illustrates the logic used to perform the L2 extended cache tag lookup in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 9 illustrates general purpose registers, predicate registers, and thread state or control registers maintained for each thread processing unit (TPU) in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 10 illustrates a mechanism for fetching and dispatching instructions executed by a thread in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 11 illustrates a queue management mechanism used in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 12 illustrates a queue management mechanism used in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 13 illustrates a SoC (system-on-a-chip) implementation of the processor module of FIG. 1 including logic for implementing a thread processing unit according to an embodiment of the present invention. FIG. 14 is a block diagram of a pipeline control unit in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 15 is a block diagram of individual unit queues in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 16 is a block diagram of a branch unit in a system configured and operative in accordance with an embodiment of the present invention. FIG. 17 is a block diagram of a memory unit in a system configured and operative in accordance with an embodiment of the present invention. FIG. 18 is a block diagram of a cache unit that implements either an L1 instruction cache or an L1 data cache in a system configured and operative in accordance with an embodiment of the present invention. FIG. 19 illustrates an implementation of the L2 cache and logic of FIG. 7 in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 20 illustrates a register file implementation in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 21 is a block diagram of integer units and comparison units in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 22 is a block diagram of integer units and comparison units in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 23A is a block diagram of floating point numbers in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 23B is a block diagram of floating point numbers in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 24A illustrates the use of consumer and producer memory instructions in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 24B illustrates the use of consumer and producer memory instructions in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 25 is a block diagram of a digital LCD-TV in a system constructed and operative in accordance with an embodiment of the present invention. FIG. 26 is a block diagram of a digital LCD-TV or other application subsystem in a system constructed and operative in accordance with an embodiment of the present invention.

Explanation of symbols

10 address translation 14 address translation 20 address translation 22 L1 instruction cache 24 L1 data cache 26 L2 cache 28 startup and pipeline control 30 integer unit (unit)
32 Floating point unit (fpunit)
34 Comparison unit
36 memory unit
38 branch unit
44 Event-Thread Delivery 46 TPU Queue 48 TPU Queue 70 Data Block 72a Cache Tag Array Group 72p Cache Tag Array Group 74a Tag Compare 74p Tag Compare 80 Data Block 82a Data Array Group 82p Data Array Group 84a Select Matched Tag 84p Matched Select tag 86 Physical page number 112 Insert (or fetch) pointer 116 Commit pointer 114 Extract (or issue) pointer 120 Dual port memory or register 130 Pipe control 138 Load store buffer 140 Thread class queue control 142 Thread class 144 Instruction dispatch 148a Unit Queue 148e Unit queue 160 Control 168 Segment Conversion 166 the address adder 164 thread selector 162a thread ₀ state 162b Thread ₁ state 162e thread _n state 170 control 172 address adder 174 segment transform CAM
192 State machine 194 Request queue 190 Current state control logic 196 L1 cache interface 26c DDR Drum Ctl
200a integer register file 200b FP register file 200c comparison register file 200d branch register file 200e memory register file 236 tuner or stream generator 230 MPEG2 DMUX thread 232 video decode step 1 thread 234 video decode step 2 thread

Claims (63)

An embedded processor,
A. A plurality of processing units each executing one or more processes or threads (collectively “threads”);
B. One or more execution units shared by the plurality of processing units and communicatively connected to the plurality of processing units, wherein the execution unit executes instructions from the thread Unit,
C. An event delivery mechanism for delivering the event to each thread with which the event is associated, the event delivery mechanism comprising:
i communicatively connected to the plurality of processing units;
an embedded processor comprising: an event delivery mechanism that delivers each such event to the respective thread without executing an instruction.   The embedded processor of claim 1, wherein the thread to which the event is delivered processes the event without executing an instruction outside the thread.   The embedded processor of claim 1, wherein the event comprises one of a hardware interrupt, a software initiated signaling event (“software event”), and a memory event.   The embedded processor of claim 1, wherein the execution unit executes an instruction from the thread without needing to know from which thread the instruction is.   The embedded processor of claim 1, wherein each thread is forced or not forced to execute on the same processing unit while the thread is alive.   The embedded processor of claim 1, wherein at least one of the processing units is a virtual processing unit. An embedded processor,
A. A plurality of virtual processing units, each executing one or more processes or threads (collectively “threads”), each thread forcing execution on the same processing unit while the thread is alive With multiple virtual processing units that are or cannot be forced;
B. Multiple execution units;
C. A pipeline control communicatively connected to the plurality of processing units and the plurality of execution units, wherein the pipeline control is configured to Pipeline control that launches instructions from multiple threads,
D. An event delivery mechanism that is communicatively connected to the plurality of processing units and delivers the event to each thread with which the event is associated without execution of an instruction, wherein the event is a hardware interrupt, An embedded processor with an event delivery mechanism, including any of software initiated signaling events ("software events") and memory events,
E. An embedded processor in which a thread to which an event is delivered processes the event without executing instructions outside the thread.   The embedded processor of claim 7, wherein the pipeline control comprises a plurality of instruction queues each associated with a respective virtual processing unit.   The embedded processor of claim 8, wherein the pipeline control decodes an instruction class from the instruction queue.   9. The embedded processor of claim 8, wherein the pipeline control accesses a resource supply source and a destination register for the instruction dispatched from the instruction queue by the processing unit.   The embedded processor according to claim 8, wherein the execution unit includes a branch execution unit responsible for any of instruction address generation, address translation, and instruction fetch.   The embedded processor according to claim 11, wherein the branch execution unit maintains a state of the virtual processing unit.   The embedded processor according to claim 7, wherein the pipeline control accesses the execution unit by the virtual processing unit.   The embedded processor according to claim 7, wherein the pipeline control signals a branch execution unit shared by the virtual processing unit when the instruction queue for each virtual processing unit becomes empty.   The embedded processor of claim 7, wherein the pipeline control idles the execution unit.   The embedded processor according to claim 7, wherein the plurality of execution units include any one of an integer unit, a floating unit, a branch unit, a comparison unit, and a memory unit. An embedded processor system,
A. Multiple embedded processors;
B. A plurality of virtual processing units executing on the plurality of embedded processors, each virtual processing executing one or more processes or threads (collectively “threads”), and each virtual processing unit comprising: A plurality of virtual processing units that may or may not be forced to execute on the same processing unit while the thread is alive;
C. One or more execution units shared by the plurality of processing units and communicatively connected to the plurality of processing units, the execution unit executing instructions from the thread, the execution unit comprising: One or more execution units comprising any of an integer unit, a floating unit, a branch unit, a comparison unit, and a memory execution unit;
D. An event delivery mechanism for delivering the event to each thread with which the event is associated, the event delivery mechanism comprising:
i communicatively connected to the plurality of processing units;
an embedded processor system comprising: an event delivery mechanism for delivering each such event to said respective thread without executing an instruction.   The embedded processor system of claim 17, wherein the thread to which an event is delivered processes the event without executing an instruction outside the thread.   The embedded processor system of claim 18, wherein the events include any of hardware interrupts, software initiated signaling events (“software events”), and memory events.   The embedded processor system of claim 18, wherein the branch unit is responsible for fetching instructions to be executed for the thread.   21. The embedded processor system according to claim 20, wherein the branch unit is further responsible for either instruction address generation or address translation.   The embedded processor system according to claim 21, wherein the branch unit includes a thread state storage device that stores a thread state for each of the virtual processing units. A. A pipeline control communicatively connected to the plurality of processing units and the plurality of execution units, wherein the pipeline control is configured to With pipeline control, dispatching instructions from multiple threads
B. The pipeline control comprises a plurality of instruction queues each associated with a respective virtual processing unit,
C. 19. The embedded processor system of claim 18, wherein instructions fetched by the branch execution unit are placed in the instruction queue associated with the respective virtual processing unit on which a corresponding thread is executed.   24. The embedded processor system of claim 23, wherein one or more instructions are fetched at some point for the thread for the purpose of keeping the instruction queue at an equal level.   25. The embedded processor system of claim 24, wherein the pipeline control dispatches one or more instructions from a given instruction queue at a point in time for execution.   26. The embedded processor system of claim 25, wherein the pipeline control causes a number of instructions dispatched from a given instruction queue at a given time to be controlled by stop flags in the queue's instruction sequence.   24. The embedded processor system of claim 23, wherein the pipeline control is activated and executed by the execution unit simultaneously with a plurality of instructions from one or more threads. An embedded processor,
A. A plurality of processing units, each executing one or more processes or threads (collectively “threads”), each thread being forced to execute on the same processing unit while the thread is alive With multiple processing units, which are not forced or
B. An event delivery mechanism for delivering the event to each thread with which the event is associated, the event delivery mechanism comprising:
i communicatively connected to the plurality of processing units;
an embedded processor comprising: an event delivery mechanism that delivers each such event to the respective thread without executing an instruction.   30. The embedded processor of claim 28, wherein the thread to which an event is delivered processes the event without executing an instruction outside the thread.   29. The embedded processor of claim 28, wherein the event comprises any of a hardware interrupt, a software initiated signaling event ("software event"), and a memory event.   30. The embedded processor of claim 28, wherein at least one of the processing units is a virtual processing unit. An embedded processor system,
A. Multiple embedded processors;
B. A plurality of virtual processing units executing on the plurality of embedded processors, each virtual processing executing one or more processes or threads (collectively “threads”), and each virtual processing unit comprising: A plurality of virtual processing units that may or may not be forced to execute on the same processing unit while the thread is alive;
C. An event delivery mechanism for delivering the event to each thread with which the event is associated, the event delivery mechanism comprising:
i communicatively connected to the plurality of processing units;
an embedded processor system comprising: an event delivery mechanism for delivering each such event to said respective thread without executing an instruction.   33. The embedded processor system of claim 32, wherein the thread to which an event is delivered processes the event without executing an instruction outside the thread.   34. The embedded processor system of claim 33, wherein the events include any of hardware interrupts, software initiated signaling events ("software events"), and memory events. A method of embedded processing,
A. Executing one or more processes or threads (collectively “threads”) on each of the plurality of processing units;
B. Executing instructions from the thread in one or more execution units shared by the plurality of processing units;
C. Delivering the event to each thread with which the event is associated without executing the instruction.   36. The method of claim 35, comprising processing the event delivered by the thread without executing an instruction outside the thread.   36. The method of claim 35, wherein the event comprises one of a hardware interrupt, a software initiated signaling event ("software event"), and a memory event.   36. The method of claim 35, wherein, in the one or more execution units, executing an instruction from the thread does not require knowing from which thread the instruction is.   36. The method of claim 35, wherein each thread is forced or not forced to execute on the same processing unit while the thread is alive.   36. The method of claim 35, wherein at least one of the processing units is a virtual processing unit. A method of the embedded processing comprising:
A. Executing one or more processes or threads (collectively "threads") on each of a plurality of virtual processing units, each thread running on the same processing unit while the thread is alive With steps that are forced or not forced to perform,
B. Activating instructions from a plurality of threads of the threads to execute simultaneously on a plurality of units of the execution unit;
C. Delivering the event to each thread with which the event is associated without executing an instruction, the event comprising a hardware interrupt, a software initiated signaling event ("software event") and a memory event Including any of the steps,
D. Processing the event delivered by the thread without executing instructions outside the thread.   42. The method of claim 41, wherein the initiating step includes the step of decoding an instruction class from the instruction queue.   42. The method of claim 41, wherein the initiating step includes controlling access by the virtual processing unit to a resource supply source and a destination register of the instruction dispatched from the instruction queue.   42. The method of claim 41, comprising performing any of the following: instruction address generation, address translation, and instruction fetching using a branch execution unit shared by all of the virtual processing units.   45. The method of claim 44, comprising maintaining the state of the virtual processing unit using the branch execution unit.   42. The method of claim 41, wherein the execution unit comprises any of an integer unit, a floating unit, a branch unit, a comparison unit, and a memory unit. A method of embedded processing,
A. Executing a plurality of virtual processing units on a plurality of embedded processors;
B. Executing one or more processes or threads (collectively “threads”) on each of a plurality of virtual processing units, each thread being the same virtual processing unit and / or while the thread is alive Or steps forced or not forced to run on the same embedded processor, and
C. Executing instructions from the thread in one or more execution units shared by the plurality of processing units, the execution units comprising an integer unit, a floating unit, a branch unit, a comparison unit, and a memory execution A step comprising any of the units;
D. Delivering the event to each thread with which the event is associated without executing the instruction.   48. The method of claim 47, comprising processing the event to which the thread is delivered without executing instructions outside the thread.   49. The method of claim 48, wherein the event comprises one of a hardware interrupt, a software initiated signaling event ("software event"), and a memory event.   49. The method of claim 48, comprising fetching instructions to be executed for the thread using the branch execution unit.   51. The method of claim 50, comprising performing any of instruction address generation and address translation in the branch execution unit. A. Dispatching instructions from a plurality of threads of the thread for simultaneous execution on a plurality of units of the execution unit;
B. 49. The method of claim 48, wherein the step of dispatching includes placing instructions fetched for each respective thread in an instruction queue associated with the virtual processing unit in which the thread is executed. .   53. The method of claim 52, wherein the dispatching step includes fetching one or more instructions at a point in time for a given thread for the purpose of keeping the instruction queue at an equal level.   54. The method of claim 53, wherein the dispatching step includes dispatching one or more instructions from a given instruction queue at a point in time for execution by the execution unit.   55. The method of claim 54, wherein the pipeline control causes a number of instructions dispatched from a given instruction queue at a given time to be controlled by stop flags in the queue's instruction sequence.   53. The method of claim 52, comprising initiating and executing a plurality of instructions simultaneously from one or more threads. A method of embedded processing,
A. Executing one or more processes or threads (collectively “threads”) on each of a plurality of processing units, each thread executing on the same processing unit while the thread is alive With forced or unforced steps,
B. Delivering the event to each thread with which the event is associated without executing the instruction.   58. The method of claim 57, comprising processing the event delivered by the thread without executing an instruction outside the thread.   58. The method of claim 57, wherein the event comprises one of a hardware interrupt, a software initiated signaling event ("software event"), and a memory event.   58. The method of claim 57, wherein at least one of the processing units is a virtual processing unit. A method of embedded processing,
A. Executing a plurality of virtual processing units on a plurality of embedded processors;
B. Executing one or more processes or threads (collectively “threads”) on each of a plurality of virtual processing units, each virtual processing unit being the same virtual processing unit while the thread is alive And / or steps forced or not forced to run on the same embedded processor; and
C. Delivering the event to each thread with which the event is associated without executing the instruction.   64. The method of claim 61, wherein the thread processes the event delivered without executing an instruction outside the thread.   64. The method of claim 62, wherein the event comprises one of a hardware interrupt, a software initiated signaling event ("software event"), and a memory event.

Images