linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* Re: [hw-dev] UNIX-Class Platform Specification Working Group
       [not found] <CAGjNQTpOQj_tsHC3bWRwk=y7szhR85qhHQi6LxWGAhe4CVnuSQ@mail.gmail.com>
@ 2019-04-03  1:53 ` Palmer Dabbelt
  0 siblings, 0 replies; only message in thread
From: Palmer Dabbelt @ 2019-04-03  1:53 UTC (permalink / raw)
  To: delisvhdl; +Cc: Atish Patra, linux-riscv, sw-dev, isa-dev, hw-dev

On Tue, 02 Apr 2019 10:57:38 PDT (-0700), delisvhdl@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 <palmer@sifive.com>:
>
>> 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.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "RISC-V HW Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to hw-dev+unsubscribe@groups.riscv.org.
>> To post to this group, send email to hw-dev@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
>> .
>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-04-03  1:53 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAGjNQTpOQj_tsHC3bWRwk=y7szhR85qhHQi6LxWGAhe4CVnuSQ@mail.gmail.com>
2019-04-03  1:53 ` [hw-dev] UNIX-Class Platform Specification Working Group Palmer Dabbelt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).