Observing internal FPGA signals


By Werner Almesberger

Sometimes, when debugging some firmware or hardware, it is necessary to see how the internal state of a chip changes in response to external signals.

With microcontrollers, this can be accomplished by adding code that toggles some pin that is then used for debugging, and watching that pin with an oscilloscope. Such a pin can also serve as sophisticated trigger, e.g., to capture some input signal only when an error is detected.

With M1, we can do the same, e.g., make LM32 or Navre toggle an I/O under software control. But we can do better: we can also route “hardware” signals directly, without involving software.

Here are three ways to do this:

  1. Change the Verilog to properly route the signal to the output pad. This is nice and clean but has the following disadvantages:
    • need to run the full build process for each change of taps,
    • need to edit the sources (and remember to undo all the changes once the problem is fixed),
    • the signals need to be propagated step by step up the module hierarchy (*), which means a lot of small changes in many files,

      (*) Verilog should support also direct references that “jump” the hierarchy, but this doesn’t seem to be properly implemented in the Xilinx tools.

  2. The pros just edit the FPGA with a WYSIWYG editor (Part three shows how to route signals to a pad). What I don’t like about this is that it’s not script-friendly. I’d also suspect that the changes are lost or at least in danger when re-synthesizing.
  3. Like above, but edit non-interactively. This is an experimental hack I’ve now implemented.

Read the rest from the Milkymist mailing list

Comments are closed.