Last visit was: Fri Nov 13, 2026 8:22 am
It is currently Fri Nov 13, 2026 8:22 am



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

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2547
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: 2547
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: 2547
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

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2547
Location: Canada
Worked on updating the documentation.

Changed how vector registers are specified. The vector register code now specifies the vector register number. Because of the large number of physical registers required there are only 23 vector registers each a maximum of eight physical registers wide (512-bits).

Reduced the number of bits in the micro-op from about 230 to about 160.

Removed decoding of the register spec field from the micro-op stage. It was redundant to do it there and required more bits in the micro-op. It is being done at the decode stage.

Changed the ISA for Qupls5 to have 32 integer registers instead of the 64/128 for Qupls4. For general-purpose use 32 is plenty. The number of registers is reduced in part to allow more vector registers. The plan is to use a pool of 1024 physical registers to implement everything. That limits the number of logical registers to 256. 64 of those will be used to implement integer and float instructions, 6 special purpose registers will also be used. That leaves 186 for vectors. That is enough for 23 vector registers built out of eight physical registers each. Or 31 vector registers made up of six physical registers each.

Changed how IP relative addressing is specified. It is specified now using an opcode instead of specifying register 63 the IP register. With reduction of the number of registers to 32, I did not want to waste a register just to reference the IP. It was important to have all 32 registers available for software compatibility.

Changed how the index scaling works, both to save a bit in the instruction and to allow the index register to be suppressed. Previously using register code zero would suppress the index register, but this may not be the best with only 32 regs. Now the scaling is exponential starting at zero. Therefore, multiplying the index register by zero has the effect of suppressing it.

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


Fri Nov 13, 2026 4:41 am WWW
 [ 334 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23

Who is online

Users browsing this forum: claudebot, SERankingBacklinksBot, Version15-old-iOS and 25 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