草榴社区

Optimizing Debugging with HAPS ProtoCompiler Instrumentation

Deep Trace Debug is enabled for the user’s design on the HAPS system using HAPS ProtoCompiler. HAPS ProtoCompiler prototyping software is tailor made for HAPS systems, providing prototypers with an integrated prototyping solution. HAPS DTD scales with HAPS system capacity, which ranges from a single FPGA to 64 FPGAs using 16 HAPS-80 systems, approximately 1.6 billion ASIC gates. HAPS ProtoCompiler’s hardware awareness allows for the automation of many tedious and error prone bring-up tasks such as gated clock conversion, partitioning and the insertion of the required interconnect and time domain multiplex communication logic. Moreover, the tool automates the instrumentation of the user’s design for debug and connecting the debug logic to the HAPS system’s hardware infrastructure such as connectors, memories and debug interfaces.

This is especially important when the design is partitioned over multiple FPGAs and has multiple clock domains as it imposes additional demands on the trigger and sampling logic for tracing. With manual flows and non-integrated prototyping these are major obstacles as they are hard to deal with. Often, the required effort prevents prototypers from investing in debugging as they are primarily focused on getting the FPGA bit files in place. However, frustration and many lengthy prototype bring-up iterations typically remind prototypers of how expensive not having debug can be, as it is not easy to bring back debug into the prototype when using a manual flow. Every change to the design, as well as additional debug instrumentation logic may impact the partitioning with a whole ripple effect on redesigning the communication and interconnect. Through the automation in HAPS ProtoCompiler, the preparation of a HAPS system for debug almost comes at no cost in terms of enablement effort except for the manual steps to tailor the debug visibility to meet the user’s needs for a given design and use case. This is accomplished using the HAPS ProtoCompiler Instrumentor and will be explained later in this article.

For DTD, performance, signal capacity and tracing depth are parameters which the prototype can adjust to find the optimal trade-off for the targeted debugging task. For interface IP prototypers, performance may be of highest importance due to the real-time requirements of the analog interfaces. For SoC prototypers, it may be much more important to capture a large amount of signals (e.g. the interconnect) over a long scenario, but with less strict requirements on performance.

This flexibility is typically not possible with “traditional” FPGA Block RAM (BRAM) based tracing. Here, the tracing depth is strictly limited by the available BRAM and BRAM for debug now even competes with the BRAM required for the design. Therefore, next to BRAM based tracing, HAPS DTD allows tracing into external DDR3 memory banks. This doesn’t take away any memory from the design and with 16GB of DDR3 storage for sampling data, the prototype can be very generous in terms of defining the signals scope for sampling. With DTD, the prototyper can choose to sample up to 2000 signals per FPGA at 20Mhz, or 250 signals per FPGA can be traced at 160MHz in case performance is more important than signal breadth (e.g. interface IP).

As a frontend to the whole DTD flow, the prototyper uses the HAPS ProtoCompiler Instrumentor. Here, the prototype tailors the visibility breadth and depth to the needs of the user persona. As a first step, an IICE (intelligent in-circuit emulator) is instantiated. The IICE will later serve as the communication and control interface between the HAPS ProtoCompiler Debugger on the host and the instrumented design on HAPS. An IICE is associated to a clock domain in the design. If multiple clock domains need to be traced, multiple IICEs can be inserted. Furthermore, per IICE the prototyper choses the sampling memory (BRAM, DDR on board, DDR on debug hub). Now, the instrumentation can be conducted. A key value of the HAPS ProtoCompiler instrumentation flow is the ability to define signals for sampling in the original RTL code.

Instead of trying to find signals back in generated files such as EDIF (Electronic Data Interchange Format) with generated signal names, the instrumentation is conducted in the original VHDL or Verilog implementation. In this implementation, the user can define breakpoints to be used as sampling triggers. Breakpoints allow for very complex trigger conditions at a small cost in area. Another type of trigger is a watchpoint. Here the instrumentation logic is associated with an RTL node or signal. Within the IICE the prototype also defines the complexity of the trigger logic. HAPS ProtoCompiler allows for complex state machine based triggers with multiple conditions. This is very beneficial to pin-point tracing to scenarios of interest by only starting the trace after e.g. specific registers have been written in a specific sequence with specific values. An example for this is when a peripheral shall be traced after being configured by the software (e.g. 1. reset has been applied, 2. control register enable bit has been written, 3. interrupts have been enabled). All triggers can be pre-armed so that a software developer would not even need to interfere with the HAPS ProtoCompiler RTL Debugger. Furthermore, it shall be mentioned that HAPS ProtoCompiler allows for post compile instrumentation which is crucial as RTL may not be always usable for instrumentation. As an example, the VHDL/Verilog code may contain a for-loop and only in the fully elaborated circuit the user can then select the signals within a schematic view. All the steps for instrumentation are fully scriptable, as also all other phases in the prototyping flow are with HAPS ProtoCompiler.