inconsistent values in register when reading switches

[GoogleCodeExporter]

I was working on a lab assignment involving a clock and a stopwatch. The 
switches are read in to a register constantly (lines 37+38) and the value is 
not always consistent. We didn't notice any other problems elsewhere in the 
code, and it works fine in the simulator, but occasionally reads wrong when 
running on hardware.

Changing the li instruction to use $fp instead of $t0 solved the issue, along 
with just using a lui instruction to load the address (since a full li is not 
needed).

We tried a lot of different things and couldn't decide if the problem was 
hardware or software related.

Original issue reported on code.google.com by scaveng...@gmail.com on 10 Oct 2011 at 10:09

Attachments:

• lab4.plp

[GoogleCodeExporter]

this project has a similar problem.

Original comment by david.jakob.fritz on 11 Oct 2011 at 9:43

Attachments:

• Lab4.plp

[GoogleCodeExporter]

Original comment by david.jakob.fritz on 11 Oct 2011 at 9:43

[GoogleCodeExporter]

This project has a similar problem. :P

Original comment by RMJe...@gmail.com on 11 Oct 2011 at 10:19

Attachments:

• Lab4_Jeter.zip

[GoogleCodeExporter]

This looks like a hardware bug, especially since three groups with three very 
different implementations have the same issue. Looking into it now.

Original comment by david.jakob.fritz on 12 Oct 2011 at 1:44

• Changed state: Started

[GoogleCodeExporter]

Original comment by david.jakob.fritz on 12 Oct 2011 at 1:44

• Added labels: Milestone-3.3
• Removed labels: Milestone-3.2

[GoogleCodeExporter]

Lab4_Jeter.zip appears to work just fine. There was a memory leak in the ISR 
(push op codes at the end instead of pop). Without that fix, the stack 
eventually grows into the program text, causing the failure. This may not show 
up in the simulator simply because it would take so long for it to occur.

Original comment by david.jakob.fritz on 12 Oct 2011 at 2:15

[GoogleCodeExporter]

This issue was closed by revision 2d599963a186.

Original comment by david.jakob.fritz on 12 Oct 2011 at 4:50

• Changed state: Fixed

[GoogleCodeExporter]

Problem is fixed. The interrupt controller in the hardware was not correctly 
flushing the IF stage pipeline register. Allowing the third instruction after 
the return from the interrupt to execute twice in a bizarre order.

Original comment by david.jakob.fritz on 12 Oct 2011 at 5:03