Universal debug system promises to avoid nightmares of SoC debug

This increase in complexity will be accompanied by an exponential increase in the cost of actually getting them to work. According to start up UltraSoC Technologies chief executive, Dr Karl Heeks, the solution is not software based; instead, he sees the need for pieces of silicon IP to be integrated in the design. These pieces of IP will allow the software running on the SoC to be debugged. UltraSoC was founded in 2006, based on research conducted at the Universities of Kent and Essex. For a while, the company existed within the universities, but got its first money in 2009, which allowed it to open an office in Cambridge and to start hiring. "Since then," said Dr Heeks, "we have raised another £4.5million from Octopus." He says the investment in UltraSoC is a different kind than would be needed by a semiconductor company. "They need huge amounts of cash," he pointed out, "we'll probably need less than £10m." So what might that £10m investment result in? Something which allows for universal debug. "There's a requirement for this kind of functionality," Dr Heeks noted. "Demand is being driven by SoC complexity and by more IP from different vendors; what's needed is an independent solution – and that's what we're developing." The solution, called UltraDebug, is a response to what Dr Heeks calls a 'debug nightmare'. The reason is SoC complexity. "The big SoC vendors are looking for one piece of silicon that connects to all IP," he continued. "The nearest to that at the moment is ARM's CoreSight, but our approach is more advanced. It can plug into any IP at the system level, rather than the developer having to debug their SoC in a piecemeal fashion. Because designs are becoming so complex, the piecemeal approach is becoming unsustainable." UltraDebug provides a system level capability to detect software and hardware bugs in such elements as graphics cores and custom accelerators, as well as allowing optimisation of memory interfaces and system fabrics. He explained the current situation. "SoCs have a number of processors and each processor has its own – and different – debug support, probe and debugger. Meanwhile, some IP elements, such as a memory controller or custom modules, may have no debug at all. "We have been talking with SoC vendors for some time about this, because there is a crisis in debug. UltraDebug isn't a solution to a problem about which they know little." He said that integrating debug support on chip for each piece of IP is not feasible; it requires additional engineering time, takes up more silicon area and consumes valuable I/O. The better approach, he contends, is something which supports any vendor's IP. "This enables more reuse, speeds time to market, reduces silicon area and takes up fewer I/O pins. It also brings better quality assurance, better performance and more reliability in the market." Dr Heeks positions UltraDebug as a generic and flexible platform that scales with system complexity. The approach is applicable to IP from any vendor, as well as with any processor architecture, so it imposes no constraints on the IP which is used. "It's universal debug and it's distributed debug," he added. The fundamental requirement for a product such as UltraDebug is the ability to deal with complexity. "This is where the piecemeal approach falls down," Dr Heeks observed. "You can get contention between blocks looking at the same area in memory, for example. Our system level approach is suited to handle complexity." UltraDebug comprises three elements: modules; a message engine; and communicators (see fig 1). "It's a holistic, connected system where high and low level observations can be combined," Dr Heeks explained. "It's hierarchic, with simplified internal interconnects to ease integration issues and reduce routing congestion." UltraDebug is message based. Modules address individual IP blocks and route data back to the message engine. Following some processing, data is fed through the communicators, which could be Jtag, USB or serial trace ports. "Integration of our modules to IP blocks is not too problematic," Dr Heeks claimed. "We obviously need to be able to see an interface and, providing we have that access, integration is relatively straightforward. "The message engine then looks at the data fed back from the modules and, through a filtering process, determines which areas are problematic. Finally, the conclusions are output via the communicators. It allows users to quickly see where the difficulties are or may be." While still a technology in its early days, UltraDebug has already been used 'in anger' by PMC-Sierra, which is working with UltraSoC as part of its development programme. "PMC needed a way to solve a customer's debug problem," Dr Heeks explained. "It had a couple of choices: do it in house or use a third party. It saw our technology overlapped with what was needed." Salman Ghufran, vp of product development for PMC's enterprise storage division, said: "Analysing complex hardware and software interactions in high end SoCs requires insight into what is happening through the entire device. PMC partnered with UltraSoC because we recognised its monitoring and debug infrastructure would give us the visibility we needed to enhance our device operation and accelerate time to market for our customers." Beyond SoC debug, Dr Heeks sees UltraDebug as being useful in providing consistent visibility across simulators, emulators and fpga prototypes. Not only does he see the approach being applicable to system integration, he thinks there are opportunities in system bring up, software development and system optimisation. "Achieving performance objectives is an essential part of the development process," he noted. Memory interface efficiency is one area on which UltraSoC has its eyes and Dr Heeks sees issues with bottlenecks. "Because UltraDebug is looking at the whole chip, it can help to optimise the design and highlight where the bottlenecks are." When processor cores compete for memory, the data flow is degraded (see fig 2). Without optimisation, adding more cores will further degrade performance. UltraDebug allows internal and external interface efficiency to be measured and the impacts of software enhancements, cache configurations and data prioritisation schemes understood. But there's another potential application, said Dr Heeks. "Debug has usually been applied before the product goes to market and that's that. Because UltraDebug is on chip, it could be used for other types of monitoring; for example, product recalls. We are seeing interest from potential customers in the use of this in the field. "We have always felt that UltraDebug would be a powerful architecture that could be used for many things. But we don't want to be unfocused; software debug is the nut which needs to be cracked at the moment," he concluded.