Last visit was: Thu Nov 12, 2026 8:44 pm
It is currently Thu Nov 12, 2026 8:44 pm



 [ 333 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23
 Qupls (Q+) 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2546
Location: Canada
Mulling over the idea of supporting 256-bit loads and stores in the ISA. The ISA already spec’s an uncompressed 256-bit capability load or store. The regular 256-bit load / store would be almost the same except for the tag bit. One could just load a capability, then clear the tag bit. I would add the instructions except that there are only about six free opcode left.
The load / store queue has a cache line buffer for each entry. That makes it possible to load or store 256-bit unaligned data.

Got rid of the 72-bit load / store instructions that loaded or stored the flags of a register in addition to the register. Anticipating that most of the time keeping track of the flags is not necessary. If needed, the flags may be manipulated by moving them into the value area of the register. Then ordinary byte load and stores could be used to save them.

Improved the timing of the ROB queue head and tail indexes. Head indexes used to be calculated from head[0] using combo logic. They now use registered logic and are incremented independently of head[0]. Same for tail indexes. IIRC this was on the critical timing path at one point.

Switched the valid flag of the ROB from being a bit vector into just a single bit. This eliminates numerous five-bit comparators and vector reduction operators. It was being used to sometimes hold the instruction stream number, but there is another field for that purpose. I had changed things around a while ago and apparently, I did not do a good job. I found numerous places where I missed the conversion to a bit vector.

CSR instructions would not update the CSR register file; the code to do this was relying on an argument value being in the reorder buffer and that argument was not being set. Added code to fill the ‘arg’ field of the reorder buffer for CSR instructions. CSR instructions are special because they update the special-purpose register set instead of the usual register file.

_________________
Robert Finch http://www.finitron.ca


Sat Nov 07, 2026 3:37 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2546
Location: Canada
With fixes coming out of simulation runs, the core is now too large. It took 44 hours to synthesize. The toolset works really hard when the FPGA is full.
Attachment:
SynthUtil.png

Got most of the support for capabilities coded. It turned out to be not as bad as I thought, but supporting capabilities seems to affect the design.
Q+ is allowing capabilities stored in one of four formats: raw 256-bit uncompressed, 128-bit compressed, 64-bit compressed or not in use. This affects the capability load and store instructions, which load or store according to the size in use. Otherwise, four times as many load / store instructions are required.

Added some more MOVE instructions to move register flags. MORF (move or with flags) allows packing the flag register into a destination register which may be either a GPR or extended register. IMORF (inverse MORF) allows unpacking the flags.

Hey, a free opcode was found. The bitfield instructions were initially given their own root opcode. But they were moved to be under the R3 format opcode. It was forgotten to mark the opcode free in the table.
Added bitfield instructions to the ALU. The bitfield instructions are capable of modifying or extracting the flags associated with a register. The SET operation allows a small constant between -4 and +3 to be set in a bitfield. This is useful for clearing bit fields.

Merged the different FP status registers into a single register called the arithmetic status register (ASR). This is probably better than having a dedicated register for each data type. Instead, different data types are represented by different fields in the status register.


You do not have the required permissions to view the files attached to this post.

_________________
Robert Finch http://www.finitron.ca


Mon Nov 09, 2026 5:11 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2546
Location: Canada
Started working on Qupls5. I was spurred on to do so after some more research revealed flaws in the Qupls4 design. Always improving. Qupls5 is largely the same as Qupls4.

Getting rid of the SIMD instructions, with vectors the SIMD instructions were redundant. They are replaced by vectors of length one, which are almost identical to the SIMD instruction except for a couple of bits in the instruction to represent length.

Some time was spent documenting the changes. Still a lot of documentation to do. The documentation is in a state of flux right now.

Spent a good chunk of the day porting over Qupls4 code to Qupls5. All the references to Qupls4 were renamed. Some of the references in the RTL code were not specifying which version was in use. These needed to be fixed up.

One may wonder why module names are prefixed with the CPU version. Doing so allows multiple versions of the module to be loaded and processed at the same time. It also helps prevent accidently overwriting a module with an earlier version.

Pretty much decided now to go with separate logical register files for integers, floats, integer vectors, and float vectors. This is just from an ISA perspective. The register specs take up fewer bits of the instruction then making it easier to encode operations. 64 registers now for each file.

_________________
Robert Finch http://www.finitron.ca


Wed Nov 11, 2026 3:46 am WWW
 [ 333 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23

Who is online

Users browsing this forum: Chrome-11x-bots, Chrome-14x-bots, claudebot, Version15-old-iOS and 19 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software