Debugging and Other Auxiliary Tools

Most tools and methodologies described in previous sections are related more with the design of FPGA-based systems than with their validation, with the exception of simulation tools. Simulation is an essential part of the whole development process of FPGA-based systems (actually of any electronic system). There are other features that, not being strictly required such as simulations, are very useful to identify design problems, particu- larly in the case of complex systems. These optional tools for hardware and software debugging are described in Section 6.6.1. Other auxiliary tools that facilitate the design of FPGA systems, such as pin planners or power estima- tors, are addressed in Section 6.6.2. 

Hardware/Software Debugging for SoPC Systems

The complexity of SoPCs makes it necessary to have tools available not only for software debugging (like in any other microprocessor system) but also for verifying the interaction between the software and hardware parts. Actions taken by the programs running in the processor cores have an impact on the hardware, which is not always easy to follow and verify just with the aid of external signals. Interfaces between elements may not be exercised properly, making it difficult to check whether or not the operation of the system will be correct in all scenarios. 

When problems arise, it may be extremely difficult to tell if they come from an inconsistent software design, an incorrect interfacing, or any other reasons. For “small” designs, where there are enough pins left in the FPGA, debugging actions may be performed by taking outside of the chip critical signals that pro- vide indications of correct or incorrect behavior of the system. However, this method is usually difficult to implement and is error prone since it requires navigating through the system hierarchy of modules so that the target signals can be identified and taken out from (possibly deeply) embedded blocks. On the other hand, it may be not possible to correctly transfer fast- switching internal signals outside of the device, for instance, because of sig- nal integrity problems or because available pins cannot achieve the same switching speed. 

Finally, tracing and fixing potential problems in a conventional manner might require the design to be modified a high number of times, which implies the need to repeatedly run the time-consuming synthesis process; whereas trying to identify potential problems beforehand and having embedded instruments selecting and analyzing the signals of interest at runtime would help in reducing the number of synthesis processes required for a successful design to be completed. 

Therefore, it is very interesting to have specific debugging tools targeting SoPC systems, allowing instrumentation to be embedded inside the devices, so that internal signals can be directly monitored in place. Fortunately, it is currently possible to have very powerful embedded instrumentation imple- mented inside FPGAs, whose features are in some cases comparable to those of conventional instruments, such as logic analyzers, and which are capable of combining software and hardware debugging. 

It is important to clarify that, since many SoPC systems may have real- time constraints, the addition of debugging resources should neither have any impact on execution time nor use resources that would be required for normal system operation. The main debug mechanism to access resources inside the FPGA in a nonintrusive way is the use of the JTAG interface, which is not typically used during normal operation of the device. Remote debug- ging may also be possible by means of a TCP/IP connection to the system, for instance, when an OS is used. 

Software Debugging 

The main tasks involved in software debugging are the inspection of the con- tents of memories and register banks, and execution control, which relies on step-by-step execution, breakpoints, and watchpoints. For embedded hard processors, the logic resources required to provide such features are embed- ded into the logic, so there is no need to specify them as part of the design. In soft processors, where it may be necessary to specify their inclusion, inte- grated design tools provide mechanisms to attach the required embedded logic to the processor core. 

Software debugging is performed from the software development envi- ronment, where it is seamlessly integrated. For instance, breakpoints and watchpoints can be directly inserted in the source code (or, rarely, in the assembly code). There are no significant differences with respect to conven- tional software debuggers, one of them being the potential need for con- trolling more than one processor execution at a time, given the fact that the system may include several processor cores. In this case, a breakpoint or watchpoint may be used to stop execution in just the processor where they are inserted or in all of them. More advanced synchronization techniques are also available, but they require the insertion of additional logic, as dis- cussed in Section 6.6.1.2. 

The way breakpoints operate on the underlying hardware is by continu- ously comparing the contents of the program counter with the address in the instruction memory where the breakpoint is placed. This can also be done by checking the address bus in the instruction memory. Access must be gained in the bus between the processor and the cache memories. Otherwise, if comparisons are done close to the program memory itself, instruction cache must be stopped to avoid hit accesses not observable in the outer bus. 

Watchpoints are similar to breakpoints, except that they check for data memory instead of instruction memory addresses. Thus, the same consid- erations apply to data caches and watchpoints as to instruction caches and breakpoints. In some cases, the condition to stop execution is based on a specific value being read from or written to a data memory position. In such cases, a second comparator is required in the data bus of the data memory, in addition to the one checking addresses. 

Performance monitors are also commonly available, providing a method to measure execution time, bus utilization, and so on. They allow profiling execution of software in the real system, with the aim of optimizing resource utilization. 

Hardware Debugging

Hardware debugging is not as specific as software debugging. Its features are related to the ability to observe internal signal activity in the hard- ware by means of generic, but configurable, embedded instrumentation. These instruments internal FPGA resources, so their use can be a problem in systems with high resource utilization. In particular, in order to be able to acquire the activity of signals at their nominal speeds, internal memory resources (usually relatively scarce) may be necessary to store the corre- sponding traces, so special care must be taken when specifying the amount of memory reserved for such task. 

Before synthesis, the tools allow users to specify the signals to be moni- tored after the system is designed and implemented in the FPGA. These sig- nals are kept in the design-along stages, preventing them from disappearing due to circuit optimizations during the design process. This is automatically accomplished by the tools, either by making simple modifications at netlist level or by including an MUX to select signals at runtime, so that they are connected to the embedded instrumentation for analysis and/or storage. The second option is more flexible, but could incur higher resource utilization overhead as well as some speed degradation, which could be neglected if operating frequency is not a critical design constraint. 

Different FPGA vendors offer similar embedded debugging instrumenta- tion, which in essence is also similar to the functionality provided by conven- tional logic analyzers, mainly based on the acquisition of a group of signals, synchronized by events in a sampling signal, and triggered by the occur- rence of some events or combination of events in a signal or set of signals. The sampling signal determines at which moments of the execution the observed signals are to be acquired. It may be any clock signal in the design, but it is not the only solution. For instance, if transactions in a communica- tions link are to be analyzed, once it is known that their timing behavior is correct, any data validation signal (data strobe, an acknowledgment sig- nal, an enable signal in an input data register, or similar) may be used as sampling signal. In this way, only actual transactions are registered, sav- ing a lot of acquisition memory or, in other words, allowing for longer data acquisitions. In these cases, time stamps can be registered together with the acquired data in order to determine the instants when data transactions actually occurred. 

Since in most cases acquisition has to be carried out under nonrepetitive conditions, specific events in trigger signals cause acquisition to start. These may be: 

• Simple trigger events: value of a given signal (or combination of values of a group of them), edges in certain signals, or similar. 

• Advanced trigger events: for instance, a trigger may be controlled by a counter, which activates it after a given number of occurrences of a simple trigger event. 

• Cascaded or interconnected trigger events: sophisticated trigger conditions can be specified by different combinations of simple trigger events. 

The effective moment to react to the trigger event (whatever its complexity is) can be configured to be the exact one at which the event is produced or a given number of sampling periods before or after its occurrence. For data acquisition to effectively occur before a trigger event is produced, data sam- pling needs to be active at all times. Acquired data are stored in a memory that operates as a circular buffer. When the memory is completely full after the trigger, acquisition is stopped. 

Virtually any signal or group of signals (buses, internal control signals, or elements that are not accessible through read-back operations from any memory map) can be monitored and the corresponding data stored in memory for debugging purposes under the occurrence of any trigger event. Since the sampling signal can be specifically generated for that purpose, sampling speed is in principle only bounded by the limits of the technology. Debugging tools allow results to be visualized in several different ways: 

• The most usual one is equivalent to the visualization of simulated waveforms, with similar interfaces and analysis tools. 

• Signals can be shown as monitoring windows, virtual LEDs, or the like. Virtual LEDs can also be used to virtually represent outputs, which is useful when the FPGA board being used has not enough visualization capabilities for the target application. 

• Similarly, inputs can also be made virtual, using virtual switches to set the values of internal signals or registers, without having them physically available in the FPGA board. 

Hardware/Software Co-Debugging 

Both hardware and software debugging can be combined, mainly to verify interaction between both parts of the SoPC. For instance, a breakpoint may be used to trigger the acquisition of an embedded logic analyzer, or a trigger con- dition may be used to stop the execution of a program running in a processor core. With this feature, it is relatively simple, for instance, to set interrupt condi- tions as triggers or to verify whether interrupts are occurring when required. 

Auxiliary Tools

Pin Planning Tools 

Modern FPGAs have a huge amount of pins, and the selection of the most suitable ones to ensure the proper operation of the whole circuit the FPGA takes part in may not be a simple task. Some pin locations are preassigned for specific signals (e.g., clock signals) or specific types of signals (e.g., DRAM memory interfaces, PCIe connections, other communication transceivers, or, in general, any signal with specific timing or speed restrictions, requiring a preassigned position close to the embedded hard blocks that use or gener- ate them). In addition, some I/O configuration possibilities require specific supply voltages in auxiliary supply pins, which may be incompatible with other I/O standards. Finally, there are also restrictions associated with noise immunity, especially for low-voltage signals, as well as some requirements that limit the number of simultaneously changing signals in order to avoid voltage drops due to excessive switching activity. 

I/O pins are organized into different banks, each one with its own power and auxiliary voltage supplies (which allow, for instance, unused banks to be turned off to reduce overall power consumption). Some of the aforemen- tioned restrictions affect each bank separately. 

Since handling all these restrictions may be not a trivial task, design envi- ronments include pin planning tools. They allow signals to be assigned to pins either “manually” or from the placement restrictions file discussed in Sections 6.2.1 and 6.2.3.3 and, later, the fulfillment of the restrictions to be verified, flagging warnings, incompatibilities, or errors* that might force the pinout of the design to be changed. For instance, pin planning tools advise on the need for having differential signals close to each other to avoid noise, or even for using prespecified pin pairs for them. As another example, LVDS signals cannot have nearby signals with high switching activity, and it is recommended that they are placed near to or even surrounded by pins set to ground for noise protection. All signals in a bus are preferably (if possible) spread out through the same FPGA bank, or even split into two banks, for signal integrity reasons. 

Once the pinout of the FPGA design is decided, pin planning tools should be run in order to allow the PCB design to be performed in parallel with the FPGA design. 

FPGA Selection Advisory Tools

In many cases, there is no specific requirement guiding the decision about which FPGA to use in a particular application, apart from the needs for enough resources and achievable speed. Since most FPGAs are available in different speed grades, the speed issue can be addressed once the maximum operating frequency posed by the design is known. 

FPGA selection advisory tools provide a means of choosing the adequate FPGA that fits the design needs. They may operate from area estimations after synthesis or through specific analyses. If there is uncertainty about the final contents and functionality of the design, it is advisable to select a range of devices from a family of pin-compatible FPGAs so that, after detailed design, the right device may be selected among a set of them, in order for the cost to be reduced. 

Power Estimation Tools 

Power estimation is useful during design space exploration in order for the most appropriate design among several implementation possibilities to be selected and for the maximum currents to be supplied by the power convert- ers to be determined, in order to advance PCB design. In the first case, abso- lute power consumption values are not so important since relative power consumption among different approaches is the factor that may influence the selection. In the second case, only rough estimates are required since some security coefficient will be applied resulting in an increase in the cur- rent the power converters would be able to supply, or the use of heat dissipa- tion techniques, and so on. 

These are the reasons why power estimators are just aimed at supporting decisions during the early stages of the development of the circuit, rather than at providing a mechanism to accurately estimate the actual power that will be consumed by a circuit once it is implemented. As a consequence, some early power estimations just rely on the expected amount of I/Os and resources to be used, affected by an activity factor, which is the expected switching frequency of every signal (referring not to clock frequency but to the expected activity of each particular signal). At later stages, some more sophisticated power estimators may use simulation results to estimate activ- ity, but it is worth noting that they are prone to offer values higher than real ones since simulations try to “compress” the whole behavior of the system into the minimum possible number of clock cycles in order for simulation time to be reduced.