[libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Lauri Kasanen]

Hi,

IBM has released the POWER10 ISA doc. It includes specifics on the
optional Power-compliant levels.

https://ibm.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0

Same, but wgettable, as the above only works in a browser:
https://ibm.box.com/shared/static/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

On Mon, May 11, 2020 at 6:33 PM Lauri Kasanen <cand@gmx.com> wrote:
>
> Hi,
>
> IBM has released the POWER10 ISA doc.

oo, major version-bump, ooo :)

> It includes specifics on the
> optional Power-compliant levels.

ahh thank you.  which section / page number?

> https://ibm.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0
>
> Same, but wgettable, as the above only works in a browser:
> https://ibm.box.com/shared/static/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0

star

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

ok found it, p9-10.
l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Yehowshua]

> On May 11, 2020, at 2:25 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 
>> IBM has released the POWER10 ISA doc.

OK - before we get confused on all this power non-sense any further - I’d like to stress that the ISA is currently committed at POWER3.0B.

POWER10 is an IBM processor family set to hit market 2021.

Why on earth IBM thought it was a good Idea to name a spec and implementation with conflicting numbers? Only God knows.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, May 11, 2020 at 7:31 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
>
>
> > On May 11, 2020, at 2:25 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> >
> >> IBM has released the POWER10 ISA doc.
>
> OK - before we get confused on all this power non-sense any further - I’d like to stress that the ISA is currently committed at POWER3.0B.

yehyeh.  right now, to stand a chance to hit oct 2020, we've cut FP,
cut vector, cut regfile stratification - everything.  absolute basic
processor.

> POWER10 is an IBM processor family set to hit market 2021.
>
> Why on earth IBM thought it was a good Idea to name a spec and implementation with conflicting numbers? Only God knows.

:)

we do however need to have the conversation with them, to plan ahead.

page xii (OpenPOWER Architecture Sandbox), i see where they're going...
"Developers are encour-aged to provide a means to disable custom extensions
to present an architecture that is supported by standard
system software and toolchain"

um... that's precisely what ISANS / ISAMUX is for!!

*smacks forehead*.

the language is nowhere near strong or clear enough.  "encouraged" is
inadequate.  it needs to be, "if you go one route, you follow these
procedures.  if you go the other route you follow _these_ procedures"

Alain, Yehowshua: we need to talk with Hugh about this.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Lauri Kasanen]

Hi,

The thing that stood out to me in the levels was BE/LE. An int or float
compatible Power processor must support BE, LE is optional at those
levels. A Linux level processor must support LE, BE is optional at that
level. However the Linux level requires SIMD.

So this means that our int+float processor must support BE.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Jacob Lifshay]

On Mon, May 11, 2020, 23:01 Lauri Kasanen <cand@gmx.com> wrote:

> Hi,
>
> The thing that stood out to me in the levels was BE/LE. An int or float
> compatible Power processor must support BE, LE is optional at those
> levels. A Linux level processor must support LE, BE is optional at that
> level. However the Linux level requires SIMD.
>
> So this means that our int+float processor must support BE.


not necessarily, it defines 4 compatibility levels, notice that all
features included in higher levels are not forbidden in lower levels, so we
could claim to be 100% compatible with the lowest level and we could still
implement nearly everything from higher levels, we just couldn't claim to
implement the named int+fp level. We could still claim to implement fp
instructions (assuming we actually do) and to be totally compatible with
LE-only int+fp (which we should probably ask OpenPower to add as a
supported level).

Note that the levels aren't strictly subsets of each other, so they're more
like named feature sets rather than levels.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Lauri Kasanen]

On Mon, 11 May 2020 23:27:38 -0700
Jacob Lifshay <programmerjake@gmail.com> wrote:

> On Mon, May 11, 2020, 23:01 Lauri Kasanen <cand@gmx.com> wrote:
>
> > Hi,
> >
> > The thing that stood out to me in the levels was BE/LE. An int or float
> > compatible Power processor must support BE, LE is optional at those
> > levels. A Linux level processor must support LE, BE is optional at that
> > level. However the Linux level requires SIMD.
> >
> > So this means that our int+float processor must support BE.
>
> not necessarily, it defines 4 compatibility levels, notice that all
> features included in higher levels are not forbidden in lower levels, so we
> could claim to be 100% compatible with the lowest level

No, we couldn't. The lowest level, int only, has the same BE
requirement.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Jacob Lifshay]

On Mon, May 11, 2020, 23:43 Lauri Kasanen <cand@gmx.com> wrote:

> On Mon, 11 May 2020 23:27:38 -0700
> Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > On Mon, May 11, 2020, 23:01 Lauri Kasanen <cand@gmx.com> wrote:
> >
> > > Hi,
> > >
> > > The thing that stood out to me in the levels was BE/LE. An int or float
> > > compatible Power processor must support BE, LE is optional at those
> > > levels. A Linux level processor must support LE, BE is optional at that
> > > level. However the Linux level requires SIMD.
> > >
> > > So this means that our int+float processor must support BE.
> >
> > not necessarily, it defines 4 compatibility levels, notice that all
> > features included in higher levels are not forbidden in lower levels, so
> we
> > could claim to be 100% compatible with the lowest level
>
> No, we couldn't. The lowest level, int only, has the same BE
> requirement.
>

Ok, sounds like we definitely need to talk to OpenPower about this.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

On Tue, May 12, 2020 at 8:07 AM Jacob Lifshay <programmerjake@gmail.com> wrote:

> > No, we couldn't. The lowest level, int only, has the same BE
> > requirement.
> >
>
> Ok, sounds like we definitely need to talk to OpenPower about this.

we need to talk to them, however it would be good to review and agree
what we talk about, before contacting them, because the people on the
openpower-hdl-cores low-traffic list are extremely busy.

they're sufficiently busy that the core engineers (the ones in IBM,
responsible for the POWER architecture) have not yet responded -
publicly - to our ISAMUX/NS letter
(https://libre-riscv.org/isa_conflict_resolution/isamux_isans/), and
ISAMUX/NS is an extremely important part (absolutely mission-critical)
of what we need to do.

hugh has been working hard to encourage them to engage on the list: i
believe it'll be the first time that they've ever publicly interacted
with a libre/open community.

so we therefore need to treat them as a critical strategic resource
and plan our responses very carefully.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Hendrik Boom]

On Tue, May 12, 2020 at 08:56:15AM +0100, Luke Kenneth Casson Leighton wrote:
> 
> they're sufficiently busy that the core engineers (the ones in IBM,
> responsible for the POWER architecture) have not yet responded -
> publicly - to our ISAMUX/NS letter
> (https://libre-riscv.org/isa_conflict_resolution/isamux_isans/), and
> ISAMUX/NS is an extremely important part (absolutely mission-critical)
> of what we need to do.

Just noticing that document is RISCV-oriented, and nowhere mentions POWER at 
all.

Should it be changed to explicitly refer to the POWER architecture as one that 
should acquire the CSR proposal?

-- hendrik

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

On Tue, May 12, 2020 at 2:55 PM Hendrik Boom <hendrik@topoi.pooq.com> wrote:
>
> On Tue, May 12, 2020 at 08:56:15AM +0100, Luke Kenneth Casson Leighton wrote:
> >
> > they're sufficiently busy that the core engineers (the ones in IBM,
> > responsible for the POWER architecture) have not yet responded -
> > publicly - to our ISAMUX/NS letter
> > (https://libre-riscv.org/isa_conflict_resolution/isamux_isans/), and
> > ISAMUX/NS is an extremely important part (absolutely mission-critical)
> > of what we need to do.
>
> Just noticing that document is RISCV-oriented, and nowhere mentions POWER at
> all.

sorry, browser-auto-complete history: this one.
https://libre-soc.org/openpower/isans_letter/

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Hendrik Boom]

On Tue, May 12, 2020 at 03:46:33PM +0100, Luke Kenneth Casson Leighton wrote:
> On Tue, May 12, 2020 at 2:55 PM Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> >
> > On Tue, May 12, 2020 at 08:56:15AM +0100, Luke Kenneth Casson Leighton wrote:
> > >
> > > they're sufficiently busy that the core engineers (the ones in IBM,
> > > responsible for the POWER architecture) have not yet responded -
> > > publicly - to our ISAMUX/NS letter
> > > (https://libre-riscv.org/isa_conflict_resolution/isamux_isans/), and
> > > ISAMUX/NS is an extremely important part (absolutely mission-critical)
> > > of what we need to do.
> >
> > Just noticing that document is RISCV-oriented, and nowhere mentions POWER at
> > all.
> 
> sorry, browser-auto-complete history: this one.
> https://libre-soc.org/openpower/isans_letter/

This one reads much better.  It argues why standardising the way the PowerPC 
ISA is essential.

But it lacks technical detail about the mechanism you're proposing.  It mostly 
rules out a lot of options you're not proposing.  Perhaps that's elsewhere?

-- hendrik

> 
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

On Tue, May 12, 2020 at 4:11 PM Hendrik Boom <hendrik@topoi.pooq.com> wrote:

> But it lacks technical detail about the mechanism you're proposing.

that's correct.  the first step is to seek consensus that *a*
mechanism is needed - at all.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

On Tue, May 12, 2020 at 7:00 AM Lauri Kasanen <cand@gmx.com> wrote:
>
> Hi,
>
> The thing that stood out to me in the levels was BE/LE. An int or float
> compatible Power processor must support BE, LE is optional at those
> levels. A Linux level processor must support LE, BE is optional at that
> level. However the Linux level requires SIMD.
>
> So this means that our int+float processor must support BE.

michael and i have added BE byte-flipping into the instruction decode,
which is code used by both the simulator and the hardware.

we need BE because without it we cannot detect Compressed, VBLOCK or
SVPrefix modes in the same instruction stream as 32-bit operations,
because only in BE mode will the opcode be in the front 2 bytes in the
sequential bytes read from the instruction stream.

see https://libre-soc.org/openpower/

where it is mentioned that we will need to take 8 major opcodes to do
this: 2 bits per "mode".

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

On Tue, May 12, 2020 at 7:00 AM Lauri Kasanen <cand@gmx.com> wrote:

> level. However the Linux level requires SIMD.

this is more serious.  the implementation burden of POWER SIMD
compliance is absolutely massive.  a quick count from figure 91 i
estimate 600 instructions dedicated to INT and FP SIMD.

the scalar instruction set is much more manageable: there's 378
opcodes from microwatt CSV files, then there's 20 FP LD/ST, and
estimated 70 or so FP arithmetic and 8 or so status registers.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Lauri Kasanen]

On Tue, 12 May 2020 08:50:09 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> On Tue, May 12, 2020 at 7:00 AM Lauri Kasanen <cand@gmx.com> wrote:
>
> > level. However the Linux level requires SIMD.
>
> this is more serious.  the implementation burden of POWER SIMD
> compliance is absolutely massive.  a quick count from figure 91 i
> estimate 600 instructions dedicated to INT and FP SIMD.
>
> the scalar instruction set is much more manageable: there's 378
> opcodes from microwatt CSV files, then there's 20 FP LD/ST, and
> estimated 70 or so FP arithmetic and 8 or so status registers.

It's just a name though, even the doc says you can run Linux on the
lower levels. It's fine for libresoc to be at the int+fp level, and
include optional features from above that are useful. I just wanted to
point out the BE/LE requirement as it surprised me at least.

BE for instructions is not full BE, as data changes too.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

On Tue, May 12, 2020 at 9:22 AM Lauri Kasanen <cand@gmx.com> wrote:

> It's just a name though, even the doc says you can run Linux on the
> lower levels.

yes... you can.... however note the phrase "Linux Compliancy".  this
means that they have plans for actual Compliance Test Suites.  this in
turn will mean that

one option therefore is to have a software-driven emulator mode for
SIMD.  this would be our responsibility to write and maintain.

> It's fine for libresoc to be at the int+fp level, and
> include optional features from above that are useful. I just wanted to
> point out the BE/LE requirement as it surprised me at least.

yeh - in the West it is just not known that the majority of S.E.Asia
industry runs on BE hardware that is often 40 years old (VME Bus).

> BE for instructions is not full BE, as data changes too.

i recall (and could be wrong about) seeing that there's different
bits, one covering instructions, one covering data.  would need to
read them more closely.  are you saying that the BE-for-instructions
bit will flip *data* order as well?

 See Section 1.10 of Book I and its first two subsections. Also see
the description
 of the ILE field of the LPCR in Section 2.2 of Book III and the
description of the
 LE bit of the MSR in Section 4.2.1 of Book III.

p1122:

Interrupt Little-Endian (ILE)
The contents of the ILE bit are copied into
MSRLE by interrupts that set MSRHV to 0 (see

p1146:

63 Little-Endian Mode (LE)
0 The thread is in Big-Endian mode.
1 The thread is in Little-Endian mode.


if we are to flip the instruction stream to BE mode (to support the
SVP/C/VBLOCK capability) we definitely don't want data to flip as
well.

bottom line: if there *isn't* a separate bit for instructions-BE/LE
and data-BE/LE, we definitely need one.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Lauri Kasanen]

On Tue, 12 May 2020 09:33:52 +0100
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> i recall (and could be wrong about) seeing that there's different
> bits, one covering instructions, one covering data.  would need to
> read them more closely.  are you saying that the BE-for-instructions
> bit will flip *data* order as well?

I'm not that familiar with the low level details, I was speaking from
the compliance POV. Aka BE instructions only is not enough to be
compliant. If there are plans to support full BE, then it'd be fine.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] PowerISA 3.1 (Power10) spec released

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Tue, May 12, 2020 at 9:49 AM Lauri Kasanen <cand@gmx.com> wrote:
>
> On Tue, 12 May 2020 09:33:52 +0100
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>
> > i recall (and could be wrong about) seeing that there's different
> > bits, one covering instructions, one covering data.  would need to
> > read them more closely.  are you saying that the BE-for-instructions
> > bit will flip *data* order as well?
>
> I'm not that familiar with the low level details, I was speaking from
> the compliance POV. Aka BE instructions only is not enough to be
> compliant. If there are plans to support full BE, then it'd be fine.

ok so, combining page x "Linux Optional Features"

Big Endian (BE)
(LE is required for LCS. Linux supporting
LCS is 64b LE Linux.)

this basically defines - *defines* - the Linux Compliancy Subset - as
64 bit LE, with BE being optional


and page xi "Scalar Float Optional Features":

Little Endian (LE)
(BE is required for SFFS and SFS. Linux
supporting SFFS and SFS is 32b BE
Linux.)

this *defines* the "Scalar Fixed (+Float) Compliancy Subset" - both
SFFS and SFS - as *32-bit* BE, with **LE** being optional - the
*opposite* of the 64-bit case.


ah.

i recognise this pattern.  i know what this is for.

* AIX compliance is for IBM internal support of AIX - running on IBM POWER9
* Linux compliance is for debian / fedora ppc64le - running on IBM POWER9
* SFFS compliance is for NXP Quorl (2.07B compliant) such as that used
in powerpc-notebook.org
* SFS compliance is for NXP MCP5xxx processors - 32-bit non-FP-based
embedded (32 to 300 mhz)

(there's probably other processor products out there which match with
those 4 levels, i just don't know what they are).

so they're recognising the various product ranges that already exist
in the various market(s).  which is sensible.

what they haven't had time to do is take into full consideration our
design, which needs to be GNU/Linux compliant but not completely
overwhelm both us and the power consumption and the die area, only to
support instructions suited to high-end server and supercomputing
markets (VSX and VMX), placing even the Quad-Core ASIC into markets
it's *never going to be in*.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev