Debug life cycle expands with on-chip infrastructure
By widening the range of resources that can be tracked within an SoC, Ultrasoc says it has uncovered ways to make debug a long-term tool for complex multicore designs.
Rupert Baines, Ultrasoc CEO, pointed to situations involving high-end processors for communications switches and servers, safety-critical systems, and power optimization of mobile-device software over time as examples for where hardware-assisted cross-chip debug access can expand the role of debug itself.
Baines pointed to one possibility for high-end multiprocessor applications, “where the system vendor will have service-level agreements and performance requirements. But the system is running very complex software that is hard to define in the lab in a way that is truly representative.
“They can use debug for accurate performance monitoring using real customer data and report exactly what the performance is. They can also be tuning code and performance because they have analytics they can’t get from test benches. With full diagnostics they can pull out analytics and get true performance data. The systems companies are happy because they see very granular analytics that they can use with their customers and they can improve performance over time,” Baines added.
Power tracking
“At the other extreme you have mobile phones, with their very tight time-to-market pressures,” Baines said, where a key requirement is to pass compliance checks as early as possible to ensure the products can ship. Initially, this will trump other issues that matter in the marketplace, such as long-term energy efficiency.
“By analysing what’s going on over time, measuring stalls, contentions, and deadlocks they can see where they are burning power on the things that have no use. You can optimise micro schedulers and organize bus access patterns to save you a lot of digital power. You can look at how people are using things and optimize software controlling the display and other parts of the the phone that are tuned to actual user behaviour.”
“There is a realm of analytics, dynamic and forensics that’s way beyond normal debug,” Baines claimed. “But there is the ability to do more in forensics and analytics. A different world is safety critical where people are happy to invest in the forensics, using features such as circular buffers to record events and see what caused a problem, such as phantom braking in an automotive system. You can log the data and report. It is maybe not something you do remotely but have the data sucked out once in a while, possibly as part of a vehicle service.”
Long-term debug access has been deployed by companies such as Wind River in the past to fix systems remotely, famously by NASA in the case of its Mars landers, as well as to provide runtime logs of long-term behavior in other embedded systems. But these techniques have been used primarily for single processor cores and require a software executive or RTOS to collect the data. Hardware-assisted debug has focused on specific processors, such as ARM’s CoreSight.
Heterogeneous debug
“In the ARM world we can hook into CoreSight. But nobody’s chip is homogenously ARM-exclusive. You may have ARM CPUs, an Imagination GPU, communications from Ceva, a security coprocessor from someone else, and an accelerator you developed yourself. Each vendor’s debug can only do their own flow, which is 10 to 20 per cent of the functionality.”
Ultrasoc has designed hardware IP and an on-chip communications network to collect the data for external probes that avoid the need to have software debug executives. Baines said some users might opt to deploy a dedicated processor to orchestrate data collection on behalf of an external debug probe.
“We can link up to the ARM ecosystem and pull in debug information that’s utterly consistent with those tools and do the same for MIPS, Ceva, Tensilica, and others. We can also do things such as monitor bus interactions, which may use a standard format, such as AXI, or something custom. We can interpret outputs from generic logic to perform status monitoring and bring that back. There is a portfolio of subsystems, such as state-machine monitors that report on state transitions and look for illegal transitions in a rich way, as well as things like FIFOs and buffers. It’s rich information: not just the state of the buffer but overflows, underflows, average fill level.”
Like the software-based techniques, Ultrasoc has developed interfaces that allow SoC designers to avoid the need to leave JTAG pins accessible.
Access control
Baines said: “It’s a different debug challenge when you start leaving the test bench and it gets into a product. It has been difficult historically because we’ve lost a lot of access by then. At some point you have to put it into the real package and you no longer have access to test points. The first step was the introduction of debug over USB. It’s nice because it’s a lot faster than the serial port and it also means you can use a finished form factor. We will be supporting other interfaces. The same architecture can support ethernet and PCI-Express, for example.”
As long-term debug access opens up potential security issues, the company has defined a mechanism for controlling authentication and encryption for the reported data. “Every block has its own security elements. The key architecture is hierarchical and the keys are under the customer’s control. The chip engineer can have full access. They can turn off certain blocks and provide the customer with access to some. And they can lock down others. That architecture is carried through to the USB infrastructure. The USB can also be soft blown through keys or hard blown using fuses to disable access to the debug engine through the multiplexer.”
