Latest Bug Fixes
The write ack from the system scratchpad RAM for an ERC cycle was being generated too soon. This led to a response of all zeros from the RAM. An ERC write is a request for a response back after the write cycle.

After running for 50us the data cache controller locked up. It hit a tranid that was the same as a tranid in one of its buffers for an older transaction, and assumed the transaction was done already. So, it never started a new one. The transaction command field is now used as a flag, being set to NONE once a transaction is complete, so the controller can tell if it is matching against an already completed transaction.

Milestone Reached:
SIM working to the point of setting LEDs in the boot code for the scalar machine. First build for FPGA: does not work.

Spent most of the last few days updating the compiler.

Did not update enough entries in the page table to cover the use during startup. This led to a page fault hang while accessing memory.

Tried running the core in the FPGA board a few times. According to the logic analyzer it hangs right when it tries to write the LEDs. The address used to write the LEDs is incorrect. Since this works in SIM things must be close. At least it can be seen that the CPU starts up and fetches instructions.

The boot program looks like the following, which does not do anything more than flash the LEDs.

Note the assignment of values to pointers. I think this is illegal in a lot of programming languages.

Latest Status:
Running the core in the FPGA hangs, but it works in simulation. However, post synthesis simulation does the same thing as the hardware running on an FPGA board. So, there is some subtle difference. It hangs accessing an I/O device. I tried changing which device was being accessed and it did not make a difference. Functional simulation shows that a page fault occurred. This should not happen. The scratchpad RAM is accessed in the same manner as the other I/O and access to the RAM is working.
So, virtual memory is disabled for now. The core can now clear the screen and flash LEDs!

Got a surprise looking at compiler output generated for interrupt routines. On entry all the registers are saved as specified by a register mask, but on exit not all the registers were loaded. The compiler detected the lack of use of some registers and elided the load instructions. The interrupt routine did not use any temporary registers so they did not get loaded at the end of the routine.

Latest Changes:
Made the TLB four-way associative.

Latest Additions:
Added jump to subroutine with an absolute address mode. The target range is 37-bits. This has the same format as the branch to subroutine instruction. There is already an indexed jump to subroutine instruction but with a 24-bit displacement. Thinking of running systems without virtual memory, the address range supported by the jump instructions needs to be larger.

Added constant optimization of branches to the compiler. If two constants are being compared for a branch condition, then either an unconditional branch is output or no branch is output. Unconditional branches are faster than conditional ones because they are performed earlier in the pipeline. So, smaller and faster code results if constants are being compared. This happens fairly often at the start of loops with loop inversion. For the first iteration the value of the loop counter is known.

Latest Bugfixes
Found a bug in the page table walker. The select lines were being shifted over too much. This would cause them to be set to zero sometimes. Meaning the data may not have been retrieved in all cases. I think the select lines might be ignored by the scratchpad memory for reads. If a read cycle is taking place the memory does not care which bytes it is, they are all returned.

Latest Changes
Broke the page table walker down into three modules as part of refactoring for code cleanup.

Latest Bugs
Block RAM/ROM was not being initialized correctly. A branch displacement was incorrect causing a branch to the wrong address and a crash. It appears specifying a .mem file to load did not work correctly. It appears to be a toolset bug, a Windows bug, or a hardware error on the workstation. So, the contents of the ROM were specified directly in the Verilog source code.

Latest Bugfixes
Figured out a hang that was occurring after code ran in the FPGA for about three seconds. Millions of instructions executed, then it hung on a store operation. It turns out there was an I$ load happening at the same time, and the store needed to be retried. The retry code got left out when the sequential core was created. It is amazing that it worked for millions of load / store ops.

Got the page table walker working.
A startup condition was causing a false TLB miss to occur. The page table walker then could not walk the page table properly because it had not been setup yet. The reset PC was being placed on the bus for the TLB to translate, before the default TLB entries were setup. There is a delay of about 15 clocks before the TLB is ready. Before that time the TLB would always generate a miss. A startup timer was used to prevent the TLB from translating the PC address until after the TLB had time to load defaults.

The data cache was locking up because tran id’s assigned to two different bus transaction were the same. The second transaction never got processed then. So the data cache thought the CPU’s bus transaction was not complete. The solution was to scrap the automatic assignment of tran id's and manually hard-code a set.