Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-27 Thread Palmer Dabbelt

On Thu, 22 Aug 2019 15:37:15 PDT (-0700), alistai...@gmail.com wrote:

On Wed, Aug 21, 2019 at 6:56 PM liuzhiwei  wrote:



On 2019/8/22 上午3:31, Palmer Dabbelt wrote:
> On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistai...@gmail.com wrote:
>> On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell
>>  wrote:
>>>
>>> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic
>>>  wrote:
>>> >
>>> > > We can accept draft
>>> > > extensions in QEMU as long as they are disabled by default.
>>>
>>> > Hi, Alistair, Palmer,
>>> >
>>> > Is this an official stance of QEMU community, or perhaps Alistair's
>>> > personal judgement, or maybe a rule within risv subcomunity?
>>>
>>> Alistair asked on a previous thread; my view was:
>>> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html
>>> and nobody else spoke up disagreeing (summary: should at least be
>>> disabled-by-default and only enabled by setting an explicit
>>> property whose name should start with the 'x-' prefix).
>>
>> Agreed!
>>
>>>
>>> In general QEMU does sometimes introduce experimental extensions
>>> (we've had them in the block layer, for example) and so the 'x-'
>>> property to enable them is a reasonably established convention.
>>> I think it's a reasonable compromise to allow this sort of work
>>> to start and not have to live out-of-tree for a long time, without
>>> confusing users or getting into a situation where some QEMU
>>> versions behave differently or to obsolete drafts of a spec
>>> without it being clear from the command line that experimental
>>> extensions are being enabled.
>>>
>>> There is also an element of "submaintainer judgement" to be applied
>>> here -- upstream is probably not the place for a draft extension
>>> to be implemented if it is:
>>>  * still fast moving or subject to major changes of design direction
>>>  * major changes to the codebase (especially if it requires
>>>changes to core code) that might later need to be redone
>>>entirely differently
>>>  * still experimental
>>
>> Yep, agreed. For RISC-V I think this would extend to only allowing
>> extensions that have backing from the foundation and are under active
>> discussion.
>
> My general philosophy here is that we'll take anything written down in
> an official RISC-V ISA manual (ie, the ones actually released by the
> foundation).  This provides a single source of truth for what an
> extension name / version means, which is important to avoid
> confusion.  If it's a ratified extension then I see no reason not to
> support it on my end.  For frozen extensions we should probably just
> wait the 45 days until they go up for a ratification vote, but I'd be
> happy to start reviewing patches then (or earlier :)).
>
> If the spec is a draft in the ISA manual then we need to worry about
> the support burden, which I don't have a fixed criteria for --
> generally there shouldn't be issues here, but early drafts can be in a
> state where they're going to change extensively and are unlikely to be
> used by anyone.  There's also the question of "what is an official
> release of a draft specification?".
> That's a bit awkward right now: the current ratified ISA manual
> contains version 0.3 of the hypervisor extension, but I just talked to
> Andrew and the plan is to remove the draft extensions from the
> ratified manuals because these drafts are old and the official manuals
> update slowly.  For now I guess we'll need an an-hoc way of
> determining if a draft extension has been officially versioned or not,
> which is a bit of a headache.
>
> We already have examples of supporting draft extensions, including
> priv-1.9.1.  This does cause some pain for us on the QEMU side (CSR
> bits have different semantics between the specs), but there's 1.9.1
> hardware out there and the port continues to be useful so I'd be in
> favor of keeping it around for now.  I suppose there is an implicit
> risk that draft extensions will be deprecated, but the "x-" prefix,
> draft status, and long deprecation period should be sufficient to
> inform users of the risk.  I wouldn't be opposed to adding a "this is
> a draft ISA" warning, but I feel like it might be a bit overkill.
>
Hi, Palmer

Maybe it is the headache of open source hardware. Everyone cooperates to
build a better architecture.

In my opinion, we should focus on the future. The code in QEMU mainline
should evolve to the  ratified extension step by step, and only support
the best extension at last.

At that time,  even many hardwares just support  the deprecated draft
extension,  the draft codes should be in the wild and maintained by the
hardware manufactures.

But before that,  it is better to  have a draft implementation. So that
We can work step by step to accelerate the coming of the ratified
extension.

Even at last draft extension implementation are deprecated, they are not
meaningless. The manufactures may use  the  history commit to support
their hardwares that

only support drafted extension.


Overall I agree with 

Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-22 Thread Alistair Francis
On Wed, Aug 21, 2019 at 6:56 PM liuzhiwei  wrote:
>
>
> On 2019/8/22 上午3:31, Palmer Dabbelt wrote:
> > On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistai...@gmail.com wrote:
> >> On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell
> >>  wrote:
> >>>
> >>> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic
> >>>  wrote:
> >>> >
> >>> > > We can accept draft
> >>> > > extensions in QEMU as long as they are disabled by default.
> >>>
> >>> > Hi, Alistair, Palmer,
> >>> >
> >>> > Is this an official stance of QEMU community, or perhaps Alistair's
> >>> > personal judgement, or maybe a rule within risv subcomunity?
> >>>
> >>> Alistair asked on a previous thread; my view was:
> >>> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html
> >>> and nobody else spoke up disagreeing (summary: should at least be
> >>> disabled-by-default and only enabled by setting an explicit
> >>> property whose name should start with the 'x-' prefix).
> >>
> >> Agreed!
> >>
> >>>
> >>> In general QEMU does sometimes introduce experimental extensions
> >>> (we've had them in the block layer, for example) and so the 'x-'
> >>> property to enable them is a reasonably established convention.
> >>> I think it's a reasonable compromise to allow this sort of work
> >>> to start and not have to live out-of-tree for a long time, without
> >>> confusing users or getting into a situation where some QEMU
> >>> versions behave differently or to obsolete drafts of a spec
> >>> without it being clear from the command line that experimental
> >>> extensions are being enabled.
> >>>
> >>> There is also an element of "submaintainer judgement" to be applied
> >>> here -- upstream is probably not the place for a draft extension
> >>> to be implemented if it is:
> >>>  * still fast moving or subject to major changes of design direction
> >>>  * major changes to the codebase (especially if it requires
> >>>changes to core code) that might later need to be redone
> >>>entirely differently
> >>>  * still experimental
> >>
> >> Yep, agreed. For RISC-V I think this would extend to only allowing
> >> extensions that have backing from the foundation and are under active
> >> discussion.
> >
> > My general philosophy here is that we'll take anything written down in
> > an official RISC-V ISA manual (ie, the ones actually released by the
> > foundation).  This provides a single source of truth for what an
> > extension name / version means, which is important to avoid
> > confusion.  If it's a ratified extension then I see no reason not to
> > support it on my end.  For frozen extensions we should probably just
> > wait the 45 days until they go up for a ratification vote, but I'd be
> > happy to start reviewing patches then (or earlier :)).
> >
> > If the spec is a draft in the ISA manual then we need to worry about
> > the support burden, which I don't have a fixed criteria for --
> > generally there shouldn't be issues here, but early drafts can be in a
> > state where they're going to change extensively and are unlikely to be
> > used by anyone.  There's also the question of "what is an official
> > release of a draft specification?".
> > That's a bit awkward right now: the current ratified ISA manual
> > contains version 0.3 of the hypervisor extension, but I just talked to
> > Andrew and the plan is to remove the draft extensions from the
> > ratified manuals because these drafts are old and the official manuals
> > update slowly.  For now I guess we'll need an an-hoc way of
> > determining if a draft extension has been officially versioned or not,
> > which is a bit of a headache.
> >
> > We already have examples of supporting draft extensions, including
> > priv-1.9.1.  This does cause some pain for us on the QEMU side (CSR
> > bits have different semantics between the specs), but there's 1.9.1
> > hardware out there and the port continues to be useful so I'd be in
> > favor of keeping it around for now.  I suppose there is an implicit
> > risk that draft extensions will be deprecated, but the "x-" prefix,
> > draft status, and long deprecation period should be sufficient to
> > inform users of the risk.  I wouldn't be opposed to adding a "this is
> > a draft ISA" warning, but I feel like it might be a bit overkill.
> >
> Hi, Palmer
>
> Maybe it is the headache of open source hardware. Everyone cooperates to
> build a better architecture.
>
> In my opinion, we should focus on the future. The code in QEMU mainline
> should evolve to the  ratified extension step by step, and only support
> the best extension at last.
>
> At that time,  even many hardwares just support  the deprecated draft
> extension,  the draft codes should be in the wild and maintained by the
> hardware manufactures.
>
> But before that,  it is better to  have a draft implementation. So that
> We can work step by step to accelerate the coming of the ratified
> extension.
>
> Even at last draft extension implementation are deprecated, they are not
> meaningless. The 

Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-21 Thread liuzhiwei



On 2019/8/22 上午3:31, Palmer Dabbelt wrote:

On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistai...@gmail.com wrote:
On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell 
 wrote:


On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic
 wrote:
>
> > We can accept draft
> > extensions in QEMU as long as they are disabled by default.

> Hi, Alistair, Palmer,
>
> Is this an official stance of QEMU community, or perhaps Alistair's
> personal judgement, or maybe a rule within risv subcomunity?

Alistair asked on a previous thread; my view was:
https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html
and nobody else spoke up disagreeing (summary: should at least be
disabled-by-default and only enabled by setting an explicit
property whose name should start with the 'x-' prefix).


Agreed!



In general QEMU does sometimes introduce experimental extensions
(we've had them in the block layer, for example) and so the 'x-'
property to enable them is a reasonably established convention.
I think it's a reasonable compromise to allow this sort of work
to start and not have to live out-of-tree for a long time, without
confusing users or getting into a situation where some QEMU
versions behave differently or to obsolete drafts of a spec
without it being clear from the command line that experimental
extensions are being enabled.

There is also an element of "submaintainer judgement" to be applied
here -- upstream is probably not the place for a draft extension
to be implemented if it is:
 * still fast moving or subject to major changes of design direction
 * major changes to the codebase (especially if it requires
   changes to core code) that might later need to be redone
   entirely differently
 * still experimental


Yep, agreed. For RISC-V I think this would extend to only allowing
extensions that have backing from the foundation and are under active
discussion.


My general philosophy here is that we'll take anything written down in 
an official RISC-V ISA manual (ie, the ones actually released by the 
foundation).  This provides a single source of truth for what an 
extension name / version means, which is important to avoid 
confusion.  If it's a ratified extension then I see no reason not to 
support it on my end.  For frozen extensions we should probably just 
wait the 45 days until they go up for a ratification vote, but I'd be 
happy to start reviewing patches then (or earlier :)).


If the spec is a draft in the ISA manual then we need to worry about 
the support burden, which I don't have a fixed criteria for -- 
generally there shouldn't be issues here, but early drafts can be in a 
state where they're going to change extensively and are unlikely to be 
used by anyone.  There's also the question of "what is an official 
release of a draft specification?".
That's a bit awkward right now: the current ratified ISA manual 
contains version 0.3 of the hypervisor extension, but I just talked to 
Andrew and the plan is to remove the draft extensions from the 
ratified manuals because these drafts are old and the official manuals 
update slowly.  For now I guess we'll need an an-hoc way of 
determining if a draft extension has been officially versioned or not, 
which is a bit of a headache.


We already have examples of supporting draft extensions, including 
priv-1.9.1.  This does cause some pain for us on the QEMU side (CSR 
bits have different semantics between the specs), but there's 1.9.1 
hardware out there and the port continues to be useful so I'd be in 
favor of keeping it around for now.  I suppose there is an implicit 
risk that draft extensions will be deprecated, but the "x-" prefix, 
draft status, and long deprecation period should be sufficient to 
inform users of the risk.  I wouldn't be opposed to adding a "this is 
a draft ISA" warning, but I feel like it might be a bit overkill.



Hi, Palmer

Maybe it is the headache of open source hardware. Everyone cooperates to 
build a better architecture.


In my opinion, we should focus on the future. The code in QEMU mainline 
should evolve to the  ratified extension step by step, and only support 
the best extension at last.


At that time,  even many hardwares just support  the deprecated draft 
extension,  the draft codes should be in the wild and maintained by the 
hardware manufactures.


But before that,  it is better to  have a draft implementation. So that 
We can work step by step to accelerate the coming of the ratified 
extension.


Even at last draft extension implementation are deprecated, they are not 
meaningless. The manufactures may use  the  history commit to support 
their hardwares that


only support drafted extension.

Best Regards,

Zhiwei



Alistair



thanks
-- PMM






Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-21 Thread Palmer Dabbelt

On Thu, 15 Aug 2019 14:37:52 PDT (-0700), alistai...@gmail.com wrote:

On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell  wrote:


On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic
 wrote:
>
> > We can accept draft
> > extensions in QEMU as long as they are disabled by default.

> Hi, Alistair, Palmer,
>
> Is this an official stance of QEMU community, or perhaps Alistair's
> personal judgement, or maybe a rule within risv subcomunity?

Alistair asked on a previous thread; my view was:
https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html
and nobody else spoke up disagreeing (summary: should at least be
disabled-by-default and only enabled by setting an explicit
property whose name should start with the 'x-' prefix).


Agreed!



In general QEMU does sometimes introduce experimental extensions
(we've had them in the block layer, for example) and so the 'x-'
property to enable them is a reasonably established convention.
I think it's a reasonable compromise to allow this sort of work
to start and not have to live out-of-tree for a long time, without
confusing users or getting into a situation where some QEMU
versions behave differently or to obsolete drafts of a spec
without it being clear from the command line that experimental
extensions are being enabled.

There is also an element of "submaintainer judgement" to be applied
here -- upstream is probably not the place for a draft extension
to be implemented if it is:
 * still fast moving or subject to major changes of design direction
 * major changes to the codebase (especially if it requires
   changes to core code) that might later need to be redone
   entirely differently
 * still experimental


Yep, agreed. For RISC-V I think this would extend to only allowing
extensions that have backing from the foundation and are under active
discussion.


My general philosophy here is that we'll take anything written down in an 
official RISC-V ISA manual (ie, the ones actually released by the foundation).  
This provides a single source of truth for what an extension name / version 
means, which is important to avoid confusion.  If it's a ratified extension 
then I see no reason not to support it on my end.  For frozen extensions we 
should probably just wait the 45 days until they go up for a ratification vote, 
but I'd be happy to start reviewing patches then (or earlier :)).


If the spec is a draft in the ISA manual then we need to worry about the 
support burden, which I don't have a fixed criteria for -- generally there 
shouldn't be issues here, but early drafts can be in a state where they're 
going to change extensively and are unlikely to be used by anyone.  There's 
also the question of "what is an official release of a draft specification?".  

That's a bit awkward right now: the current ratified ISA manual contains 
version 0.3 of the hypervisor extension, but I just talked to Andrew and the 
plan is to remove the draft extensions from the ratified manuals because these 
drafts are old and the official manuals update slowly.  For now I guess we'll 
need an an-hoc way of determining if a draft extension has been officially 
versioned or not, which is a bit of a headache.


We already have examples of supporting draft extensions, including priv-1.9.1.  
This does cause some pain for us on the QEMU side (CSR bits have different 
semantics between the specs), but there's 1.9.1 hardware out there and the port 
continues to be useful so I'd be in favor of keeping it around for now.  I 
suppose there is an implicit risk that draft extensions will be deprecated, but 
the "x-" prefix, draft status, and long deprecation period should be sufficient 
to inform users of the risk.  I wouldn't be opposed to adding a "this is a 
draft ISA" warning, but I feel like it might be a bit overkill.




Alistair



thanks
-- PMM




Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-15 Thread Alistair Francis
On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell  wrote:
>
> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic
>  wrote:
> >
> > > We can accept draft
> > > extensions in QEMU as long as they are disabled by default.
>
> > Hi, Alistair, Palmer,
> >
> > Is this an official stance of QEMU community, or perhaps Alistair's
> > personal judgement, or maybe a rule within risv subcomunity?
>
> Alistair asked on a previous thread; my view was:
> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html
> and nobody else spoke up disagreeing (summary: should at least be
> disabled-by-default and only enabled by setting an explicit
> property whose name should start with the 'x-' prefix).

Agreed!

>
> In general QEMU does sometimes introduce experimental extensions
> (we've had them in the block layer, for example) and so the 'x-'
> property to enable them is a reasonably established convention.
> I think it's a reasonable compromise to allow this sort of work
> to start and not have to live out-of-tree for a long time, without
> confusing users or getting into a situation where some QEMU
> versions behave differently or to obsolete drafts of a spec
> without it being clear from the command line that experimental
> extensions are being enabled.
>
> There is also an element of "submaintainer judgement" to be applied
> here -- upstream is probably not the place for a draft extension
> to be implemented if it is:
>  * still fast moving or subject to major changes of design direction
>  * major changes to the codebase (especially if it requires
>changes to core code) that might later need to be redone
>entirely differently
>  * still experimental

Yep, agreed. For RISC-V I think this would extend to only allowing
extensions that have backing from the foundation and are under active
discussion.

Alistair

>
> thanks
> -- PMM



Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-15 Thread Aleksandar Markovic
15.08.2019. 11.07, "Peter Maydell"  је написао/ла:
>
> On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic
>  wrote:
> >
> > > We can accept draft
> > > extensions in QEMU as long as they are disabled by default.
>
> > Hi, Alistair, Palmer,
> >
> > Is this an official stance of QEMU community, or perhaps Alistair's
> > personal judgement, or maybe a rule within risv subcomunity?
>
> Alistair asked on a previous thread; my view was:
> https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html
> and nobody else spoke up disagreeing (summary: should at least be
> disabled-by-default and only enabled by setting an explicit
> property whose name should start with the 'x-' prefix).
>
> In general QEMU does sometimes introduce experimental extensions
> (we've had them in the block layer, for example) and so the 'x-'
> property to enable them is a reasonably established convention.
> I think it's a reasonable compromise to allow this sort of work
> to start and not have to live out-of-tree for a long time, without
> confusing users or getting into a situation where some QEMU
> versions behave differently or to obsolete drafts of a spec
> without it being clear from the command line that experimental
> extensions are being enabled.
>
> There is also an element of "submaintainer judgement" to be applied
> here -- upstream is probably not the place for a draft extension
> to be implemented if it is:
>  * still fast moving or subject to major changes of design direction
>  * major changes to the codebase (especially if it requires
>changes to core code) that might later need to be redone
>entirely differently
>  * still experimental
>

OK.

Thanks for detailed response.

Aleksandar

> thanks
> -- PMM


Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-15 Thread Peter Maydell
On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic
 wrote:
>
> > We can accept draft
> > extensions in QEMU as long as they are disabled by default.

> Hi, Alistair, Palmer,
>
> Is this an official stance of QEMU community, or perhaps Alistair's
> personal judgement, or maybe a rule within risv subcomunity?

Alistair asked on a previous thread; my view was:
https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html
and nobody else spoke up disagreeing (summary: should at least be
disabled-by-default and only enabled by setting an explicit
property whose name should start with the 'x-' prefix).

In general QEMU does sometimes introduce experimental extensions
(we've had them in the block layer, for example) and so the 'x-'
property to enable them is a reasonably established convention.
I think it's a reasonable compromise to allow this sort of work
to start and not have to live out-of-tree for a long time, without
confusing users or getting into a situation where some QEMU
versions behave differently or to obsolete drafts of a spec
without it being clear from the command line that experimental
extensions are being enabled.

There is also an element of "submaintainer judgement" to be applied
here -- upstream is probably not the place for a draft extension
to be implemented if it is:
 * still fast moving or subject to major changes of design direction
 * major changes to the codebase (especially if it requires
   changes to core code) that might later need to be redone
   entirely differently
 * still experimental

thanks
-- PMM



Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-15 Thread Aleksandar Markovic
> We can accept draft
> extensions in QEMU as long as they are disabled by default.
>
> Alistair
>

Hi, Alistair, Palmer,

Is this an official stance of QEMU community, or perhaps Alistair's
personal judgement, or maybe a rule within risv subcomunity?

Yours,
Aleksandar


Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-11 Thread Alistair Francis
On Sat, Aug 10, 2019 at 6:55 AM LIU ZhiWei  wrote:
>
>
> On 8/9/19 6:54 PM, Alistair Francis wrote:
>
> On Thu, Aug 8, 2019 at 2:52 AM liuzhiwei  wrote:
>
> Hi all,
>
> My workmate  and I have been working on Vector & Dsp extension, and
> I'd like to share develop status  with folks.
>
> Cool!
>
> The spec references for  Vector extension is riscv-v-spec-0.7.1, and
> riscv-p-spec-0.5 for DSP extension. 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.
>
> What code are you talking about? Is this QEMU code?
>
> Hi Alistair,
>
> It's the QEMU code I have been working on these days, which implements Vector 
> extension. It is under testing,
> and will be sent later.

Great! Please send it when you have it ready. We can accept draft
extensions in QEMU as long as they are disabled by default.

Alistair

>
>  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.
>
> Just use the latest (master) from the ISA spec git repo.
>
> I will follow your advice.Thanks for your attention to this matter.
>
> Best Regards,
>
> Zhiwei
>
> I don't know anyone doing vector work for QEMU. It would be very
> useful, but everyone is busy with something at the moment
> unfortunately.
>
> Alistair
>
> Best Regards
>
> LIU Zhiwei
>
>
>



Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-10 Thread LIU ZhiWei



On 8/9/19 6:54 PM, Alistair Francis wrote:

On Thu, Aug 8, 2019 at 2:52 AM liuzhiwei  wrote:

Hi all,

 My workmate  and I have been working on Vector & Dsp extension, and
I'd like to share develop status  with folks.

Cool!


 The spec references for  Vector extension is riscv-v-spec-0.7.1, and
riscv-p-spec-0.5 for DSP extension. 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.

What code are you talking about? Is this QEMU code?


Hi Alistair,

It's the QEMU code I have been working on these days, which implements Vector 
extension. It is under testing,
and will be sent later.


  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.

Just use the latest (master) from the ISA spec git repo.


I will follow your advice.Thanks for your attention to this matter.

Best Regards,

Zhiwei



I don't know anyone doing vector work for QEMU. It would be very
useful, but everyone is busy with something at the moment
unfortunately.

Alistair


Best Regards

LIU Zhiwei





Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-10 Thread LIU ZhiWei



On 8/8/19 6:48 AM, Chih-Min Chao wrote:



On Thu, Aug 8, 2019 at 7:29 PM Aleksandar Markovic 
mailto:aleksandar.m.m...@gmail.com>> wrote:


On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei mailto:zhiwei_...@c-sky.com>> 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


Hi chihmin,

Thank you for the detailed and informative response. You have a very 
good understanding of the specifications.


I will modify the code according to the latest spec(currently 
riscv-v-spec 0.7.2) from the ISA spec git repo as Alistair advised.


Yours,

Zhiwei



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
>
>
>
>



Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-09 Thread Alistair Francis
On Thu, Aug 8, 2019 at 2:52 AM liuzhiwei  wrote:
>
> Hi all,
>
> My workmate  and I have been working on Vector & Dsp extension, and
> I'd like to share develop status  with folks.

Cool!

>
> The spec references for  Vector extension is riscv-v-spec-0.7.1, and
> riscv-p-spec-0.5 for DSP extension. 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.

What code are you talking about? Is this QEMU code?

>
>  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.

Just use the latest (master) from the ISA spec git repo.

I don't know anyone doing vector work for QEMU. It would be very
useful, but everyone is busy with something at the moment
unfortunately.

Alistair

>
> Best Regards
>
> LIU Zhiwei
>
>
>



Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-08 Thread Aleksandar Markovic
On Thu, Aug 8, 2019 at 3:48 PM Chih-Min Chao 
wrote:

>
>
> On Thu, Aug 8, 2019 at 7:29 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>> On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei  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.
>

Hello, Chih-Min.

Too many unclear points here.

What does this sentence mean? What is "stable"? Is that the same as
"final"? If the document is stable, why the title "draft/proposal"? Can a
"draft" be stable? Can you, or anybody else, guarantee that the final
version of this document will not affect QEMU implementation, if it is done
by the current document? If not, why would you like QEMU upstream to
support something not fully specified? Why has the final document not been
released, if the situation is stable?.

Yours,
Aleksandar

  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
>> >
>> >
>> >
>> >
>>
>


Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-08 Thread Chih-Min Chao
On Thu, Aug 8, 2019 at 7:29 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

> On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei  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
> >
> >
> >
> >
>


Re: [Qemu-devel] RISC-V: Vector && DSP Extension

2019-08-08 Thread Aleksandar Markovic
On Thu, Aug 8, 2019 at 11:52 AM liuzhiwei  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?

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
>
>
>
>