Our CPU core will expose a debug trace bus signal, which will be the data captured. Im not currently using the UART connected to the FTDI USB controller, as our logging output is displayed graphically via a text-mode display over HDMI. Not that much youd think for a CPU running at over 100MHz, but youd be surprised how quickly RPU falls over when it gets into an invalid state. We have a good amount of block rams on our Spartan 7-50 FPGA, so we can dedicate 32KB to this circular buffer quite easily. Plenty for a significant amount of state to be recorded, which will be required in order to perform meaningful analysis. Ill define exactly what the data is later but for now, the data is defined as 64-bits per cycle. The data contained in a trace is always being captured on the device in order that if a request is made, the data is available. Multiple traces can be taken, but when the data transfer is initiated, the data needs to be a real representation of what occurred immediately preceding the request to dump the trace. It is mostly used for performance profiling but for RPU would be an ideal debugging aid. It is not interactive, like the debugging most developers know. This is when at an arbitrary time slice, low level details on the inner operation of the core are captured into some buffer, before being streamed elsewhere for analysis and state reconstruction later.
0 kommentar(er)
