Today’s process is a ”trial-and-error” debugging method that requires a more active debug approach that can perform dynamic “cuts and jumps” to find the issue faster. For instance, hardware can force an interrupt at run time to cause the software to enter a debugging state which will examine current status; then the hardware can disable IP blocks or functional blocks interactively at run time to better detect the problem area; then software can send a message to a pseudo port to cause the hardware to catch intermediate information.
Using a more active debug approach also means that the engineer is spending more time in actual debug rather than probing around in the dark and waiting for another FPGA P&R iteration. More specifically, we see an active debug approach as changing the state of certain signals to force certain circuit behaviors and testing various complex conditions on various signals and busses without having to rerun FPGA P&R. Collectively we call this Active Debug.
Using a more active debug approach also means that the engineer is spending more time in actual debug rather than probing around in the dark and waiting for another FPGA P&R iteration. More specifically, we see an active debug approach as changing the state of certain signals to force certain circuit behaviors and testing various complex conditions on various signals and busses without having to rerun FPGA P&R. Collectively we call this Active Debug.