Philipp,

The Common Software Interface concept seems like it could be a promising
idea, but at this point, that appears to be all it is: an idea. Whether
that idea is fully realized into something that is suitable as the
cornerstone of a platform remains to be seen. I think titling the platform
that way at this point is premature and sets up false expectations. You
said that "CSI was chosen as an unencumbered term", yet every time I have
heard it described, it was something along the lines of "CMSIS, but for
RISC-V", which, to me at least, carries a fair set of assumptions.

On the other hand, you said that a variety of things with respect to the
planning of the Common Software Interface have been communicated up through
leadership at RISC-V. If I understand correctly, that is a driving factor
in retitling the platform to match. If that is the case, it is a little
unclear to me what role this committee has had or is expected to have in
influencing this process. If RISC-V leadership has already decided that
this CSI approach will be followed, then I suppose they could also dictate
the name.

I think evolving the platform previously called M will have some of the
same challenges I have mentioned previously. Inconsistency within and
between the Platform Policy, the Specification, and statements in the
meetings as well as terminology that is not clearly defined make it
difficult to make progress in improving the specification. For example,
the Platform Policy indicates that the purpose of a policy is to ensure
binary compatibility, but you are saying that the goal of the platform
previously called M is specifically not that. As another example, it has
been repeated stated that there are no optional requirements in the
Platform Specification, but there are many such requirements in the
platform previously called M. The Platform Policy is conspicuously silent
on the matter, as well as not having a definition for terms like
"recommended".

// darius

On Tue, Nov 16, 2021 at 03:42:52PM +0100, Philipp Tomsich wrote:

Darius,





On Tue, 16 Nov 2021 at 14:17, Darius Rad <darius@...> wrote:

Philipp,

The Common Software Interface concept seems like it could be a promising
idea, but at this point, that appears to be all it is: an idea. Whether
that idea is fully realized into something that is suitable as the
cornerstone of a platform remains to be seen. I think titling the platform
that way at this point is premature and sets up false expectations. You
said that "CSI was chosen as an unencumbered term", yet every time I have
heard it described, it was something along the lines of "CMSIS, but for
RISC-V", which, to me at least, carries a fair set of assumptions.

On the other hand, you said that a variety of things with respect to the
planning of the Common Software Interface have been communicated up through
leadership at RISC-V. If I understand correctly, that is a driving factor
in retitling the platform to match. If that is the case, it is a little
unclear to me what role this committee has had or is expected to have in
influencing this process. If RISC-V leadership has already decided that
this CSI approach will be followed, then I suppose they could also dictate
the name.

The Platforms HSC writing the specs is a left-over (committees only provide
governance) that is expected to be restructured in the future (once the
initial set of specifications are through the door) to push the actual
specification work down into TGs. Note that the responsibility for
delivering the Platforms lies with the Software HC, which still drives the
overall process on the strategic level with the HSC leadership focusing on
the tactical aspects and the content.

The overall structure of the specifications (i.e. the strategic goal)
consisting of:

- "Rich OS" specifications provides a rigid platform definition to
enable binary compatibility.
- "Deeply Embedded" specifications supporting a wide variety of platform
implementations (with mutual incompatibility down to the ISA-level) and a
unifying abstraction layer

is based on the apparent gaps in our specification landscape and has been
deliberated in late 2020 and early 2021 in the HSC, between the HSC and the
HC, and throughout the technical leadership. After reaching agreement on
this, the HSC leadership has been tasked with implementing this overall
structure (which they have made commendable progress on this year).

There have been plenty of things gone less than optimal in how the
specifications have been put together (in no small part due to the intense
time pressure of having a self-consistent draft for the rich-OS
specifications ready before Summit): most visibly, the introductory
sections that should clearly state the purpose of each specification and
rehash the product requirements to be addressed, are terse bordering on
absent. This is an area to be improved.

However, this terseness (and the need to close these gaps) should not
distract from the fact that we are building up two families of
specifications to address two specific market segments. The goal today is
to deliver on these two specifications, so we have a foundation and a
blueprint for future specifications. The overall blueprint of having one
specification with a binary compatibility mandate and another specification
with a source-code compatibility mandate creates a solid path into the
future, as any future Platforms can build on either model or mix-and-match
as needed.

When we created the Platform policy, we made sure to leave sufficient room
for new (and even unforeseen) Platforms to be requested and specified.
This was defined in full view of the fact that neither OS-A nor M/CSI would
cover everyone's needs and that the community will surprise us in how they
evolve the Platform concept.

It sounds like you already have some ideas for how you would like things to
evolve. I can only recommend that you participate actively in us getting
the current generation of documents into a rounded-off and mature state —
while engaging both with the HSC Chairs and us Software HC Chairs regarding
those evolutionary ideas. We are working to get a roadmap and planning
underway for "what comes next" for Platforms and any input into that
process is much valued.

Philipp,

I am aware of the history of the platform working group / task group /
subcommittee, as I have been regularly attending meetings since its
inception in 2019, although I have a different understanding in how things
got to where they are now. But that's not particularly relevant at this
point.

It was my expectation that the current iteration of the committee would
first and foremost be defining what a platform is. That is, coming up with
a clear and concise set of terminology, as well as a common structure and
framework for how platforms are defined. In the course of doing that, the
committee would also define a small number of concrete platforms (i.e.,
OS-A and M).

The closest thing that exists along those lines is the Platform Policy,
which in my opinion falls short in a number of ways. It is been my
observation that this shortcoming has created unnecessary confusion and
numerous fruitless discussions. Just in the last few weeks, there have
been discussions on the mailing list (regarding consistent terminology, and
concrete vs. intent requirements) that seems to me could have been
completely avoided with a better overall definition of a platform. I
suspect if you asked everyone in the committee "what is a platform", you
would get as many different answers, with some similarities, and,
crucially, some conflicting ideas.

With respect to the M / CSI platform, I think there are fundamental
questions that need a clear, definitive answer (in the specification, not
off hand in a meeting or email), in order to guide the process. Not least
of which is "what is a platform".

I have made comments and proposed edits to the policy document that have
been unanswered for a month. This has happened multiple times, and is
ongoing. I have also mentioned, multiple times, on this mailing list, that
I believe that the process for revising the policy document is cumbersome
and, more importantly, not working.

I would recommend, to you and to RISC-V in general, if they would like to
have community input then they should be receptive to it.

// darius

Regards,
Philipp.

I think evolving the platform previously called M will have some of the
same challenges I have mentioned previously. Inconsistency within and
between the Platform Policy, the Specification, and statements in the
meetings as well as terminology that is not clearly defined make it
difficult to make progress in improving the specification. For example,
the Platform Policy indicates that the purpose of a policy is to ensure
binary compatibility, but you are saying that the goal of the platform
previously called M is specifically not that. As another example, it has
been repeated stated that there are no optional requirements in the
Platform Specification, but there are many such requirements in the
platform previously called M. The Platform Policy is conspicuously silent
on the matter, as well as not having a definition for terms like
"recommended".

// darius


On Mon, Nov 15, 2021 at 12:10:33PM -0800, Kumar Sankaran wrote:

+ platforms mailing list



Regards

Kumar



*From:* Philipp Tomsich <philipp.tomsich@...>
*Sent:* Monday, November 15, 2021 9:25 AM
*To:* darius@...
*Cc:* Kumar Sankaran <ksankaran@...>
*Subject:* M-Platform/CSI-Base naming



Darius,



As indicated, I'd like to fully understand your thoughts on the M

platform

and how it could evolve. Note that defining this platform does not
preclude us from adding other deeply-embedded platforms in the future.



Maybe, to start, let me summarize what has been communicated already to
various stakeholders:

1. It will be based on the RVM profile (which gives us a lot of options

and

very few guarantees).

2. We want to provide source code compatibility (for some parts of the
source code).

The blueprint for this was ARM's CMSIS… i.e., a software interface spec
that allows portability for software on uCs in deeply embedded use cases.



Assumption 1 (RVM) precludes us from having anything resembling binary
compatibility.



Note that CSI was chosen as an unencumbered term to mean "Common Software
Interface".

Given that we'll have a large number of extensions to the basic CSI (e.g.
an abstraction of crypto-operations, security features, NN, etc.), the
model is similar to the ISA: a small CSI with many extensions for

specific

use-cases.



This plan and specification scope have been communicated all the way up

to

the BoD in early summer. The lack of a draft document should not

preclude

us from communicating this plan and scope to the ecosystem at Summit —

and

this should be what drives any discussion on the naming.



That said: please share your concerns and thoughts…



Philipp.

It is late in my timezone, so please excuse that I respond only to the
part that I feel is most critical to drive this forward.

On Tue, 16 Nov 2021 at 23:52, Darius Rad <darius@...> wrote:

It was my expectation that the current iteration of the committee would
first and foremost be defining what a platform is. That is, coming up with
a clear and concise set of terminology, as well as a common structure and
framework for how platforms are defined. In the course of doing that, the
committee would also define a small number of concrete platforms (i.e.,
OS-A and M).

The closest thing that exists along those lines is the Platform Policy,
which in my opinion falls short in a number of ways. It is been my
observation that this shortcoming has created unnecessary confusion and
numerous fruitless discussions. Just in the last few weeks, there have
been discussions on the mailing list (regarding consistent terminology, and
concrete vs. intent requirements) that seems to me could have been
completely avoided with a better overall definition of a platform. I
suspect if you asked everyone in the committee "what is a platform", you
would get as many different answers, with some similarities, and,
crucially, some conflicting ideas.

Well said and no disagreement there.

In fact, I have suggested to the committee leadership to improve on
these introductory sections and to improve the self-consistency in
doing so.
Unless we clearly answer basic questions—such as "What is a
Platform?", "What market segments and use cases does the give Platform
address?", "What is the Platform implementation vs. what is compatible
software?", etc.—we are clearly not done.

I expect that these structural topics will receive more attention in
the near future and would appreciate your assistance in closing these
gaps in the documents.
Let us sync up following the next Platform HSC (from my understanding,
some of the work to address these opens will be distributed then), so
I can get your feedback into the process.

With respect to the M / CSI platform, I think there are fundamental
questions that need a clear, definitive answer (in the specification, not
off hand in a meeting or email), in order to guide the process. Not least
of which is "what is a platform".

I have made comments and proposed edits to the policy document that have
been unanswered for a month. This has happened multiple times, and is
ongoing. I have also mentioned, multiple times, on this mailing list, that
I believe that the process for revising the policy document is cumbersome
and, more importantly, not working.

I must admit that I have not been following the deliberations
regarding the comments on the Policy (to my knowledge Kumar has been
looking into these), even though I am very interested in this topic,
as I helped draft the Policy document.
Let me reach out to the TPMs at RISC-V to see what the expected
process for dealing with comments against an approved Policy are.

Thanks,
Philipp.