Debbuging a RISC processor on an FPGA

What about adding a simple UART or low-cost HD44780 (or compatible) LCD displays to your processor.

Hans

For a CPU that I designed once, I setup an automated testing platform where I ...

- ran a small, simple test case on the CPU, and recorded changes in the program counter (PC)

- fed the recorded PCs back into my desktop computer ... (for this particular design, I was able to use an existing serial connection)

- I wrote a small C program to gather the results coming in the serial port and analyze the PCs that were output by the CPU (to compare it to expected results)

I had a suite of several test cases which tested various ADD, MULT, etc. instructions, and these were often used to JMP to different locations (thereby changing the PC). Any differences in the program counter were automatically picked up by the C software when it analyzed the "trace" of PCs.

This took a bit of time to get working perfectly (i.e., you have to design the test cases and the C program correctly :), but as a real believer in automated testing, I feel that it saved me a fair bit of time down the road.

K.

Interesting approach I have to admit. But is in my case probably not applicable as I execute programs that include almost no jmp or branch instructions. So for me it is essential that I could read out the register content or maybe the RAM content at the end of the computation.

Would be thankful for more such ideas ;)

Hm LCD Display would be interesting. The problem is, that I have zero experience with this kind of approach. So I dont know how difficult it would be to connect such a LCD display.. is it straightforward?

Have a look on the web, there are lots of projects that use the Hitachi HD44780 (or compatible) controller chip. The interface is a simple 4/8 bits bus with some strobe signals.

You can hook one up to your parallel port (assuming you still have one) and experiment with it first before you connect it to your processor.

You can find these modules on ebay for very little money.

Hans

Are you using one of the xilinx development boards? IF so you could make use of the on-board LCD or if you have an older model board the 7 segment LED display.

Hi,

Make sure that your test program both works in simulation and on target since you will need to go back and forth between them.

Create small assembler programs that test one feature (instruction) each and make them self-checking. You could make your programs to light one of two led to show if that program succeeded or not.

This way you can run them in simulation and on a board.

Then it's just a large labour of writing all programs for all features that you want to test.

Göran

Thanks for your feedback Goeran, the simlation in the Modelsim works fine. I have a PCI card, so the LEDS approach sounds good but I have already written some kind of libraray with different applications and I wanna see if they also work on the FPGA and not only in the simulation.

So I was thinking of having the program counter as my trigger, so when the end is reached then I wanna somehow read out the values of the register with Chipscope. Or each time the program counter changes I read out the values of the Registers to see if the results are as expected and could so also immediately identify the instructions that have caused problems. SO far i have just debugged a simple counter with the chipscope so I hope the approach with the RISC also works as I have just described.

Göran Bilski wrote:

One thing I have done is make a special debug version of the processor, and bring out the interesting bits (pipelines,registers,PC, status) so they are readable by the host (you mentioned you had a PCI card...). Then I have a single clock register that clocks the CPU when written to. This hardware is accessed by a simple disassembler/singlestep program running on the host...

That sounds pretty cool. So you make all the interesting parts of the processor visible to the host over this PCI interface, and from the host you can give it the command to proceed one step in the program. WOuld be perfect, have to figure out how this PCI interface works!

Thanks for this good idea!

Since you have simulation working, and thus expect to be looking for subtle failures (or even testing over-clocking..) what about using a compare array scheme. Most FPGA's have RAM 'for free', so use that thus:

Code looks like this

FOR ALL Tests Ans = FuncCall(tests); IF Ans ArrayCompare[tests] THEN ArrayCompare[tests] := Ans; INC(ErrorCounter); ENDIF

On SIM, you clear ArrayCompare[xx], and so should fail and load, on all calls, on the first pass, and on the second pass, fail on none. You then copy that Answer ArrayCompare[] from SIM, and download to the FPGA, and run, which becomes the same as the second pass, and you should have zero compare failures..

-jg

There is nothing magic about Chipscope. It's a wrapper around a dual port RAM. You probably don't want it to grab all Registers when X happens. It's hard to do that on a single clock cycle.

What would you want in a RAM if you knew there was a problem?

It might make sense to grab the register (address and value) whenever X happens, maybe when X is write to a register.

It might make sense to grab the PC whenever a branch happens.

As a hack, you can ignore Chipscope and figure out how to wiggle a few external wires and then sprinkle debugging crap into your code. If the wires are connected to LEDs, you can use them for low level debugging just by looking at them.

You can also connect a scope or logic analyzer. This assumes the CPU (hardware and software) is mostly working. I'd use one signal for a trigger and others for X happened. With modern digital scopes, you can see the pattern of X leading up to the error that triggers the scope.

"There is no extra magic inside the FPGA, just the usual magic." -- Göran Bilski