Also, could you please inform me about RISC-V Vector compliance tests v1.0? 25.07.2022 13:52, Umer Shahid пишет:

Great, thanks for letting me know. Regards, Umer -- Umer Shahid Member Technical Staff 10xEngineers Mobile: +92-334-4072836 Email: umer.shahid@..., umershahid@...,pk

Xi Wang has been developed vector compliance tests at RIOS lab, Krste

Hello all, I hope you are fine, safe, and healthy. I want to know if there is any test suite or platform which can be used to run RISC-V Vector compliance tests? We, in our team, have started to work

| While I share some concern about the cited language, as this is a concept, and not a spec, I think the time to require checking | would be when individual specs implement the concept. I would think

| On another topic, I have this vague feeling that it would be best if we had VL and SEW always set for vector instructions, and | not be implicit in the opcode, but I have not fleshed out this

Hi Yann, I think Ken is referencing the optimization of splitting the sha256's state in two and merging rounds. It is for example described here :

Hi Ken Not sure to follow you on your 128-bit inputs and outputs for the SHA256. The spec speaks about 8 32-bit working variables, a, b, c, ..., g,h, used as the current state, so 256 bits and then an

There is a plan to insert the formal Sail code for an operator in the spec. That is an ongoing project that has been started (there's a prototype), but no resource. Vector has many state variables

Thanks for putting this concept proposal together, Krste. I have several initial comments and questions: I am all for the concept of element groups. As you point out, they are especially useful in

In as much as this is a concept, it may be worth commenting on how this should interact with 64-bit instructions that encode SEW in the instruction. (Which, if I am not mistaken, is a possible future

While I share some concern about the cited language, as this is a concept, and not a spec, I think the time to require checking would be when individual specs implement the concept. I would think it

It's interesting that there seems to be some overlap between this work and the work I've been doing for a matrix multiplication subextension proposal for machine learning workloads. Perhaps we should

A quick look, and ugh: yet another architectural option unconnected to any opcode or CSR bit that we have to specify to get the correct operation in Sail: On Thu, Jul 14, 2022 at 10:31 PM Krste

I've been working up a scheme to handle vector element groups in general, with vector crypto being the first anticipated use case. This replaces the EDIV concept with a more general group concept

It is legal to fill bits vl..VLEN-1 with 1s because of the clause that these instructions are always tail-agnostic. It is also legal to compute bits 0..VLMAX-1 (as a function of elements 0..VLMAX-1),

1. Question for tail bits of mask-producing instructions. In the case of mask-producing instructions, tail elements are the bits with (vl <= bit index < VLEN).So according to riscv-v-spec-1.0, page

Sorry, I have followed the thread but COVID kept me busy here. Zvediv is not strictly needed for matrix multiply. I have to correct Peter Lieber who interpreted that from what we talked at the

I have serious doubts Zvediv helps with graphics. My previous experience is that trying to force SIMD4 over vectors doesn't really help nor does optimize hardware usage. Every major vendor moved away

The current vector TG is only tasked with one more deliverable, which is the IEEE FP16 half-precision extensions (Zvfh, Zvfhmin). This is effectively already defined in ratified specification, and so