The added features allow SoC architects, developers and debug engineers to detect and diagnose hard-to-find corner cases which can cause complex SoCs to “hang” or stall intermittently and unpredictably, sometimes after days of continuous normal operation.
“Our customers tell us that intermittent deadlock and stall conditions are amongst the hardest problems to solve in their SoC designs,” said Gadge Panesar, UltraSoC CTO. “These conditions are a major contributor to the current crisis in the SoC industry. Conventional approaches either ignore the problem, or attempt to deal with it by generating massive, unmanageable data sets. UltraSoC takes a smarter approach, focusing on generating meaningful, actionable information; for the first time chip design teams can truly understand the behaviour of today’s complex SoCs.”
UltraSoC technology allows chip designers to efficiently and intelligently “look inside” their products, at wire speed, during normal operation. The new deadlock detection capabilities are targeted at particularly difficult conditions that can cause devices to fail intermittently and unpredictably, including bus and software deadlocks.
Bus deadlocks occur when a processor is waiting for a response from another sub-system via an on-chip bus such as AXI or OCP, but the response never arrives. Traditionally, the only way of isolating such problems has been to attempt to continuously trace and output all bus activity, requiring a high-bandwidth off-chip connection to gather the data, and difficult offline analysis software of huge data-sets. The UltraSoC solution uses a “smart” on-chip bus monitor that is protocol-aware and can be triggered when the time taken for a bus transaction exceeds a programmable limit. When triggered by a deadlocked transaction, the system identifies the complete transaction ID and address, guiding the engineer’s attention to both the master and slave of the problem.
Software deadlocks are increasingly common in today’s SoCs. In a typical scenario, two different software processes might use a locking mechanism to govern shared access to common on-chip resources: for example another core, hardware