Microprocessor Report (MPR) Subscribe

UltraSoC Embeds Run-Time Analytics

Licensable IP Includes Debug, Performance, and Security Monitors

October 16, 2017

By Mike Demler


UltraSoC Technologies develops licensable intellectual property (IP) for analyzing and monitoring a chip’s internal operations. The IP includes traditional test-bench debug functions that engineers use to bring up devices before production, but it also offers capabilities for in-field run-time data logging and reporting, performance optimization, and security monitoring. A venture-capital-backed startup with fewer than 100 employees, UltraSoC began operations in 2005 as a University of Kent spinoff. CEO Rupert Baines and CTO Gajinder Panesar both previously worked at PicoChip, a vendor of small-cell base-station SoCs.

SoC designers and software developers typically use on-chip debug structures provided by CPU-IP vendors, such as CoreSight from Arm, debug and trace probes from Mips, and DesignWare Small Real-Time Trace (Smart) modules from Synopsys. The debug components connect through a dedicated JTAG port to analysis software running on a PC or workstation, enabling run-time controls for setting break points, accessing memory, and tracing data/program execution. UltraSoC’s products are compatible with and connect to such CPU-centric systems; its partners include Arm, Cadence/Tensilica, Ceva, and Mips. The company also worked with the RISC-V Foundation to develop a processor-trace specification for that open-source architecture, and SiFive is using UltraSoC IP in its Freedom platform (see MPR 8/1/16, “SiFive Offers RISC-V Platforms”).

The UltraSoC hardware works with a variety of CPU/GPU/DSP architectures and other types of IP cores, as well as with custom logic. One component is a USB2.0 debug communicator module, which offers a higher-speed alternative to a JTAG port. The interfaces to the analysis and monitoring module are compatible with standard or proprietary on-chip interconnects as well as with third-party networks-on-a-chip (NoCs). The UltraSoC components, however, connect together on a separate message-passing infrastructure without using any of the underlying SoC resources, as Figure 1 shows.

 

Figure 1. Example SoC integrating UltraSoC analytics modules. Green boxes show UltraSoC components. Users configure the monitors by employing a communicator connected to an I/O port, which can also output analytics data sent through the message engines and interconnect.

Designers integrate the configurable and synthesizable UltraSoC RTL components with their chip architecture during SoC implementation, but users can configure and change the IP’s functions at run time. The analytics and debug IP modules are nonintrusive, connecting passively to master and slave system-bus interfaces to sniff data traffic in the various logic blocks. Configurations vary, but on average, the analytics functions and messaging infrastructure add approximately one percent to the die area, according to the company’s calculations. UltraSoC supports its IP with software tools running in a standard Eclipse integrated development environment (IDE), but it also works with other debug-software vendors and instrumentation suppliers including LeCroy and Teledyne. Among its customers are Huawei’s HiSilicon group, Intel (Movidius), and Microsemi.

Embedding Analytics

UltraSoC IP comprises three module types: analytics, message engine, and communicator. The analytics modules are probes that integrate nonintrusively into the system by connecting to the block-level interfaces of bus-fabric links and other system components. Status monitors are a type of analytics module for debugging, diagnostics, event detection, and performance profiling. They work like embedded logic analyzers by counting, accumulating, and tracing data in response to system states or a sequence of events.

The processor modules access standard CPU features such as breakpoint, cross-triggering, and run control. So-called processor advanced modules connect with vendor-proprietary debug IP such as Arm’s CoreSight and support that company’s Cortex CPUs. They include variants for MIPS, RISC-V, and Cadence’s Xtensa as well. UltraSoC also plans to support ARC (Synopsys), Andes, and other licensable CPUs.

Bus-analytics monitors are protocol-aware functions for detecting user-specified transactions on a chip’s internal buses. The IP sniffs data traffic at the master or slave terminals of on-chip buses. These monitors apply filters to detect transactions of interest, and the filters are cascadable to detect more-complicated series of events. The bus-monitor IP works with popular protocols including Ace, Ace-Lite, the packet-based Amba 5 Chi interface, AXI, and Open Core Protocol (OCP) versions one and two. It also works with NoCs by connecting to master/slave ports without altering the interconnect structure. The messaging engines route communications between all of the UltraSoC blocks using an interconnect infrastructure that’s independent of the underlying SoC buses. Designers can size the message interconnect from 1 to 512 bits wide.

UltraSoC communicators link the other components to debug and performance tools. The lineup comprises off-chip interfaces for connecting through Ethernet, GPIO, JTAG, serial/parallel ports, and USB, as well as a communicator block for a dedicated on-chip subsystem. The USB communicator links directly to a USB PHY to create a dedicated debug channel or to an optional USB debug hub. It’s a state-machine-based implementation of the standard USB protocol, so it requires no software support from the target system. Applications for on-chip communicators include self-monitoring safety and security functions.

The analysis IP comes with its own clock-domain-crossing functions, enabling designers to tap into their SoC’s functional blocks and interconnect them without altering the chip’s architecture. The monitors are also power-domain aware and will automatically boot up or shut down in accordance with the chip’s power gating.

Real-Time Monitoring

UltraSoC analytics monitors operate while the chip is running in its normal mode. To set up internal analytics, users load configuration messages to the various monitors through a communicator module. For example, a user can configure the bus monitors connected to the DRAM controller to count cache misses on an instruction-cache port. Detection of two outstanding misses on a particular port may indicate the need for better hints to the branch predictor. A CPU-performance monitor can track the number of stall cycles and send that data off chip through a communicator. Programmers can employ such diagnostic information to perform regression tests and assess the quality of their software updates.

Bus monitors are reconfigurable for use in analyzing other memory transactions, such as to measure instruction-cache traffic initiated by the scalar CPUs and the DSPs. By measuring the traffic from each initiator, programmers can determine whether a software change for one processor core has an inadvertently detrimental effect on another core’s performance. Identifying the source of high peak read requests enables designers to avoid exceeding the DRAM controller’s bandwidth.

Another use of the bus monitors is to detect deadlocks. Users can program them to trigger whenever the number of cycles consumed by a particular bus transaction exceeds a specified threshold. After such a monitor triggers, it keeps a trace of transactions leading up to the deadlock, including transaction IDs and the identities of the bus master/slave pair that caused the deadlock.

As Figure 2 shows, bus monitors can also identify the source of data corruption that results when two initiators write to the same memory address or range of addresses. To perform this function, the monitor tracks the master IDs and side-band channels for all write transactions in the specified memory region, triggering if that transaction comes from an unauthorized initiator. It can then either trigger a processor shutdown or set an alarm flag with the fault data and time stamp.

 

Figure 2. UltraSoC data-corruption detection. The bus monitor keeps track of transactions coming from each of the initiators; it can flag an unauthorized access to a prohibited range of memory addresses or a conflict from two initiators writing to the same space.

Designers can also employ static instrumentation blocks to output monitor data to independent mailboxes in the UltraSoC IP. Software developers can read the time-stamped data into third-party tools to analyze program flow and create various trace views of system performance.

Bare-Metal Security

Because the UltraSoC monitors and message-passing infrastructure combine to yield an independent nonintrusive subsystem, the IP’s visibility into the underlying SoC operations makes it well suited to security monitoring. It can also handle performance-tracing and diagnostic functions. Hackers are unlikely to be aware of the UltraSoC IP, since it’s completely outside the control of the main CPU subsystem. It acts as another security layer alongside traditional methods such as encryption and embedded key storage. For example, the bus monitors can watch for attempts to access the keys and set an alarm if the transaction didn’t originate from a trusted application or the hardware crypto engine. They can detect when a chip isn’t operating as intended, thwarting attempts at unauthorized access.

The bus monitors can also detect attempts to read from secure memory, flag unauthorized writes, and identify frequent accesses or interrupts. These events may indicate a distributed-denial-of-service (DDoS) attack that’s attempting to overwhelm a processor’s bandwidth. When the monitor discovers an unauthorized operation, it can trigger a system shutdown, activate a secure supervisor, or use the communicators to transmit the event trace to an off-chip agent.

Since the UltraSoC IP is entirely hardware based and therefore requires no on-chip software, it works in any type of integrated circuit, not just a processor. To maintain security, it has built-in authorization mechanisms that enable designers to designate protected subsystems and operations. As Figure 3 shows, designers implement the messaging infrastructure by constructing a hierarchy of message engines. Each engine employs a challenge-response mechanism to control access to the next level in the hierarchy. The modules use different security keys to control routing of downstream and upstream messages, making it difficult for hackers to infiltrate the hardware-based security.

               

Figure 3. UltraSoC messaging-infrastructure hierarchy. The message engines act as secure gateways, controlling downstream and upstream message passing through a challenge-response mechanism.

To employ UltraSoC IP for bare-metal security, users configure it through a secure channel that’s independent from the underlying system. This channel can be a connection to a host computer, a service running in a remote data center, or a small subsystem in the UltraSoC domain. Because the IP is run-time configurable, access rights and the chip’s designated secure areas can be set in accordance with the application and deployment. In standalone systems that lack a direct connection, designers can integrate a small dedicated controller that operates in the UltraSoC analytics domain. This controller configures the security subsystem at boot time and handles run-time analysis.

A Holistic Vendor-Independent Method

Although SoC designers often use debug IP from their CPU providers, UltraSoC’s technology offers additional capabilities. Arm’s CoreSight IP, for example, has a similar set of debug and trace functions, including a debug-access port and embedded logic analyzer as well as memory-, processor-, and system-trace macrocells. The CoreSight SoC-600 abstracts the debug-hardware interface through a higher-layer protocol, enabling its use for different physical interfaces. Whereas the SoC-600 protocol can handle debug targets in either software or hardware, UltraSoC runs completely in hardware and therefore requires integrating a debug module for each port.

Arm processor-trace macrocells are specific to each of its Cortex CPUs, offering designers the insights they need into the CPU’s internal pipeline. The UltraSoC processor monitors lack that low-level visibility, instead providing a complementary set of tools that are agnostic to a particular vendor’s IP cores and SoC interconnect. UltraSoC IP bolts nonintrusively onto any CPU architecture, and it can connect to CoreSight interfaces to deliver more-holistic system-level visibility.

UltraSoC’s greatest advantage is the additional analytics it provides for a range of applications beyond traditional debugging, from performance optimization to troubleshooting to security. This flexibility makes it much more powerful than single-function dedicated logic. The IP does more than identify and trace faults, delivering valuable insights to software developers. Its standalone self-monitoring functions, and its use as a monitoring tool in nonprocessor devices, make it well suited to a wider range of tasks than traditional debug hardware. The security capabilities are an added bonus. SoC designers will find the UltraSoC IP to be valuable for pre- and postproduction analysis, and device users will be attracted to its ability to produce analytic data that enables performance optimization in the field.

Price and Availability

UltraSoC doesn’t disclose licensing fees for its IP, which is available now. For more information, access www.ultrasoc.com/technology-2/ultradebug-modules.

Events

Linley Spring Processor Conference 2018
April 11 - 12, 2018
Hyatt Regency, Santa Clara, CA
Linley Fall Processor Conference 2018
Covers processors and IP cores used in embedded, communications, automotive, IoT, and server designs.
October 31 - November 1, 2018
Hyatt Regency, Santa Clara, CA
More Events »

Newsletter

Linley Newsletter
Analysis of new developments in microprocessors and other semiconductor products
Subscribe to our Newsletter »