UNIX-Class Platform Specification Working Group

[Palmer Dabbelt]

Atish and I have approval from the RISC-V technical committee and board to
start a group to manage the UNIX-class platform specification. This working
group will start by defining a subset of this platform specification that both
allows compatibility with existing implementations and extensibility for the
future needs. The contents of this first platform specification will include:

* A versioning scheme for future versions of the UNIX-class platform
specification.
* A specification for a platform-level interrupt controller that is compatible
with existing implementations of SiFive's PLIC.
* A specification for a standard SBI that is compatible with the current
implementation in Linux as well being extensible for future needs.
* An SBI extension for CPU power management.
* A specification of the interface between a bootloader and supervisor-mode
software.

Since this working group mostly consists of standardizing existing
implementations, I hope it can progress quickly. As such, I'd like to set a
6-month deadline between when the working group is started (ie, today) and when
a specification enters the 45-day review period.

[Luke Kenneth Casson Leighton]

this sounds great, palmer, it will help resolve some of the
uncertainty surrounding the Unix platform, allowing implementors to
commit to silicon with confidence.

as you are no doubt aware, the commercial and mass-volume libre risc-v
SoC is a hybrid CPU / VPU / GPU [1], where for example the TLB /
Virtual Memory handling and other aspects *may* need to deviate from
the standard UNIX-class platform specification, or suffer significant
(commercially unacceptable) performance degradation, jeapordising its
chances of commercial success if its hybrid requirements are not met
by the UNIX-class platform.

in addition, as it is not intended as a proprietary (secretive,
closed doors) design, those (potential) modifications *will* end up as
publicly-released common-place mass-volume and high profile
modifications to the associated software and toolchains that will
ultimately require (potentially forcibly - not by our team! - due to
user demand) upstream long-term distribution and support.

in addition to *that*, there are funding applications being
considered and under review that *require* full disclosure and full
transparency, as part of "Enhanced Privacy and Trust" for end-users
[2]. secretive closed-doors discussions of innovations and potential
enhancements to, and ratification of, the UNIX-class platform are *not
possible*, because engaging in secretive discussions would be viewed
by investors, customers and end-users alike as "something to hide",
and thus irrevocably cause harm to the reputation of the project by
undermining its business case as a "trusted independently auditable
product at every level of its development and manufacture".

question: is the discussion of the UNIX-class platform specification
to take place in a fashion that is inclusive of the *business* needs
of this commercial *and* libre project to remain entirely public and
transparent at all times?

difficult as this is to point out: we have asked about this in the
past, many times, and have not received a response. investigations
into Trademark Law show that the point at which financial and other
damages occur due to manufacturing and design delays caused by
persistently and systematically not receiving a response is the point
at which a Trademark may be irrevocably invalidated.

whilst we continue to develop this product in good faith (an
important factor to note under Trademark Law), and will make our best
efforts to ensure interoperability (another extremely important factor
to note under Trademark Law), our coninued exclusion from access to
ongoing innovations and the Standards Development Process *will* at
some point require us to make decisions or suffer substantial
financial loss as a result.

l.

[1] unlike a discrete GPU, which is a completely separate isolated
processor where IPC is deployed to shuttle data between the CPU and
GPU, and thus any augmentations or non-compliance with Standards *does
not matter*, a hybrid CPU / GPU / VPU has CPU workloads *and* GPU
workloads *and* VPU workloads operating on the exact same SMP cores.
the number of *general-purpose* registers has therefore been increased
to a whopping 256 (128 INT and 128 FP), the ISA extended to cope (as
hinted at as a possibility right at the top of the priv-spec), the TLB
will almost certainly require pre-load "hints" due to the
significantly different nature of GPU parallel workloads, and many
other aspects besides.

[2] https://nlnet.nl/PET/

[Gurjeet Singh]

Not that I'm interested in participating, but just curious as to how these officially approved groups work. Is there a mailing list for this group? Is it open to public? How does one request to participate in these lists? How does one follow along in these conversations, that is, where are the mailing list archives for this group?

The list [1] seems to be for this purpose, but it is not hosted @groups.riscv.org so I'm not so sure.

[1]: linux...@lists.infradead.org

Best regards,

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/mhng-99966160-5466-4cfc-b3d8-48ad48d3dc74%40palmer-si-x1c4.

--

Gurjeet Singh http://gurjeet.singh.im/

[Palmer Dabbelt]

On Tue, 02 Apr 2019 10:57:38 PDT (-0700), deli...@gmail.com wrote:
> I am confused, SiFive is commercial, right?
>
> Why would one commercial company drive everything and use its own
> implementation for it?

The goal here is not to standardize exactly the existing SiFive implementation,
but we do want to maintain compatibility with pre-standard implementations
where the cost to do so is low. Note that this isn't really driven by the
SiFive hardware implementation, it's more driven by the existing software stack
-- for example, we're defining the SBI to be compatible with existing
implementations while still being extensible in the future.

The only SiFive hardware standard that will be proposed as a RISC-V standard
here is the SiFive PLIC, which as far as I can tell has been implemented by
both Andes and Kentryte (can't tell for sure, though as I don't see proper
documentation for either of these on a quick search) and should therefor really
be a RISC-V standard as opposed to one owned by SiFive. The PLIC as it
currently stands is sufficient for some but not all systems, so it will be an
optional part of the platform to allow for a different interrupt controller to
be added in the future.

> It would be horrible if it is about "standardizing existing
> implementations", especially
> (and it could be outdated), the list of cores and SoC's mentions none have
> been
> evaluated as compliant (compliance in development), more importantly,
> without knowing which embedded OS's will be used and for what application.
> I doubt SiFive covers all applications from AI extreme performance to a
> million
> IoT variants.

The platform spec will simply refer to the other RISC-V ISA specifications for
ISA compliance, so if it turns out that existing implementations are not
compliant then that's tough for them. There's a lot of work going on WRT the
compliance suite, but I'm confident that we will have one so I don't see any
reason to block defining a platform on finishing the compliance specification
-- if anything, having a platform specification will make the mechanics of
running the compliance tests easier because there will be more infrastructure
to share.

As far as OSes go: this is aimed at UNIX-class systems, where Linux is the main
contender. RISC-V has had a FreeBSD port for a long time, and one of the goals
of this effort is to make sure that the various UNIX-style OS implementations
can all run on hardware from various vendors without too much duplication of
effort.

>
> Best regards,
> Bert
> Veteran SoC designer and blogger <https://delisvhdl.com/blog> (>1M views on
> Quora, topwriter 2018)
> Linkedin showcase page <https://www.linkedin.com/showcase/5396093> (HW
> accelerators for AI)
> Portugal Silver Coast Holiday Rentals <https://www.vilaoasisverde.com>
> My 3D printed objects
> <https://nl.pinterest.com/bertdelis/cool-3d-printed-objects/>
> Life is too short, act now and enjoy!
>
>
> Op di 2 apr. 2019 om 17:50 schreef Palmer Dabbelt <pal...@sifive.com>:

>> "RISC-V HW Dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to hw-dev+un...@groups.riscv.org.
>> To post to this group, send email to hw-...@groups.riscv.org.
>> Visit this group at
>> https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

>> To view this discussion on the web visit

>> https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/mhng-99966160-5466-4cfc-b3d8-48ad48d3dc74%40palmer-si-x1c4
>> .
>>

[Palmer Dabbelt]

On Tue, 02 Apr 2019 11:59:04 PDT (-0700), lk...@lkcl.net wrote:

> On Wednesday, April 3, 2019, Bert <deli...@gmail.com> wrote:
>
> It would be horrible if it is about "standardizing existing
>> implementations",
>>
>>
>>

> The PLIC was one of the first key strategic parts of hardware that needed
> heavy interdependence on software, particularly the linux kernel.
>
> Without an interrupt controller, you don't have a modern processor. So the
> PLIC was designed out of necessity, and SiFive should be respected for
> taking the initiative.
>
> Since its creation the PLIC has wide de-facto adoption, with several
> independent implementations, many of them in actual silicon.
>
> For example, Richard Herveille, an independent Open Hardware designer, has
> made available a libre licenced PLIC.
>
> For example, the Shakti Design by IIT Madras University, which had working
> silicon last year, and they have several more designs in development which
> would be extremely costly to start changing.
>
> Whilst the PLIC (a global interrupt controller) is pretty much de-facto
> already a standard, the CLIC (a per-core-local interrupt controller) is
> nowhere near the same level of adoption, so its inclusion in a first
> iteration would not be wise.
>
> That having been said, you are right in that backwards retrofitting of
> standards to preexisting (incompatible) implementations is a rubber stamp
> recipe for interoperability disaster. Look at the quotes specialisation
> quotes in IEEE754 NaN arithmetic as a good example.
>
> Biting the bullet and saying "sorry guys, you jumped the gun, you should
> have discussed the required changes publicly, that you didn't do so, you're
> on your own" is better than having permanent incompatibility that requires
> indefinite support in upstream source code for multiple implementations.
>
> That having been said I do not believe that any such incompatibilities
> actually exist, so the issue is moot.

That's a big part of the reason we want the PLIC as a RISC-V standard and not a
SiFive standard -- if there's an incompatibility it's probably due to an
ambiguity in the spec, and having a RISC-V standard means we can pick the
answer that makes the most sense rather than just picking whatever SiFive has
done.

[Palmer Dabbelt]

On Tue, 02 Apr 2019 16:42:30 PDT (-0700), gur...@singh.im wrote:
> Not that I'm interested in participating, but just curious as to how these
> officially approved groups work. Is there a mailing list for this group? Is
> it open to public? How does one request to participate in these lists? How
> does one follow along in these conversations, that is, where are the
> mailing list archives for this group?

There is (or will soon be) an internal RISC-V foundation mailing list. You
sign up for it via your RISC-V foundation account -- I've never quite figured
out how to use that, mostly because Arun handles it for me.

The tool is called workspace, which lives here:
http://workspace.riscv.org/higherlogic/ws/public . If you're a RISC-V member
then you should be able to log in. I can't find the platform spec group,
though, so I may be screwing something up...

> The list [1] seems to be for this purpose, but it is not hosted @
> groups.riscv.org so I'm not so sure.
>
> [1]: linux...@lists.infradead.org

That's the Linux kernel mailing list for RISC-V. It's CC'd here because users
on it may be interested in the platform specification, but it's not the
platform specification mailing list.

[Palmer Dabbelt]

On Tue, 02 Apr 2019 17:31:23 PDT (-0700), lk...@lkcl.net wrote:

> On Wed, Apr 3, 2019 at 12:42 AM Gurjeet Singh <gur...@singh.im> wrote:
>>
>> Not that I'm interested in participating, but just curious
>> as to how these officially approved groups work.
>> Is there a mailing list for this group?
>

> that's the question that i asked. i had to ask it in the way that i
> did, using the words that i did, due to issues related to Trademark
> Law.

>
>> Is it open to public?
>

> it has not been made clear, hence my question.
>
> (as an aside: none of the "official" RISC-V Working Group mmailing
> lists are open access.)

It's a RISC-V working group and therefor follows the same policies as the rest
of them. IIRC we're in a bit of a transition from workspace to groups.io, but
either way the list (and associated meetings) will only be available to RISC-V
members. There's a free membership for open source projects, as well as a
cheap membership for individuals.

>
>> How does one request to participate in these lists?
>

> again: it wasn't made clear. if however it has been expected that
> the lists be "RISC-V Working Group Mailing lists", then it is
> mandatory to sign the "RISC-V Membership Agreement", which prevents
> and prohibits all and any public discussion or release of information
> outside of the group without the expressed and explicit consent and
> approval of the RISC-V Foundation (Section 5).
>
> this being what our team absolutely cannot do [enter into secret
> agreements that interfere with the BUSINESS objectives], hence why i
> requested clarification.

OK, well, I'm sorry you'll be unable to contribute. We considered different
contribution models as part of starting the group, but decided the standard
RISC-V arrangement was the best fit for this group as well.

>> How does one follow along in these conversations, that is, where are the mailing list archives for this group?
>

> again it was not stated (apologies, to palmer), so we do not know.
>
>> The list [1] seems to be for this purpose, but it is not hosted @groups.riscv.org so I'm not so sure.
>> [1]: linux...@lists.infradead.org
>
> exactly: it's not clear. so, it needs to be made clear exactly what
> the Standards Development Process is to be, where discussion is to
> take place, and whether there are any terms or conditions required for
> participation.
>
> at that point, once it has been made clear, people will know what
> they are getting into.

That's the RISC-V Linux kernel mailing list, where is where RISC-V kernel
development happens. That is an open list, but does not directly discuss the
development of RISC-V standards like the platform specification. Platform spec
discussions will happen the same place as all the other RISC-V discussions --
my other groups are on workspace.riscv.org, but I don't see a platform spec
group there and with the LF transition IIRC we're deprecating workspace in
favor of something else. Maybe we'll be the first group to figure out how it
works :)

I pinged some of the LF people to try and figure out how to get at least myself
added to the list.

[Luke Kenneth Casson Leighton]

On Wed, Apr 3, 2019 at 3:43 AM Palmer Dabbelt <pal...@sifive.com> wrote:
>
> On Tue, 02 Apr 2019 17:31:23 PDT (-0700), lk...@lkcl.net wrote:
> > On Wed, Apr 3, 2019 at 12:42 AM Gurjeet Singh <gur...@singh.im> wrote:
> >>
> >> Not that I'm interested in participating, but just curious
> >> as to how these officially approved groups work.
> >> Is there a mailing list for this group?
> >
> > that's the question that i asked. i had to ask it in the way that i
> > did, using the words that i did, due to issues related to Trademark
> > Law.
> >
> >> Is it open to public?
> >
> > it has not been made clear, hence my question.
> >
> > (as an aside: none of the "official" RISC-V Working Group mmailing
> > lists are open access.)
>
> It's a RISC-V working group and therefor follows the same policies as the rest
> of them. IIRC we're in a bit of a transition from workspace to groups.io, but
> either way the list (and associated meetings) will only be available to RISC-V
> members. There's a free membership for open source projects, as well as a
> cheap membership for individuals.

monetarily zero cost... as long as they have no conflict of interest
that prevents and prohibits joining. and we have a clear business
case (full transparency and independent third party audit
requirements).

to be clear: it would actually be considered to be *fraud* to have
put in a Grant Application under false pretenses (namely: to state
that we intended to develop a commercial chip in a fully transparent
fashion, then immediately on doing so join a *CLOSED* secretive
group).

> >> How does one request to participate in these lists?
> >
> > again: it wasn't made clear. if however it has been expected that
> > the lists be "RISC-V Working Group Mailing lists", then it is
> > mandatory to sign the "RISC-V Membership Agreement", which prevents
> > and prohibits all and any public discussion or release of information
> > outside of the group without the expressed and explicit consent and
> > approval of the RISC-V Foundation (Section 5).
> >
> > this being what our team absolutely cannot do [enter into secret
> > agreements that interfere with the BUSINESS objectives], hence why i
> > requested clarification.
>
> OK, well, I'm sorry you'll be unable to contribute.

you may be misunderstanding: we have a clear business case for
involvement in the standards development process, and have been
consistently requesting access to resources such that we may
participate in innovation.

we have yet to receive a response.

failure of the RISC-V Foundation to accept this and take it into
account is not an option for the RISC-V Foundation if the RISC-V
Foundation wishes to continue to enjoy the benefits afforded by
Trademark Law.

so we are being excluded from the standards development process,
despite having a clear-cut business case for being included. given
the failure of the RISC-V Foundation to take our business case into
consideration, we are not going to just "give up", and will proceed as
best we can under the circumstances with our business objectives.

acting in good faith as we are, we will endeavour to ensure that our
business objectives are met with the minimum disruption to the wider
RISC-V community, however given that we are clearly being
discriminated against, we cannot and will not be held responsible for
any incompatibilities or non-interoperability: that is clearly down to
the failure of the RISC-V Foundation to take our business objectives
into consideration.

if anyone has a problem with that, particularly that the libre/open
community depends critically on good-will, PLEASE SPEAK UP. it is
very important that you do so, as it will strengthen the case that
substantial damages have arisen to our business objectives as direct
consequence of continued and persistent silence and abdication of
responsibility regarding Trademark Law by the RISC-V Foundation.
(Executive Director once again cc'd so that there is no possibility
that the RISC-V Foundation may claim "It Did Not Know")

> e considered different
> contribution models as part of starting the group, but decided the standard
> RISC-V arrangement was the best fit for this group as well.

this constitutes discrimination. Trademark Law is unfortunately quite
clear: discrimination in this fashion is not permitted. any Tradmark
owner that engages in discriminatory practices irrevocably forfeits
the Trademark.

it is also very clear that persistent failure by a Trademark holder
to respond to communications to resolve such matters also results in
permanent forfeiture, and a consequent loss of right of enforcement.

we're *going* to go ahead, palmer. we *will* meet the business
objective of creating an entirely and wholly libre-licensed RISC-V
hybrid GPU/CPU/VPU that is fully transparent in its development and
manufacture, right to the bedrock, with or without the RISC-V
Foundation's cooperation.

l.

[Luke Kenneth Casson Leighton]

On Wed, Apr 3, 2019 at 3:43 AM Palmer Dabbelt <pal...@sifive.com> wrote:

> We considered different
> contribution models as part of starting the group, but decided the standard
> RISC-V arrangement was the best fit for this group as well.

to make it clear as to why this process constitutes "discrimination":
why was there no invitattion made public for actively interested
parties aka "stakeholders" to participate in the decision-making
process? why was there no wider consultation? why was the decision
made in secret? why are we being told *after* the decision has been
made, and why do you believe that our business objectives do not
matter?

executive director of the RISC-V Foundation once again cc'd so that
there is no way that the RISC-V Foundation may claim that they are
unaware.

l.

[Luke Kenneth Casson Leighton]

https://entertainment.slashdot.org/story/19/04/02/218226/justice-department-warns-academy-about-changing-oscar-rules-to-exclude-streaming#comments

that's interesting. i was not previously aware of "Section 1 of the
Sherman Act".

Delrahim cited Section 1 of the Sherman Act that "prohibits
anticompetitive agreements among competitors." "Accordingly,
agreements among competitors to exclude new competitors can violate
the antitrust laws when their purpose or effect is to impede
competition by goods or services that consumers purchase and enjoy but
which threaten the profits of incumbent firms," Delrahim wrote.

i wonder therefore if "deciding the standard RISC-V arrangement was
the best fit for this group as well" - excluding us from that
decision-making process constitutes a violation of the Sherman Act,
given that "profits of incumbent firms are threatened", and
"competition by goods that consumers purchase is impeded"?

l.

[Palmer Dabbelt]

Sorry for the delay, but it appears we now have a mailing list set up!  I managed to announce the group right in the middle of the workspace -> groups.io transition, which means we're the first group to try out the new infrastructure.  As a result there may be some wrinkles, but at least a handful of us can get into the group so with any luck it'll work for anyone else.

You should be able to join here: https://lists.risc-v.org/g/tech-unixplatformspec/topics .  Just like the other RISC-V specs, you'll need to be a member of the RISC-V foundation to contribute to the platform specification -- sorry if there was some confusion in my original email.

[Christoph Hellwig]

On Fri, 2019-04-05 at 08:43 -0700, Palmer Dabbelt wrote:
> Sorry for the delay, but it appears we now have a mailing list set
> up! I managed to announce the group right in the middle of the
> workspace -> groups.io transition, which means we're the first group
> to try out the new infrastructure. As a result there may be some
> wrinkles, but at least a handful of us can get into the group so with
> any luck it'll work for anyone else.
>
> You should be able to join here:
> https://lists.risc-v.org/g/tech-unixplatformspec/topics . Just like
> the other RISC-V specs, you'll need to be a member of the RISC-V
> foundation to contribute to the platform specification -- sorry if
> there was some confusion in my original email.

So in the past the way to join was through workspace.riscv.org - but
login in there just returns an internal server error. Has lists.risc-
v.org replaced the above infrastructure or is it in addition?

[Jim Wilson]

On Sun, Apr 7, 2019 at 12:36 AM Christoph Hellwig
<Christop...@wdc.com> wrote:
> So in the past the way to join was through workspace.riscv.org - but
> login in there just returns an internal server error. Has lists.risc-
> v.org replaced the above infrastructure or is it in addition?

Ignore the server error. You are actually logged in, and can click on
the groups or projects links to continue to the workspace site.

Jim