Closed zhaoxiahust closed 2 years ago
Actually, I find a lot of signals related to vector instructions in the ifetch and decode stage.... Any comments?
The T-head people said they didn't release the V extension because it wasn't officially Final yet.
@zhaoxiahust I also find a lot of signals related to vector instruction in the source code. Analyzing in depth the code I realized that the processor should originally contain a floating point unit and a vector unit, but it turns out that in the design these two pipelines seem to have been merged.
My understanding of the design leads me to conclude that: There is a Float-register Rename Table (FRT) but no Vector-register Rename Table (VRT), there is a Vector Issue Queue (VIQ) but no Float Issue Queue (FIQ) (maybe they plan to make a Vector&Float Issue Queue VFIQ), there is a Float register file (Fregfile) but no Vector register file (Vregfile) (but the Fregfile is built from gated_vreg), and finally the free-list of physical Vector-registers (PST_VREG, don't know what this acronym means) is connected to the Float-register Renaming Table (FRT) and there is no PST_FREG. (This may sound like a joke but it's not)
I have not yet inspected the code of the VFPU ("Vector & Float Processing Unit" or "Vector & Float-Point Unit") but I predict that it only handles floats.
@avianes , thanks for the clarification. Based on my understanding, the architectural floater register and architectural vector register usually share one physical register file. Depending on your description, I guess these guys only remove the vector execution unit?
Based on my understanding, the architectural floater register and architectural vector register usually share one physical register file.
Be careful you have to distinguish between vector operations and SIMD operations.
For simplicity we usually talk about "vector operations" for "SIMD operations" because few machines still work with real vector operations today. But RISC-V includes a real Vector extension (and a SIMD extension which still in development).
So, I think you are referring to x86 "vector extensions" (SSE, AVX, ...) which actually are SIMD extensions. Yes, in x86 architectural SIMD registers and architectural float registers (for SSE scalar float instructions) are merged and share the same physical register file. But in RISC-V the architectural registers for float and vector are distinct. And using the same physical register file could lead to unexpected issues. (Allocation of float registers could prevent the allocation of large vector registers, or the opposite, vector and float units can be distant and cause routing problems, etc.)
And in the design there is a fregfile and an empty vregfile. Maybe I'm misinterpreting the fregfile & vregfile, but for now I think it matches respectively the float-physical-register-file and vector-physical-register-file (without any design in it).
So I think they planned to use a vector&float execution unit but a separate vector and float physical register file.
Depending on your description, I guess these guys only remove the vector execution unit?
I think so. (removed the vector part from the vector & float execution unit)
It is Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension. I am curious will it be released in the future?
As mentioned above,openC910 didn't include the V extension because it wasn't officially Final yet.
It is Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension. I am curious will it be released in the future?
As mentioned above,openC910 didn't include the V extension because it wasn't officially Final yet.
It is Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension. I am curious will it be released in the future?