Coordination and synchronization of an asymmetric single-chip, dual multiprocessor and method for operating a multiprocessor a multiprocessor for coordination or synchronization of individual program instructions

Coordination and synchronization of dual multi-processors of asymmetric single chip and method for operating multi-processors

Mutual reference of related technologies:

This is a partial continuation case filed on August 19, 1996 with the title "SINGLE-INSTRUCTION-MULTIPLE-DATA PROCESSING IN A MULTIMEDIA SIGNAL PROCESSOR" whose serial number is unknown.

Background of the invention:

The present invention relates to a multi-processor, especially a system and method for coordinating or synchronizing the parallel execution of individual program threads.

Known multi-processors include multiple processors that operate to complete work. A fairly simple multi-processor system includes a co-processor (such as an 80386 processor) and a floating-point processor (such as an 80387 Arithmetic coprocessor). In such a system, when the processor encounters an instruction that requires a floating-point operation, the processor starts the coprocessor that executes the instruction, such as an arithmetic coprocessor like 80387 when instructed Restricted to execute a single instruction and idle between floating-point instructions, the increase in processing power provided by this coprocessor is quite limited.

Another multi-bit processor structure contains two or more identical processors that execute separate but coordinated program threads. For example, because the time required to complete a part of the program thread changes, it is difficult to maintain the coordination or synchronization of the program thread. To transfer results between program clues, for example, cache hits and misses and instruction dependencies can delay the execution pipeline and change the number of cycles required to complete instructions. Therefore, in different programs The sequence of instructions in the thread is often not synchronized with each other.

In order to maintain proper synchronization, the hardware connected between the processors can delay or idle the processors as required to synchronize one of the program threads with the other. In some cases, there are multiple identical processors. In the system, each program thread is responsible for delaying itself or other program threads. Such systems often have complex synchronization hardware and necessary complex software to maintain the synchronization and coordination of the program threads. Complex synchronization hardware increases in The chip size and complex synchronization in the integrated system make the software longer and more difficult to develop.

We have found that the multi-processor system can provide high processing power, the flexibility of multiple separate program threads, and a simple method for synchronizing and coordinating the program threads.

According to an embodiment of the present invention, an integrated multi-processor includes two processors with asymmetric program control. One processor, sometimes referred to herein as a control processor, executes continuous program threads and can start or stop. The execution of the second program thread on the second processor. The second processor is sometimes referred to as a co-processor. The two processors share an extended register set to help synchronize communication and control processing The register uses the register in and out of the coprocessor to initialize the coprocessor for a program thread that will be started later. The coprocessor does not have or does not need to be used for the control or memory of the first processor. Therefore, the synchronization hardware is simplified.

The processor may have an asymmetric instruction set and structure, for example, an instruction for controlling the processor to improve the read or write of the register of the coprocessor, an instruction for accessing an extended register, an instruction for An instruction to start the coprocessor and an instruction to interrupt the coprocessor. The coprocessor is improved to access the extended register but cannot access the register of the control processor, the coprocessor The instruction is completed by an interrupt to the control processor to terminate the program thread signal of the program thread, and by setting a status flag in the extended register to indicate that the coprocessor is in an idle state, The control processor can poll the extended register or use an interrupt mechanism to determine when the control processor has completed the task. In addition, a synchronization flag in the extended register can be used by the control processor or The coprocessor is polled to determine whether other processors have completed the precursor to the execution of a program thread. Using polling, the control processor and the coprocessor can be synchronized without interrupting the coprocessor , A special control processor instruction that both tests and sets the flag in the extended register helps synchronous polling.

In an embodiment of the present invention, the control processor is a general-purpose processor and the coprocessor is a vector processor with a single instruction multiple data structure. This embodiment is extremely effective because the vector processor Provides high computing power that will not be sufficient when the synchronization function is improved, and the control processor for processing synchronization can be a relatively low-energy processor with a narrower data path than that of a vector processor. In the present invention The dual processor structure in this embodiment provides a large data path with high processing capacity, multiple processing units in the vector processor, flexibility of two separate program threads, and is mainly improved by the control processor Simplicity in software synchronization.

Fig. 1 is a block diagram of a multi-element processor according to an embodiment of the present invention.

FIG. 2 is a block diagram illustrating the interface between the control processor and the vector processor according to an embodiment of the present invention.

FIG. 3 is a flowchart illustrating a method of synchronizing parallel program threads according to an embodiment of the present invention.

FIG. 4 is a flowchart illustrating another method of synchronizing parallel program threads according to an embodiment of the present invention.

5A, 5B, and 5C illustrate the parallel and sequential software structure used in the multi-processor of FIG. 1.

The use of the same reference symbol in different drawings indicates similar or identical items.

The multi-element processor according to the embodiment of the present invention includes a pair of processors. Each processor can execute a separate program in parallel with the other processor. The control and synchronization of the execution are asymmetrical because one processor is the main processing unit. Processor or control processor and the other processor is a slave processor or a controlled processor, the control processor executes a continuum that is diverted by a second parallel program thread starting on the controlled processor The second program thread meets the program thread when the controlled processor completes the second program thread and becomes idle, and the instruction set of the controlled processor includes terminating the second program thread when it executes And an interrupt request is sent to the control processor to indicate that the second program thread has been completed.

The information that can be passed between the program clues through the mechanism includes: the shared address space and memory of the processor, and the controlled processing that the controlling processor can access when the controlled processor is idle The register set of the processor; and the "expansion" register that can be accessed by the two processors. A representative extended register includes the controlled processor that can be set to indicate that a special operation has been completed One or more of the flag bit, the other flag bit indicates whether the controlled processor is running a previously started job or in an idle state, use this flag bit to control the processors program The thread can include a waiting loop that polls the flag bit to determine whether the result requested from the controlled processor is ready. Typically, the controlled processor does not need software in its own program thread Synchronization, therefore, software synchronization requires very few additional bits.

FIG. 1 shows a block diagram of an embodiment of an integrated multi-element processor 100 according to the present invention. The multielement processor 100 includes a general-purpose processor 110 and a vector processor 120, which are integrated on a monolithic semiconductor chip The processors 110 and 120 are connected to the other on-chip components of the multi-processor 100 via a cache subsystem 130 including SRAMs 160 and 190, a ROM 170, and a cache controller 180. The cache The memory controller 180 can configure the SRAM 160 or an instruction cache 162 and a data cache 164 for the processor 110, and configure the SRAM 190 to become an instruction cache 192 for the vector processor 120 And data cache memory 194, parts of SRAM 160 and 190 are alternately formed as temporary memory in the address space shared by processors 110 and 120.

The on-chip ROM 170 contains data and firmware for the processors 110 and 120 and can also be accessed as a cache memory. The ROM 170 typically contains: reset and initialization procedures; self-test and diagnostic procedures; and Interrupt and exception handling programs. In a representative embodiment of the present invention, the multi-processor 100 is used for signal processing in multimedia applications and is sometimes referred to herein as a multimedia signal processor or MSP. For this representative embodiment, the ROM 170 additionally contains sub-programs for sound card simulation; sub-programs for signal processing of the modulator and demodulator; sub-programs for general telephone functions; 2-D and 3-D graphics The sub-program library; and the sub-program library used for the encoding and decoding of audio and video such as MPEG-1, MPEG-2, H.261, H.263, G.728 and G.723, in 1996 The U.S. Patent Application Serial No. Unknown 1 filed on August 19, 2007 entitled "Multiprocessor Operation in a Multimedia Signal Processor" further explains the use of multi-processors in multimedia applications and the entirety is hereby taken as a reference. Incorporated.

The cache sub-system 130 connects the processors 110 and 120 to the two system buses 140 and 150 and serves as a cache for the processor 110, the processor 120 and the device connected to the buses 140 and 150 To operate both with a switching station, the system bus 150 operates at a clock frequency higher than the clock frequency of the bus 140 and is connected to a memory controller 158, a local bus interface 156, and a DMA (direct (Memory Access) Controller 154, and a faster device such as a device interface 152, which respectively provide for an external local memory, a host computer's local bus, direct memory access, and various analogs Interfaces to digital and digital-to-analog converters, such as a system timer 142, a UART (Universal Asynchronous Receiver Transmitter) 144, a bit string processor 146, and an interrupt controller 148, etc. The slower device is connected to bus 140, titled "Multiprocessor Operation in a Multimedia Signal" The patent application incorporated above "Processor" further describes the operation of the cache subsystem 130 and its processors 110 and 120 through the cache subsystem 130 and the bus 140 and 150 to access representative devices. , The United States Patent Application Serial No. Unknown No. 2 entitled "Methods and Apparatus for Processing Video Data" filed on August 19, 1996 explains the variable-length encoding and decoding of bit strings conforming to the MPEG specification The bit string processor 146 and its entirety is hereby incorporated as a reference.

The processors 110 and 120 execute separate program threads and have different structures for more effective execution of special tasks. The processor 110 mainly executes a real-time operating system for the abnormal routines of the processors 110 and 120 and handles them Without a lot of repeated calculations, the processor 110 also controls the initialization, start and end of the vector processor 120. The vector processor 120 mainly performs digital manipulation involving repeated operations on a common data area in multimedia processing.

2 shows a block diagram illustrating the interaction between the processor 110 and the vector processor 120. The control processor 110 includes an instruction decoder 260 with control logic, an execution data path 270, and write and Read the registers 280 and 290. The processor 110 has a general structure of scalar data values. In the execution data path 270 of FIG. 2, a register file 272 includes a set of 32-bit data registers and a set of A state register, and a processing unit 276 has a 32-bit bus for operating operands up to 32 bits in size.

In a representative embodiment, the processor 110 is a 32-bit RISC processor operating at 40 megahertz (MHz) and conforming to the structure of the ARM7 processor. Sheet)" file number: ARM DDI 0010G describes the structure and instruction set for an ARM7 RISC processor. The whole of the ARM7DM data sheet is hereby incorporated as a reference. Appendix A explains in this representative embodiment Expansion of the ARM7 instruction set for the interaction between the processor 110 and the vector processor 120 or the cache subsystem 130.

In the embodiment of FIG. 2, the vector processor 120 has a SIMD (single instruction multiple data) structure and includes an instruction extraction unit (IFU) 210, a decoder 220, a scheduler 230, and an execution data path 240 , And a load/store unit (LSU) 250. IFU210 fetches instructions and processes control flow instructions like branches. The instruction decoder 220 decodes an instruction every cycle, in accordance with the order of arrival from the IFU, and decodes it by the instruction The field value is written in FIF0234 in the scheduler 210, and the sending control logic 232 in the scheduler 230 selects the field values sent to the execution data path 240 and LSU 250 as required to complete the operation, and executes the data path 240 Execute logic/arithmetic instructions for operating vectors or scalar data, load/store unit 250 executes load/store instructions for accessing the address space shared by vector processor 120 and control processor 110, exception control logic 215 is connected To the IFU 210, the decoder 220, and the scheduler 230 and send out an interrupt to control the processor 110 when decoding or executing the vector processor instruction causes an exception.

In this representative embodiment, the execution data path 240 includes a parallel processing unit 246, which includes 8 32-bit floating point units, 8 36-bit integer multipliers, and 8 36-bit arithmetic logic units (ALUs), each 36-bit integer processing unit can perform one operation on 36-bit data elements, perform two simultaneous operations on 16-bit data, or on 8-bit or 9-bit data It performs four simultaneous operations. The parallel processing unit 246 can process 288-bit vector operands and 32-bit scalar operands. A register file 242 used to execute the data path 240 contains a 288-bit vector. The register 244, and most of the data path in the vector processor 120 is 288-bit or 576-bit wide to support up to 32 8-bit or 9-bit data elements, 16 16-bit data The parallel processing unit 246 in the vector processor 120 executes and completes the same instruction simultaneously with the SIMD structure, or the simultaneous operation of 8 32-bit data elements.

The vector processor 120 includes a RISC engine operating on an 80 megahertz (MHz) pipeline in a representative embodiment. The register of the vector processor 120 includes a 32-bit dedicated register 245, a return address stack (not shown) (Shown), a 32-bit scalar register 243, two sets of 288-bit vector registers 244, and two double-sized (that is, 576-bit) vector accumulation registers (not shown), The register file 242 includes 32 scalar registers identified by a 5-bit register number ranging from 0 to 32 in the command, and 64 vector registers organized into two rows of 32 vector registers The 288-bit vector register of the device, each vector register can be identified by a 1-bit row group number (0 or 1) and a 5-bit vector register number ranging from 0 to 31 Most of the instructions only access the vector register in the current bank as indicated by the control bit CBANK stored in the dedicated (control/status) register VCSR of the vector processor 120, A second control bit, VEC64, indicates whether it is recognized by the default register number, and includes a vector register of twice the size of the register from each row group. The syntax difference of the command identifies the register of the vector register The register number and the register number of the identification scalar register and the register number of the special-purpose register for identification.

Each vector register 244 can be divided into data elements of programmable size. For example, a 288-bit vector register can hold 32 8-bit or 9-bit integer data elements, and 16 16-bit data elements. Elementary integer data element, or 8 32-bit integer or floating point data elements, two vector registers logically combined as a double-sized register store a data element with an image that is twice as large As many vectors, in the representative embodiment of the present invention, the set control bit VEC64 places the vector processor 120 in a mode VEC64. In this mode VEC64, the vector processor is defaulted to be twice the size (576 bits). Yuan), the US patent application filed on August 19, 1996 entitled "SINGLE-INSTRUCTION-MULTIPLE-DATA PROCESSING IN A MULTIMEDIA SIGNAL PROCESSOR" further explains the structure of the representative embodiment for the vector processor 120 And the instruction set and the entirety is hereby incorporated as a reference.

The multi-processor 100 also includes a set of 32-bit expansion registers 115 that can be accessed by both the processors 110 and 120. The expansion registers 115 include licensed expansion registers and user expansion registers. The licensed extended register controls or represents the general operation mode of the multi-processor 100. The user extended register includes registers used to synchronize the program threads executed by the processors 110 and 120. In an exemplary embodiment, the user extended register includes a vector processor state flag VPSTATE and a synchronization flag VASYNC. The state flag VPSTATE has two values (VP_RUN and VP_IDLE) and indicates whether the vector processor 120 is running Running a program thread or is in an idle state. In this representative embodiment, the vector processor 120 regards the extended register VASYNC as its own dedicated register, and provides a vector processor instruction like the instruction VMOV Read or write access to the register VASYNC, other commands implicitly access the special extended register, for example, when a program thread is completed or is aborted due to an exception, an exception is generated VCINT and VCJOIN or any instruction changes the state flag VPSTATE to state VP_IDLE. The extended registers VPSTATE and VASYNC have two read ports to read both processors 110 and 120 at the same time to read the register.

When the vector processor 120 is in the VP_IDLE state, the processor 110 can read or write the scalar and dedicated registers of the vector processor 120, but when the vector processor 120 is in the VP_RUN state, the processor 110 can read or write The result of the processor 110 of a register of the vector processor 120 is undefined. The expansion of the ARM7 instruction set used for the processor 110 includes the instructions MFER and MTER to access the extended register 115 and access to vector processing If the scalar or special register commands MFVP and MTVP of the device 120 meet a previous condition, then a conditional command TESTSET reads an extended register and sets the bit 30 of the extended register to 1, The instruction TESTSET is cleared by a vector processor 120 to indicate the value of a synchronization point and resets the bit 30 to prepare for the next synchronization point to help the user/manufacturer to synchronize.

The processor 110 executes the instructions STARTVP and INTVP to start and stop the vector processor 120, and, as shown above, can access the scalar and dedicated registers of the vector processor 120. In contrast, the vector processor 120 cannot start or stop. The processor 110 cannot access the register of the processor 110. This asymmetrical distribution of control between the processors 110 and 120 simplifies the synchronization of the processors 110 and 120. According to an aspect of the present invention, Every time when the vector processor 120 becomes idle, the vector processor 120 generates an interrupt request to the processor 110. For example, at the end of a typical program thread, the vector processor 120 executes an interrupt request and sets the vector When the processor is in the state VP_IDLE with the instruction VCJOIN or VCINT, the processor 110 can use the interrupt processing routine to transfer the result and restart the vector processor 120. Therefore, the interrupt processor can synchronize the processors 110 and 120, US Patent Application No. The case of Unknown No. 4 is titled "System and Method for Handling Software Interrupts with Argument Passing" and the U.S. Patent Application Serial No. Unknown No. 5 is titled "System and Method for Handling Interrupts and Exception Events in an Asymmetric Multiprocessor Architecture" case, both of which were filed on August 19, 1996, illustrate the exception and interrupt handling used in a representative embodiment of the present invention and the entirety is hereby taken as a reference. enter.

The polling program can be used for synchronization instead of the interrupt handler. FIG. 3 is a flowchart of an example of a program 300 for dual threads according to an embodiment of the present invention. After starting a program thread on the vector processor 120 Previously, the processor 110 determined whether the vector processor 120 is running or in an idle state by executing a waiting loop 315 including steps 310 and 320 that determine the value of the register VPSTATE, after starting or resetting the multi-processor 100 And after the vector processor 120 executes an instruction that generates an exception, the vector processor is idle.

The U.S. Patent Application Serial No. Unknown No. 3 filed on August 19, 1996, titled "Efficient Context Saving and Restoring in Multiprocessors", illustrates that a processor 110 and 120 can be used and the entirety is hereby incorporated as Refer to the context exchange process. During the context storage process, the vector processor 120 periodically executes a conditional context exchange command VCCS, which jumps to a context exchange subroutine if the flag bit in an extended register VIMSK When the meta CSE is set, at the end of the context exchange subroutine, the vector processor 120 can execute the instruction VCINT or VCJOIN and enter the state VP_IDLE, so in a representative context exchange process, the processor 110 sets the flag Bit CSE and wait for the vector processor 120 to become idle as in the wait loop 315.

The processor 110 remains in the waiting loop 315 and continues to poll the extended register VPSTATE until the vector processor 120 is idle. Once the vector processor 120 is idle, the processor 110 immediately executes step 330 for a new program thread to create a vector The processor 120, in step 330, the processor 110 can write a program address into a special register VPC that is the program counter of the vector processor 120, and the processor 110 can also write other parts of the vector processor 120 The scalar and dedicated registers are used to transfer parameters to the vector processor 120. Once the vector processor 120 is initialized, the processor 110 immediately executes in step 345. In step 345, an instruction STARTVP starts the vector processor to execute in step In the program thread in 345, the instruction STARTVP sets the register VPSTATE to the state VP_RUN, and when the value VP_RUN is read, the vector processor 120 starts to fetch and execute instructions. At this time, the processor 110 continues to execute its program thread to make the processing The devices 110 and 120 operate in parallel.

In the procedure 300, the processor 110 can continue the execution of its program thread, but step 380 must be synchronized with the result from the vector processor 120. The vector processor 120 in the execution of its program thread completes the result in step 355 and executes The instruction VCINT or VCJOIN is in step 365, and its execution is stopped in step 375. In order to ensure that step 380 occurs after step 355, the processor 110 executes the waiting loop including steps 360 and 370 and waits until the vector processor 120 is idle. A possible sequence of events is that the processor 110 reaches step 360 before the vector processor 120 executes step 365. In this case, the processor 110 repeatedly executes instructions 360 and 370 until the vector processor 120 becomes idle. A second possibility is The sequence of events is that the processor 120 executes step 365 before the processor 110 reaches step 360. In this second case, the processor 110 executes steps 360 and 370 each time.

In step 380, the processor 110 processes the result and can use another STARTVP instruction to simply initialize and restart the vector processor 120. In the event that there may be a context exchange due to previous program clues, the processor 110 can The vector processor 120 is initialized by an address of a subprogram that restores the previously stored content and restores the interrupted program thread.

FIG. 4 shows another example of a dual-thread program 400 using polling for synchronization according to an embodiment of the present invention. The program 400 starts as described above for the program 300 illustrated in FIG. 3, In particular, the processor 110 remains in the waiting loop 315 until the vector processor 120 is idle, the vector processor 120 is created in step 330, and the vector processor 120 is activated in step 340 in response to the vector processor 120 to start executing a program The clue is in step 345. In the program 400, the processor 110 requires the vector processor 120 to complete the result in step 355 before the processor 110 executes step 480. The difference between the program 400 and the program 300 is that the vector processor 120 performs the next step After the execution of 455, it does not enter the idle state so that the register VPSTATE is not used for synchronization. Instead, a loop 460 polls the extended register VASYNC to synchronize steps 480 and 355.

In loop 460, a first step 462 reads the extended register VASYNC. In this representative embodiment, the processor 110 can use the read extended register and set the register's flag bit (bit Element <30>) command TESTSET to read the extended register. When register number 15 is used as the end of the command TESTSET, the flag bit is transferred to the state register of the processor 110 The program 400 relies on the vector processor to clear the flag bit to indicate that step 355 has been completed, so that the instruction 468 can determine whether the state bit Z is not equal to 0 by branching Return to step 462 and complete step 355. When the flag bit is 0, the processor 110 moves to step 480 and continues processing. The use of the command TESTSET in step 462 has the flag in the extended register VASYNC The standard bit is the same as the loop 460 for a future synchronization loop and has the advantage of being automatically reset.

Using the control processor instruction VPSTART and the vector processor instruction VCJOIN, the multi-element processor 100 of FIG. 1 can support the programming paradigm of parallel execution and sequential execution. FIGS. 5A and 5B illustrate two situations for the parallel execution paradigm. In FIG. 5A, the processor 110 executes an instruction string 510 that diverges the execution thread 520 for the vector processor 120. The STARTVP instruction 512 specifies the target address of the vector processor 120 to start fetching instructions, so one is processed by the vector The first instruction 522 executed by the processor 120 is followed by the instruction 512 and is executed in parallel with the instruction executed by the processor 110. The processor 110 continues to execute its instruction string until it reaches the image related to FIGS. 3 and 4 In the waiting loop 514 described above, the vector processor 120 executes its instruction string until it reaches the clear register VASYNC and when the vector processor 120 is in the idle mode VCJOIN instruction 524, (in another embodiment, the vector processing The processor 120 sends an interrupt request to the processor 110, and an interrupt handler executed by the processor 110 clears the register VPSTATE). In FIG. 5A, the processor 110 arrives in the waiting loop before the processor 120 reaches the VCJOIN instruction 524 514, and the processor 110 spins and waits until the vector processor 120 completes its designated task.

On the other hand, as illustrated in FIG. 5B, the vector processor 120 completes the instruction string 540 starting with the instruction 542 and ending with the VCJOIN instruction 544 before the processor 110 reaches the waiting loop 534. In this case, the processing The processor 110 does not waste time spinning waiting, but passes through the waiting loop 534. However, from the time the VCJOIN instruction is executed until after the waiting loop 534 when the processor 110 can start the vector processor 120 again, the vector processor 120 is in Idle state.

This parallel programming paradigm provides high performance because when the scalar part of the calculation is executed in parallel on the processor 110, the parallel program of multiple threads can develop the power of the vector processor 120, which is between the processors 110 and 120. The data communication between them occurs at the synchronization point marked by the waiting loop executed by the processor 110, and the vector processor 120 does not need any spin waiting.

5C illustrates a programming paradigm for sequential execution of the multiprocessor 100 of Fig. 1. In the sequential execution programming paradigm, the processor 110 uses a STARTVP instruction 552 to diverge the execution thread and immediately Entering the waiting loop 554, the processor 110 waits in the loop 554 until the vector processor 120 completes a program sequence 560 from the instruction 562 to the VCJOIN instruction 564. When the vector processor 120 executes the VCJOIN instruction 564 and becomes idle, the processor 110 leaves Waiting for the loop 554 and starting to execute the instructions following the instructions 562 to 564 in sequence. The programming paradigm of sequential execution is not as efficient as the programming paradigm of parallel execution but may be logically simpler.

A modification of the programming paradigm of sequential execution in FIG. 5C or the programming paradigm of parallel execution in FIG. Interrupts and exceptions, this change may be useful in a representative embodiment where the vector processor 120 operates at twice the operating frequency of the processor 110 and is more powerful than the processor 110.

Although the present invention has been described with reference to its specific embodiments, this description is only an example of the application of the present invention and should not be taken as a limitation. The various applicability and combinatorial characteristics of the disclosed embodiments are all It is within the scope of the present invention as defined by the scope of subsequent patent applications.

Appendix A:

In this representative embodiment, the processor 110 is a general-purpose processor that complies with the specifications for an ARM7 processor. Please refer to the ARM7 Data Sheet (in The document number ARM DDI 0020C issued in December 1994), the expansion of the ARM7 instruction set, the processor 110 and the vector processor 120 by: start or stop the vector processor 120; the test includes the vector processor for synchronization Status; and the transfer of data between the register of the vector processor to the register of the processor 110 or the expansion processor interacts, the transfer between the general register and the vector register requires one Intermediate storage, such as in local memory.

Table A.1 illustrates the expansion of the ARM7 instruction set for the processor 110 that initiates the interaction between the vector processor 120 and the cache subsystem 130.

<tables><img file="TW366455B_D0001.tif" /></tables><tables><img file="TW366455B_D0002.tif" /></tables><tables><img file="TW366455B_D0003.tif" /></tables>

Table A.2 lists the ARM7 anomalies detected and reported before the execution of the error instruction. The address of the anomaly vector is expressed in hexadecimal notation.

<tables><img file="TW366455B_D0004.tif" /></tables>

Next, the extended syntax of the ARM7 instruction set is explained. The ARM7 structure provides three instruction formats for the coprocessor interface: 1. Coprocessor Data (CDP) format

2. Co-processor data transfer (LDC/STC) format

3. Co-processor register transfer (MRC/MCR) format

<u style="single">CDP format</u>The command is used to return to the ARM7 processor without communication. Table A.3 defines the fields of the CDP format command

<tables><img file="TW366455B_D0005.tif" /></tables><tables><img file="TW366455B_D0006.tif" /></tables>

The coprocessor data transfer format (LDC/STC) is directly loaded from the memory to the register of a subset of the coprocessors or directly stored in the register of a subset of the coprocessors to the memory, supplied by the ARM7 processor Character address, and the co-processor supplies or receives data and controls the number of characters transferred. Table A.4 defines the fields in the LDC/STC format.

<tables><img file="TW366455B_D0007.tif" /></tables><tables><img file="TW366455B_D0008.tif" /></tables>

The co-processor register transfer format (MRC, MCR) is used to directly communicate with the data between the ARM7 register and the co-processor register. Table A.5 defines the instructions with the MRC/MCR format Field.

<tables><img file="TW366455B_D0009.tif" /></tables><tables><img file="TW366455B_D0010.tif" /></tables>

<u style="single">Extended ARM7 instructions</u>

The following is an extended ARM7 instruction.

CACHE (Cache Memory Operation)

Format: LDC/STC

With L=O; CRn=Opc; and CP#=1111.

Syntax of assembly program:

STC{cond} p15, cOpc,&lt;Address&gt;

cache{cond} Opc,&lt;address&gt;where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv} and Opc={ 0, 1, 2, 3}. For the instruction CACHE, the field CRn in the LDC/STC format specifies the opcode Opc, so the decimal notation of the opcode in the first syntax starts with the letter'C' (for example, use c0 instead of 0), the reference bit ARM7 Data Sheet for address mode syntax.

instruction:

The CACHE instruction is executed only when Cond is true. The field Opc&lt;3:0&gt; specifies the following operations:<tables><img file="TW366455B_D0011.tif" /></tables>

For how to calculate EA, please refer to the ARM7 Data Sheet.

Anomaly: ARM7 protection infringement

<u style="single">INTVP (Interrupt Vector Processor)</u>

Format: CDP

Among them, Opc=0001; 0; CP#=0111; and CRn, CRd, CP, and CRm are not used.

Syntax of assembly program:

CDP{cond} p7, 1, c0, c0, c0 INTVP{cond}

Where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, bits 19:12, 7:15 and 3:0 Is reserved.

instruction:

When Cond is true, the instruction INTVP signals the vector processor to stop. In one embodiment, the instruction INTVP sets the bit CSE to indicate that the vector processor should store its current context and stop until the vector processor executes a condition next time When the VCCS instruction is stored in the context, the ARM7 processor does not wait for the vector processor to stop and continues to execute. The ARM7 processor should execute an MFER busy waiting loop to see if the vector processor has stopped after the INTVP instruction. The processor is already in the VP_IDLE state, then the INTVP instruction has no effect.

Exception: When the vector processor is not available for use

<u style="single">MFER transferred from the extended register</u>

Format: MCR

Where Opc=010; L=1; CRn=cP; CP#=0111; CP is not used; CRm=ER

Syntax of assembly program:

MRC{cond} p7, 2 Rd, cP, cER, 0

MFER{cond} Rd, RNAME

Where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd={r0,....,r15}, p= {0, 13}, ER={0,..., 15}, and RNAME refers to the extended register.

instruction:

The instruction MFER is executed only when Cond is true, as shown in Table A.9 below, the data from the extended register ER identified by P:ER&lt;3:0&gt; is transferred to the ARM7 register Rd.

<tables><img file="TW366455B_D0012.tif" /></tables><tables><img file="TW366455B_D0013.tif" /></tables><tables><img file="TW366455B_D0014.tif" /></tables>

abnormal:

Protection infringement when attempting to access PERx while in user mode.

<u style="single">MFVP transfer from vector processor</u>

Format: MRC/MCR

Where Opc=001; L=1; CP#=0111; and CP is not used.

Syntax of assembly program:

MRC{cond} P7, 1, Rd, CRn, CRm, 0

MFVP{cond} Rd, RNAME

Where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd={r0,....,r15}, CRn= {c0,....,c15}, CRm={c0,....,c15}, and make RNAME refer to the scalar or special register in the vector processor.

instruction:

The instruction MFVP is executed only when Cond is true, and the data from the scalar or dedicated register of the vector processor identified by CRn&lt;1:0&gt;:CRm&lt;3:0&gt; is transferred to an ARM7 register Rd, bit CRn&lt;3:2&gt; is reserved. Table A.10 shows the mapping from CRn&lt;1:0&gt;: CRm&lt;3:0&gt; scalar register SR0 to SR15 and dedicated temporary storage in the vector processor The device is mapped from SP0 to SP15.

Table A.1O mapping from CRn:CRm to VP register<tables><img file="TW366455B_D0015.tif" /></tables><tables><img file="TW366455B_D0016.tif" /></tables>

SR0 is always read as 32 bits of 0 and written to SR0 is ignored.

Exception: When the vector processor is not available for use.

<u style="single">MTER transfer to the extended register</u>

Format: MRC/MCR

Where Opc=010; L=0, CRn=cP; CP#=0111; CP is not used; and CRm=ER.

Syntax of assembly program:

MRC{cond} P7, 2, Rd, cP, cER, 0

MFVP{cond} Rd, RNAME

Where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd={r0,....,r15}, P= {0,1}, ER={0,....,15}, and RNAME refers to the register mnemonic (such as PERO).

instruction:

The instruction MTER is executed only when Cond is true. As shown in Table A.9 above, the data from the ARM7 register Rd is transferred to the extended register specified by P:ER &lt;3:0&gt;.

abnormal:

Protection infringement when attempting to access PERx while in user mode.

<u style="single">MTVP transfer to vector processor</u>

Format: MRC/MCR

Where Opc=1; L=0; CP#=0111; and CP is not used.

Syntax of assembly program:

MRC{cond}P7, 1, Rd, CRn, CRm, 0

MFVP{cond}RNAME, Rd

Where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd={r0,....,r15}, CRn= {c0,...c15}, CRm={c0,....,c15}, and RNAME refers to the register mnemonic (such as SPO or VCSR).

instruction:

The instruction MTVP is executed only when cond is true, and the data from the ARM7 register Rd is transferred to the vector processor scalar/dedicated register CRn&lt;1:0&gt;:CRm&lt;3:0&gt;, CRn=CRm The mapping of scalar and dedicated registers to the vector processor are shown in Table A.10 above.

Exception: When the vector processor is not available for use.

<u style="single">PFTCH</u>Pre-extracted

Format: LDC/STC

With N=0; L=1; CRn=0010; and CP#=1111.

Syntax of assembly program:

LDC{cond}P15, 2,&lt;Address&gt;

PFTCH{cond}&lt;Address&gt;

Where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, refer to the ARM7 Data Sheet of address mode syntax.

instruction:

The instruction PFTCH is executed only when Cond is true, and a cache boundary specified by EA is extracted in advance into the ARM7 data cache. For how to calculate EA, please refer to the ARM7 Data Sheet.

Exception: None.

<u style="single">STARTVP</u>Start vector processor

Format: CDP format

With Opc=0000; CP#=0111; and CRn, CRd, CP and CRm are not used.

Syntax of assembly program:

CDP{cond}P7, 0, c0, c0, c0

STARTVP{cond}

Where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}.

instruction:

The instruction STARTVP is executed only when Cond is true. The instruction STARTVP signals that the vector processor starts to execute and automatically clears VISRC&lt;vjp&gt; and VISRC&lt;vip&gt;. The ARM7 processor does not wait for the vector processor to start executing and continues to execute the next one. Instruction, the vector processor must be initialized to the required state before executing this instruction. If the vector processor is already in the VP-RUN state, then the instruction STARTVP has no effect.

Exception: When the vector processor is not available for use.

<u style="single">TESTSET</u>Testing and setting

Format: MRC/MCR

With Opc=000; L=1; CRn=0; CP#=0111; CRm=ER; and CP is not used.

Syntax of assembly program:

MRC{cond}P7, 0, Rd, c0, cER, 0

TESTSET{cond}Rd, RNAME

Where cond={eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd={r0,....,r15}, ER= {0,...15}, and RNAME refers to the register mnemonic (for example, UER1 or VASYNC).

instruction:

The instruction TESTSET is executed only when Cond is true. The instruction TESTSET returns the context of the extended register UERx to the general register Rd and sets UERx &lt;30&gt; to 1, if the ARM7 register 15 is designated as the target register Then the UERx&lt;30&gt; is sent back to the bit Z of the CPSR register, which makes it possible to improve the short waiting loop.

Exception: none

Attachment B:

This appendix describes the instructions VCINT, VCJOIN, and VMOV used by the vector processor to support synchronization with the control processor in the representative embodiment of the present invention. -INTSRUCTION-MULTIPLE-DATA PROCESSING IN A MULTIMEDIA SIGNAL PROCESSOR" The patent application describes the entire instruction set used in the vector processor, and the instruction operation is defined using a structure like the C programming language.

<u style="single">VCINT</u>Conditional interrupt ARM7

<tables><img file="TW366455B_D0017.tif" /></tables>

Syntax of assembly program:

VCINT.cond #ICODE

Where cond={un, lt, eq, le, gt, ne, ge, ov}.

instruction:

If cond is true, if the interrupt is enabled, the execution is aborted and the ARM7 processor is interrupted.

operate:

<img file="TW366455B_D0018.tif" />

Exception: VCINT interrupt

<u style="single">VCJOIN</u>Conditional and ARM7 working joint

<tables><img file="TW366455B_D0019.tif" /></tables>

Syntax of assembly program:

VCJOIN. cond #Offset

Where cond={un, lt, eq, le, gt, ne, ge, ov}.

instruction:

If Cond is true, if the interrupt is enabled, the execution is aborted and the ARM7 processor is interrupted.

operate:

<img file="TW366455B_D0020.tif" />

Exception: VCJOIN interrupted

<u style="single">VMOV</u>Transfer

<tables><img file="TW366455B_D0021.tif" /></tables><tables><img file="TW366455B_D0022.tif" /></tables>

Syntax of assembly program:

VMOV.dt Rd, Rb

Where dt={b, b9, h, w, f}, Rd and Rb represent the name of the register, and the suffix .w and .f represent the same operation.

Support mode:

int8(b), int9(b9), int16(h), and int32(w)

instruction:

The context of the register Rb is transferred to the register Rd, and the field group specifies the source register group and the target register group as defined in Table B.4.

Table B.4: Group field definition<tables><img file="TW366455B_D0023.tif" /></tables><tables><img file="TW366455B_D0024.tif" /></tables>

In B.4, the register group representation system: the vector register of the current group of VR

Vector register of VRA alternate group

SR scalar register

SP dedicated register

RAS loopback address stack register

VAC vector progressive register (see Table B.5) A vector register cannot be transferred to the scalar register with the instruction VMOV but can be transferred to the scalar register with the instruction VEXTRT.

Table B.5 defines the VAC register number coding

Table B.5: VAC register number<tables><img file="TW366455B_D0025.tif" /></tables>

operate:

Rd=Rb

abnormal:

The abnormal status bit set in VCSR or VISRC will cause related abnormalities.

Programming considerations:

The instruction VMOV is not affected by element masking, because the alternate group concept does not exist in the VEC64 mode, and the instruction VMOV cannot be used in the VEC64 mode to transfer from or to the alternate group register.