WO2000079400A1 - Procedes et appareils permettant la detection d'evenements et la specification d'actions generalisees dans un processeur - Google Patents

Procedes et appareils permettant la detection d'evenements et la specification d'actions generalisees dans un processeur Download PDF

Info

Publication number
WO2000079400A1
WO2000079400A1 PCT/US2000/040273 US0040273W WO0079400A1 WO 2000079400 A1 WO2000079400 A1 WO 2000079400A1 US 0040273 W US0040273 W US 0040273W WO 0079400 A1 WO0079400 A1 WO 0079400A1
Authority
WO
WIPO (PCT)
Prior art keywords
eventpoint
instruction
event
register
loop
Prior art date
Application number
PCT/US2000/040273
Other languages
English (en)
Inventor
Edwin Frank Barry
Patrick R. Marchand
Gerald G. Pechanek
Charles W. Kurak, Jr.
Original Assignee
Bops Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bops Incorporated filed Critical Bops Incorporated
Publication of WO2000079400A1 publication Critical patent/WO2000079400A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30105—Register structure
    • G06F9/30112—Register structure comprising data of variable length
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3024—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30101—Special purpose registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Definitions

  • a processor event or p-event may be defined as some change of state that it is desirable to recognize.
  • the acknowledgement of a processor event may be termed a processor action or p-action.
  • the purpose of the event-action mechanism, or eventpoint is to synchronize various actions with specific program and/or data flow events within the processor. Examples of eventpoints which may be encountered include reaching a specified instruction address, finding a specific data value during a memory transfer, noting the occurrence of a particular change in the arithmetic condition flags, accessing a particular memory location, etc.
  • Eventpoints can also include a linked sequence of individual eventpoints, termed chaining, such as finding a specific data value after reaching a specified instruction address, or reaching a second specified instruction address after reaching a first specified instruction address.
  • the p-actions can include changing the sequential flow of instructions, i.e., vectoring to a new address, causing an interrupt, logging or counting an event, time stamping an event, initiating background operations such as direct memory access (DMA), caching prefetch operations, or the like.
  • DMA direct memory access
  • each p-event and its consequent p-action typically was treated uniquely and separately from other specific event-actions in order to solve some special problem.
  • One of the many new contributions the architecture of the present invention provides is a generalized eventpoint mechanism.
  • a requirement of the traditional sequential model of computation is that the processor efficiently handle the programming constructs that affect the sequential flow of instructions to be executed on the processor.
  • one of these programming constructs is an auto-looping mechanism, which is found on many digital signal processors (DSPs). Auto-looping is employed to change the program flow for repetitive loops without the need for branch instructions, thereby improving the performance of programs that use loops frequently. Nested loops have also been supported in the prior art.
  • the present invention addresses the need to provide a processor with a generalized p- event and p-action architecture which is scalable for use in a very long instruction word (VLIW) array processor, such as the ManArray processor.
  • generalized p-event detection facilities are provided by use of a compare performed to discover if an instruction address, a data memory address, an instruction, a data value, arithmetic-condition flags, and/or other processor change of state eventpoint has occurred.
  • generalized p-action facilities are provided to cause a change in the program flow by loading the program counter with a new instruction address, generating an interrupt, generating a log, counting the p-event, passing a parameter, etc.
  • the generalized facilities may be advantageously defined in the eventpoint architecture as consisting of a control register and three eventpoint parameters: 1) a register to compare against, 2) a register containing a second compare parameter, vector address, or parameter to be passed, and 3) a count or mask register.
  • new capabilities are supported that extend beyond typical prior art capabilities. For example, auto-looping with capabilities to branch out of a nested auto-loop upon detection of a specified condition, background DMA facilities, and the ability to link a chain of p-events together for debug purposes, among others are all new capabilities easily obtained by use of this invention.
  • Fig. 1 illustrates an exemplary 2x2 ManArray iVLIW processor suitable for use in conjunction with the present invention
  • Fig. 2A illustrates an exemplary load from special purpose register (LSPR) instruction encoding
  • Fig. 2B illustrates an exemplary load from special purpose register syntax/operation description
  • Fig. 3A illustrates an exemplary store to special purpose register (SSPR) instruction encoding
  • Fig. 3B illustrates an exemplary store to special purpose register syntax operation description
  • Fig. 4 illustrates an exemplary placement of eventpoint registers in an special purpose register file (SPRF) in accordance with the present invention
  • Fig. 5 illustrates an exemplary instruction eventpoint high level logic flow diagram
  • FIGs. 6A-6G illustrate exemplary decode and control logic descriptions for instruction eventpoint modules in accordance with the present invention
  • Fig. 7A illustrates an exemplary event point loop (EPLOOP) instruction encoding in accordance with the present invention
  • Fig. 7B shows a syntax/operation table for the EPLOOP instruction of Fig. 7A
  • Fig. 7C illustrates an exemplary event point loop immediate (EPLOOPI) instruction encoding in accordance with the present invention
  • Fig. 7D shows a syntax/operation table for the EPLOOPI instruction of Fig. 7C;
  • Fig. 8 illustrates a ManArray pipeline timing diagram for the EPLOOP instruction of Fig. 7A
  • Fig. 9 illustrates an exemplary data eventpoint high level logic flow diagram
  • Figs. 10A- 10J illustrate exemplary decode and control logic descriptions for data eventpoint modules in accordance with the present invention
  • Fig. 1 1 illustrates an exemplary eventpoint chaining apparatus in accordance with the present invention
  • Figs. 12A-12C illustrate aspects of an exemplary background DMA eventpoint program in accordance with the present invention. Detailed Description
  • Provisional Application Serial No. 60/113,637 entitled “Methods and Apparatus for Providing Direct Memory Access (DMA) Engine” filed December 23, 1998
  • Provisional Application Serial No. 60/113,555 entitled “Methods and Apparatus Providing Transfer Control” filed December 23, 1998
  • Provisional Application Serial No. 60/139,946 entitled “Methods and Apparatus for Data Dependent Address Operations and Efficient Variable Length Code Decoding in a VLIW Processor” filed June 18, 1999
  • 60/140,245 entitled “Methods and Apparatus for Generalized Event Detection and Action Specification in a Processor” filed June 21, 1999
  • Provisional Application Serial No. 60/140,163 entitled “Methods and Apparatus for Improved Efficiency in Pipeline Simulation and Emulation” filed June 21, 1999
  • Provisional Application Serial No. 60/140,162 entitled “Methods and Apparatus for Initiating and Re-Synchronizing Multi-Cycle SIMD Instructions” filed June 21, 1999
  • 60/140,244 entitled “Methods and Apparatus for Providing One-By-One Manifold Array (lxl ManArray) Program Context Control” filed June 21, 1999
  • Provisional Application Serial No. 60/140,325 entitled “Methods and Apparatus for Establishing Port Priority Function in a VLIW Processor” filed June 21, 1999
  • Provisional Application Serial No. 60/140,425 entitled “Methods and Apparatus for Parallel Processing Utilizing a Manifold Array (ManArray) Architecture and Instruction Syntax” filed June 22, 1999
  • Provisional Application Serial No. 60/165,337 entitled “Efficient Cosine Transform Implementations on the ManArray
  • a minimum of two parameters are used with generally three parameters utilized. These three general parameters are defined in the eventpoint architecture as a first register to compare against, a second optional register containing either a second compare parameter, a vector address, or parameter to be passed, and a third register acting as a p-event counter or a mask. To allow flexibility in the control of how these three parameters are used, a control register is employed for each eventpoint set of the three parameters. The control register content specifies the type of comparison that is to be made and defines the action to be taken.
  • an eventpoint can be uniquely identified when a compare match occurs between the first compare register parameter and a specified processor state, or when a chain of eventpoints occurs in some logical or sequential fashion.
  • Some of the possible processor states that can be compared for include an instruction address, a specific instruction, a VLIW Memory (VIM) address, a data memory address, a memory or register file data value, flags, a control register value, and the like.
  • the control register also defines how the eventpoint is to be treated and the p-action that is to occur. Some p-actions make use of the second register parameter.
  • the second register parameter can contain a vector address that is loaded in the program counter upon a p-event detection, thereby directing the program to a debug routine or the beginning of a program loop.
  • Other examples include: starting a background operation at an eventpoint, such as a DMA operation, and using the second parameter register to pass a variable to the DMA hardware, generating an interrupt at the eventpoint and using the second parameter register to pass a variable to the interrupt routine, and the like.
  • Other p-actions include counting the p-event, link to and enable another eventpoint, etc.
  • the determination of whether a p-event is used directly to cause a p-action, or whether multiple occurrences of the same p-event are required before causing a p-action, is made by the control register in conjunction with the third count parameter.
  • the eventpoint counter is tested for a zero state, a one state, or other state indicating it contains some count value. These three states can be tested for at different eventpoints and different p-actions can result.
  • An eventpoint (EP) auto-loop with unique capabilities can be specified as a subset of the capabilities of the present invention.
  • an EP auto-loop can be set up that skips the loop completely if the count is zero at the loop start address, or an auto-loop can be set up that allows a conditional exit from the auto-loop based upon the state of an arithmetic condition flag.
  • an EP auto-loop can be set up that skips the loop completely if the count is zero at the loop start address, or an auto-loop can be set up that allows a conditional exit from the auto-loop based upon the state of an arithmetic condition flag.
  • a ManArray 2x2 iVLIW single instruction multiple data stream (SIMD) processor 100 shown in Fig. 1 contains a controller sequence processor (SP) combined with processing element-0 (PE0) SP/PE0 101, as described in further detail in U.S. Application Serial No. 09/169,072 entitled “Methods and Apparatus for Dynamic Merging an Array Controller with an Array Processing Element”.
  • SP controller sequence processor
  • PE0 processing element-0
  • Three additional PEs 151, 153, and 155 are also utilized to demonstrate the generalized processor event detection and action specification architecture and design apparatus for the present invention.
  • the fetch controller 103 provides the typical functions needed in a programmable processor, such as a program counter (PC), branch capability, eventpoint (EP) loop control operations, support for interrupts, and also provides the instruction memory control which could include an instruction cache if needed by an application.
  • the SIW I-Fetch controller 103 dispatches 32-bit SIWs to the other PEs in the system by means of the 32-bit instruction bus 102.
  • the execution units 131 in the combined SP/PEO 101 can be separated into a set of execution units optimized for the control function, for example, fixed point execution units, and the PE0 as well as the other PEs 151 , 153 and 155 can be optimized for a floating point application.
  • the execution units 131 are of the same type in the SP/PEO and the other PEs.
  • SP/PEO and the other PEs are shown as all using a five instruction slot iVLIW architecture which contains a very long instruction word memory (VIM) 109 and an instruction decode and VIM controller function unit 107 which receives instructions as dispatched from the SP/PEO's I-Fetch unit 103 and generates the VIM addresses-and-control signals 108 required to access the iVLIWs stored in the VIM.
  • Store, load, arithmetic logic unit (ALU), multiply accumulate unit (MAU), and data select unit (DSU) instruction types are identified by the letters SLAMD in VIM 109 as follows; store (S), load (L), ALU (A), MAU (M), and DSU (D).
  • ALU arithmetic logic unit
  • MAU multiply accumulate unit
  • DSU data select unit
  • the data memory interface controller 125 must handle the data processing needs of both the SP controller, with SP data in memory 121, and PE0, with PE0 data in memory 123.
  • the SP/PEO controller 125 also is the source of the data that is sent over the 32-bit or 64-bit (depending upon implementation) broadcast data bus 126 and contains a special purpose register file (SPRF) and instruction and data eventpoint modules described in this invention.
  • SPRF special purpose register file
  • the other PEs, 151, 153, and 155 contain common physical data memory units 123', 123", and 123'" though the data stored in them is generally different as required by the local processing done on each PE.
  • the interface to these PE data memories is also a common design in PEs 1 , 2, and 3 and indicated by PE local memory and data bus interface logic 157, 157' and 157".
  • the interface logic units 157, 157', and 157" also contain the PEs SPRF and data eventpoint modules described further below.
  • Interconnecting the PEs for data transfer communications is the cluster switch 171 more completely described in U.S. Patent No. 6,023,753 entitled “Manifold Array Processor", U.S. Patent Application Serial No. 08/949,122 entitled “Methods and Apparatus for Manifold Array Processing", and U.S. Patent Application Serial No. 09/169,256 entitled “Methods and Apparatus for ManArray PE-to-PE Switch Control”.
  • the interface to a host processor, other peripheral devices, and/or external memory can be implemented in many ways.
  • the primary mechanism shown for completeness is contained in a direct memory access (DMA) control unit 181 that provides a scalable ManArray data bus 183 that connects to devices and interface units external to the ManArray core.
  • the DMA control unit 181 provides the data flow and bus arbitration mechanisms needed for these external devices to interface to the
  • ManArray core memories including the VIM via the multiplexed bus interface represented by line 185.
  • a high level view of the ManArray control bus (MCB) 191 is also shown.
  • Each eventpoint specifies a set of one or more p-events which are to be monitored and the associated p-actions to perform when they occur.
  • the eventpoints are separated into two basic classes: instruction eventpoints and data eventpoints. This separation allows a better utilization of the control register that specifies the eventpoints, though having a bit in the control register that selects instruction or data type eventpoints is not precluded.
  • Both classes of eventpoint parameters and controls are stored in registers located in a ManArray special purpose register file (SPRF).
  • SPRF ManArray special purpose register file
  • SPRs are registers that provide specialized control and/or communication capabilities to the array processor. Most SPRs are accessible by the SP, but some are implemented in both the SP's SPR address space and in the PE's SPR address space.
  • registers are accessible in 1 -cycle by the SP (or PE) when using the Load SPR (LSPR) instruction encoding format 200 shown in Fig. 2A, or store SPR (SSPR) instruction, having encoding format 300 of Fig. 3 A.
  • LSPR Load SPR
  • SSPR store SPR
  • Syntax/operation tables 210 and 310 for these instructions are shown in Figs. 2B and 3B, respectively.
  • the LSPR instruction loads a byte, half-word, or word operand into an SP target register from an SP special-purpose register or into a PE target register from a PE special-purpose register.
  • the SPR to load from is specified by its SPR Address SPRADDR.
  • the SSPR instruction stores a byte, half-word, or word operand to an SP special-purpose register from an SP source register or to a PE special-purpose register from a PE source register.
  • the SPR being stored to is specified by its SPR Address SPRADDR.
  • Fig. 4 shows an exemplary SPR register map 400 providing details of the placement of the instruction and data eventpoint registers in the ManArray SPR address space.
  • the leftmost column 401 contains the specific system addresses for the eventpoint registers 410 as seen from the ManArray control bus (MCB).
  • the next column 403 has the core SP/PE addresses for the eventpoint registers 410 as identified in the rightmost three columns 405, 407 and 409.
  • the eventpoint SPRs have a guaranteed single cycle access.
  • the primary mechanism to access to the SPRs is through the use of load and store SPR instructions that move data between the compute register file (CRF) and the SPRs.
  • CRF compute register file
  • FIG. 5 depicts an exemplary instruction eventpoint module 500 having three eventpoint registers, comprising two half-word 16-bit registers 516 and 518, and two other eventpoint registers 524, and 528, an 8-bit control register 514 comprising a plurality of instruction eventpoint control bits, eventpoint decode and control logic 510 and the interfaces necessary for implementing the generalized instruction eventpoint architecture of the present invention.
  • the IEPxR2.H0 register 518 is operable as a counter whose initial count value is loadable under program control.
  • the plurality of instruction eventpoint control registers are byte-wide registers with one such assigned for each instruction eventpoint, for example, register 514.
  • Each eventpoint "x" has associated with it an IEPx control byte that specifies how the three eventpoint parameter registers IEPxRO, IEPxRl and IEPxR2 are used for detecting instruction events and generating corresponding actions as explained further below.
  • Each control byte is made up of a three bit field labeled (SPT) and a five bit field labeled with the instruction event point number (IEPx).
  • SPT three bit field labeled
  • IEPx instruction event point number
  • control logic for each eventpoint receives an input trigger signal from a predecessor eventpoint and generates a trigger signal output to a successor eventpoint.
  • all SP resident eventpoints (IEP0-IEP5 and SP DEP0 - DEP2) are linked in a circular chain so that it is possible to support chaining of the eventpoints.
  • the SPT bits are defined as follows:
  • S Signal bit Used to control output signal generation from eventpoint logic. This bit is primarily used to indicate whether or not an EP interrupt signal will be generated when the specified event occurs, but may be used for other purposes for some specialized types of event points.
  • P Pass-through control bit This bit is most commonly used to indicate pass-through of the InTrigger signal from input to output. If this bit is a "0”, then the InTrigger signal is passed from input to output of the eventpoint logic. If this bit is a "1 " then the InTrigger signal is not passed to the output of the eventpoint logic.
  • T Trigger function bit This bit is used to control the use of the InTrigger and/or
  • InTriggerFF signals within the eventpoint logic is dependent on the control code (IEPx fields).
  • InTrigger refers to an input signal representing that a p-event has been detected.
  • InTriggerFF refers to a latched signal to enable event monitoring.
  • OutTrigger refers to an output control signal indicating a p-event has been detected, and EP Interrupt refers to whether an eventpoint interrupt is specified to occur on detecting the eventpoint. The detection of a p-event is indicated in the generation of an OutTrigger signal which is connected to the InTrigger input of the next eventpoint logic module to allow chaining of eventpoints.
  • EP Interrupt is an output of an eventpoint module that can be enabled to cause an interrupt depending upon the encoding of the eventpoint control. In the exemplary ManArray architecture, the eventpoint interrupt is also termed the debug interrupt. The following table describes these signals in greater detail:
  • Fig. 5 Operation utilizing these signals is illustrated in Fig. 5 and described in more detail in the following sections.
  • the programmer/compiler specified content of the control register 514 is one of the byte fields from the 32-bit IEPCTLO or IEPCTL1.
  • the eventpoint control information is conveyed on the 8 -bit output of the ⁇ SPT, IEPx ⁇ byte register on signal lines 529 to the decode and control logic 510.
  • IEPxRO 524 holds a programmer-specified value, that had been loaded via a store to special purpose register (SSPR) instruction, as illustrated in Figs. 3A and 3B, over the SPR bus 517, which consists of address, data, and control, that is to be compared with a selected bus signal 521.
  • Multiplexer 534 selects either the instruction fetch address bus 519 or other implementation specific bus signal 557 by means of multiplexer control signal 563.
  • IEPxRO 524 contains either an address value (an instruction fetch address, a load unit's effective address, or a store unit's effective address) or an instruction as a data value.
  • the exemplary implementation, though not architecturally limited to this, shown in Fig. 5 provides for two compare IEPxRO paths: the instruction fetch address bus 519 and the other bus signal 557 which could be an instruction bus, for example.
  • the IEPxRO register 524 is loaded, via the SSPR instruction, with the address of the last instruction in a program loop. During each instruction fetch, the contents of the IEPxRO register 524 are compared with the instruction fetch address.
  • comparator 526 detects a match as indicated by signal 539, then, if the count value in the associated IEPxR2.H0 counter register 518 is greater than one, the program counter is loaded with the contents of the associated IEPxRl register 528, which contains the address of the first instruction in the EP loop, to start a new iteration of the EP loop.
  • the value stored in the IEPxRl register 528 represents the programmer-specified value that had been loaded via the SSPR instruction either over the SPR bus 517, which consists of address, data, and controls, or the instruction fetch address bus 519 as selected by multiplexer 530 under control of the decode and confrol logic 510 and control output signal 561.
  • the value loaded into the IEPxRl register 528 is either passed to a background operation, over the EpxBus 551 or is used as an address to be loaded into the program counter (PC) as is done in eventpoint looping, using the EPxBus 551 , to change the flow of the program to a new start address.
  • the value placed upon the EPxBus 551 is accompanied by a load EPxBus signal 549.
  • the IEPxR2 register is split into two half-word portions IEPxR2.Hl 516 and IEPxR2.H0 518.
  • the IEPxR2.H0 counter register 518 portion contains a programmer specified count value that is counted down on the detection of each event by counter hardware included in register 518.
  • the counter register is useful for the counting of events and indicating if a count is pending or if, on a count down operation, it has reached a 1 or a 0.
  • Both halfword portions of IEPxR2 are loaded over the SPR bus 517,which consists of address, data, and controls, and the IEPxR2.H0 portion can also be loaded with the IEPxR2.Hl value 531 as selected by multiplexer 520 to pass through to input 533, depending upon the event as controlled by the decode and control logic 510 based upon the control register 514.
  • the IEPxR2.H0 is equal to 1 and the address in the associated IEPxRO register matches the instruction fetch address, the contents of IEPxR2.H0 are replaced with the reload count IEPxR2.Hl .
  • decode and control logic 510 is discussed below in connection with exemplary decode and control logic descriptions 600, 640, 650, 660, 670, 680, and 690 shown in Figs. 6A-6G, where the control value, ⁇ Sx, Px, Tx, IEPx ⁇ , represents the byte control field loaded in control register 514 and is shown as SPTxxxxx.
  • An operation column 601 of the tables describes the operation of the decode and control logic 510, use of the inputs, and specifies the output generation.
  • a control value column 602 contains a functional description of the operation.
  • Fig. 6 A will be explained in detail to describe the general operation of the eventpoint logic.
  • the control value for eventpoint 'x' is '00000000' which indicates the eventpoint 'x' is disabled, no action is to be specified, and the InTrigger signal 515 of Fig. 5 is passed through the multiplexer 508 to the OutTrigger signal 545.
  • the IEPCTLz.By control byte is loaded with a value '00T11000' 604
  • pseudo code describes the control logic for this control code encoding.
  • Line 610 indicates that "When" the value in the program counter (PC), or, in other words, the instruction fetch address, equals the value stored in IEPxRO OR the value of the PC equals the value stored in IEPxRl , then some type of action is to be taken. It is noted that for use in eventpoint looping the value stored in IEPxRO is the last instruction in a program loop and the value stored in IEPxRl is the first instruction of the program loop.
  • PC program counter
  • Statement 610 indicates that when the program counter reaches either the start of a program loop or the last instruction in a program loop some p-action is to be taken.
  • the next line 61 1 indicates a compare 532 of the instruction fetch address 519 with the IEPxRl 551 which at the match point indicates the program counter has reached the first instruction of a loop. If this compare is true AND either the trigger is enabled AND active (line 612) OR the loop count is zero (line 613), then the p-action of lines 614-617 is to occur.
  • Line 614 indicates the PC is loaded with the end of loop address, causing a jump to the end of the loop.
  • the loop counter is reinitialized as indicated in line 615 and the InTriggerFF is cleared in line 616 to prepare it for another event detection. It is noted that since the PC was directed to the last instruction in the loop and the loop is to be bypassed this "last instruction in the loop" is canceled in line 617. It is further noted that this canceling procedure was done in this exemplary implementation to avoid a timing path problem with having an adder in the path to load "last instruction in the loop + 1". Alternative implementations may choose to implement this adder scheme which is also supported by the present invention.
  • this logic is in the decode and control logic block 510 which receives input 527 from the InTriggerFF (InTFF) register 512.
  • InTriggerFF InTFF
  • line 620 which requires the hardware to load the program counter with the next sequential program step, i.e., taking the program away from the loop.
  • line 621 requires the eventpoint to be reinitialized in case the loop is entered again by loading the loop reload count stored in IEPxR2.Hl into IEPxR2.H0. This reload path is implemented in Fig.
  • this is implemented in hardware in block 522 that tests the output of the IEPxR2.H0 counter register 518 and sends the results to the decode and control block 510. If this situation is detected, then the loop is to be exited due to count completion, or if the loop count had been loaded with a zero, then the program loop is not to be repeated. Consequently, line 624 requires the program counter to be loaded with the next sequential program address and line 625 requires the loop count to be reinitialized to the value stored in the reload count IEPxR2.Hl . If these conditions are not met, line 626, then the loop count is neither a 0 nor a 1 and since the program counter is at the last instruction in the loop the loop is to be repeated.
  • the program counter is loaded with the loop "start" address IEPxRl 627.
  • This loading is accomplished by sending the start address IEPxRl value on the EPxBus 551 and a load EPxBus signal 549 to the program counter causing the PC to be loaded and directing the program flow back to the beginning of the loop.
  • Line 628 indicates the loop counter register 518 is to be decremented indicating the loop has completed another execution sequence. This ends the logic operation description of what happens when the PC is at the end address of a loop.
  • Figs. 6B-6G illustrate other forms of instruction eventpoint operations providing a programmer with unique capabilities due to the general approach taken for the architecture.
  • Figs. 6C and 6D illustrate the logic operation for loop operations that can exit based on the state of the F0 arithmetic condition flag.
  • Fig. 6E represents the logic operation for generating an EP or debug interrupt with optional pre-count and pre-trigger.
  • the approach of Fig. 6F is useful for vectoring or branching to a target address after count matches have occurred.
  • the approach of Fig. 6G is used to generate an EP interrupt after count InTriggers have been received. It will be appreciated that other eventpoint operations are easily achieved for numerous purposes using this architectural and programming approach for eventpoints.
  • Another aspect of this invention regards handling single instruction loops where the loop start address and loop end address are the same.
  • the instruction eventpoints have a priority associated with them to handle situations where more than one eventpoint asserts its control to load the PC with the next fetch address.
  • the priority is chosen such that when a program uses nested loops that share starting and/or ending addresses, the inner most loop should be the lowest numbered eventpoint. The priority is as follows:
  • this priority is used in the logic provided that one of the two following statements is true: a) the eventpoint is configured as a loop and no higher numbered eventpoint asserts control to skip a loop, or b) for those alternative uses of the eventpoint logic, the eventpoint is not configured as a loop.
  • a set up and execute an instruction eventpoint loop (EPLOOPx) instruction encoding 700 shown in Fig. 7A and a set up and execute an instruction eventpoint loop immediate (EPLOOPIx) instruction encoding 720 shown in Fig. 7C may be advantageously employed.
  • the syntax/operation descriptions 710 and 730 for these instructions are shown in Figs. 7B and 7D, respectively.
  • the EPLOOPx instruction 700 sets up and executes a program loop beginning with the next sequential instruction.
  • the instruction eventpoint register (IEPxRl) is loaded with the address of the next sequential instruction, representing the start address of the first instruction in the loop.
  • the instruction event point register (IEPxRO) is loaded with the address of the last instruction in the loop, which is the sum of the address of the LOOP instruction and a 10-bit unsigned displacement UDISP10 which is produced in the assembly using a label.
  • the appropriate instruction eventpoint control field IEPx, IEP0-IEP3, in the IEPCTL0 register is loaded with the hexadecimal value 0x18. If the loop counter
  • the EPLOOPIx instruction 720 shown in Fig. 7C sets up and executes a program loop beginning with the next sequential instruction.
  • the instruction eventpoint register (IEPxRl) is loaded with the address of the next sequential instruction.
  • the instruction eventpoint register (IEPxRO) is loaded with the address of the last instruction in the loop, which is the sum of the address of the EPLOOPI instruction and the 10-bit unsigned displacement UDISP10.
  • the instruction eventpoint register (IEPxR2) is loaded with the unsigned 12-bit value LoopCnt, placing the value in both the upper and lower half-words.
  • the appropriate instruction eventpoint control field IEPx, IEP0-IEP3, in the IEPCTLO register is loaded with the hexadecimal value 0x18.
  • loop counter (IEPxR2) is non-zero, execution proceeds with the next sequential instruction. If the loop counter is zero, the body of the loop is skipped and execution proceeds with the next sequential instruction after the IEPxRO. While the loop counter is greater than zero, a loop is active and each instruction address is compared to the IEPxRO. When there is a match and the loop counter is greater than one, PC is set to IEPxRl and the loop counter is decremented. When there is a match and the loop counter equals one, the loop counter is loaded with the loop reload value and the loop is exited.
  • the EPLOOP and EPLOOPI instructions 700 and 720 are used to provide a low latency mechanism for a select group of the eventpoints.
  • the exemplary ManArray architecture allows up to four nested eventpoint loops so as to better optimize utilization of the eventpoint hardware and conserve bits in the EPLOOP instructions.
  • the four eventpoints are specified in the EPLOOP and EPLOOPI instructions, by means of the BPID encoding in bits 23-22, for this purpose.
  • FIG. 8 An exemplary pipeline timing diagram 800 for a ManArray processor implementation for the start up sequence of the EPLOOPx instruction 700 for a multi-instruction program loop is shown in Fig. 8. It is noted that for the EPLOOPx instruction the loop count is loaded using the SSPR instruction prior to issuing the EPLOOPx instruction. EPLOOPIx simplifies this further by not requiring a separate load of the loop count value as it is already contained in an immediate field 722, bits 21-10 in the instruction 720 of Fig. 7C.
  • a clock cycle indicator column 802 which is set to zero as a reference point for the fetch of the EPLOOPx instruction
  • an EP compare column 804 indicating when the compares for a program loop occur
  • a fetch column 806 indicating the instruction fetch sequencing
  • a decode column 808 indicating the operations that occur during decode
  • an execute column 810 indicating the operations that occur during execute. Beginning with cycle 0 shown in row 812, the
  • EPLOOPx instruction is fetched and prior instructions continue to execute.
  • cycle 1 shown in row 814 the first instruction of the program loop is fetched.
  • the end address for the loop is calculated as program counter value plus a 10-bit displacement obtained from the EPLOOPx instruction.
  • the program counter is held, and a no-operation (NOP) instruction is inserted in the pipe.
  • NOP no-operation
  • the previous instruction to the EPLOOPx instruction is executed.
  • no new instruction is fetched as the first instruction of the program loop has already been fetched.
  • the hardware executes the NOP that was inserted in the pipe in the previous cycle.
  • the end address is sent to the IEPx module on the SPR bus and loaded into IEPxRO.
  • the program counter value is loaded into IEPxRl representing the start address of the loop.
  • the program counter is still held, and a second NOP instruction is inserted in the pipe.
  • cycle 3 shown in row 818 the first compare of IPExRO loop start address with the program counter is done with a match signal generated. The first instruction of the loop is allowed to continue in the pipe.
  • the second inserted NOP is decoded.
  • the first inserted NOP is executed.
  • the next or second instruction of the program loop is fetched.
  • the first instruction of the loop is decoded.
  • the second inserted NOP is executed.
  • cycle 5 shown in row 822, the processing continues to proceed with fetching, decoding, and executing the instructions in the program loop.
  • Fig. 9 shows an exemplary data eventpoint module 900 having three data eventpoint registers, comprising two half-word 16-bit registers 916 and 918, and two other parameter registers 924 and 928.
  • Data eventpoint module 900 also includes a control register 914, eventpoint decode and control logic 910 and the necessary interfaces required for a generalized data eventpoint architecture in accordance with the present invention.
  • the data eventpoint confrol register 914 is one of a plurality of byte-wide control registers, with one byte-wide register assigned for each data eventpoint.
  • the data eventpoint control registers for up to three data eventpoints may be suitably stored in an SPR file made up of a 32-bit register as shown in the tables below: SP/PEO DEPCTL0
  • DEPx Specifies how DEPxRO, DEPxRl and DEPxR2 are used for detecting data events and generating co ⁇ esponding actions.
  • Px Px 0: Pass InTrigger signal to OutTrigger signal (except when generating an
  • Px 1 : Always generate OutTrigger from confrol logic.
  • Tx Tx 0: InTriggerFF always set to ' 1 ' during monitoring.
  • DMASelx 0: Monitor DMA Lane 0 address.
  • PEDEPx For SP/PEO these bits indicate whether the DEP is configured to monitor SP or PE0 addresses.
  • PEDEPx 0: Monitor SP data addresses.
  • PEDEPx l: Monitor PE0 data addresses.
  • the confrol register 914 represents one of the byte fields from the DEPCTL0 and passes the 8-bits of confrol information on signal lines 929 to the decode and control logic 910.
  • DEPxRO data eventpoint registers 924
  • DEPxRl data eventpoint registers 928
  • 16-bit half-word registers 916 and 918, DEPxR2.Hl and DEPxR2.H0 respectively, are shown in the tables below: DEPxRO
  • the register DEPxRO 924 holds a programmer-specified value, loaded over the SPR bus 917, which consists of address, data, and confrols, that is to be compared with the bus/signals 921 as selected by the control register 914 DEPCTLz.By encoded bit field.
  • multiplexer 923 provides a mechanism to select either the load effective address (LEA) or the store effective address (SEA) as the value on the multiplexer output 921 to be compared. This mechanism provides the capability to trigger an event on a match of a load data effective address or a store data effective address.
  • the register DEPxRl 928 holds a programmer specified data value, loaded over the SPR bus 917, which consists of address, data, and controls, that is to be compared with either a selected data value 975 that represents a masked 950 LDATA or SDATA bus by use of the DEPxR2.Hl and DEPxR2H0 or one of the bus/signals 971 as selected by the control register 914 DEPx encoded bit field. It is noted that the load data (LDATA) bus 977 and store data (SDATA) bus 979 are latched data values stored in a hidden scratch pad register due to the execution pipeline in use for the ManArray processor.
  • the DEPxR2.H0 count register 918 can also act as an eventpoint counter which indicates a count of 1 , a count of 0, or if the count is greater than 1.
  • the decode and confrol logic 910 operation is described in detail in operation tables 1010, 1015, 1020, 1030, 1040, 1050, 1060, 1070, 1080, 1090, and 1095 shown in Figs. 10A-10J. These tables are constructed in the same manner as the instruction eventpoint logic descriptions of Figs. 6A-6G.
  • the control value column 1012 of each figure provides a description of the logic operation for the programmed confrol value also indicated in the same column.
  • Eventpoint Chaining Fig. 11 depicts an eventpoint chaining apparatus 1100 which may be advantageously used in an exemplary implementation of the ManArray architecture similar to the system shown in Fig. 1 is discussed further below.
  • the eventpoint chaining apparatus 1100 uses the OutTrigger (OutTrig) signal, for example signal 1 101 from an eventpoint module 1104 as an input InTrigger (InTrig) signal 1103 for the next eventpoint module 1102.
  • Eventpoint modules 1 102-1118 are linked together in a circular chain.
  • the chaining of eventpoints in reference to Figs. 5 and 9, is accomplished through the use of the OutTrigger signal 545 or 945 and the InTrigger signal 515 or 915.
  • the OutTrigger signal 545 or 945 is selected by multiplexer 508 or 908 as controlled by confrol signal 543 or 943, when the OutTrigger path 941 is enabled and an eventpoint is discovered.
  • the InTrigger signal 515 or 915 can be passed through the eventpoint module as selected by multiplexer 508 or 908 and controlled by confrol signal 543 or 943.
  • the InTriggerFF (InTFF) latch 512 or 912 when enabled, captures the state of the InTrigger signal 515 or 915 which is sent to the decode and control logic 510 or 910 over line 527 or 927.
  • the InTFF latch, 512 or 912 is cleared whenever • A value is written to the confrol register field associated with its eventpoint, or
  • Fig. 11 depicts an exemplary chaining with a mixture of six instruction eventpoints
  • Eventpoints may be programmed with various control options. The purpose of some of these options is simply to detect when a particular event or sequence of events has occurred.
  • the EPSTAT register is used to capture event occurrence for those events which generate an EP interrupt so that if multiple eventpoint interrupts are being tracked, they may be distinguished.
  • Suitable EPSTAT registers and the chosen definition for the status bits for the exemplary 2x2 ManArray implementation are shown in the following format tables for a 32-bit example. Since the ManArray processor merges the SP array confroller with PEO of the PE array, the EPSTAT register data eventpoints are shared between the SP and the PEO. In other implementations, this organization may not exist, but the concepts and use of the eventpoints and the EPSTAT registers still applies.
  • SP/PEO EPSTAT Read-only, SP SPR
  • DEVx This bit is set when a match event generates an EP interrupt for Data Event Point 'x'. (Not all confrol codes that may be programmed cause an interrupt to be generated on a match event, and for these cases the DEVx bits are not set).
  • IEVx This bit is set when a match event generates an EP interrupt for Instruction Event Point 'x'. (Not all confrol codes that may be programmed cause an interrupt to be generated on a match event, and for these cases the IEVx bits are not set).
  • Fig. 1 1 further illustrates that for each eventpoint module 1102-1123 an EP Interrupt can be generated. All instruction 1126 and data 1128 eventpoint EP interrupts are logically ORed together by OR gate 1125 to provide the eventpoint interrupt signal to the SP interrupt confrol unit 1130.
  • the EPSTAT registers are used to store event status from SP or PE resident event point control logic. The EP status saved in the EPSTAT registers indicates when an event point has matched its event criteria and generated an EP interrupt. A read from this register returns the status while a write to this register with any data clears the status flags. These bits are also cleared at reset. It is noted that other formats and bit definitions are not precluded. For example, status indication on any match event can be provided in addition to the above noted match and EP interrupt event status.
  • the SP/PEO and each of the other PEs contains an EPSTAT register that is visible in their own SP and PE SPR address spaces.
  • the SP EPSTAT register can be read by use of the LSPR.S instruction illustrated in Figs. 2A and 2B.
  • the PEs the PE
  • each PE's EPSTAT register can be read by use of the LSPR.P instruction also illustrated in Figs. 2A and 2B.
  • each PE's EPSTAT register contains only a single status bit that indicates if the PE generated a match event which caused an EP interrupt.
  • each PE such as one of the PEs 151 , 153 or 155 of Fig. 1 , supports one data eventpoint requiring only three parameter registers and one confrol register.
  • PE event status may be read using an LSPR.P instruction along with SPRECV instructions to retrieve each PE's status to the SP register file.
  • the SPRECV instruction causes the specified SP target register to receive data from PEO's cluster switch input port.
  • eventpoint Background DMA In the SP and depending upon the implementation and with two eventpoint confrol register specifications, up to eight instruction eventpoints can be set up. It will be recognized that additional eventpoints can be added as desired.
  • the eventpoints can be shared and combinations of capabilities provided. For example,” 1 in the SP, two nested EP loops with two background DMA operations with two instruction and two data debug eventpoints can be programmed.
  • highly advantageous capabilities as described in the confrol value and logic description of Figs. 6A-6F and 10A-10G, are provided to the general programmer. Eventpoint Background DMA
  • One of the many unique uses of the present eventpoint architecture is its use to initiate and confrol background direct memory access (DMA) operations to efficiently move data while normal processing continues.
  • DMA background direct memory access
  • a data buffer 1200 such as is shown in Fig. 12A, where a local memory data segment M is split into two buffer portions, a Bufl 1202 and a Buf2 1204.
  • a typical application such as processing an MPEG compressed bit-stream
  • the eventpoint architecture of the present invention advantageously achieves this goal as discussed further below.
  • the following requirements are assumed:
  • a stream of variable-length data elements is consumed from a circular buffer in memory which is of length BUFSIZE words.
  • the background operation is a DMA operation to refill a buffer.
  • Buffer halves are labeled Bufl and Buf2, each of length N.
  • a DMA transfer is set up to move N words of data at a time to a circular buffer of size 2N, that is the core transfer count (CTC) of data to be transferred to the core is N, but the buffer size of the circular transfer is 2N.
  • CTC core transfer count
  • the DMA transfer uses a semaphore to indicate when it is allowed to fill a buffer. Initially, the DMA semaphore is set to 2, indicating it can fill both buffers. Each time the DMA semaphore is set to 2, indicating it can fill both buffers. Each time the DMA semaphore is set to 2, indicating it can fill both buffers.
  • DMA unit decrements CTC to zero, i.e., transfers N data values, it also will decrement and check the semaphore. If the semaphore is non-zero after the decrement, the transfer reloads CTC with N and continues the transfer, filling the other half of the buffer (Buf2). If the semaphore has been decremented to zero, then the DMA waits until it is non-zero to reload CTC and continue with another transfer.
  • the EP sends a signal to the DMA unit which causes its semaphore to increment.
  • the count value can be up to two.
  • Fig. 12B contains an outline of a simple program routine 1220 set up as a data dependent loop to process an unknown quantity of data elements.
  • the data processing is to continue until an end-of-data code is decoded from the received encoded bit- stream stored in the buffers prior to processing.
  • a DMA for Bufl is started, after which the program routine starts at address L0.
  • the routine 1220 then loops until an end-of- data code is decoded.
  • the routine accesses data from the memory buffer by use of a load modulo index type of instruction that begins addressing at the address A, the start address of Fig. 12 A, and automatically wraps the address around, at the end of Buf2, to the beginning of Bufl , address A.
  • the three eventpoints used are shown in table 1240 of Fig. 12C.
  • the first eventpoint is an instruction event point that is chained to the two data eventpoints, DEP0 and DEP1.
  • the IEPO counter is set up by its decode and confrol logic to increment the counter upon receiving a DMA fransfer complete signal 509 (Fig. 5).
  • the counter decrements whenever an InTrigger event occurs.
  • the instruction eventpoint when InTrigger occurs and the count is a one, causes the vector address XI to be loaded into the PC thereby changing the program flow to the DMA-not-complete-do-something-else routine. In normal operation, the count is incremented by the DMA transfer complete signal prior to receiving an InTrigger signal and the IEPO eventpoint will not occur. If the DMA is held up and the DMA operation is not complete, only then will the program reach the special routine. The other two background DMA data eventpoints are set up for interfacing with the system DMA unit.
  • the DMA unit is set up previous to the program routine to fransfer a buffer size of N beginning at a start address that is passed to the DMA hardware when the background DMA is initiated.
  • the sequence of events is as follows assuming Bufl is fully loaded with the initial data at the start of the program.
  • the program routine begins processing data in Bufl , which on the first access at address A the DEP0 eventpoint is detected which initiates a DMA operation to load data into Buf2 beginning at address C, which address value is passed to the DMA hardware unit over the EPIBus 981.
  • the count in IEP1R2.H0 reloads a 0 indicating that Buf2 is empty.
  • the program routine continues processing the data in Bufl while the DMA unit in the background independently loads the next set of data elements into Buf2.
  • the DMA unit At the end of the DMA transfer of data to Buf2, the DMA unit generates a DMA complete signal which increments the Buf2 count in DEP0R2.H0 to 1 indicating Buf2 is now full and processing can proceed.
  • the DMA unit now initiates the background loading of Bufl while the program is allowed to continue with the processing of Buf2 data.
  • the program routine continues processing the two buffers until the end-of-data code is decoded. If the program ever tries to access data from Bufl at address A, or Buf2 at address C, and the DMA fransfer has not completed for that buffer, instruction eventpoint IEPO is triggered, indicating the background DMA has not completed operation.
  • This concept is extended by allowing address masking in the address compare, for example, by using a single address with a mask register, and then supporting multiple address matching for buffer sizes that are a power of 2. Since masking is already allowed for the data compares, this approach may be readily implemented.
  • Address masking is also useful for trapping when access to specified regions of memory by either instruction fetch or data fetch is attempted.
  • the generalized eventpoint architecture shown in Figs. 5 and 9 and discussed above in detail includes the advantageous capabilities highlighted in the partial list that follows: auto looping, auto looping with loop skip if count is zero, auto looping where an InTrigger signal can be used to exit or skip the loop, background DMA, initiating a timer from some data or instruction eventpoint, and cache pre-fetch operation. While the present invention has been disclosed in the context of various aspects of presently preferred embodiments, it will be recognized that the invention may be suitably applied to other environments and applications consistent with the claims which follow.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

La présente invention concerne un processus avec une architecture de points d'événements généralisée qui peut être scalaire pour une utilisation dans un processeur de réseau à très long mot d'instruction (VLIW), tel que le processeur de réseaux multiples (ManArray). Selon un aspect de l'invention, les installations de détection d'événements de processeur (p-event) généralisée permettent, par utilisation de comparaisons (526), de vérifier si une adresse d'instruction, une adresse de mémoire de données, une instruction, une valeur de données, des indicateurs d'état arithmétique, ou d'autres changements de processeur de point d'événement d'état ont eu lieu. Selon un autre aspect de cette invention, les installations d'action de processeur (p-action) généralisée permettent d'induire un changement dans le flux de programme par chargement du compteur de programme avec une nouvelle adresse d'instruction, de générer une interruption, de signaler un sémaphore, d'enregistrer ou de compter l'événement de processeur, de marquer la date et l'heure de l'événement, de lancer une opération d'arrière-plan, ou d'induire d'autres actions de processeur devant avoir lieu.
PCT/US2000/040273 1999-06-21 2000-06-21 Procedes et appareils permettant la detection d'evenements et la specification d'actions generalisees dans un processeur WO2000079400A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14024599P 1999-06-21 1999-06-21
US60/140,245 1999-06-21

Publications (1)

Publication Number Publication Date
WO2000079400A1 true WO2000079400A1 (fr) 2000-12-28

Family

ID=22490373

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/040273 WO2000079400A1 (fr) 1999-06-21 2000-06-21 Procedes et appareils permettant la detection d'evenements et la specification d'actions generalisees dans un processeur

Country Status (1)

Country Link
WO (1) WO2000079400A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1703670B (zh) * 2002-10-11 2010-12-08 Nxp股份有限公司 指令的寻址范围相关并行化的数据处理设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5740413A (en) * 1995-06-19 1998-04-14 Intel Corporation Method and apparatus for providing address breakpoints, branch breakpoints, and single stepping
US6112298A (en) * 1996-12-20 2000-08-29 Texas Instruments Incorporated Method for managing an instruction execution pipeline during debugging of a data processing system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5740413A (en) * 1995-06-19 1998-04-14 Intel Corporation Method and apparatus for providing address breakpoints, branch breakpoints, and single stepping
US6112298A (en) * 1996-12-20 2000-08-29 Texas Instruments Incorporated Method for managing an instruction execution pipeline during debugging of a data processing system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1703670B (zh) * 2002-10-11 2010-12-08 Nxp股份有限公司 指令的寻址范围相关并行化的数据处理设备

Similar Documents

Publication Publication Date Title
US6735690B1 (en) Specifying different type generalized event and action pair in a processor
US7254695B2 (en) Coprocessor processing instructions in turn from multiple instruction ports coupled to respective processors
US9158547B2 (en) Methods and apparatus for scalable array processor interrupt detection and response
US6058465A (en) Single-instruction-multiple-data processing in a multimedia signal processor
US6003129A (en) System and method for handling interrupt and exception events in an asymmetric multiprocessor architecture
US5838984A (en) Single-instruction-multiple-data processing using multiple banks of vector registers
US8185879B2 (en) External trace synchronization via periodic sampling
US7178133B1 (en) Trace control based on a characteristic of a processor's operating state
EP0992907B1 (fr) Gestion de fifo de traçage
US7185234B1 (en) Trace control from hardware and software
US7069544B1 (en) Dynamic selection of a compression algorithm for trace data
US7181728B1 (en) User controlled trace records
WO2001004765A1 (fr) Procede et appareil d'adressage d'instructions dans des processeurs indirects a tres long mot d'instruction (vliw)
WO2012068494A2 (fr) Procédé et appareil de commutation de contexte
CN1211012A (zh) 将一个处理器与一个协处理器相接口的方法和装置
JP2001202245A (ja) 改良式命令セットアーキテクチャを有するマイクロプロセッサ
US11042468B2 (en) Tracking debug events from an autonomous module through a data pipeline
US7168066B1 (en) Tracing out-of order load data
WO2000078120A2 (fr) Procedes et appareil pour declencher et resynchroniser des flux d'instructions uniques appliquees a des donnees multiples (simd) a plusieurs cycles
US7124072B1 (en) Program counter and data tracing from a multi-issue processor
WO2000079400A1 (fr) Procedes et appareils permettant la detection d'evenements et la specification d'actions generalisees dans un processeur
US20040098577A1 (en) Dynamically booting processor code memory with wait instruction
EP0365187A2 (fr) Dispositif d'exécution sélective des instructions succédant à une instruction de branchement

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA IL JP KR

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP