In this post I’ll explain how I debug the new core of AEMB, and the current bug that I’m facing.
Debugging the CPU takes place using the demo program originally attached with AEMB. The waveform generated from the demo program running on the new CPU is compared with the waveform generated by AEMB. This way I try to ensure that the same instructions are executed in the same order with respect to each thread and that write backs are in the same order as well. Differences expected to be observed are the ones due to the different threading model. When a difference is observed, it is further expected till the bug causing it is resolved.
So far the two cores perform similarly up until the point where the threading split takes place. In the new model the same threading splitting mechanism using MSRCLR instruction is used. The following picture demonstrates the threading split
The threads split as expected but after threading a problem is encountered. Instruction C88 is a BNEI and it is supposed to evaluate true only for thread 1 because the instruction before it does an AND between the content of the MSR and the hex value of 0x20000000. This result of this operation will only give a value not equal to zero if it was performed on thread 1. Should this all prove to be right, thread 1 then branches to instruction CBC. That is how AEMB performs. Thread zero doesn’t go through this instruction at all.
However, with the new CPU it happens that the thread that executes this instruction is thread 0 and hence the branch is not taken and the instructions executed following this point divert greatly from those executed by the old processor as demonstrated by the following waveform.
Further investigation is needed to decide whether this is a mistake in the pipeline of the new core or the core is supposed to behave this way and the demo program need to be altered.
0 Comments