good idea. minus 0 as the reset fault.
Can you tag the internal registers for address and data, where a zero in address is a fault or null pointer?

I made the registers a byte wider so that tags or flags could be added to them, but this is not implemented. There is a bit reserved to indicate a pointer in a register. It could be combined with the value to indicate a fault.

The MSI interrupt controller was outputting an NMI all the time. This occurred because a state of no interrupts was indicated with the same code as an NMI (with one more top bit set).

Pretty much decided to drop predicates and the PRED modifier from the ISA. It turns out to be tricky to implement with multiple threads present. I think I got it implemented but sheesh. Predicates are adding a fair bit of logic to the design. It is a bit disproportionate to the value. There could be multiple active predicates in the pipeline for each thread and everything needs to be tracked.
A predicate fault occurred during testing. The fault occurs when the commit pointer is sitting at an instruction waiting for a predicate and there are no longer any active predicates. It is a hardware issue. I decided not to spend time debugging.

The design may clock faster without the predicates. Branches automatically predicate instructions anyway if they are in a short branch shadow.

For some reason the exception flag on the ROB entry was being set during enqueue. This caused all instructions to exception. It was supposed to be set only if there was a decode exception.

Spent about an hour figuring out why the reset jump was jumping to $FFFFC000 instead of $FFFF8000 like it should. Looked at the assembler encoding, instruction decoding, etc. Then I remembered that the memory file used to load the ROM was still pointing to the file for 2025. I switched this to the 2026 version to fix things.

Milestone:
The core is jumping to the reset address, so it is executing the first jump instruction after a reset now. And it is loading up instructions in the pipeline. Still more work to do…

Bug Fixes
There was no valid signal associated with an I$ miss address. This led to cache lines for the default miss address to be fetched repeatedly. This would affect performance, which was obvious on the sim trace as long spaces between instructions. A valid miss address signal was added to rectify this.

Micro-ops were not marked as valid when translated resulting in all micro-ops being treated as NOP operations. No instructions were executing except branches performed in the extract stage. (Branches in the extract stage operate on raw instructions not micro-ops).

It seems that NOPs are not always indicated as such in the decode bus. I am not sure where the issue is. But since they are normally marked done right away and do not get dispatched, lacking a NOP indicator causes the machine to hang. Just wondering if to add dispatch logic for this case. Eventually, I figured this one out.

A couple of the test conditions for instruction dispatchability were incorrect. This meant instructions would not dispatch causing the machine to hang. Dispatchability conditions are pre-computed before they are used.

Fixed up the use of the old 'instruction' structure to the newer micro-op structure in a few places. Some of the older code was ported that did not use micro-ops. I should really go through all the code and ensure there are no references to the old structure.

The super-fast, super compact instruction dispatcher from the other day did not work. It required a fix, not sure how timing is impacted.

Choosing the ready RSE (reservation station entry) written as a function was re-written as a module. It did not work as a function, always returning -1 meaning no RSE was selected.

I found a better way to handle flow control dependencies. All instructions are marked as depending on the stream they are associated with. It only matters for instructions that have dependencies like stores for instance. When the state of the stream resolves to a known value, then the instructions for that stream are unmarked as dependent. I think this is more efficient than the previous mechanism that searched backwards through the ROB for flow control dependencies. To do this a stream state array had to be added along with some state management.

A case statement in the LSQ (load store queue) was coded incorrectly. I must have been drunk at the time.

Results do not seem to be written to the register file. I found one or two bugs related to this but have not found the panacea yet. There are so many bugs it is hard to know where to start.

My debugging is old school, use the front panel.
If I can't read/write memory then back to the drawing board.
Then I check if halt works and other simple operations.
Then I run the basic bootstrap from ROM
with the current memory to load displayed on the front panel and a # is output on the serial port.
This uses a only a few primitive basic instructions.
register operate, half word register indirect, jmp , jz ,half word immediate.
At this point I can use the bootstrap to run simple test programs.
later I can then burn the e-prom for the full bootstrap.
hardware debugging is easy, just sleep on it over night.
Software debugging is a pain as I often only can revise a few lines of code a day.

I have a process where I debug what causes the machine to hang. Eventually longer and longer runs of instructions work. At some point it may be debugged well enough.


Immediate constants do not seem to make it through the pipeline resulting in zeros instead of the constant. This leads to all values being zero. I have not been able to track down yet what the issue is. Cache-lines seem to be passed down the pipeline correctly and constants are read from the cache-lines. There must be a decode issue of some sort but it is not obvious.

The bitmap for the function results queue select signal was not counter rotated. This led to results not being updated correctly and queues not being read in the right order. Which eventually led to a hang. Fixing this allowed the machine to progress further.

The FLO144 / FLO288 (find-last set bit) modules were messed up. This caused the same register rename to appear for two registers causing a rename stall and a hang.

I found one issue with constants being zero which turned out to be a software issue. The assembler was encoding constants incorrectly, it was off by one bit. This caused the constant one to appear to be a zero when decoded by the CPU.

I found a second issue with micro-op translation. The raw micro-op was not completely transferred to the cooked version. This caused constants and other information to be omitted. Fixing this issue shows micro-ops being propagated down the pipeline correctly, but still did not fix the zero constants.

All the instructions making it through the front-end were marked as stomped on. In the micro-op translation the code that marks unused micro-ops was not working correctly, and ended up marking all micro-ops unused.

Some of the fields were not correctly assigned at the data input to the functional results queue. This led to ‘X’s in values and incorrect values.

Finally got the constant one to appear as an immediate in the re-order buffer.

Some results almost make it to the register file now. They are coming out of the queue as ‘00000000x’ instead of ‘000000001’. (They do make it to the register file now).

Decoding for oddball instructions was not complete. This showed up as a commit count of zero resulted. The total instruction count was also zero. I had purposely left this decode as something to be done at a later date…

The instruction count is not working. I am mystified as to why. It is very simple logic. The only thing I could think of is of there is a name conflict of some sort. I called the count ‘I’. So I have renamed it to ‘TotInsn’. How can this code go wrong? Cmtcnt is 4, do_commit is 1, irst is zero, and the clock is happening. I is fixed at zero and it should be incrementing by cmtcnt.

After all the fixes that have gone in recently, I decided to try re-synthesizing the core. It turns out to be too big now by about 20%. I do not think there is an easy way to fix this. I decided to shelve the core for now and work on other things.

The instruction count issue from the other day seems to possibly be an issue with the core size or complexity. There is nothing wrong with the code, but it does not work in simulation. This has left me wondering what else does not work.

One thought I had was to re-write the core as maybe a two-wide core without the reservation stations and just using the re-order buffer to buffer things. It might be small enough then.

Other things worked on being the memory controller today. The test bench for it was improved, and the memory controller ports connected up to WISHBONE bridges as it is desired to use the WISHBONE bus to interface to the core. The core currently works using an asynchronous bus. A project was specially created just for the testing. The tools were not working well with the core in place in another project.

The WISHBONE bridge was modified slightly to accommodate the memory controller core. It used TID values of 1 and 2 to perform transactions, and the memory controller needs to see a TID of zero for streamed memory accesses. Normally zero is an invalid TID used when the bus is supposed to be vacant. A TID of zero is a good value to use as it is somewhat meaningless for a burst access.

After a couple of minor fixes the core seems to work at least in simulation.

The next project will likely be a traffic generator to test the memory controller in the FPGA. The rf68000 project or something similar may be used.