Re: Smaller embedded version of the Vector extension


Guy Lemieux
 

Allowing VLEN<128 would allow for smaller vector register files, bit it would also result in a profile that is not forward-compatible with the V spec. This would produce another fracture the software ecosystem.

To avoid such a fracture, there are two choices:
(1) go with P instead
(2) relax the V spec to allow smaller implementations

So the key question for this group is whether to relax the minimum VLEN to 32 or 64?

note: a possible justification for keeping 128 might be to recommend (1) instead. I don’t know anything about P, but it seems like it could be speced in a way that is competitive/comparable with Helium.

Guy

PS — I have started to design an “RVV-lite” profile which would be more amenable to embedded implementations. However, I have adopted a stance that it must remain forward compatible with the full V spec, so I have not considered VLEN below 128. I am happy to share my work on this and involve other contributors — email me if you would like to see a copy.



On Wed, Jun 2, 2021 at 3:15 AM Andrew Waterman <andrew@...> wrote:
The uppercase-V V extension is meant to cater to apps processors, where the VLEN >= 128 constraint is not inappropriate and is sometimes beneficial.  But there's nothing fundamental about the ISA design that prohibits VLEN < 128.  A minimal configuration is VLEN=ELEN=32, giving the same total amount of state as MVE.  (And if you set LMUL=4, then you even get the same shape: 8 registers of 128 bits apiece.)

Such a thing wouldn't be called V, but perhaps something like Zvmin.  Other than agreeing on a feature set and assigning it a name, the architecting is already done.

(If you search the spec for Zfinx, you'll see that a Zfinx variant is planned, but only barely sketched out.)

On Wed, Jun 2, 2021 at 3:04 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:
















Hi everyone,



 



Are there any plans for a cut-down configuration of the vector extension suitable for embedded cores? It seems that the 32x128-bit register file is suitable for application class cores but it very large for embedded cores, especially if

the F registers also need to be implemented (which I think is the case, unless a Zfinx version is specified).



 



ARM MVE only has 8x128-bit registers for FP and Vector, so it much more suitable for embedded applications.



https://en.wikichip.org/wiki/arm/helium



 



What’s the approach here? Should embedded applications implement the P-extension instead?



 



Tariq



 



Tariq Kurd



Processor Design

I RISC-V Cores, Bristol



E-mail:

Tariq.Kurd@...



Company:

Huawei technologies R&D (UK) Ltd

I Address: 290

Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4TR, UK      



 



315px-Huawei   

http://www.huawei.com





This e-mail and its attachments contain confidential information from HUAWEI, which

is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s)

is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !



本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!



 



























Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.