Hi all, For common AI workloads such as DNNs, data communications between network layers introduce huge pressure on capacity and bandwidth of the memory hierarchy. For instance, dynamic large

Correct, Krste

Hi all, I understand the EEW, as explicitly encoded in the load/store instructions applies to the vector of indices for the indexed loads and stores. For instance we can load a vector "SEW=8,LMUL=1"

Hi Cohen, Thanks for your careful reading. Hopefully this edit clarifies some of the ambiguity: https://github.com/riscv/riscv-v-spec/pull/565 Best, Nick Knight

The non-normative text you quoted should be edited to delete the words “it is signed”. The immediate is sign-extended, but then is treated as an unsigned value. So the operation doesn’t differ

From chapter 11, section 1 (#3): The 5-bit immediate is unsigned when either providing a register index in vrgather or a count for shift, clip, or slide. In all other cases it is signed and sign

Sorry for late notice, but I have to cancel the vector tech meeting today, Krste

Thank you for the clarification. Excellent.

The user can call functions anything they want. The example might be better if this was clear by calling it foo() or demo_vector_add() or something. The variable "a" in an "int *" pointer. When you

Thank you very much for this advancement. I have two concerns, in the body is a response. . On 2020-08-21 9:34 a.m., Kito Cheng wrote: Shouldn't this be

Just a reminder that we will differentiate between branding (i.e. what we trademark and what members can advertise) and internal use (like uname in linux vs. splash screen, etc.). the proposed policy

thanks - I am OK with whichever you choose.-- ==================================================================== The information contained in this electronic mail message and any attachments

Anybody is free to use any subset of supported instructions and element widths/types. The Z names can be extended down to individual instructions/width if necessary. However, we have to guide the

Works for me. -Allen

Under the scheme I'm promulgating, it's true that you couldn't describe your hypothetical machine as implementing capital-letter "V". Perhaps it could be an RV32I_Zvbase_Zvm machine or something?

For layout reasons, I can easily imagine a vector unit that has multiply HW for vector registers, but can't easily use them to implement scalar multiply/divide. Whether someone would ever want to

We had a long discussion about how to name different portions of the vector ISA at one of the recent meetings. You can see the issue here: https://github.com/riscv/riscv-v-spec/issues/550 And the

We definitely want to sanction configurations that have different datatype support on scalar and vector. The current thinking is that the letter V means "whatever apps-profile processors want", just

I think a common embedded and FPGA scenarios will be F on the scalar side but no F on the vector side. Adding F to V is nontrivial in area, particularly for FPGAs that lack FPUs, yet an integer-only

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too