Milestone:
After much manipulation of pipeline registers I finally got the first couple of instructions of Fibonacci to fetch and execute.

Hurrah!

The docs for Thor2023 are seriously outdated. Spent some time improving them. Instructions now have a vector indicator in bit 8, but many instructions have yet to be updated to reflect this. Heck, bit manipulation instructions still show 32-bit forms and the instruction set was switched to 40-bit a while ago.

Modified the assembler to handle operand one’s or two’s complement. This is indicated by placing a ‘~’ or ‘-‘ before the register as in: add r1,r2,-r3, Which will add negative r3 to r2. Which is how the subtract instruction works. Two’s complement is indicated with ‘-‘, ones with ‘~’. Only a single complement may be used, and it depends on the instruction for ones or twos. Arithmetic type instructions add, sub, multiply, divide can have two’s complement operands, whereas logic and shift instructions can have one’s complemented operands.

Being able to complement operands eliminates instructions which are present in other architectures. For instance nand is just "and ~Rt,Ra,Rb". There is no need for a separate nand instruction.

Upgraded the bit manipulation instructions to bit field manipulation instructions. I had included these initially to mirror the operation of 68k bit instructions, then added bit pair operation. But it makes more sense just to manipulate entire bit fields. 68k instructions updated the bit and left the previous value of the bit in the ccr. Since there is no ccr for Thor2023 this could not be mimicked. Instead a field extract is used to get the current value of the bit(s) prior to using another instruction to modify the bit(s). Hopefully I can come up with a way to make executing the two instructions atomic to mimic the effect on the 68k. Possibly with an ATOM modifier.
A field up to eight bits in size may be manipulated with a single instruction. Wider fields are accommodated using instruction postfix values.

Do you have a addressing mode mode for small structures? I am thinking a +- 2048 byte offset here.
Perhaps this could be combined with the bit field stuff, for easy I/O. Most i/o devices I can think of are
only 8 bits wide other than network or fixed disc i/o.
Ben.

ATM there is only a single address mode, scaled indexed with displacement. d(Ra, Rb*Sc) The displacement may be 7, 32 or 64 bits. Loads and stores can be for 8,16,24,32,40,64 or 96 bits, and half,single,double, or triple precision floats.

Moved the REGION table from being an MMIO table to a set of CSR registers.

Decided to limit the core to a 68-bit physical address. There are many CSRs that need physical addresses to be supplied. Only the upper 64-bits of the physical address may be specified so that the physical address may fit into a single 64-bit register.

I have been busy putting together a book full of stories, so have not done much lately on Thor.

How much real physical RAM do you have?

The FPGA board has only 512MB or 29 bits worth. But I am designing big with this one. TG we got off post 666.

I have been working on the design of the MMU and an IO MMU. The IO MMU works in a fashion like the MMU but is simpler. The IO MMU sits between an I/O device that can be a bus master and the system’s memory. It allows addresses generated by the I/O device to be virtualized, meaning memory for the I/O device does not need to be contiguous.

I have also been busy studying PCI with the thought to use when implementing I/O devices in the system.

Still busy writing my story book too.

The IO MMU turned into just a mapping table for the frame buffer, and possibly for the graphics accelerator when I get around to it. I managed to code PCI config spaces for about ½ the devices in the system now, including the programmable interval timer, PIT. The PIT is part of the MPU component along with the programmable interrupt controller, PIC. Reworked the PIT component so that there are up to 64 timers in a group instead of 32. Each timer is then represented by a bit in some control registers.

Still tweaking the instruction set.

Realized the “zero bit extend”, ZBX, instruction was redundant with the clear bitfield instruction, so removed it from the instruction set. This led to moving the SBX instruction as well.

Moved the “sign bit extend” instruction to the bit manipulation group of instructions rather than the shift group and made it slightly more powerful. SBX can sign extend to a field width rather than just to the machine width.

Rearranged the opcodes in the shift instructions so that there is an additional free bit. 64 opcodes were allowed for shift instruction, but they only occupied 16 instructions. The number of allowed opcodes was reduced to 32.

Added a second operation which may be one of ‘and’, ‘or’ or ‘xor’ to the left-shift. Shift-and-or, LSLOR, allows it to insert a field into a target register. Shfit-and-and LSLAND, allows a field to be isolated.

Work on the caches today, upgrading them to support a multi-core architecture with cache coherency using bus snooping.

I did the cheesy thing of only storing the virtual address as a tag in the cache since the size of the cache was small enough that less than a single page of memory fit into it. Which meant the bits from the physical and virtual address were the same for the tag index. However now I want to implement cache coherence using a snoop and the physical address associated with the virtual one is needed. So, now both the virtual and physical address associated with a cache line are being stored. This leads to two sets of cache tags to compare for hits. If the physical address tag matches the snoop address then that cache line is invalidated.

Beefed up the TLB component which is now a shared TLB between all CPU cores. Increased the associativity to eight-way from four-way. This doubles the amount of BRAM used. Also added a sub-ASID experimentally used to identify the thread owning a page of memory. A SASID of zero means any thread can access the page, otherwise access is restricted to the thread associated with the SASID. The ASID is used to prevent unnecessary TLB flushes, and SASID does not come into play here.

Built the BIU, bus interface unit, for the CPU core and it is quite large, about 40,000 LUTs. It contains two 32kB caches, 10k LUTs apiece. I have yet to remove the TLB and associated logic, which will be moved to be associated with a group of CPU cores rather than local to each core. Given the size of the BIU only one CPU core will be able to fit.

More work on the cache.

For snoop invalidation the cache was made fully associative; there is a comparator against every physical tag in the cache. The output of the comparators only have to drive the cache valid bits. This was necessary to take care of the case of shared physical memory where two different virtual tags might point to the same physical memory. This can be gotten away with because the cache is small, just 256 lines. So, 256 x21 bit tag comparators. It uses about 6,500 LUTs or about 5% of the device. Using virtual tags for read lookups means the address does not have to be translated at every memory access and cache access does not need to wait for physical address lookup. Both the virtual and physical address tags are stored when the cache is loaded.