Nexus architecture is based on a packet-based messaging scheme, which supports debugging complex multicore systems. Control ofthe multicore debug processes based on a transaction protocol (TCODE) that allows data to be sent in packets, using a packet header toprovide information on the source and assumed destination of the data on-chip components as well as information on the subsequentdata packets
containing trace or other information. This simplifies interleaving of multiple trace sources and concurrent communication with multipleNexus instruments. The Nexus specification defines a standard set of TCODEs for common identification and trace operations;the TCODE protocol is also extensible to user-defined debug commands (see Table 11.4).Nexus also defines a standard set of debug-related on-chip registers, which facilitateApplications have varying debug requirements, but most debug can be grouped into performing certain classes of tasks. Nexus defines debugger functionality and compatibilityover four classes of operation. Device instrumentation and tools are defined as being class 1- to 4-compliant if they support all of the features defined for that class. Class 1starts with basic debug functions over a JTAG port, with higher classes involving more instrument access and system complexity usingthe AUX port to progressively increase debug capabilities, such as adding m ore complex.
Features in the Nexus implementation classes can be customized so that designers can select features of importance and not beburdened with more advanced features or those that are not applicable or efficient to their debug needs. This allows a variety ofdebug features to be supported, while keeping the number and types of different Nexus implementations that need to be tracked andsupported manageable. All Nexus classes by definition include all of the features in (i.e. are a superset of) the prior class(es). Thekey features of the different implementation classes are summarized in the Table 11.1.The most basic, class 1, provides features similar to standard JTAG implementation.Class 1 provides run-control debug features that are common with most processor implementations, including core identification, single stepping,
breakpoints and watchpoints, and static memory and I/O access. Class 1 has certain minimum requirements, such as the need for atleast two hardware breakpoints. Debugging halts the chip while commands are executed.Class 2 contains more complex debugging features with real-time monitoring. It also adds instruction tracing and more sophisticated watchpoints. Class 2 enables processorexecution trace-related features including real-time monitoring of process ownership and instruction tracing, along withcomplex watchpoints and branch tracking , flagging indirect branches, and eliminating redundant addressing information. The class2 programindirect branches from exception-handling operations. Additional messages are included for improved branch tracking. Theformat of the trace data allows for the elimination of redundant addressing information, which increases throughput.Class 3 allows data-tracing services and includes the ability to read and write memory and I/O while the proce ssor is running. Class 3 supports data tracing and memory and I/O read and write while the processor is running. This makes the system design more complex, but significantly improves the debugging capabilities.
Finally, class 4 delivers features found in many in-circuit emulators (ICEs). Class 4 allows direct user control of a processor to executeprograms from the Nexus port (memory substitution), plus additional features for remapping memory and I/O ports and starting trace onwatchpoint occurrence. This is especially useful when simulating peripherals. It can also be used to provide other applications runningmemory substitution on watchpoint occurrence, monitoring data reads while the processor is running in real time, port replacement and port sharing, and the ability to transmit data values for acquisition.Nexus messages consist of a 6-bit TCODE that contains Nexus-specific instructionsfollowed by a variable number of packets (the number of packets for each TCODE is defined in the standard).
Messages can be sync or nonsync. Sync messagesmessage also contains a SRC field (source ID) to help development tools identify the source of a particular Nexus message in a multiprocessing SoC sharing a single debug port. Packet types supported includethefollowing:Variable: A variable-size packet means the message must contain the packet but the packet's size may vary from aminimum of 1 bit. An example is an address field that may be full or partial for a given message. When messages are transferred via the AUX, variable-size packets must end on a port boundary.Vendor-fixed:These are used to allow Nexus packets in to match characteristics of a vendor's device. An example is a SRC field that identifies thesource ID;
Nexus architecture is based on a packet-based messaging scheme, which supports debugging complex multicore systems. Control ofthe multicore debug processes based on a transaction protocol (TCODE) that allows data to be sent in packets, using a packet header toprovide information on the source and assumed destination of the data on-chip components as well as information on the subsequentdata packets
containing trace or other information. This simplifies interleaving of multiple trace sources and concurrent communication with multipleNexus instruments. The Nexus specification defines a standard set of TCODEs for common identification and trace operations;the TCODE protocol is also extensible to user-defined debug commands (see Table 11.4).Nexus also defines a standard set of debug-related on-chip registers, which facilitateApplications have varying debug requirements, but most debug can be grouped into performing certain classes of tasks. Nexus defines debugger functionality and compatibilityover four classes of operation. Device instrumentation and tools are defined as being class 1- to 4-compliant if they support all of the features defined for that class. Class 1starts with basic debug functions over a JTAG port, with higher classes involving more instrument access and system complexity usingthe AUX port to progressively increase debug capabilities, such as adding m ore complex.
Features in the Nexus implementation classes can be customized so that designers can select features of importance and not beburdened with more advanced features or those that are not applicable or efficient to their debug needs. This allows a variety ofdebug features to be supported, while keeping the number and types of different Nexus implementations that need to be tracked andsupported manageable. All Nexus classes by definition include all of the features in (i.e. are a superset of) the prior class(es). Thekey features of the different implementation classes are summarized in the Table 11.1.The most basic, class 1, provides features similar to standard JTAG implementation.Class 1 provides run-control debug features that are common with most processor implementations, including core identification, single stepping,
breakpoints and watchpoints, and static memory and I/O access. Class 1 has certain minimum requirements, such as the need for atleast two hardware breakpoints. Debugging halts the chip while commands are executed.Class 2 contains more complex debugging features with real-time monitoring. It also adds instruction tracing and more sophisticated watchpoints. Class 2 enables processorexecution trace-related features including real-time monitoring of process ownership and instruction tracing, along withcomplex watchpoints and branch tracking , flagging indirect branches, and eliminating redundant addressing information. The class2 programindirect branches from exception-handling operations. Additional messages are included for improved branch tracking. Theformat of the trace data allows for the elimination of redundant addressing information, which increases throughput.Class 3 allows data-tracing services and includes the ability to read and write memory and I/O while the proce ssor is running. Class 3 supports data tracing and memory and I/O read and write while the processor is running. This makes the system design more complex, but significantly improves the debugging capabilities.
Finally, class 4 delivers features found in many in-circuit emulators (ICEs). Class 4 allows direct user control of a processor to executeprograms from the Nexus port (memory substitution), plus additional features for remapping memory and I/O ports and starting trace onwatchpoint occurrence. This is especially useful when simulating peripherals. It can also be used to provide other applications runningmemory substitution on watchpoint occurrence, monitoring data reads while the processor is running in real time, port replacement and port sharing, and the ability to transmit data values for acquisition.Nexus messages consist of a 6-bit TCODE that contains Nexus-specific instructionsfollowed by a variable number of packets (the number of packets for each TCODE is defined in the standard).
Messages can be sync or nonsync. Sync messagesmessage also contains a SRC field (source ID) to help development tools identify the source of a particular Nexus message in a multiprocessing SoC sharing a single debug port. Packet types supported includethefollowing:Variable: A variable-size packet means the message must contain the packet but the packet's size may vary from aminimum of 1 bit. An example is an address field that may be full or partial for a given message. When messages are transferred via the AUX, variable-size packets must end on a port boundary.Vendor-fixed:These are used to allow Nexus packets in to match characteristics of a vendor's device. An example is a SRC field that identifies thesource ID;
No comments:
Post a Comment