What is UltraSoC?
UltraSoC is a platform that allows the construction of a complete on-chip analytics and monitoring infrastructure, designed for debug, performance monitoring and to integrate value-added functions to an SoC. It is modular, consisting of over 30 different parameterized and configurable modules that can be used to debug third-party IP cores or custom code; it also includes an on-chip messaging network. The system architect controls which points they wish to monitor, to what level of detail, how information is passed around the system and communicated externally.
A list of the basic UltraSoC modules is available here.
Which processors are supported?
We support many cores such as ARM Cortex (v7 and v8 ISA) and MIPS, along with Cadence (Tensilica) XTensa and CEVA Teaklite.
We are constantly expanding the range of processors we support as part of our roadmap of UltraDebug modules: for processors that are derivatives or variants of the above it is usually straightforward to develop new modules.
If you have a particular requirement or would like more details of what’s on the roadmap, please contact us.
Can you support a heterogeneous mix of IP blocks?
Yes. Indeed, this is one of the key strengths of UltraSoC. It is specifically architected to support complex SoCs that have lots of blocks, including many different blocks from different IP vendors. The architecture allows the system engineer to combine all of these into one coherent platform, with holistic visibility.
What kinds of on-chip structures can UltraSoC monitor?
We provide optimized support for the most common processor cores, including ARM, MIPS, CEVA and Cadence XTensa (Tensilica). We can also monitor bus and memory structures and custom logic: in fact, most common on-chip structures are supported.
A list of the basic building blocks of UltraSoC is available here.
What bus protocols are supported? How about custom protocols?
We support many, including: AXI, AXI-4, ACE and OCP3.0. Our approach is easily extended to proprietary packet-based protocols and buses.
Can UltraSoC support both licensed-in IP and in-house logic?
Absolutely. That is one of the core benefits of UltraSoC: we can support any mixture of complex blocks licensed-in, together with any amount of custom, in-house, logic.
We have optimized modules dedicated for the more sophisticated licensed blocks, and a very wide range of configurable/parametizable modules to support custom logic.
What 3rd-party IP do you support?
We have a very long list of blocks already supported and under development. You can see the list of our basic modules here.
Please contact us if you need to see an exhaustive list, find out what’s on our roadmap, or if you have a specific requirement.
Can you support software development?
Yes. We have support for a wide range of standard processors, DSPs and GPUs and where appropriate can integrate with the processor vendor’s debug infrastructure.
This gives full visibility of code, with all of the run-control, trace, breakpoints and cross-triggers that you would expect.
We can support Eclipse-based IDEs for system debug and analytics or integrate with a number of third-party tools.
However, there are two important points:
First, in respect of processors UltraDebug is multi-vendor and non-proprietary, so supports any heterogeneous mix of processors from different vendors. Combining an application processor from one vendor, GPU from another and DSP from a third can often be a challenge, with multiple different incompatible development systems, each operating in a silo. In contrast, UltraDebug is a single, coherent platform.
Secondly, UltraDebug was also designed for advanced symmetric multi-core systems, so it scales seamlessly to support the large clusters or arrays being designed at 16nm, 10nm and beyond.
Can you support standard development tools?
UltraSoC is supplied with an Eclipse-based IDE development framework. Eclipse can be readily extended with plug-ins.
However, we also enable third-party debug / development tool vendors to support our IP and are open to working with other IP vendors to interoperate with their IP and tools.
Please contact us if you have specific questions or requirements.
How do you support custom logic?
We have dedicated, optimized modules for the more sophisticated licensed blocks, and a very wide range of configurable/parameterized modules to support custom logic.
These can simply be probes, to report on status lines. Or there are more sophisticated blocks designed to monitor and support more complex sub-systems.
For example, UltraSoC can monitor a FIFO or buffer and report on over-flow, under-flow, and average fill level and temporal conditions.
There is also functionality to help debug state machines, with functionality to report on transitions, illegal states and the like.
In practice though, UltraSoC scales to monitor many thousands of signals; for custom circuits, a single entity can be configured to monitor several state-machines, control signals, inputs and buffers all at once.
Other blocks exist to support different sub-systems, and the generic components can easily be configured to suit almost any application.
How about hardware/software co-integration?
Because we can monitor all hardware and also processors, it is very straightforward to view hardware and software events time-correlated in one coherent environment. That is especially important in identifying the subtle problems that often occur from interactions between the two.
Is UltraSoC a standard block?
No. UltraSoC is a platform that the architect and designer can use in a variety of ways to best solve their problems.
There are over 30 different components, and the system architect is in complete control of which points they wish to monitor, and to which level of detail.
In addition to selecting which modules to use where, all of the blocks are parameterized and configurable at both design time and run-time.
What is the overhead?
Obviously, this is a critical aspect, and one we have worked very hard to optimize.
However, because UltraSoC is completely configurable, there is no easy answer to that. The level of analysis and performance is under the complete control of the architect, deciding which blocks to monitor and to what level of detail.
For example, a safety critical system or high-reliability (e.g. “five nines”) environment will typically choose to dedicate more die area than a cost-sensitive system: UltraSoC can support all of those with an appropriate level of performance. But in general, the overhead required is very small – of the order of a few percent of die area – and not material to the cost.
We would be happy to discuss the implications for your specific system in more detail, or to give worked examples.
How does UltraSoC compare to CoreSight?
UltraSoC can either be used to replace CoreSight, or can be used as a “wrapper”, interworking seamlessly with CoreSight and providing greatly enhanced functionality.
Our technology is fully interoperable with CoreSight, acting as an extension to support a more complex heterogeneous mix of IP from different vendors. It can join multiple ARM sub-systems together into one coherent debug framework across the whole SoC in a way that is increasingly impractical with CoreSight alone.
Or if you decide to replace CoreSight completely, UltraSoC will integrate directly with the processor or MP-group.
How does debug over USB work?
We have a unique on-chip hub that allows both “normal” system traffic and debug information to simultaneously share the same USB port. As such, you can simply plug a PC into the target system and both functions will operate at once.
This has three advantages:
First, it is much faster than JTAG or CoreSight SWD. Debugging over serial interfaces can be painfully slow; using USB can save a lot of time.
Second, in many systems the debug interface is not exposed in the production form. This allows developers to continue to debug systems in final form factor.
Finally, pins have a cost. By re-using existing pins, it eliminates the need for dedicated test pins, saving money.
What about security?
If desired, the USB debug functionality can be fully disabled (fused out) for production without impairing the system’s use of the USB port.
Alternatively, UltraDebug optionally integrates rich security features such as challenge response authentication, layered access and encryption.
What other types of interface do you support?
UltraSoC is fully message-based and has been designed to work with practically any interface including USB and Ethernet.
Ethernet is in development, based on a standalone IP component, enabling high performance and can enable independent run-control of CPUs and other system components. Such a component will have a comparable gate-count to a similarly specified Ethernet system IP.
Other system interfaces (PCIe, SATA, HDMI, CAN etc) are roadmap items. Please contact us to discuss your needs.
Can you support dedicated high-speed serial interfaces?
Yes. There is the option of a dedicated high-speed serial interface or alternatively the trace interface provided by the CPU vendor can be used: for example ARM’s HSSTP or MIPS PDTrace.
How does UltraSoC handle triggers?
UltraSoC replaces cross-triggers with real-time events. Real-time events are a lightweight high-priority communication that takes precedence over messages so that triggers can be conveyed efficiently even when the chip is so vast that point-to-point cross-trigger wires are impractical.
What about latency, given the latency of message passing?
Real-time events incur register delays at each hop, rather than at each cross-trigger hierarchy level. Across a large chip the hop delays are similar to those for a hierarchical cross-trigger matrix; however integration and place & route will be much easier.
Moreover, the faster message interfaces are clocked the faster events travel, so this approach scales with process, which is not a characteristic of a cross-trigger matrix that typically employs asynchronous communication that can in practice be slow given that wires now dominate delay.
How does UltraSoC support secure boot?
UltraSoC has a powerful layered security infrastructure that optionally restricts access to specific capabilities during secure boot.
UltraSoC otherwise needs to play no specific part in the secure boot process: it is fully compatible with your security architecture.
Can UltraSoC monitor resource contention at bus slaves?
UltraSoC’s bus monitor family supports both master and slave interfaces.
They are optionally able to monitor and filter on any bus field including the master and virtual master (thread) ID fields needed to segregate accesses from different masters, groups or virtual machines into a slave and AXI-4 QoS. This enables segregated performance monitoring so that the resources used, quality of service and contention can be understood. It is possible to detect specific patterns involving multiple bus fields and to capture data from specific transactions.
Does UltraSoC support systems with an MMU?
The bus monitor operates using the fields present on the bus and has no awareness of whether an address is virtual, intermediate or physical so can monitor any transactions. Its location within the system determines what type of address is observed.
Prior to an MMU, such as for systems where the MMU is not tightly-coupled with a CPU core, the address is virtual and corresponds to the software’s view of memory which is usually necessary for debugging that software.
Further away from the CPUs, such as at the memory controller, addressing is generally physical and that’s what a bus monitor located there would observe.
Monitoring close to the memory controller is generally to enable performance optimization rather than debugging. At that location distinguishing transactions by address is often less interesting than at their source or at the entry to a peripheral control bus. Although the bus monitor can be parameterized to filter by address at a slave, it is generally more important for performance monitoring to qualify transactions by their ID and other meta-fields, like QoS, in order to determine their source, than it is to qualify by address. Hence in some applications address filtering could be omitted to save gates. In contrast, where peripheral control is being performed, address filtering can be essential to debugging peripheral drivers and determining the address of transactions returning an error response.
Can error transactions be debugged?
The bus monitor’s address filtering and trace can both be used to determine the address of transactions returning an error response. Trace allows the address to be captured, which is useful for sporadic hard-to-recreate problems. Without the trace feature the filtering capability can still be used to find the problem, however an iterative approach is required.
How does UltraSoC handle cache coherency transactions?
UltraSoC’s bus monitors are able to monitor and qualify any field on the bus, so can be used to count and even capture appropriate coherency transactions just as they can also qualify by AXI-4 fields like ID and QoS.
What VIP is supplied?
UltraSoC is supplied with verification IP to drive and where appropriate monitor UltraSoC interfaces.
It is supplied as class-based System Verilog and can be used in SV UVM environments and Specman/e environments.
Legacy Verilog environments are supported using an adapter module.
What about Open CL?
There is nothing to prevent the bus monitor from viewing any transactions on the bus it observes, so can be used to observe traffic flowing to and from Open CL accelerators. The status monitor can be used to monitor any supplementary interfaces on the accelerator or embedded inside it to provide appropriate internal visibility.
Can UltraSoC replace trace encoder IP components such as an ETM?
In theory it is possible to replace the ETM for certain cores.
We are experienced in this space and have investigated higher performing trace encoders in order to lower the bandwidth needed and therefore reduce I/O usage when streaming or cut the size of on-chip buffers.
In practice though, replacing the trace encoder for a processor is becoming increasingly challenging, as although the trace encoder is separate for some older cores, the newer generations embed the encoder as an option within the processor core.
Hence we’ve not developed a product to replace the ETM for recent cores like ARM’s A57.
Can UltraSoC replace the CoreSight infrastructure?
UltraSoC is a sophisticated IP product that offers a range of capabilities for the whole system, including system-level debug. It can replace the CoreSight infrastructure, if that’s needed, and makes chip-scale integration of many ARM cores and other units much easier and with less congestion.
UltraDebug can also integrate with CoreSight, so it’s very flexible to work with new and upgrade designs.
What is the difference between JTAG IEEE1149.1 and UltraSoC?
IEEE 1149.1 is a standard for boundary scan-testing which can be used to perform functional testing of the chip via a Test Access Port (TAP) as part of a Design-for-Test (DfT) methodology that typically occurs in a dedicated test mode. In order to save adding further device pins the same scan interface can also be reused for the Design-for-Debug (DfD) methodology to provide a portal into the debug support components. For example, most MIPS processor cores contain a TAP enabling their debug support to be accessed via the IEEE 1149.1 interface, and ARM provides a Debug Access Port (DAP) component to convert from scan-based communication to memory transactions so that its CoreSight components can be accessed.
UltraSoC is interface agnostic, so although it can be accessed via IEEE 1149.1, it can also be accessed via system interfaces such as USB, PCIe, Ethernet and other dedicated serial debug interfaces such as IEEE1149.7 (CJTAG) and UltraSoC’s alternative to ARM’s SWD.
Can messages be time-stamped?
UltraSoC employs a dynamic time stamping design and various classes of message can be time-stamped in a bandwidth efficient way.
This approach allows debugging over huge time windows without a significant bandwidth penalty to the debug system when it is busy.
The timers are distributed and can be automatically synchronized at run-time so sub-systems can be reliably power cycled.
How do you ensure there is sufficient trace bandwidth?
The bandwidth within the UltraSoC infrastructure is scalable. The approach we recommend is to consider some standard use cases of the high-bandwidth sources, usually processor trace units and other items like bus trace. It is generally impractical to trace certain high-bandwidth sources continuously in real-time, such as an AXI bus with 256b data at 1GHz. In that case it’s more appropriate to set a more modest amount of bandwidth in certain places and consider the filtering and local buffering resources needed.
It is generally impossible to know exactly how much bandwidth you need and in practice the only thing you can reliably predict is that someone will ask for more information than the infrastructure can deliver, because you cannot have huge bandwidth everywhere or for very long.
We have considered this, which is why UltraSoC not only offers flexible and powerful filtering to reduce the data/information collected, it also includes a flow-management system enabling the debug platform to manage its message traffic dynamically. That way the important information can take precedence where appropriate.
Is there a security system?
Yes, UltraSoC has several parts to its security system. An access controller that interfaces with a key-store/ROM provides authentication and generates session keys. A security layer at the debugger interfaces to direct authentication messages to the access controller; restrict access; and optionally provide encryption. There are also locks distributed throughout the system controlled privately by the access controller in order to enable layered security rights.
The design is modular and licensees can replace the access controller with an adapter that interfaces to their own security system or ARM’s TrustZone.
How does UltraSoC affect power consumption?
Power consumption varies based on the system chosen, the way it’s used and physical implementation.
The components have optional fine-grained dynamic clock gating to lower dynamic power significantly when components or specific features are not in use. This enables UltraSoC monitors to be co-located with the system components they observe and used as part of the final product. UltraSoC can be disabled or powered off in part or as a whole as it supports multiple power and clock domains.
Does UltraSoC support different power domains?
Yes. UltraSoC supports different power domains. It will also maintain state and automatically resynchronize between regions as they are power cycled.
Does UltraSoC support multiple clock domains?
Yes. UltraSoC was specifically designed for modern, complex SoCs with multiple domains and complex sub-systems.
The message protocols and time synchronization methods of UltraSoC are designed to go across large chips (without being hard to place & route) and to maintain time coherence, even when systems use multiple clock domains.
Are development tools available?
UltraSoC is supported by various software tools. There is an Eclipse-based GUI called UltraDevelop that enables run-time configuration of the debug system and display of results. It allows users to debug and monitor performance using UltraSoC via a range of interfaces including USB and JTAG using one of several third-party probes. There is also emerging support by third-parties within their own software environments.
In addition to the UltraDevelop GUI there are also several options for scripting.
Is UltraSoC difficult to program and use?
UltraSoC is versatile and configurable (both at design time and at run time). That is a lot of necessary flexibility for experienced users, but can be daunting. UltraDevelop supports what we call “tasks”. These are simplified configuration dialogs within the GUI that can be used to hide unneeded fields or group them from several components for ease of use. Tasks are user creatable plain-text files that can be added at run-time to create customized configuration dialogs to help with the ‘task’ in-hand. They can be used by power-users to enable less experienced users to perform specific activities.
Scripts can also be used to automate complicated activities.
Can UltraSoC be driven by on-chip firmware and is there a software API?
Yes. UltraSoC is designed to be programmed by on-chip firmware as well as by off-chip software tools, potentially at the same time. There is also a layered API with auto-generated libraries available for a variety of languages.
Can UltraSoC be used for automotive SoCs?
Yes. Indeed, automotive was one of the key areas the drove the development of UltraSoC.
One of our advisory board is Professor Stuart Jobbings, who was head of development at Delphi.
How do you support the verification process?
We are using constraint random testing for our blocks with standard UVM. For each block we have a verification plan which lists the functional coverage bins to be developed.
When a block gets frozen, we stress test it, running tests for many days and gather functional and code coverage, which gets reviewed. All tests in this run must pass. Target is 100% for code, branch, condition, FSM and functional coverage using excludes (which are reviewed too). Functional coverage might contain coverpoints which are a cross of many elements to indicate any unexpected bias in our tests.
Nightly regressions are run for all blocks to ensure stability.
What integration support do you provide?
For integration testing we supply a verification suite containing the modules a customer wants to use in his system plus basic tests which the customer can use a s a template for more complicated ones.
New blocks also implement assertions to catch misbehavior at the interfaces or UVM monitors which the implementer can reuse in their system testbenches to check for protocol issues.
Can UltraSoC be used with FPGA implementations?
Yes. Indeed, our demo system is implemented in FPGA (Xilinx ZYNQ) and we have customers using us for FPGA in both prototyping and production systems.
Is there a real-time visualization function?
Yes. There are a number of real time visualization modes, and others are under development.
Does the USB function require a hub or its own PHY?
No. The USB functionality is completely transparent and is designed to utilize an existing functional block within the SoC: it integrates in and does not affect the existing system. It does not require support from the processor in the embedded system or affect performance at all.
Can UltraSoC send signals or messages into the chip?
Yes, it is possible to send signals for control or configuration.
As regards probes and monitors: most often this will be things like asserting HALT or RUN instructions to control a processor. For example, cross-triggering from another element to stop the processor.
But it is possible to be more active. For example, we have a pilot study with one customer on inserting bus errors to simulate soft errors and radiation effects; and another customer is investigating this for testing robustness.
This would be a (deliberate) exception to the concept that UltraSoC is non-intrusive and invisible to the operation of the system.
We also have a class of components we call communicators: these are expressly intended as two-way communications systems.
For example, we can deliberately DMA data into memory, for example to store larger quantities of debug information. Or for the bidirectional communications links such as USB.
Similarly, we have a GPIO block. We can also drive JTAG as well as receive / understand it.
Finally, these can be used to link to a host processor (for example AXI) such that this can be used to configure, drive and receive debug information. This is how debug in the field (in-life, post release) can be implemented.
Importantly, however, this functionality is under security control.
Does the tapping of the bus monitor affect bus speed / performance?
No, it doesn’t. The bus monitor is non-intrusive (other than a slight increase in capacitance from an extra contact). We have invested a lot of time and effort in design and verification to be confident about this.
Is the ‘serial interface’ a special interface?
We currently support JTAG and USB serial interfaces. In both cases, the electric connection is standard but, of course, the information flow is in our format (our XML messages).
We are developing other interfaces, including cJTAG and a scalable serial port similar to ARM’s SWD.