Source: http://patents.com/us-9038076.html
Timestamp: 2018-11-20 12:00:58
Document Index: 351723131

Matched Legal Cases: ['Application No. 1496', 'Application No. 200580030789', 'Application No. 200580030789', 'Application No. 200580030789', 'Application No. 200580030789', 'Application No. 05779159', 'Application No. 05779159', 'Application No. 05779159', 'Application No. 2007', 'Application No. 2007', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 094131673', 'Application No. 530774', 'Application No. 1496', 'Application No. 201210004184', 'Application No. 201210004184', 'Application No. 201210004215', 'Application No. 201210004215', 'Application No. 1496', 'Application No. 1496', 'art 1']

US Patent # 9,038,076. Debug in a multicore architecture - Patents.com
United States Patent 9,038,076
Lippett , et al. May 19, 2015
Debug in a multicore architecture
A method of monitoring thread execution within a multicore processor architecture which comprises a plurality of interconnected processor elements for processing the threads, the method comprising receiving a plurality of thread parameter indicators of one or more parameters relating to the function and/or identity and/or execution location of a thread or threads, comparing at least one of the thread parameter indicators with a first plurality of predefined criteria each representative of an indicator of interest, and generating an output consequential upon thread parameter indicators which have been identified to be of interest as a result of the said comparison.
Lippett; Mark David (Watlington, GB), Oung; Ayewin (Maidenhead, GB)
Family ID: 1000001106658
13/965,120
US 20130326283 A1 Dec 5, 2013
10941457 Sep 14, 2004
Current U.S. Class: 718/100; 712/232; 714/47.1
Current CPC Class: G06F 11/3409 (20130101); G06F 11/3636 (20130101); G06F 11/348 (20130101); G06F 11/0724 (20130101)
Current International Class: G06F 9/46 (20060101); G06F 11/00 (20060101); G06F 9/44 (20060101)
5828880 October 1998 Hanko
6587967 July 2003 Bates et al.
6593940 July 2003 Petersen et al.
6903556 June 2005 Sutton
7047521 May 2006 Bunnell
7146529 December 2006 Aguilar et al.
2003/0005417 January 2003 Gard et al.
2003/0097613 May 2003 Kageshima
2004/0128663 July 2004 Rotem
2005/0183069 August 2005 Cepulis
2006/0037017 February 2006 Accapadi et al.
1402132 Mar 2003 CN
1089183 Apr 2001 EP
04-211842 Aug 1992 JP
2001-154876 Jun 2001 JP
2003-131902 May 2003 JP
2004-021751 Jan 2004 JP
544629 Nov 2003 TW
559729 Nov 2003 TW
WO 00/73809 Jul 2000 WO
Indian First Office Action, Indian Application No. 1496/CHENP/2007, Aug. 6, 2013, 4 pages. cited by applicant .
Beynon, M. D. et al., "Low-Cost Non-Intrusive Debugging Strategies for Distributed Parallel Programs," 2002 IEEE International Conference on Cluster Computing, Sep. 23-26, 2002, pp. 439-442. cited by applicant .
Chinese First Office Action, Chinese Application No. 200580030789.4, Jul. 4, 2008, 11 pages. cited by applicant .
Chinese Second Office Action, Chinese Application No. 200580030789.4, Apr. 10, 2009, 7 pages. cited by applicant .
Chinese Third Office Action, Chinese Application No. 200580030789.4, Jul. 30, 2010, 1 page. cited by applicant .
Chinese Fourth Office Action, Chinese Application No. 200580030789.4, Feb. 10, 2011, 6 pages. cited by applicant .
European Examination Report, European Application No. 05779159.2, Aug. 29, 2007, 5 pages. cited by applicant .
European Examination Report, European Application No. 05779159.2, Jan. 18, 2011, 6 pages. cited by applicant .
European Result of Consultation, European Application No. 05779159.2, Jul. 29, 2011, 5 pages. cited by applicant .
Japanese Office Action, Japanese Application No. 2007-530774, Aug. 2, 2011, 19 pages. cited by applicant .
Japanese Office Action, Japanese Application No. 2007-530774, Jul. 31, 2012, 9 pages. cited by applicant .
Korean Office Action, Korean Application No. 10-2007-7006808, Feb. 16, 2012, 5 pages. cited by applicant .
Korean Notice of Allowance, Korean Application No. 10-2007-7006808, Dec. 28, 2012, 3 pages. cited by applicant .
Korean Office Action, Korean Application No. 10-20127021494, Dec. 14, 2012, 7 pages. cited by applicant .
Mitchell, E., "Multi-Core and Multi-Threaded SoCs Present New Debugging Challenges," Datasheet MIPS Technologies, Aug. 2003, pp. 1-6. cited by applicant .
PCT International Search Report, PCT Application No. PCT/GB2005/003525, Nov. 14, 2006, 5 pages. cited by applicant .
PCT Written Opinion, PCT Application No. PCT/GB2005/003525, Nov. 14, 2006, 6 pages. cited by applicant .
PCT International Preliminary Report on Patentability, PCT Application No. PCT/GB2005/003525, Mar. 20, 2007, 7 pages. cited by applicant .
Rosenberg, J.B., "How Debuggers Work? Chapter 9: "Multithreaded debugging,"" John Wiley & Sons, 1996, 14 pages. cited by applicant .
Taiwan Office Action, Taiwan Application No. 094131673, Sep. 19, 2012, 3 pages. cited by applicant .
Japanese Office Action, Japanese Application No. 530774-2007, Apr. 16, 2013,10 pages. cited by applicant .
United States Office Action, U.S. Appl. No. 10/941,457, Sep. 3, 2008, 14 pages. cited by applicant .
United States Office Action, U.S. Appl. No. 10/941,457, Apr. 14, 2009, 13 pages. cited by applicant .
United States Office Action, U.S. Appl. No. 10/941,457, Sep. 28, 2009, 16 pages. cited by applicant .
United States Office Action, U.S. Appl. No. 10/941,457, Apr. 12, 2010, 18 pages. cited by applicant .
United States Office Action, U.S. Appl. No. 10/941,457, Feb. 13, 2013, 18 pages. cited by applicant .
United States Office Action, U.S. Appl. No. 10/941,457, Sep. 23, 2013, 14 pages. cited by applicant .
Indian Office Action, Indian Application No. 1496/CHENP/2007, Jan. 27, 2014, 1 page. cited by applicant .
Chinese First Office Action, Chinese Application No. 201210004184.X, Nov. 28, 2013, 10 pages. cited by applicant .
Chinese Second Office Action, Chinese Application No. 201210004184.X, Jul. 23, 2014, 15 pages. cited by applicant .
Chinese First Office Action, Chinese Application No. 201210004215.1, Jan. 13, 2014, 9 pages. cited by applicant .
Chinese Second Office Action, Chinese Application No. 201210004215.1, Jul. 23, 2014, 13 pages. cited by applicant .
Indian Second Office Action, Indian Application No. 1496/CHENP/2007, Jan. 27, 2014, 1 page. cited by applicant .
Indian Third Office Action, Indian Application No. 1496/CHENP/2007, May 21, 2014, 1 page. cited by applicant .
United States Office Action, U.S. Appl. No. 13/965,116, Jul. 31, 2014, 10 pages. cited by applicant .
United States Office Action, U.S. Appl. No. 10/941,457, Feb. 13, 2014, 14 pages. cited by applicant.
This application is a continuation of co-pending U.S. application Ser. No. 10/941,457, filed Sep. 14, 2004, which is incorporated by reference in its entirety.
1. A controller for a multicore processor architecture comprising a plurality of interconnected processor elements each communicatively coupled to the controller, the controller comprising: an input configured to receive a plurality of thread parameter indicators indicative of a plurality of parameters relating to the function, identity, or execution location of at least one thread within the multicore processor architecture; a plurality of hardware debug machines, each configured to compare at least one received thread parameter indicator with a first plurality of predefined criteria representative of a thread parameter indicator of interest, and to generate a trace enable signal in response to the comparison; and a static events filter communicatively coupled to each of the plurality of debug machines and configured to compare each received thread parameter indicator with a second plurality of predefined criteria based on one or more trace enable signals, and to generate a trace output for a trace buffer based on the plurality of thread parameter indicators and the result of the comparisons with the second plurality of predefined criteria.
2. The controller of claim 1, wherein each of the plurality of debug machines comprises: an event first-in-first-out ("FIFO") register configured to store a sequence of the first plurality of predefined criteria; an action FIFO register configured to store a sequence of action instructions corresponding to the sequence stored in the event register, each action instruction indicating actions to be performed; and an event service module configured to determine whether the at least one received thread parameter indicator matches the first plurality of predefined criteria that is first in the sequence stored in the event register, and to generate a trace enable signal in response to a determined match and a determination that a corresponding action instruction stored in the action register indicates that a trace is to be enabled.
3. The controller of claim 1, further comprising: a static interface configured to provide the second plurality of predefined criteria to the static events filter in the form of a user-programmed event filter mask.
4. The controller of claim 1, wherein the multicore processor architecture further comprises a processor controller comprising a number of interconnected sub units.
5. The controller of claim 4, further comprising: a debug interface configured to control the dynamic operation of the controller by interfacing the plurality of debug machines with the static events filter; and a sub block command interface configured to allow the processor controller to access the debug interface.
6. The controller of claim 5, further comprising: an auxiliary debug interface configured to allow an external debug host to access the debug interface.
7. The controller of claim 1, further comprising: a trace data module configured to receive a plurality of generated trace outputs and to compress the received trace outputs; and a trace buffer interface configured to provide the compressed trace outputs from the trace data module to the trace buffer.
8. The controller of claim 7, wherein the trace data module comprises: a plurality of two-entry FIFO registers; an event switch configured to receive each generated trace output and to route the generated trace output to a two-entry FIFO register; a field base correlator configured to receive and process generated trace outputs from the plurality of two-entry FIFO registers by performing fixed function operations on the generated trace outputs to maximize trace output zeros by exploiting spatial and temporal correlation with a reference generated trace output; a plurality of field correlated FIFO registers configured to receive the processed trace outputs, each processed trace output comprising a plurality of symbols; a first encoder configured to receive the processed trace outputs from the plurality of field correlated FIFO registers and to encode the processed trace outputs by performing zero run length encoding on each symbol of the processed trace outputs to produce encoded trace outputs comprising variable length symbols; a plurality of output FIFO registers configured to receive the encoded trace outputs from the first encoder; a second encoder configured to generate an output bitstream based on the encoded trace outputs received by the plurality of output FIFO registers; and a variable length packetizer configured to generate variable length packets based on the output bitstream as required by the trace buffer interface.
9. The controller of claim 1, wherein the static events filter further comprises a time interface configured to time stamp the trace output.
10. A method for controlling a multicore processor architecture comprising a plurality of interconnected processor elements each communicatively coupled to a controller, comprising: receiving, by an input, a plurality of thread parameter indicators indicative of a plurality of parameters relating to the function, identity, or execution location of at least one thread within the multicore processor architecture; comparing, by a plurality of debug machines, at least one received thread parameter indicator with a first plurality of predefined criteria representative of a thread parameter indicator of interest; generating, by the plurality of debug machines, a trace enable signal in response to the comparison; comparing, by a static events filter communicatively coupled to each of the plurality of debug machines, each received thread parameter indicator with a second plurality of predefined criteria based on the trace enable signal; and generating, by the static events filter, a trace output for a trace buffer based on the plurality of thread parameter indicators and the result of the comparison with the second plurality of predefined criteria.
11. The method of claim 10, wherein each of the plurality of debug machines comprises: an event FIFO register configured to store a sequence of the first plurality of predefined criteria; an action FIFO register configured to store a sequence of action instructions corresponding to the sequence stored in the event register, each action instruction indicating actions to be performed; and an event service module configured to determine whether the at least one received thread parameter indicator matches the first plurality of predefined criteria that is first in the sequence stored in the event register, and to generate a trace enable signal in response to a determined match and a determination that a corresponding action instruction stored in the action register indicates that a trace is to be enabled.
12. The method of claim 10, further comprising: providing, by a static interface, the second plurality of predefined criteria to the static events filter in the form of a user-programmed event filter mask.
13. The method of claim 10, wherein the multicore processor architecture further comprises a processor controller comprising a number of interconnected sub units.
14. The method of claim 13, further comprising: controlling, by a debug interface, the dynamic operation of the controller by interfacing the plurality of debug machines with the static events filter; and allowing, by a sub block command interface, the processor controller to access the debug interface.
15. The method of claim 14, further comprising: allowing, by an auxiliary debug interface, an external debug host to access the debug interface.
16. The method of claim 10, further comprising: receiving, by a trace data module, a plurality of generated trace outputs; compressing, by the trace data module, the received trace outputs; and providing, by a trace buffer interface, the compressed trace outputs from the trace data module to the trace buffer.
17. The method of claim 16, wherein the trace data module comprises: a plurality of two-entry FIFO registers; an event switch configured to receive each generated trace output and to route the generated trace output to a two-entry FIFO register; a field base correlator configured to receive and process generated trace outputs from the plurality of two-entry FIFO registers by performing fixed function operations on the generated trace outputs to maximize trace output zeros by exploiting spatial and temporal correlation with a reference generated trace output; a plurality of field correlated FIFO registers configured to receive the processed trace outputs, each processed trace output comprising a plurality of symbols; a first encoder configured to receive the processed trace outputs from the plurality of field correlated FIFO registers and to encode the processed trace outputs by performing zero run length encoding on each symbol of the processed trace outputs to produce encoded trace outputs comprising variable length symbols; a plurality of output FIFO registers configured to receive the encoded trace outputs from the first encoder; a second encoder configured to generate an output bitstream based on the encoded trace outputs received by the plurality of output FIFO registers; and a variable length packetizer configured to generate variable length packets based on the output bitstream as required by the trace buffer interface.
18. The method of claim 10, further comprising: time stamping, by a time interface, the trace output.
In recent years, there has been a trend towards producing processors containing multiple cores, in order to maximise silicon efficiency (i.e. "application-available" MIPs/mm.sup.2 or MIPs/mW). Such multicore architectures are ideally suited to running applications based on threads, because a thread defines an autonomous package of work containing an execution state, instruction stream and dataset, which, by definition, may execute concurrently with other threads. However, this concurrency of execution introduces additional problems into the software debug process used on these multicore architectures. Software debug is the general term for locating and correcting errors in the execution of a computer application.
One of the key problems faced in software debug is the Heisenberg bug (also known as the "probe effect"). Any code which is added for the purpose of debug, for example to increase the level of system diagnostics, is likely to subtly change the timing of concurrent and/or parallel executing threads. This brings with it the risk of masking bugs that would otherwise be observed in the production release of the same application. It is also difficult to extract meaningful performance measurements and instrumentation when extensive debug code is present in the build. This is because second order effects like cache and bus performance may be affected by the additional code, as well as it having the more obvious impact on code size.
The present invention may be put into practise in a number of ways, and some embodiments will now be described by way of example only and with reference to the accompanying drawings.
FIG. 1 shows a schematic block diagram of the logical layout of a typical multicore processor architecture system.
FIG. 2 shows a schematic block diagram of one exemplary implementation of the logical layout of FIG. 1, wherein a thread management and allocation controller is incorporated within a general purpose, multicore processor architecture, along with a dedicated memory device and a controller client.
FIG. 3 shows, again in block diagram form, an example of a contemporary System on Chip (SoC) bus-based architecture incorporating the elements of FIG. 2.
FIG. 4 shows a more detailed view of external connections to the controller of FIGS. 1, 2 and 3.
FIG. 5 shows a more detailed view of the memory device of FIGS. 2 and 3.
FIG. 6 shows a more detailed view of the internal composition of the controller of FIGS. 2, 3 and 4.
FIG. 7 shows a schematic block diagram of a controller client as shown in FIGS. 2 and 3.
FIG. 8 shows a more detailed schematic block diagram of a hardware controller client.
FIG. 9 shows a typical relationship between a thread descriptor, the controller, a processing resource and the shared system memory.
FIG. 10 shows a schematic block diagram of one exemplary implementation of the logical layout of a typical multicore processor architecture system incorporating a debug architecture in accordance with an embodiment of the present invention.
FIG. 11 shows a more detailed view of external connections to the thread debug controller of FIG. 10.
FIG. 12a shows a more detailed view of the external connections to the trace buffer of the thread debug controller of FIG. 10.
FIG. 12b shows a timing diagram of a typical output of the trace buffer of FIG. 12a.
FIG. 13 shows another detailed view of external connections to the thread debug controller of FIG. 10, including connections to the subblocks of the controller of FIG. 2.
FIG. 14 shows a functional block diagram of the internal composition of the thread debug manager of FIG. 11.
FIG. 15 shows a logical block diagram of one of the debug machines of FIG. 14.
FIG. 16 shows a physical block diagram of one of the debug machines of FIG. 14.
FIG. 17 shows an example of the concatenation ability of the debug machines of FIG. 14.
FIG. 18 shows the instruction dataflow within a debug machine in the case of a single word EventWatch.
FIG. 19 shows the instruction dataflow within a debug machine in the case of a double word EventWatch.
FIG. 20 shows a functional block diagram of an exemplary Static events filter module of FIG. 14.
FIG. 21 shows an exemplary allocation of Even Filter masks within a Static Event Filter module of FIG. 20.
The system frame work also comprises a centralized thread management and allocation system, which includes a thread management and allocation controller 130 and a dedicated tightly coupled memory 190, connected to the thread management and allocation controller ("controller" hereinafter) via memory interface 180. Each processing resource 150 is able to access the controller 130 via an interconnect 115. It is to be understood that no particular interconnection strategy (that is, the arrangement by which the controller 130 communicates with each processing resource 150 and vice versa, and the arrangement by which each processing resource 150 communicates with the system resources, for example memory 140) is required in the implementation of the arrangement of FIG. 1; in particular, point to point links, a central system bus or even a pipelined architecture may equally be employed, save only that each of the processing resources 150 should be able to communicate directly or indirectly (i.e. via other processing resources 150 or otherwise) with the controller 130.
FIG. 2 shows a multicore processor implementing the logical arrangement of FIG. 1, again by way only of an example. The multicore processor of FIG. 2 employs a plurality of the processing resources 150, each connected via a system interconnect 160. The system interconnect 160 communicates in turn with the controller 130 via input interfaces 100, and output interfaces 110. In the example of FIG. 3, the system interconnect 160 is laid out as a traditional central bus which connects each of the processing resources 150 with one another and with the controller 130, and also with the shared system resources 140 such as a system memory. Interfacing with shared system resources 140 may be achieved via any one of a number of currently available interface technologies. The memory may consist of any of the currently available central computer memory technologies, for example Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), or Double Data Rate Random Access Memory (DDR RAM).
As seen in FIG. 2, each of the multiple processing resources 150 has an associated controller client 120 configured to receive control information from the central controller 130, and to administer the processing resources 150 in accordance with the control information received. The function and purpose of the controller clients 120 is described in more detail below. Each processing resource 150 also has an associated interconnect agent 170 for communication with the controller 130 via the system interconnect 160. The interconnect agent 170 provides a generic interface to the controller client 120, which is independent of the underlying interconnect protocol in use on the system interconnect 160, i.e., it provides protocol translation between the communication protocols in use on the system interconnect 160 and the communication protocol in use by the controller client 120. Due to the use of an interconnect agent 170, the controller clients 120 of embodiments of the present invention may be used with any system interconnect protocol currently available. Indeed, the interface protocol 115 through which the controller client 120 communicates with the controller 130 may be physically distinct and of dissimilar nature to any or all of the interface protocols 160 deployed to enable communication between the processing resources 150 and shared system resources 140, for example, system memory.
The multicore processor 10, as a whole, is configured to execute a target application, which may be broken down into a number of individual tasks, called threads. Each processing resource 150 is allocated a suitable thread by the controller 130. This allocation is carried out according to a number of parameters, including, but not limited to, the priority of the thread in question, the availability of each processing resource 150 and the suitability of a particular processing resource 150 to the execution of a particular thread.
It is however to be understood that the addition of the controller 130 and its dedicated memory 190 do not otherwise require a redesign of the layout of the processor 10.
One specific arrangement is shown in FIG. 3 which shows a typical System on Chip (SoC) architecture, in block diagram form, and which illustrates the various processing resources 150 that might be placed under the control of the controller 130 in a practical application. It will be noted that the processing resources 150 may in particular be of relatively general capability, such as a DSP, or may of relatively limited functionality, such as a peripheral IO.
FIG. 4 shows the controller 130 and its associated input interface groups 100, output interface groups 110, and two bi-directional interface groups 160 and 180, each group being located on the periphery of the controller 130.
The system control group 102 comprises the miscellaneous signals required to ensure the correct operation of the controller 130. These include a system clock, a real time clock and a reset signal (RST). All output signals from the controller 130 are synchronous to the system clock, although they may be re-synchronised into other clock domains as is required by the system. All input signals to the controller 130 are synchronised to the system clock prior to processing. The RST input is a synchronous reset signal, for resetting the controller 130.
The internal control group 111 consists of a synchronous interrupt for each controller client 120 and its associated processing resource 150. Therefore the number of signals will typically correspond with the number of processing resources 150 within the system and will be defined during the multicore processor 10 design phase. The internal interrupt signal is an internal thread ready interrupt signal, indicative of a thread ready for execution, and that is being assigned to the particular processing resource 150 associated with that controller client 120.
1. The auxiliary debug interface, which enables an external debug agent to gain debug access to the controller 130, and the system as a whole. Through this interface breakpoints and watchpoints may be set both internally and externally, and system state information may be read.
The tightly coupled memory interface group 180 interfaces the controller 130 to its own dedicated tightly coupled memory resource 190.
FIG. 5 shows a typical structure of the dedicated tightly coupled memory 190. The width of the address path and the datapath are defined during the multicore processor 10 design phase. The dedicated tightly coupled memory interface 180 includes a memory address bus 191, a memory read data bus 192, a memory write data bus 193 and write 194 and read 196 enable signals.
The attached memory is assumed to be a synchronous SRAM device. The dedicated tightly coupled memory 190 contains an integer number of controller memory elements 195, as defined during the multicore processor 10 design phase, according to the needs of the target application. In the currently preferred embodiment, each controller memory element 195 consumes 256 bits of memory space. Again in the currently preferred embodiment, the controller supports a maximum of 65536 controller memory elements (i.e. a 16 Mb memory). Although queue descriptors, as described later, do consume controller memory elements 195, in a typical system the number of controller memory elements 195 required would be dominated by thread support requirements. For example, a system capable of supporting 400 threads simultaneously within the controller 130 would require approximately 128 kb of attached memory.
FIG. 6 shows the main logical components of the controller 130. The functionality of the controller 130 is split amongst four primary internal parallel processing subblocks, performing the following functions:
8. A System Interface (TSIF) 280, providing interfacing between software commands received from the multicore processing resources 150 and the individual sub-blocks within the controller 130.
9. A Server Shim (TSSS) 290, configured to provide physical interfacing 115 between the controller 130 and the multicore processing resources 150.
In general terms, the controller 130 manages threads by maintaining a number of queue structures within the dedicated controller memory 190. These queue structures include Pending. Ready, Timer and Dispatch queues. Threads awaiting execution are held in one or more of these queues, and are allocated to suitable processing resources 150 once they become ready. Manipulation of the threads within the queues is mainly carried out using push, pop and sort operations. Full details of the operation of the controller 130 are described in co-pending U.S. application Ser. No. 10/308,895 and is incorporated by reference herein in its entirety.
There now follows a detailed description of the interaction of the above primary and secondary processing subblocks within the controller 130.
The thread input manager 200 provides three public functions to other sub-blocks within the controller 130.
The FreeListStatus function returns the head pointer and number of elements within the controller memory element 195 free list. The free list is a list of the controller memory elements 195 that are currently unused. This function can only be called by the system interface 280, on receipt of a similar command at the controller 130 software API
The Thread Synchronisation Manager 210 provides seven public functions to the other sub-blocks within the controller 130.
The first five of the following 7 functions can only be called by the system interface 280, in response to similar commands received by the controller 130 software API.
The TimingQueueGetStatus function returns the head pointer and a number of elements within the timer queue.
The SyncPrim function is used to issue a synchronization primitive to a given pending queue. This function is called by either the thread interrupt manager 250 or the system interface 280.
The Thread Output Manager 220 provides six public functions to the other sub-blocks within the controller 130.
The following three functions can only be called by the system interface 280, in response to the receipt of a similar command at the controller 130 software API
The Thread Schedule Manager 230 provides two public functions, one to the Thread Output Manager 220, and one to the system interface 280, both of which are located within the controller 130.
As described earlier, the term processing resource 150 is applied to any resource that may execute an instruction, regardless of how rudimentary the instruction may be. Therefore resources that have a fixed function, such as an input/output module, are also included. Depending on the type of processing resource 150, the connection between the system interconnect 160 and the processing resource 150, via the controller client 120 may be either uni-directional or bi-directional.
FIG. 7 shows a schematic block diagram of a controller client 120 for use with the controller 130.
When a hardware component is used, the controller client 120 still interfaces to the processing resource 150 using the same interface. That is to say, the controller client 120 presents an identical interface to the interconnect agent 170 as that of the processing resource 150 to the controller client 120. In some cases, it is appropriate to treat the data path into the processing resource 150 as distinct from the data path out of the processing resource 150, for example in the case of an Input/Output device.
In addition to the main interface, the controller client 120 also provides out of band interfaces for use as outputs for run-time and debug events. Where a software controller client 120 is used, these are provided using standard interrupts, calling appropriate service routines, or form inputs to processing resource 150 specific debug and trace units 151.
1. Controller client 120 configuration content. This information may be used to configure controller client 120 system resource usage policing, address or data-bus trigger configuration (for debug purposes), data presentation mode, and the like.
2. Execution phase, where the thread is being executed and the controller client 120 may be supplying data or monitoring resource utilization.
Consequently, the software controller client 120 architecture and implementation is partially processing resource 150 specific.
The basic structure of the hardware controller client 120 is shown in FIG. 8. At the functional heart of the design is the controller client Finite State Machine (FSM) 300. This Finite State Machine (FSM) 300 may be active during all three phases. The controller client FSM 300 is activated by an interrupt 111 from the controller 130.
Firstly the controller client FSM 300 masters the system interconnect 160 to read the TCB from the shared memory resource 140, which contains a reference to its own instructions. During the configuration phase the controller client 120 may master the processing resource interface, interpreting configuration commands and translating them into write cycles issued to the processing resource 150. Furthermore, the controller client 120 configures its own resource policing. The manner in which the transition from the configuration state to the executing state is processing resource 150 specific, but may be marked by an explicit execute primitive or merely an entry into a data transferral state.
The simplest controller client 120 implementation would require a FIFO style interface in both the system to processing resource 310 and processing resource to system 320 paths. During the execution phase of a controller client 120 of this nature, data can be presented to a processing resource 150 by message or streaming modes. Message mode, where the entire dataset is accumulated locally within the controller client 120 prior to processing, engenders a more coarse grained blocky interconnect behaviour which may facilitate more complex interconnect arbiters. Streaming mode, where data is streamed directly from the system memory 140 into the processing resource 150, presents a more silicon efficient solution requiring more careful consideration of hand-shaking and exhibiting fine grained interconnect transactions and tight coupling to interconnect performance.
Instances of datatypes used within the controller 130 are divided into public (visible from and manipulated by the system at large) and private visibility (visible only within the controller 130 and manipulated only by the controller 130 sub-blocks). To ensure portability of the design across multiple end applications, all thread, queue and aggregated queue descriptors are stored within the dedicated tightly coupled memory 190 using a common base class, the controller memory element 195.
Each controller memory elements 195 may represent any of ten descriptor types:
1. Free List Element. This element is free for usage by any of the other descriptor types. No user initialization or runtime manipulation is required.
2. Thread descriptor (TD). This is a data structure representative of an application/administration thread. This descriptor may exist in either a pending queue, a Ready queue or a dispatch queue within the dedicated tightly coupled memory 190. No user initialization is required, but runtime manipulation is required.
3. Scheduler Root Descriptor (SRD). This is the top descriptor of a scheduler hierarchy. User initialization is required, but no runtime manipulation is required. The root descriptor has no parent, but children can be any of: an SSTD, a DSTD or a TD.
5. Dynamic Scheduler Tier Descriptor (DSTD). This is a dynamic scheduler tier descriptor. User initialization is not required, but runtime manipulation is required. The parent of a DSTD may be either an SRD or an SSTD, but a DSTD may only have TD children.
6. Dispatch Queue Descriptor. This type of descriptor describes a list of thread descriptors, which are waiting for pop operations from the associated processing resource 150. User initialization is required including depth watermarks, but no runtime manipulation is required.
7. Pending Queue Descriptor. This type of descriptor describes a list of thread descriptors, which are awaiting a synchronisation event. User initialization is required, but no runtime manipulation is required.
8. Pool Attachment Node (PAN). PANs are used to attach the scheduler root tier to the processing resource 150 pool root tier. User initialization is required, but no runtime manipulation is required.
9. Pool Static Node (PSN). PSNs are also used to attach the scheduler root tier to the processing resource 150 pool root tier. User initialization is required, but no runtime manipulation is required.
10. Pool Root Node (PRN). There is a single PRN for each processing resource 150 pool. User initialization is required, but no runtime manipulation is required.
FIG. 9 shows a typical relationship between a thread descriptor, the controller 130, a processing resource 150 and the shared system memory 140. Each thread primitive contains a unique reference, pReference. This reference is not interpreted or modified by the controller 130. pReference provides a pointer to a data structure in system memory 140 defining the task to be executed. Typically this would be a controller client control block 125, and would contain at least the following elements: a Function pointer (shown in FIG. 9 as a processing resource instruction block 145), a Stack Pointer and an Argument Pointer (shown together in FIG. 9 as a data block 135). Additional fields may be defined which provide in-band configuration or security over shared system resources.
However, according to the application and/or target processing resource 150 the complexity of the controller client control block 125 may vary. In particular, note that further levels of indirection may be included which, given appropriate "control" instruction code and corresponding "datapath" code, may enable disparate processing resources 150 to execute the same functions on the same data under certain circumstances. In this case, there are pointers for each type of processing resource 150, corresponding to the particular instruction stream required by the dissimilar processing resource 150. The ability to allow dissimilar processing resources to execute the same threads also enables load balancing to be carried out across all processing resources available within the multicore architecture. Furthermore, processing resources may be pooled together.
Dynamic operations include, amongst other things, the monitoring of processor cycles, cache operations, inter-processor communication and system interconnect (e.g. bus) transactions. This type of monitoring is collectively referred to as trace, and it is used in the "profiling" of system behaviour. Dynamic debug, or trace, information is typically generated autonomously by the components of the embedded system.
The local instruction level debug and trace units 151 contain embedded "trigger" logic that causes the processing of instructions within the associated processing resource 150 to halt under certain pre-defined circumstances, but may also be used to initiate or terminate the accumulation of trace information, or some other function. The trigger is typically an event bit which indicates that the predefined "trigger sequence" has been observed.
As a minimum, such trigger logic typically includes breakpoint logic which issues an interrupt (trigger) to the local processing resource 150 when a given instruction is encountered. The amount of functionality that is contained within these units is processing resource 150 specific, however, where required, as mentioned previously, the controller client 120 can include debug watch registers to provide a minimum level of instruction level debug and trace capability. This would be required when the processing resource 150 was of limited function, for example, a dedicated Audio CODEC.
The Debug Access Port 141 allows an external "debug host", to control and to access the debug process. Typically, these hosts interface through a serial port or other similar low speed connection interface protocol.
The optional local trace buffers 152 and unified trace buffers 143 are used to temporarily store trace data before output. This allows a running "snap shot" of the system to be stored, and then read out through the trace port 144 at some later point. By doing this, the trace port 144 does not have to be capable of the potentially high transfer speeds required, should the debug data be outputted in real time. This removes the requirement for a large number of output pins that are (at least in part) dedicated to debug data output. This is important, since at present, it is the number of input/output pads that can be fitted onto any particular Integrated Circuit (IC) die that restricts size of the IC die, as opposed to the size of the functional logic itself.
Connected to each of the local debug and trace units 151, is the thread debug controller 400 of the present invention. This thread debug controller 400 is also connected to the controller 130, debug access port 141 and the trace output port 144, again via one or more optional local and unified trace buffers.
Each of the controller 130 subblocks 200 to 280 has a debug interface 410 for carrying signals into the thread debug controller 400. These input signals notify the thread debug controller 400 of events happening in each of the corresponding subblocks of the controller 130, as the subblocks interact to manage and allocate individual threads between the individual processing resources 150. The thread debug controller 400 can also filter subblock events for trace and trigger information.
Command execution within each subblock of the controller 130 results in the sending of an EventID field and an EventData field to the thread debug controller 400. The subblock to which each event relates is determined by which interface these fields are sent over, as each subblock has its own dedicated interface 440 to the thread debug controller 400. The EventID field is user definable, therefore can be N bits long, however in a preferred embodiment of the invention, the EventID is four bits long. Each individual EventID field identifies an individual event occurring in a particular subblock 200 to 280.
Examples of events that might occur within the subblocks include pushing/popping of threads to or from queues, read/write access to a Controller Memory Element 195, generation of synchronisation events and events that provide a form of low level communication between processing resources 150 and the controller 130.
The thread debug controller 400 also has a Time interface 420. This interface provides a 32 bit time indication, which is used by the thread debug controller 400 to time stamp all events logged, as the thread debug controller 400 receives them from each of the individual subblocks of the controller 130, via the subblock input interfaces 410.
The Auxiliary debug interface 430 is a bi-directional interface for enabling standard external software debug and system visualisation and control tools to access the thread debug controller 400. These external software debug tools are used to both set up the debug parameters on initialization of the system, and to capture and display the resultant trace data. Examples of the interfaces supported include the IEEE 1149.1 JTAG interface and the more capable IEEE Nexus 5001 AUX port Interface.
The trace buffer interface 440 is designed to be used with any currently available buffer technology. In the specific embodiment, the trace data is outputted through a simple byte wide First In First Out interface. FIG. 12a shows the byte wide interface and its associated control signals, while FIG. 12b shows the timing of the electrical signals forming these data and control inputs/outputs. Whilst a single byte wide interface is shown, it would be understood to the skilled person that the invention is not so limited in scope.
Referring back to FIG. 11, the external debug enable signal group 450 are all local debug and trace unit 151 enable signals. There is one provided for each local debug and trace unit 151 present within the multicore architecture 10, therefore the exact number is set during design phase. Each of these signals may enable a particular local debug and trace unit 151 upon detection of a trigger event. By using such local debug and trace unit 151 enable signals, and due to the inherent thread level abstraction of operation of the controller 130, the thread debug controller 400 provides a thread (i.e. macro-architectural) level debug capability that can be gated with the local instruction (micro-architectural) level of the local debug and trace units 151. This provides both a coarse-grained thread based debug and a finer grained instruction based debug to software engineers, thereby facilitating the debug process, without introducing additional debug software that would otherwise cause probe effects.
The thread debug controller interrupts signal group 470 consists of 2 signals. They allow the feedback of interrupts from the thread debug controller 400 back to the controller 130. These interrupts are handled in the same way as all other external interrupts to the controller 130. The use of these signals is entirely programmable, but typical examples of their use would include the collection of statistics on events requiring attention in the application, and the activation of a debug monitor thread in a particular processing resource 150.
The TSIF system interface 412 allows communication between the interface manager sub module 280 of the controller 130 and the thread debug controller 400. This interface comprises both an SubBlockCmd slave input interface 490 and a GenericReg master output interface 480. All processing resources 150 situated within the multicore processor and the TSIF subblock may access the thread debug controller 400 through the SubBlockCmd slave input interface 490 for normal and debug operations, for example, to program the debug parameters during run application time. Equally, the thread debug controller 400 may be granted full access to all internal subblocks of the controller 130 via the GenericReg master output interface 480.
FIG. 13 shows a more detailed diagram of the connections between each of the subblocks of the controller 130, and the thread debug controller 400. The thread debug controller 400 accesses resources within each subblock of the controller 130 via the Interface Manager (280), using the generic register, GenericReg, interface 480. This interface also allows the thread debug controller 400 to enable debug and perform single step on each subblock independently.
Secondly, dedicated TSIF system interface 280 commands can generate TSIF DebugEvents capable of holding 32 bits of data. These can then be utilized as a low bit rate communication channel between a host debugger and each of the processing resources 150.
The dynamic debug interface 540 is used to control the specifics of the dynamic operation of the thread debug controller 400, for example, what system management and allocation events are to be looked for by the thread debug controller 400, and what actions are to be carried out by the thread debug controller 400 when a particular event is observed.
The SubBlockCmd interface 490 allows the interface manager 280 of the controller 130 to access the dynamic debug interface 540. A specially designed multiplexer 560 only allows access to the dynamic debug interface 540 from the SubBlockCmd interface 490. The Nexus protocol converter 435 converts signals from an external debug host using the IEEE Nexus 5001 protocol standard into internal signals suitable for controlling the debug operation of the thread debug controller 400. In so doing, the converter 435 also provides a subset of the Nexus recommended registers. The external debug host is allowed to access both the dynamic debug interface 540, and the static debug interface 530, via the multiplexer 560. The external debug host is also allowed to access all the internal subblocks 200-280, of the controller 130 via the interface manager 280 generic interface.
Each debug machine 500 comprises an EventWatchInst First In First Out (FIFO) register 510, for storing events to be watched for by that debug machine 500, and an ActionListInst FIFO register 515, for storing the action to be carried out upon detection of a particular event from the EventWatchInst FIFO 510. These registers are programmed with their respective instructions through the dynamic debug interface 540. Each debug machine 500 also comprises an event service module 520, which takes the outputs from both the EventWatchInst and ActionListInst registers, and compares them with the system management and allocation events inputted from the individual subblocks of the controller 130. The event service module then outputs one or more of the following: a DebugEnable signal 450, for use in enabling the local debug and trace unit 151 of the corresponding processing resource 150; a TraceEnable/Disable 550 to enable (or disable) the static event filter 600 outputting the trace information to the trace buffer 440; a SyncEnable signal 555, for controlling the other debug machines concatenated together with the current debug machine 500. The debug machines 500 also have an input from the dynamic debug interface 540, for debug programming purposes.
FIG. 16 shows the physical implementation of the debug machines 500 in the specific embodiment of the invention described herein. In this embodiment, the EventWatchInst FIFO 510a and ActionListInst FIFO 515a are actually implemented as two instruction register files shared between all debug machines 500. These unified register files 510a and 515a are accessed as logically independent FIFOs, via read 506 and write 505 control logic systems. This implementation allows the FIFO depth for each debug machine 500 to be individually configured to suit a particular implementation by the user.
EventWatch instructions are used to catch single events from a particular subblock 200 to 280 within the controller 130. The Finite State Machine (FSM) that controls each debug machine 500 will look for the subblock events specified in the EventWatch instruction, and perform the action (e.g. breakpoint enable, etc) defined within the associated ActionList Instruction.
TABLE-US-00001 Single Word EventWatch Instruction Format Bit Word 43 . . . 41 40 . . . 36 35 . . . 32 31 . . . 0 0 EWOpcode SubModuleID EventID EventData
TABLE-US-00002 Double Word Event Watch Instruction Format Bit Word 43 . . . 41 40 . . . 36 35 . . . 2 31 . . . 0 1 MaskOp SubModuleIDMask EventIDMask EventDataMask 0 EWOpcode SubModuleID EventID EventData
TABLE-US-00003 EWOpcode Numonics Description 000 Reserved. 001 SWIE Single Word Instruction & Execute. When the specified event is detected the first instruction in the ActionList Instruction FIFO 515 is executed and the Debug Machine 500 is halted until reset by the user. 010 SWINE Single Word Instruction & No Execute. When the specified event is detected, the Debug Machine 500 continues to execute the next instruction from the EventWatch Instruction FIFO 510. This instruction may be used to provide nested break/watch points. No ActionList Instruction 515 is executed. 011 DWIE Double Word Instruction & Execute. Same as in SWIE, however, "MaskOp", with the corresponding mask field, is applied to each operand field prior to a check for zero. Requires two entries within EventWatch instruction FIFO 510. 100 DWINE Double Word Instruction & No Execute. Same as in SWINE, however, "MaskOp", with the corresponding mask field, is applied to each operand field prior to a check for zero. Requires two entries within EventWatch instruction FIFO 510. 101-111 Reserved.
TABLE-US-00004 SubModuletDField Module Description 00000 Reserved. 00001 TSIF 00010 TSIM 00011 TSOM 00100 TSSM 00101 TSPM 00110 TSMM 00111 TSTC 0100 TSIC 0101 TSSS 01010 - 01111 Reserved for further sub modules. 10000 Debug Machine 0. 10001 Debug Machine 1. . . . . . . 11111 Debug Machine 15.
3. EventID( ): This 4 bit code defines the individual subblock event, as described by the EventID provided within each Event provided across interface 410 from each of the subblocks 200 to 280 that make up the controller 130.
4. EventData( ): This 32 bit code defines the individual subblock 200 to 280 event being watched for, for example the pReference field within the controller dedicated controller memory 190.
For a single word event watch, the next EventWatch Instruction is first loaded from the EventWatchInst FIFO 510, into the first of two EventWatch instruction buffers within the event service module 520. Next, the SubModuleID, EventID and EventData parts are compared to the incoming controller 130 events using a comparator 522. Although these only contain the EventID and EventData, the SubModuleID is known because each subblock has its own particular interface 410. The result of the comparison is then ORed with the results of the other comparisons being carried out by the other debug machines 500, if applicable, using the OR logic block 523. The output of the OR function block is used to control the output of an EventWatch instruction decoder 524, which decodes the EWOpcode contained within the EventWatch instruction. The output of the EventWatch instruction decoder 524 itself controls the output of the ActionList instruction decoder 521, which decodes the ActionList instruction associated with the EventWatch instruction, which has previously been loaded in from the ActionList instruction FIFO 515, via an ActionList buffer 516. The output of the ActionList instruction decoder 521 can be any one of: a DebugEnable signal for controlling the local debug and trace unit 151 of the processing resource 150 associated with the debug machine 500 in question; a TraceEnable signal for enabling the output of the trace data from this point onwards; a SyncEnable signal for enabling synchronisation between debug machines 500.
TABLE-US-00005 MaskOp Field Module Description 0000 Bitwise AND. 0001 Bitwise OR. 0010 Bitwise XOR 0011 - 1111 Reserved.
TABLE-US-00006 FieldName Bits Description TraceEnable 1 Enable or Disable run time trace information. 0 - Disable trace module 151 (if enabled). 1 - Enable trace module 151 (if disabled). SFTIndex 2 Identify which "Static Filter Table Index" (within the Static Event Filter module 600), is used when the TraceEnable is asserted. BrakeEna N + 1 Breakpoint enable to system processing resources 150 & Debug Machine(s) 500, supporting up to "N" system processing resources 150. Thus any arbitrary combination of system processing resources 150 may have their breakpoints enabled. Bit[0] - Internal Debug Machine 500. Bit[1] - External system processing resource 1 debug enable. Bit[N] - External system processing resource N debug enable. SWSync M Issue Synchronisation event to other Debug Machine(s) 500 to allow complex chaining of Debug Machine(s) 500. Supporting up to "M" Debug Machines 500. IntEnable 2 Providing 2 interrupt pins to TSIC 250 to support software features, for example, run time gathering of statistics.
FIG. 20 shows the functional block diagram of the static event filter 600, which performs filtering of system management and allocation events before passing them out onto the trace data formatter compressor module 700 for capture. This filter module 600 also performs time stamping of all events received from the controller 130, using the 32 bit input from the time interface 420.
TABLE-US-00007 EventFilterMaskBits Data Bit Field Filter Status 00 0 PASS. 1 FAIL. 01 0 FAIL. 1 PASS. 10 0 PASS. 1 PASS. 11 0 FAIL. 1 FAIL.
The trace data formatter compressor 700 contains an event switch 710 which routes all the filtered and time stamped subblock events into the next available two entry FIFO 720, which form the inputs to the field base correlator 730. The FIFOs are two entry to allow either single or double word events to be stored. The event switch 710 is capable of accepting ten simultaneous events from the ten subblocks 200 to 280 of the controller 130. The event switch always writes to the lowest numbered FIFO 720 currently available.
Once all the FIFOs 720 contain at least one entry, or once an internal timer expires, denoting the end of the current FIFO load cycle, then the FIFOs are pushed into the field base correlator. The internal timer is loaded with a fixed value when at least one entry resides in any of the 10 FIFOs 720 and is reloaded when the events are read out.
TABLE-US-00008 Syntax Byte Size Comments PacketStart 1 Fixed byte pattern to indicate start of new packet 0xFF. ByteCount 1 Indicate total number of bytes within the packet following this byte. Value 0 is valid indicate no more bytes (i.e. NULL packet). PacketData ByteCount Compressed System management and allocation Events data.
Referring back to FIG. 14, the internal debug control module 580 of the thread debug controller 500 provides individual subblock debug enable signals and single-step functionality for subblocks 200 to 280 within the controller 130. On receiving the internal DebugEnable signal from any of the debug machines 500, the internal debug control module 580 will put the specified subblock into debug mode. The user can also single step specified subblocks via the dynamic debug interface 540.
Previous Patent US 9,038,075 | Next Patent US 9,038,077