EDA start-up puts 'design for debug' in the lexicon

SoC debug is an animal of many aspects. At systems and RT levels, simulation tools give nearly unlimited access to signals. But as the design moves from simulation to FPGA prototyping, that easy access starts to erode. On the FPGA board, and later on the bring-up board with the real silicon, it’s up to the design team to anticipate which signals they will need to see, to access those signals, trigger on them, and capture their waveforms.

On Monday (Nov. 1) Veridae Systems Inc., a start-up based in Vancouver, British Columbia, announced a tool to bring automation and a single user interface to this tangled problem. Clarus, a suite of analysis tools teamed with an IP generator, is designed to help identify the critical signals for debug, instrument them with what is in effect a distributed on-chip logic analyzer, extract the data from the FPGA or silicon prototype, and interpret the results. Because it embeds code in your RTL rather than modifying the netlist post-synthesis, the observation hardware becomes part of your design, so Clarus gives you the same visibility and triggering in either an FPGA prototype or your SoC silicon. Critically, the suite also addresses security. In recent years debug ports have become a major portal for attacks on systems. So Clarus provides an access controller to block attempted intrusions through the debug interface.

The on-chip debug concept is not new. Several significant patents are published, and several vendors, including for example Asset-Intertech, are long-standing providers of on-chip instrumentation IP. Further, many established SoC design teams have libraries and best-practices documents for instrumenting their designs—especially for high-performance mixed-signal blocks. But in comparison to these offerings, Veridae appears to have assembled an unusually complete end-to-end suite of instrumentation IP, design tools and analysis tools for digital blocks.

Clarus comprises four major modules. The first, Clarus Implementer, is an interactive tool that analyzes your RTL design and proposes a prioritized list of signals that you will want to observe. You then get to select a level of observability—debug coverage, if you will—and corresponding silicon overhead. Implementer then inserts into your RTL the necessary capture and infrastructure code. Clarus only provides observability—it does nothing to enhance controllability of state on the chip.

Along with modifying your RTL, Implementer generates scripts for Synopsys Formality to verify the functional equivalence of your design pre- and post-insertion. It also produces a test bench so you can verify correct operation of the new debug structures themselves.


The second Clarus module is the RTL IP generated by Implementer. This is of three kinds. At the lowest level are Capture Stations: 2-3 k-gate blocks that collect signals synchronously to the local clock, generate time stamps, and forward the data to a central resource—the second kind of RTL block--called a router. The Capture Stations are intended to be placed close to the signals they are collecting. They gather data through what Veridae calls an Observation Network. Company CTO Brad Quinton said the Observation Network was designed both to minimize loading—since many of the nets you most care about will have critical timing—and to minimize added congestion in the area of the nets.

Once the Capture Station has collected the data, it passes the data stream through a four-phase resynchronizer, back into the clock domain of the router. The router aggregates the data coming from the Capture Stations, and aligns it based on the time stamps and measured skew information, Quinton explained. This block apparently is also involved in lossless data compression to reduce the volume of data that has to leave the prototype. The router transmits the data through an AMBA APB  interface to the SoCs CPU, or directly to a JTAG port.