PC increment pulses for macro-instruction fetch were two-clocks wide. This didn’t matter most of the time… Got the micro-op engine working at least for the tiny Fibonacci test program.
Modified the I$ to work in increments of 16-bit parcels rather than 13. This was to eliminate a couple of multiply by 13 operations and replace them with a power of two shift (16). Although the I$ now works with 16-bit parcels only 13-bits are implemented. The change was to improve performance.
Decided to use the 3 bits available to add pre-decoding of the instruction length. The instruction length is now decoded when the L1 I$ is being loaded. Previously the length was decoded at the fetch stage. Now it is simply read at the fetch stage. This should improve performance.
An attempt was made to add more pipelining at the fetch stage. The fetch stage does a fair amount of work in one long clock cycle, and is suspected to affect performance.

Added more pre-decoding of instructions. Instructions that can affect program flow (branches, return, break) are now pre-decoded. These instructions are used in determining the next program counter in the fetch stage. It helps if the decodes are available fast. Decode of branches also feed into the branch predictor. The pre-decode bits use more room in the instruction cache, increasing the size of the cache by about 50%.

Found an issue with memory issue logic where things would only issue from one of the first eight queue slots. This would cause the core to hang waiting for a load / store operation to issue if it was in the ninth or greater queue slot. Found another bug where a second memory instruction would issue too soon. Found these by inspection while refactoring code.

Simulating the core today, after updating the assembler to v5. Worked on exception handling logic and oddball instruction commits.

More simulation and bug fixes. Found several bugs in the generic portion of the core. Which would have been in prior processors. Including bugs that would cause the processor to halt. Went a little nuts with the type use available in System Verilog and added a number of variable types. Implemented different instruction formats using structured types and a union. It makes the appearance of the code a little easier to understand.

Spent several hours trying to debug a mysterious ‘function must have at least one input’ error message. Things seemed to work in simulation but not in synthesis. It finally dawned on me that perhaps synthesis didn’t support all the nice features of simulation. And voila a quick check on the web reveals this to be true. The message was occurring because a class variable was used, and synthesis doesn’t support classes.

Worked on the compiler today.

Added a buffer between the instruction fetch and dispatch queue. This is commonly called a decode buffer. Splitting the logic up greatly reduces the amount of work done in a single clock cycle, which potentially increases the max core clock frequency.

For some reason the core occasionally inserts duplicate instructions into the queue. This is a pipelining bug of some sort. I can’t seem to track it down, the core works fine for several hundred cycles then poof an extra instruction is inserted. So, for now, I added logic to the queuing to detect a duplicate instruction and mark the new duplicate instruction as invalid, that seems to work.

I think back in the day when I did this sort of thing at work, this is where unit testing might well come in: with randomised flow control signals, your testbench checks that each pipelined unit obeys the pipeline rules. Testing for that kind of bug when you have a full system is, of course, much more difficult.

This caught my attention. My understanding is that the micro-op core handles native 6502 instructions. Does the compiler generate standard 6502 code?

Yeah, unit testing is great, used to do a lot of it. I used to say 90% of the job is unit testing (working as a programmer). As a hobby a rigorously unit tested approach would be too time consuming. It would take too many man years I do "unit testing" on the fly without proper documentation here. When I hit really nasty bugs that need to be worked out then I get more rigorous.

I setup a small test program to see what happens when a branch instruction spans a cache line, and it's branch miss or a branch taken.

I determined the issue after some more testing. The pc increment logic needed to be separated from the queue count logic. The pc increment happens one cycle sooner than the queue count now, because of the addition of the decode buffer. The pc was incrementing by only one if there was a predicted taken branch in the first slot. The second slot however still contained an instruction that was being queued erroneously. Since the pc incremented by only one, the instruction that was in the second fetch slot got fetched again resulting in it being queued twice. (I disabled the kludge I put in in order to get further - it doesn't really belong in the finished version.)

Nope. I've been working on another project and posting under this topic. I should really change the topic as what I've been working on has mutated. It started out as the rtf65004 native instruction set.

Ported the rtl code for a soc to the current project to use as a testbed. Also worked on many different things today, the assembler, compiler. Edited makefiles to enable building the system.

Worked on sprite controller documentation.

The compiler outputs zero and sign extension instructions when needed. Well, these weren’t in the ISA so they got added. Not wanting to use up a lot of opcode space for the rarely used operations, extra bits in the ‘or’ instruction were used to indicate to zero or sign extend the result. So now the ‘or’ operation is an ‘or with sign/zero extend’. Rather than muddy up the or instructions alternate mnemonics of ‘movsx and movzx’ were defined.

Ran the design through to implementation to get timing results. According to the results it could be clocked at about 23MHz, 3MHz faster than the clock supplied to the core. Not good enough! I want at least 40MHz operation! So, I’ve started looking at what’s slowing things down now. According to the timing results there are 40 logic levels and the slowest path involves the sequence numbers. IIRC and understand correctly from reading newsgroups the number of levels in the typical design is about 12. So, I’m going to shoot for 24 cutting the logic levels in half.

One simple change should improve things slightly – reducing the size of the sequence number. It’s currently 26 bits, but probably 20 bits is good enough. That would reduce all the comparators by six bits.
I also found the queue state variable (sometimes used with the sequence number) use could be improved. It’s currently a packed value since the queue can only be in one state at a time. However, using a packed value leads to comparators which become part of the path on the critical timing path. So, I changed the queue state variable back to a set of bits. (It was a bitset in the original design). This means the value doesn’t need to be broken down by a comparison.
Another area that could be improved was the stomp logic which happens when a branch miss occurs. By noting that a branchmiss signal is always active for at least two clock cycles, the stomp signal could be registered during the first clock cycle rather than being strictly combinational logic. Registering the signal means that dependent logic sees the output of a ff rather than more combo logic. This should reduce the delay in the stomp by quite a bit.

I made a few modifications over the day and got the timing improved somewhat. Trimmed the number of logic levels from 40 down to 35.

The rtl code changes have resulted in a pipeline issue again.

Forgot to gate the return address onto the bus for the JAL instruction. The first return didn’t work then.
Got the logic levels down to 18 using additional pipelining. This is quite a bit better than the 40 levels. According to the timing summary it looks like the core should be able to work at close to 50 MHz.

It would be nice if the core could work at 50MHz because there’s already a 4x and 2x clock available.
With the additional pipelining are additional pipelining bugs to work out.

Hi Rob,

50 MHz looks impressive to me, but I'm confused about what that figure actually means. I understand this is the clock frequency that you can achieve given your design (including the degree of pipelining) and the particular type of PFGA you use for modelling. It would be interesting to compare that figure with a standard implementation of a RISC-V or MIPS processor on the same FPGA or FPGA tools.

Up to some point, I can think that a microcoded CISC processor can potentially run as fast or even faster than a natively running RISC processor because the micro-ops for the CISC processor can be highly tuned to achieve max performance through very wide micro-code encodings and deep pipelining. I think this is the case of the x86 processors, which according to wikipedia used up to 118 bit wide micro-ops for the Pentium Pro, with the ability to hold 32 bit immediate values.

So, how does the implementation of the microop 6502 relate with the performance that would be achieved by a natively running (I mean without a microcoding stage, but just direct decoding) RISC cpu ?

I seem to recall seeing a spec of 90MHz for the RISC-V Boom processor in an FPGA, I’m not sure what the FPGA / toolset in use was, but I’m guessing they used a faster part. The FPGA I’m using is lower cost part. There are much faster versions of the part. I sometimes have a look at the Apollo website, which is a 68x080 core, running in an FPGA. I think they hit something like 200MHz, but in a fast FPGA.
I’m not sure what they mean by micro-ops with the width being 118 bits Is it referring to a whole queue entry or a distinct entity on it’s own? The information in the micro-op queue for the rtf65004 is wide as is, it includes a copy of the original instruction (32 bits) and program counter along with the “micro-op” among other things. A queue entry is about 85 bits wide.
At the moment the core is running just as a direct decoding without the micro-op stage.