[libre-riscv-dev] PPC on Talos and Playstation 3

[libre-riscv-dev] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

So I was wondering how to run unit tests for the PPC FPU. We can obviously do this on the Talos server, but also playstation 3. 

I have some old PPC Macs, but they are 32 bit not 64 bit. 

Sony’s playstation 3 however is ppc64. Also, Sony officially supported Linux on PS3 FAT models only which you can pick up on eBay for $50 - $70.

So I think this is a good route to explore if anyone needs immediate/direct access to PPC64 for unit testing. I’m considering ordering one myself.

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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

Sony’s official link.

https://www.playstation.com/ps3-openplatform/

Ubuntu was officially supported by Sony, so I imagine Debian should be a no brainer.

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] PPC on Talos and Playstation 3

[Jacob Lifshay]

On Sun, Mar 29, 2020, 13:18 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

> So I was wondering how to run unit tests for the PPC FPU.


I'm planning on making files containing the list of test cases and expected
outputs by using the talos. That way, the unit tests can be run on any
computer without requiring a power processor.

We can obviously do this on the Talos server, but also playstation 3.
>
> I have some old PPC Macs, but they are 32 bit not 64 bit.
>
> Sony’s playstation 3 however is ppc64. Also, Sony officially supported
> Linux on PS3 FAT models only which you can pick up on eBay for $50 - $70.
>

another option is one of the power macs, since they are 64-bit and can have
multiple faster cores (unlike the PS3's single power core -- the cell
broadband engine cores are not power cores) and are much more easily
upgradable. I've seen some for around $100.

I know debian works on them since I used to have one but got rid of it when
moving several years ago.

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] PPC on Talos and Playstation 3

[Luke Kenneth Casson Leighton]

On Sun, Mar 29, 2020 at 9:18 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> So I was wondering how to run unit tests for the PPC FPU. We can obviously do this on the Talos server, but also playstation 3.
>
> I have some old PPC Macs, but they are 32 bit not 64 bit.
>
> Sony’s playstation 3 however is ppc64. Also, Sony officially supported Linux on PS3 FAT models only which you can pick up on eBay for $50 - $70.

https://wiki.debian.org/PS3

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] PPC on Talos and Playstation 3

[Lauri Kasanen]

On Sun, 29 Mar 2020 20:17:49 +0000
"Immanuel, Yehowshua U" <yimmanuel3@gatech.edu> wrote:

> So I was wondering how to run unit tests for the PPC FPU. We can obviously do this on the Talos server, but also playstation 3.
>
> I have some old PPC Macs, but they are 32 bit not 64 bit.
>
> Sony’s playstation 3 however is ppc64. Also, Sony officially supported Linux on PS3 FAT models only which you can pick up on eBay for $50 - $70.
>
> So I think this is a good route to explore if anyone needs immediate/direct access to PPC64 for unit testing. I’m considering ordering one myself.

Remember that Sony blocked OtherOS in a specific firmware version, and
newer firmwares were required for running newer games. So finding a PS3
that can be used will be hard.

However, WiiUs are a viable option for recent-ish power hw for cheap.

- 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] PPC on Talos and Playstation 3

[Jacob Lifshay]

On Sun, Mar 29, 2020, 23:55 Lauri Kasanen <cand@gmx.com> wrote:

> On Sun, 29 Mar 2020 20:17:49 +0000
> "Immanuel, Yehowshua U" <yimmanuel3@gatech.edu> wrote:
>
> > So I was wondering how to run unit tests for the PPC FPU. We can
> obviously do this on the Talos server, but also playstation 3.
> >
> > I have some old PPC Macs, but they are 32 bit not 64 bit.
> >
> > Sony’s playstation 3 however is ppc64. Also, Sony officially supported
> Linux on PS3 FAT models only which you can pick up on eBay for $50 - $70.
> >
> > So I think this is a good route to explore if anyone needs
> immediate/direct access to PPC64 for unit testing. I’m considering ordering
> one myself.
>
> Remember that Sony blocked OtherOS in a specific firmware version, and
> newer firmwares were required for running newer games. So finding a PS3
> that can be used will be hard.
>

> However, WiiUs are a viable option for recent-ish power hw for cheap.
>

The Wii U is a tri-core 32-bit PPC with 2GB of ddr3. Additionally, Nintendo
is not likely to support installing custom software.

I personally think Power Macs are probably the best option since they can
use standard PC hardware (eg. ram, sata disk, pci cards (maybe pcie?),
external display, usb, ethernet), they actually are designed to be able to
install your own OS, they have 1, 2, or 4 core 64-bit Power processors, and
they are relatively inexpensive -- I saw one for $100 last I checked.

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] PPC on Talos and Playstation 3

[Lauri Kasanen]

On Mon, 30 Mar 2020 00:12:40 -0700
Jacob Lifshay <programmerjake@gmail.com> wrote:

> On Sun, Mar 29, 2020, 23:55 Lauri Kasanen <cand@gmx.com> wrote:
> > Remember that Sony blocked OtherOS in a specific firmware version, and
> > newer firmwares were required for running newer games. So finding a PS3
> > that can be used will be hard.
> >
> > However, WiiUs are a viable option for recent-ish power hw for cheap.
>
> The Wii U is a tri-core 32-bit PPC with 2GB of ddr3. Additionally, Nintendo
> is not likely to support installing custom software.
>
> I personally think Power Macs are probably the best option since they can
> use standard PC hardware (eg. ram, sata disk, pci cards (maybe pcie?),
> external display, usb, ethernet), they actually are designed to be able to
> install your own OS, they have 1, 2, or 4 core 64-bit Power processors, and
> they are relatively inexpensive -- I saw one for $100 last I checked.

The specs quote 64-bit FPU, so it's not entirely 32-bit. Nintendo
doesn't need to, they have abandoned the console, and in its last state
it was still hackable, unlike the PS3. Therefore it's safe to buy any
(NTSC, I haven't checked PAL) WiiU if you intend to hack it, vs very
careful checking to find that rare low-firmware PS3.

PowerMacs are fine, though old and power-hogging.

- 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] PPC on Talos and Playstation 3

[Jacob Lifshay]

On Mon, Mar 30, 2020, 00:31 Lauri Kasanen <cand@gmx.com> wrote:

> On Mon, 30 Mar 2020 00:12:40 -0700
> Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > On Sun, Mar 29, 2020, 23:55 Lauri Kasanen <cand@gmx.com> wrote:
> > > Remember that Sony blocked OtherOS in a specific firmware version, and
> > > newer firmwares were required for running newer games. So finding a PS3
> > > that can be used will be hard.
> > >
> > > However, WiiUs are a viable option for recent-ish power hw for cheap.
> >
> > The Wii U is a tri-core 32-bit PPC with 2GB of ddr3. Additionally,
> Nintendo
> > is not likely to support installing custom software.
> >
> > I personally think Power Macs are probably the best option since they can
> > use standard PC hardware (eg. ram, sata disk, pci cards (maybe pcie?),
> > external display, usb, ethernet), they actually are designed to be able
> to
> > install your own OS, they have 1, 2, or 4 core 64-bit Power processors,
> and
> > they are relatively inexpensive -- I saw one for $100 last I checked.
>
> The specs quote 64-bit FPU, so it's not entirely 32-bit.


Normally, the size of a pointer or general-purpose integer register is used
to determine 32 or 64-bit rather than the size of the FP unit since nearly
every processor more powerful than a microcontroller supports 64-bit FP.
even the 8086 (16-bit) supports 64-bit floating point (or even 80-bit) with
the 8087 math coprocessor. Also, recent intel processors support 512-bit FP
registers (the avx512 instruction set), but it's only a 64-bit processor.

Nintendo
> doesn't need to, they have abandoned the console, and in its last state
> it was still hackable, unlike the PS3. Therefore it's safe to buy any
> (NTSC, I haven't checked PAL) WiiU if you intend to hack it, vs very
> careful checking to find that rare low-firmware PS3.
>

From some searching I found a linux port for the WiiU, however, it only
supports booting 1 core.

https://gitlab.com/linux-wiiu/linux-wiiu#device-support

The main benefit of Power Macs is the software's highly likely to work,
whereas both the WiiU and PS3 are less likely to.


> PowerMacs are fine, though old and power-hogging.
>

yup. :)

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] PPC on Talos and Playstation 3

[Lauri Kasanen]

On Mon, 30 Mar 2020 00:52:31 -0700
Jacob Lifshay <programmerjake@gmail.com> wrote:

> Normally, the size of a pointer or general-purpose integer register is used
> to determine 32 or 64-bit rather than the size of the FP unit since nearly
> every processor more powerful than a microcontroller supports 64-bit FP.
> even the 8086 (16-bit) supports 64-bit floating point (or even 80-bit) with
> the 8087 math coprocessor. Also, recent intel processors support 512-bit FP
> registers (the avx512 instruction set), but it's only a 64-bit processor.

Aiye, but the context was running 64-bit fpu code, and with an embedded
cpu it's possible it would not have such.

- 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] PPC on Talos and Playstation 3

[Jacob Lifshay]

On Mon, Mar 30, 2020, 01:04 Lauri Kasanen <cand@gmx.com> wrote:

> On Mon, 30 Mar 2020 00:52:31 -0700
> Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > Normally, the size of a pointer or general-purpose integer register is
> used
> > to determine 32 or 64-bit rather than the size of the FP unit since
> nearly
> > every processor more powerful than a microcontroller supports 64-bit FP.
> > even the 8086 (16-bit) supports 64-bit floating point (or even 80-bit)
> with
> > the 8087 math coprocessor. Also, recent intel processors support 512-bit
> FP
> > registers (the avx512 instruction set), but it's only a 64-bit processor.
>
> Aiye, but the context was running 64-bit fpu code, and with an embedded
> cpu it's possible it would not have such.
>

yeah, I guess.

Sorry if I sound overly negative.

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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

@Jacon - If I can manipulate 64bit floats on my 32 bit ppc Mac - is that acceptable for testing the FPU?

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] PPC on Talos and Playstation 3

[Jacob Lifshay]

On Mon, Mar 30, 2020, 11:13 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

> @Jacon - If I can manipulate 64bit floats on my 32 bit ppc Mac - is that
> acceptable for testing the FPU?
>

Assuming you meant @Jacob.

32-bit ppc should be sufficient for just testing the FPU if you already
have the hardware, but 64-bit ppc64 is preferred.

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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

Before I try my hand at an FPU,

Some questions:
 - Do we have any FPU attempt in nMigen, Verilog, or some other language yet that I should be aware of?
 - The POWER ISA 3.0 PDF doc specifies an IEEE 745-1985 compliant mode as well as a faster non-compliant mode - I’m guessing we have to implement both?
 - I imagine your RUST algebraics library should be useful for this?
 - how many stages should I have for the FPU - is there a sweetspot?
 - We’re doing a reconfigureable FPU correct? What bit modes does it support?

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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

I see this:

https://salsa.debian.org/Kazan-team/simple-soft-float

But it looks like no HDL so far…

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] PPC on Talos and Playstation 3

[Luke Kenneth Casson Leighton]

On Mon, Mar 30, 2020 at 7:35 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:

> Before I try my hand at an FPU,

yehowshua, you're aware that by choosing to do this, that you'll be
committing over 6 months of your life to the task?  that's typically
how long it takes (if not longer).

> Some questions:
>  - Do we have any FPU attempt in nMigen, Verilog, or some other language yet that I should be aware of?
>  - The POWER ISA 3.0 PDF doc specifies an IEEE 745-1985 compliant mode as well as a faster non-compliant mode - I’m guessing we have to implement both?

sigh.  probably.

>  - how many stages should I have for the FPU - is there a sweetspot?

we have a trade-off between maximum clock rate and the number of
Function Units (Reservation Stations) needed.  so if there are 16-long
pipelines, then that *REQUIRES* 16 Function Units, in order to keep
them fully occupied and still be able to re-associate the result with
the correct FU when it comes back out the pipeline.

if the number of FUs increases too much, we have a problem with the
size of the Dependency Matrices.

i really do not want to go above around 20 FUs.  that's still pushing it.

* 6 to 8 of those will be LOAD/STORE.
* at least 2 will be Branch.
* at least 2 will be for predication.

this only leaves 8 (EIGHT!) for ALU operations, which in turn means
that pipelines really cannot go about 8 stages, and that we cannot
have separate FP and INT Function Units.


>  - We’re doing a reconfigureable FPU correct? What bit modes does it support?

literally anything.  it's defined in a single python dictionary, with
the mantissa and exponent being specified as parameters, by way of a
lookup (the bitwidth) as the key of the python dictionary.

one line of code.

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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

> yehowshua, you're aware that by choosing to do this, that you'll be
> committing over 6 months of your life to the task?  that's typically
> how long it takes (if not longer).

Oh wow! Why so long - I was thinking maybe 4 weeks…

At a minimum, I’d like to at least see how well Bluespec handles FPU configuration.
The maintainer of BSC has been quite helpful in general - so I should him or her just how flexible is BSC for specifying an FPU…

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] PPC on Talos and Playstation 3

[Luke Kenneth Casson Leighton]

On Mon, Mar 30, 2020 at 7:57 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> > yehowshua, you're aware that by choosing to do this, that you'll be
> > committing over 6 months of your life to the task?  that's typically
> > how long it takes (if not longer).
>
> Oh wow! Why so long

https://git.libre-riscv.org/?p=ieee754fpu.git;a=shortlog;pg=19
then page back and watch the months go by.

> - I was thinking maybe 4 weeks…

no chance.  we started in february, last year, working from jon
dawson's verilog code and hand-converting it to nmigen.  we were
delighted when, a week later, we had working IEEE754 FP add.

by around 2 months we had MUL and a decent pipeline structure.  at
some point i worked out how to parameterise the code.

at least 6 weeks were spent writing unit tests.

FPDIV took about 2 months: Jacob wrote some code that does div *and*
sqrt *and* rsqrt, that was about 5 weeks i think?  then it took me
about 3 weeks to join it together into FP (jacob's code was
fixed-integer).

then i added integer to fp and fp to integer, and class and FCVT,
those all took around... 2 and a half weeks i think, including unit
tests.

michael recently did FPMAX, FPCMP etc. which was... about a week.

we still have to do SIN, COS, ATAN2, ROOT3, POW, LOG, LOG1P, ACOS and
more.  this will be about another 2 months.


> At a minimum, I’d like to at least see how well Bluespec handles FPU configuration.

great - just remember that we're under time pressure and so anything
that means "team has to learn a new language which is KNOWN to cause
massive problems due to its insanely high barrier to entry" has to be
excluded from going into the ASIC.

> The maintainer of BSC has been quite helpful in general - so I should him or her just how flexible is BSC for specifying an FPU…

is that Niraj?  he's really good.

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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

On Mar 30, 2020, at 3:09 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> we still have to do SIN, COS, ATAN2, ROOT3, POW, LOG, LOG1P, ACOS and
> more.  this will be about another 2 months.

Ok. Cool. Also, I’m guessing we still have to support POWER’s non-IEEE mode?

It looks like all we’ve got is 754 support at the moment..

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] PPC on Talos and Playstation 3

[Luke Kenneth Casson Leighton]

On Mon, Mar 30, 2020 at 8:20 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:

> Ok. Cool. Also, I’m guessing we still have to support POWER’s non-IEEE mode?

optional.  however we'll need to add our own modes: Khronos / Vulkan Compliance.

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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

optional.  however we'll need to add our own modes: Khronos / Vulkan Compliance.

Ah. Gotcha. So do we even NEED to test on ppc64?
You can test 754 compliance on most anything.

If we opt out of the ppc mode - then I imagine we don’t need PPC specific testing for the FPU.
Is it possible to invoke PPC FPU mode through the instruction set?

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] PPC on Talos and Playstation 3

[Jacob Lifshay]

On Mon, Mar 30, 2020, 12:35 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

>
> optional.  however we'll need to add our own modes: Khronos / Vulkan
> Compliance.
>
> Ah. Gotcha. So do we even NEED to test on ppc64?
> You can test 754 compliance on most anything.
>
> If we opt out of the ppc mode - then I imagine we don’t need PPC specific
> testing for the FPU.
> Is it possible to invoke PPC FPU mode through the instruction set?
>

We still have to implement all the extra status flags that Power defines,
since they are still used even in IEEE 754 compliant mode.

What needs testing is making sure simple-soft-float calculates all the
Power-specific status flags correctly, so I will be creating a bunch of
test cases on PPC hardware such that all the test cases can then be run on
any computer including x86. The HDL can then be designed to match
simple-soft-float without requiring PPC hardware to run any tests because
simple-soft-float will be verified to be correct.

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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

> We still have to implement all the extra status flags that Power defines,

Makes sense to me!

_______________________________________________
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] PPC on Talos and Playstation 3

[Luke Kenneth Casson Leighton]

On Mon, Mar 30, 2020 at 8:35 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
> optional.  however we'll need to add our own modes: Khronos / Vulkan Compliance.
>
> Ah. Gotcha. So do we even NEED to test on ppc64?

yes absolutely.  otherwise, how will we know - for sure - that the HDL
is properly - and fully - ppc64 compliant?

> You can test 754 compliance on most anything.

except for PPC rounding modes and exception handling.  except that
IEEE754 compliance is *NOT* fully and exactly defined.  different
architectures have entirely different rules for rounding modes,
entirely different rules for NaN, and entirely different rules about
what and whether exceptions should be raised.


> If we opt out of the ppc mode -

ah no.  we absolutely have to have compliance with the requirements
set by the OpenPOWER Foundation.  otherwise we are not legally
permitted to use the name "POWER" associated with the project.

> then I imagine we don’t need PPC specific testing for the FPU.
> Is it possible to invoke PPC FPU mode through the instruction set?

it has to be enabled "by default".

we're negotiating with the OpenPOWER Foundation for the right to also
have a *Khronos* (Vulkan) Compliance Mode (as explained here:
https://libre-riscv.org/openpower/isans_letter/)

the fact that the "non IEEE mode" exists at all on POWER is a good sign.

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] PPC on Talos and Playstation 3

[Jacob Lifshay]

On Mon, Mar 30, 2020, 11:36 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

> Before I try my hand at an FPU,
>
> Some questions:
>  - Do we have any FPU attempt in nMigen, Verilog, or some other language
> yet that I should be aware of?
>

yes, https://git.libre-riscv.org/?p=ieee754fpu.git;a=summary

 - The POWER ISA 3.0 PDF doc specifies an IEEE 745-1985 compliant mode as
> well as a faster non-compliant mode - I’m guessing we have to implement
> both?
>

I was assuming we'd just implement them both as fully IEEE 754 compliant,
unless the noncompliant mode mandates something incompatible with IEEE 754
such as flushing denormals to zero.

 - I imagine your RUST algebraics library should be useful for this?
>

Assuming you mean simple-soft-float, since algebraics is basically a exact
real number arithmetic library rather than a IEEE 754 library.
I hope so, i'm currently adding support for power-specific status flags and
proper NaN payload propagation, which are the last two things needed to be
fully Power compliant (assuming no bugs). It is currently RISC-V compliant
since RISC-V doesn't have extra status flags or NaN payload propagation.

 - how many stages should I have for the FPU - is there a sweetspot?
>

for add/sub/mul, somewhere around 3 or 4, for div/sqrt/recip-sqrt more is
ok, maybe 8-10?

 - We’re doing a reconfigureable FPU correct? What bit modes does it
> support?
>

4x16-bit, 2x32-bit, 64-bit. We're planning on having 2 64-bit units. The
FPU should be designed to reuse the reconfigurable integer multiplier since
that's most of the logic in fpmul or fma.

Also, the FP divider should also be shared with integer div/rem. For a
working pipelined integer/fixed-point div/rem/sqrt/recip-sqrt unit, see:
https://git.libre-riscv.org/?p=ieee754fpu.git;a=tree;f=src/ieee754/div_rem_sqrt_rsqrt;h=f00513f47bd2a839de0ac79c578fd94d1b73e6b3;hb=HEAD


> Yehowshua
>
> _______________________________________________
> 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] PPC on Talos and Playstation 3

[Luke Kenneth Casson Leighton]

On Mon, Mar 30, 2020 at 8:01 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> On Mon, Mar 30, 2020, 11:36 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
> wrote:
>
> > Before I try my hand at an FPU,
> >
> > Some questions:
> >  - Do we have any FPU attempt in nMigen, Verilog, or some other language
> > yet that I should be aware of?
> >
>
> yes, https://git.libre-riscv.org/?p=ieee754fpu.git;a=summary

sorry, missed this question.  yehowshua: we have a *95% completed*
IEEE754 FPU already.  we don't need another one.  we _do_ however need
a formal proof of the one that we already have, plus adding POWER
rounding modes to the one that we already have.

> I was assuming we'd just implement them both as fully IEEE 754 compliant,
> unless the noncompliant mode mandates something incompatible with IEEE 754
> such as flushing denormals to zero.

have to check.  i wasn't aware the mode existed until 5 minutes ago.  3.0B p126

bit 61:

Floating-Point Non-IEEE Mode (NI)
Floating-point non-IEEE mode is optional. If
floating-point non-IEEE mode is not imple-
mented, this bit is treated as reserved, and the
remainder of the definition of this bit does not
apply.
If floating-point non-IEEE mode is imple-
mented, this bit has the following meaning.
0 The processor is not in floating-point
     non-IEEE mode (i.e., all floating-point
     operations conform to the IEEE standard).
1 The processor is in floating-point
     non-IEEE mode.

so it's optional, thank goodness.

> 4x16-bit, 2x32-bit, 64-bit. We're planning on having 2 64-bit units. The
> FPU should be designed to reuse the reconfigurable integer multiplier since
> that's most of the logic in fpmul or fma.

yes.  this means:

* splitting the FPU pipeline into pre- and post- processing pipelines
* feeding the (partial) results from the FP pre-processing pipeline *back*
  into (side-channel, non-Dependency-tracked) Function Units
* those request an InternalOp "MUL" (integer MUL) and mark the results
  as belonging to an FP operation
* such that when the INT MUL finishes, the results get pushed back
  to the Function Units again, now into the FINAL stage..
* which is to perform the FPU post-processing pipeline

so the data goes THREE TIMEs through the Function Units, going through
THREE separate pipelines.

> Also, the FP divider should also be shared with integer div/rem.

... and therefore the exact same trick as above will be needed.

interestingly this means that, hypothetically, we can do integer SQRT
and ineger RSQRT.  the hardware exists: it's just that there's no
opcodes in POWER to get access to them.

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] PPC on Talos and Playstation 3

[Michael Nolan]

On 3/30/20 3:52 AM, Jacob Lifshay wrote:
>
>  From some searching I found a linux port for the WiiU, however, it only
> supports booting 1 core.
>
> https://gitlab.com/linux-wiiu/linux-wiiu#device-support
>
> The main benefit of Power Macs is the software's highly likely to work,
> whereas both the WiiU and PS3 are less likely to.

Yehowshua sent me a couple of links to some G5 powermacs:

a 2 socket PowerMac G5 for $130 (incl S+H)

an iMac G5 with dead/dying display for $81

(not including ebay links because I didn't think that was a great idea 
on a public mailing list, will send via private email if you want)

Would LibreSoC be interested in buying either of these via me or one of 
our other members?

--Michael


_______________________________________________
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] PPC on Talos and Playstation 3

[Luke Kenneth Casson Leighton]

On Tuesday, March 31, 2020, Michael Nolan <mtnolan2640@gmail.com> wrote:

>
> Would LibreSoC be interested in buying either of these via me or one of
> our other members?


with access to the TALOS II server (which i can give you access to, and you
probably need it) these machines on ebay, unless they are POWER9 compliant,
are a bit of a distraction unfortunately, because they will be POWER8
(v2.07) or older.

the NEC processors from the powerpc-notebook project *might* be POWER9.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
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] PPC on Talos and Playstation 3

[Immanuel, Yehowshua U]

> the NEC processors from the powerpc-notebook project *might* be POWER9.

I looked into this - these are actually NXP processors. NXP T2080 to be precise.
The data sheet is a little unhelpful - not making it clear what POWER it is.

Anyways - the processor itself has some similarities to our goals. It might be a good idea to browse through its specs and see if we can match its pinouts down the road. Hopefully, by that time, powerpc-notebook is ready to go, and our processor could be just plug and play…

And I wanted to attach an image from the data sheet, but… too large at 88KB :(
_______________________________________________
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] additional ddr3 interfaces

[Jacob Lifshay]

On Tue, Mar 31, 2020, 17:23 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

> > the NEC processors from the powerpc-notebook project *might* be POWER9.
>
> I looked into this - these are actually NXP processors. NXP T2080 to be
> precise.
> The data sheet is a little unhelpful - not making it clear what POWER it
> is.
>
> Anyways - the processor itself has some similarities to our goals. It
> might be a good idea to browse through its specs and see if we can match
> its pinouts down the road. Hopefully, by that time, powerpc-notebook is
> ready to go, and our processor could be just plug and play…
>

that would be nice, however the t2080 appears to have a 64-bit memory
interface along with some really high-speed serdes -- both of which will be
more difficult to achieve.

However, if we get the funding required for the open-source custom DDR3
interface, we could potentially put two copies on our SoC, which would
improve GPU performance by a large factor (1.5x?) due to the additional
memory bandwidth. That would also double the maximum amount of memory we
could attach to the SoC which is another benefit. If we designed it so it
would work even with one interface disabled, that would benefit low cost
applications where the pcb designers don't want to have to pay for two dram
chips. I don't know if we could, but we might be able to sell two different
variants where one of them has a smaller package where one of the memory
interfaces is not bonded from the pins to the die, that way, we could save
money on the chips where both memory interfaces aren't needed without
needing more than one mask.

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] additional ddr3 interfaces

[Immanuel, Yehowshua U]

> that would be nice, however the t2080 appears to have a 64-bit memory
> interface along with some really high-speed serdes -- both of which will be
> more difficult to achieve.

Yes. I was thinking skipping on the SERDES since I personally don’t care for PCIE.
(Its not even remotely Libre).

Unless we want a 10G ethernet, we don’t need high speed SERDES.

> However, if we get the funding required for the open-source custom DDR3
> interface,

Yup. Working on the funding part at the Create-X angle :)
Also, it’d be really fascinating if we hear back more from Epic Games.
_______________________________________________
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] additional ddr3 interfaces

[Jacob Lifshay]

On Tue, Mar 31, 2020, 17:48 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

> > that would be nice, however the t2080 appears to have a 64-bit memory
> > interface along with some really high-speed serdes -- both of which will
> be
> > more difficult to achieve.
>
> Yes. I was thinking skipping on the SERDES since I personally don’t care
> for PCIE.
> (Its not even remotely Libre).
>
> Unless we want a 10G ethernet, we don’t need high speed SERDES.
>

If we do want to support multi-socket using something like OmniXtend, which
would be amazing but not strictly necessary, 10G ethernet would be
basically required, 1G would work, but would be really slow. We could also
implement something in-between such as 2.5G or 5G.

See http://bugs.libre-riscv.org/show_bug.cgi?id=70 for some previous
discussion.

Using omnixtend allows getting cache coherent memory-mapped i/o over
ethernet (standard ethernet switches work, it can be used simultaneously to
standard tcp/ip), allowing us to easily add custom devices, build giant
numa servers with thousands of cores, add pcie interfaces using a fpga,
interoperate with other processors that support omnixtend, etc.

Also, since it is based on standard ethernet, any computer with an ethernet
port could act as an emulated memory-mapped device or just additional
memory.

>
> > However, if we get the funding required for the open-source custom DDR3
> > interface,
>
> Yup. Working on the funding part at the Create-X angle :)
> Also, it’d be really fascinating if we hear back more from Epic Games.
>

Yay!

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] additional ddr3 interfaces

[Luke Kenneth Casson Leighton]

On Wed, Apr 1, 2020 at 1:44 AM Jacob Lifshay <programmerjake@gmail.com> wrote:

> that would be nice, however the t2080 appears to have a 64-bit memory
> interface along with some really high-speed serdes -- both of which will be
> more difficult to achieve.
>
> However, if we get the funding required for the open-source custom DDR3
> interface, we could potentially put two copies on our SoC,

each DDR3/4 RAM interface adds around 0.4 watts per 800mhz clock rate
which, due to power being a square law, ramps up 1.6 watts by 1600mhz.

additionally, they take 150 pins *each* including 20 pins for VDD and GND.

two such high-speed DDR3/4 RAM interfaces not only therefore increases
the power consumption to more than DOUBLE the entire budget allocated
for the SoC, it also puts it into the approx 450-pin category.

with that many pins we might need to use a 0.5 or smaller pitch grid
(otherwise it would be a 20 mm on a side BGA rather than a 15 mm one),
the packaging costs go up, the yields go down...

that said, there's no reason why we can't put the interface on... and
not bring it out....

> which would
> improve GPU performance by a large factor (1.5x?) due to the additional
> memory bandwidth. That would also double the maximum amount of memory we
> could attach to the SoC which is another benefit. If we designed it so it
> would work even with one interface disabled, that would benefit low cost
> applications where the pcb designers don't want to have to pay for two dram
> chips.

four.  designs with only one DRAM chip are extremely rare
(ultra-ultra-low-cost embedded).  typical DRAMs are x16 so you need
two.  smartphones (etc.) typically use special "stacked" ASICs with
eMMC and 1x or 2x 32-bit DRAM interfaces.  they're well north of 250
pins.

> I don't know if we could, but we might be able to sell two different
> variants where one of them has a smaller package where one of the memory
> interfaces is not bonded from the pins to the die, that way, we could save
> money on the chips where both memory interfaces aren't needed without
> needing more than one mask.

yep, that's how it's done.  ST and ATMEL both actually design the
exact same embedded controller for 10 different purposes, some of
which they discover, during testing, that parts of them fail.

all that happens is: they get shoved in a package, sold as lower-cost
items, with the pins not brought out.

it's a really good way to make sure that yields are kept high, nothing wasted.

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] additional ddr3 interfaces

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 885 bytes --]

Luke Kenneth Casson Leighton schreef op wo 01-04-2020 om 11:10 [+0000]:
> On Wed, Apr 1, 2020 at 1:44 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
> > that would be nice, however the t2080 appears to have a 64-bit memoryinterface along with some really high-speed serdes -- both of which will bemore difficult to achieve.
> > However, if we get the funding required for the open-source custom DDR3interface, we could potentially put two copies on our SoC,
> 
> each DDR3/4 RAM interface adds around 0.4 watts per 800mhz clock ratewhich, due to power being a square law, ramps up 1.6 watts by 1600mhz.

Power consumption is linear with frequency and square with voltage (P = f * C * V^2).
For overclocking increasing frequency also likely means you need to increase voltage so you need to increase power consumption more than linear with frequency.

greets,
Staf.



[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
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] additional ddr3 interfaces

[Luke Kenneth Casson Leighton]

On Wed, Apr 1, 2020 at 4:19 PM Staf Verhaegen <staf@fibraservi.eu> wrote:

> Power consumption is linear with frequency and square with voltage (P = f * C * V^2).

ah thank you.  forgot about that.  the figures i got were from a
special TI video processing chip, with dual 32-bit DDR3 1600mhz
interfaces.  the power consumption figure was 1.6 watts per channel.

> For overclocking increasing frequency also likely means you need to increase voltage so you need to increase power consumption more than linear with frequency.

yes.  i think that's where i was confused (overclocking almost always
involves increasing voltage).  actually it's a huge source of
confusion across the internet, that 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] PPC on Talos and Playstation 3

[Luke Kenneth Casson Leighton]

On Wed, Apr 1, 2020 at 1:23 AM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> > the NEC processors from the powerpc-notebook project *might* be POWER9.
>
> I looked into this - these are actually NXP processors. NXP T2080 to be precise.
> The data sheet is a little unhelpful - not making it clear what POWER it is.
>
> Anyways - the processor itself has some similarities to our goals. It might be a good idea to browse through its specs and see if we can match its pinouts down the road.

with USD $20 million just for that effort alone, yes that would be possible.

it's a massive thousand-pin monster with multi-gigabit interfaces.
packaging costs alone will far exceed the cost of the appx-300-pin SoC
we're currently aiming for.

> Hopefully, by that time, powerpc-notebook is ready to go, and our processor could be just plug and play…
>
> And I wanted to attach an image from the data sheet, but… too large at 88KB :(

send link.

l.

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