On Thu, Aug 8, 2019 at 7:29 PM Aleksandar Markovic
<address@hidden <mailto:address@hidden>> wrote:
On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei <address@hidden
<mailto:address@hidden>> wrote:
> Hi all,
>
> My workmate and I have been working on Vector & Dsp
extension, and
> I'd like to share develop status with folks.
>
> The spec references for Vector extension is
riscv-v-spec-0.7.1, and
> riscv-p-spec-0.5 for DSP extension.
Hello, Liu.
I will not answer your questions directly, however I want to bring
to you
and others another perspective on this situation.
First, please provide the link to the specifications. Via Google,
I found
that "riscv-v-spec-0.7.1" is titled "Working draft of the proposed
RISC-V V
vector extension". I could not find "riscv-p-spec-0.5".
I am not sure what the QEMU policy towards "working draft
proposal" type of
specification is. Peter, can you perhaps clarify that or any other
related
issue?
Hi Aleksandar,
As for riscv-v-spec 0.7.1, it is first stable spec for target software
development
though the name is working draft. The architecture skeleton is fix
and most of
work are focusing the issues related to micro-architecture
implementation complexity.
Sifive has released an open source implementation on spike simulation
and Imperas also
provides another implementation with its binary simulator. I think it
is worth to include the extension
in Qemu at this moment.
As for riscv-p-spec-0.5, I think Andes has fully supported this
extension and should release more
detailed spec in the near future (described Riscv Technical Update
2019/06).
They have implement lots of DSP kernel based on this extension and
also provided impressed
performance result. It is also worth to be reviewed (at least [RFC])
if the detailed spec is public.
ref:
1.
https://content.riscv.org/wp-content/uploads/2019/06/17.40-Vector_RISCV-20190611-Vectors.pdf
2.
https://content.riscv.org/wp-content/uploads/2019/06/17.20-P-ext-RVW-Zurich-20190611.pdf
3.
https://content.riscv.org/wp-content/uploads/2019/06/10.05-TechCommitteeUpdate-June-2019-Copy.pdf
chihmin
I would advice some caution in these cases. The major issue is
backward
compatibility, but there are other issues too. Let's say,
fairness. If we
let emulation of a component based on a "working draft proposal" be
integrated into QEMU, this will set a precedent, and many other
developer
would rightfully ask for their contributions based on drafts to be
integrated into QEMU. Our policy should be as equal as possible to all
contribution, large or small, riscv or alpha, cpu or device, tcg
or kvm -
in my honest opinion. QEMU upstream should not be a collecting
place for
all imaginable experimentations, certain criteria on what is
appropriate
for upstreaming exist and must continue to exist.
Yours,
Aleksandar
> The code of vector extension is
> ready and under testing, the first patch will be sent about two
weeks
> later. After that we will forward working on DSP extension, and
send the
> first patch in middle October.
>
> Could the maintainers tell me whether the specs referenced are
> appropriate? Is anyone working on these extensions? I'd like to get
> your status, and maybe discuss questions and work togather.
>
> Best Regards
>
> LIU Zhiwei
>
>
>
>