Paper Report

1. Paper Report M•CORE Architecture implements Real-Time Debug Port based on Nexus Consortium Specification Feng-Xiang Huang David Ruimy Gonzales Senior Member of Technical Staff Motorola M•CORETM Technology Center Austin, Texas david.gonzales@mot.com

2. My Research Tree IEEE 1149.1 JTAG Nexus 5001 ForumTM Standard A Scan Cell Design for Scan-Based Debugging of an SoC With Multiple Clock Domains 2010 A Design-for-Debug(DfD) for NoC-based SoC Debugging via NoC 2008 Exploiting an I-IP for both Test and silicon Debug of Microprocessor Cores 2005 A Low-Cost SOC Debug Platform Based on On-Chip Test Architectures 2009 NIFD: Non-Intrusive FPGA Debugger Debugging FPGA ‘Threads’ for Rapid HW/SW Systems Prototyping 2010 Combining Scan and Trace Buffers for Enhancing Real-time Observability in Post-Silicon Debugging 2010 A High-Level Debug Environment for Communication-Centric Debug 2009 Scan application Debug IP HW/SW

3. Abstraction • For Tool Vendors Highly integrated How Programs flow Tradeoff between Performance & Visibility Difficult Offer consistent functionality across architecture to tool venders

4. Nexus 5001 Forum • What’s Nexus • Nexus is standard, real-time interface for embedded process. • On-chip debug features • Protocols • Pin • Interface to externals tool • Companies: Motorola, Siemens, Hitachi, …,24 companies anticipated. • Nexus provides a toolbox of features for processor debug • Support existing debug interface JTAG • Auxiliary trace debug interface • Simple packet based message protocol • Define classed for standard with increasingly complex implement

5. Illustration of JTAG/Nexus Development Interface • Dynamic debug • Real-time information • Variable Levels • Static debug

6. Nexus Port Controller • A Scalable Port • EVTI: Nexus Event Input • EVTO: Nexus Event Output • MSEO: Nexus Message Start/End Output • MCKO: Nexus Message Clock Output • MDO: Nexus Message Data Output • RDY: Nexus Ready Output

7. Nexus: Class of Compliance • Half duplex • Static debug features • Class 1: • Compliancy JTAG • Basic Run-Control • Full duplex • dynamic debug features • Class 2,3,4: • Auxiliary debug interface • Variable Message-based • Simple trace compress • More Complexity • High Performance

8. Public Messages: Transaction CODE, … • Packet-based data • Monitoring Program Flow • Ownership Message: process identification • Branch Trace Message: program counter’s change of flow • Watchpoint Message: • Data Trace Messages • Reporting real-time specific data accesses to memory location • Memory substitution Messages • Emulate a bus where opcodes and data may be accessed. • Auxiliary Access Messages • Read/Write auxiliary control and status registers.

9. M•CORE M340(Class 2+) • The first implementation of this proposed standard • Low pin count • Low power consumption • OnCETM debug block • JTAG protocol • Limited observation of real-time program flow

10. M•CORE M340(Class 2+) • 16 Deep FIFO • Real-time Message • Auxiliary interface • Class 1 • JTAG interface

11. SUMMARY • Class levels classified  a scalable debug needs for specific debug stages • Standardize on a set of features, protocols…, etc. • Rapid development of real-time microcontroller based products. • Time to Market • It is Benefit of tool Vendors, providing an standardized on a set of features.

12. Comment • It is benefit not only tool vendors, but designer. • It emphasizes the message of Nexus defined, not talks more detail about protocol of Auxiliary interface. • FIFO design of control protocol is key using by auxiliary port, Message format also is.