Embedded FPGA IP as a Post-Silicon Debugger

The hardware functionality of a complex SoC is difficult to verify. Embedded software developed for a complex, multi-core SoC is extremely difficult to verify. An RTOS may need to be ported and validated. Application software needs to be developed, and optimized for performance. Sophisticated methodologies are employed to assess pre-tapeout functional verification coverage — yet, there will still potentially be defect escapes. During silicon bring-up, visibility into the SoC runtime behavior is required, to analyze the interface communications between SoC cores — the need for this signal visibility extends to diagnosis of errors in production hardware in the field, as well. To address this requirement, SoC’s often have added a debug busand a trace bus to the microarchitecture.

In this context, the connections to the debug bus consist of a debugger unit responsible for obtaining basic runtime control and evaluating/updating the state of the SoC, using a limited set of various IP core signals with some degree of observability and controllability to each core’s internal execution state.

The trace bus connections are defined to provide passive capture of key signal behavior during SoC execution, based upon a triggering event, say perhaps, an RTL assertion synthesized into logic. Ideally, tracing allows the defect corner case that escaped pre-silicon functional verification to be captured and analyzed. In perhaps the most direct implementation, the embedded software could itself be written to invoke a trace routine to write out values of specific control/data signals — yet, this may provide insufficient detail, and requires the application and RTOS software developers to add this feature to their coding tasks. And, this form of core-driven trace will be unlikely to capture interactions between cores — e.g., a data coherency issue between local core caches and shared system memory.

The overhead of implementing an SoC debug bus and trace bus of sufficient scope may be problematic, in terms of design time, validation complexity, and (potentially) additional IP licensing costs — instead, many designs need a low-impact path to implementing SoC debug and trace features.

I was recently chatting about this debug/trace requirement with Valy Ossman and Tony Kozaczuk at Flex Logix. The discussion was an enlightening one, to be sure. Valy said,“Our eFPGA tiles (and array of tiles) are implemented to provide a very large number of input/output signals. For example, the EFLX-2.5K tile offers 632 inputs and 632 outputs.(2,520 LUT’s in this tile)A maximal 7X7 array of EFLX-2.5 tiles(123K LUT’s)supports 4,424 inputs and 4,424 outputs. For many customer applications, there will likely be additional eFPGA signal pin and LUT logic resources available.”

Tony added, “We would encourage SoC designers to consider adding debug and trace features as a secondary application, to merge with the primary application for which the eFPGA IP is being integrated.”

A representative block diagram of an SoC include an eFPGA block with debug features is depicted below.

“Doesn’t the debug and trace capabilities require judicious floorplanning and signal route distribution to an eFPGA block on the SoC?”, I inquired.

Valy replied, “Yes, but it’s a simpler design task than developing a specific debug unit with the related debug bus and trace bus implementations. The high connectivity available with the eFPGA means designers are not as constrained in signal selection. A huge benefit is that the debug and trace logic is re-programmable. For example, triggering events for tracing are no longer based on a fixed logic design, but could adapt as needed during silicon bring-up, by updating the eFPGA configuration.”

“Speaking of tracing, what about the corresponding memory storage?”, I asked.

Valy explained,“There are several options available. The eFLEX tile arrays are designed to tightly integrate small memory arrays.” (see the example below)

“SoC memory outside the eFPGA IP could also be used. Perhaps the most straightforward implementation would be to utilize external memory — the rich multiplexing capabilities of the eFPGA could be used to direct the trace data through a limited number of SoC I/O’s.”, Valy continued. (See the figure below, which illustrates a smaller EFLX-100 block serving as the debug unit and providing the multiplexing of trace data out a small set of general-purpose I/O’s.)

I had not previously considered how to leverage signal connectivity and LUT resources that may be available for asecondary application within an eFPGA block (or multiple eFPGA blocks) on an SoC. The integration of debug and trace features is an excellent idea.

Valy has written an application note, illustrating the use of eFPGA resources as part of a debug/trace strategy — that app note is available here.

-chipguy