Open Power
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    Update:

    >> Interesting new project called Libre-SOC: [...]
    >> Details: https://libre-soc.org/openpower/

    > New information from the company behind Libre-SOC:
    > https://systemeslibres.org
    > https://systemeslibres.org/updates/just-incorporated/
    > https://systemeslibres.org/updates/code_to_tapeout/

    Project to be presented at XDC 2020 in September:

    https://xdc2020.x.org/event/9/contributions/607/

    Some questionable statements from the description:

    "The core processor design [...] is to be an augmented POWER9 compliant design"

    Libre-SOC surely isn't to be a POWER9-compliant design, let alone an augmented one. It is, just like POWER9, to be a PowerISAv3-compliant design.

    "This [...] project [...] is also based on [...] the CDC 6600. With help from Mitch Alsup, the designer of the Motorola 68000, it has been possible to upgrade the 6600 core to multi-issue and precise exceptions with no architectural compromises."

    According to that web page, Alsup is a designer of the ill-fated 88k, not of any 68k. The 68k designers are listed as:

    68000: Stritter, Zolnowsky, Gunter, Leitch, Shustek, Tredennick, Crudele, McAlister, Crisp, Spak, Lee
    68010: Zolnowsky, MacGregor
    68020: Moyer, Mothersole, Zolnowsky, MacGregor
    68030: Boney, MacGregor, Moyer, Lamb, Vegesna, Rupp
    68040: Shahan
    68060: Circello


    Edit: slides available, fortunately without the above-mentioned claims

    [ Edited by Andreas_Wolf 18.09.2020 - 14:03 ]
  • »26.07.20 - 19:49
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    "This [...] project [...] is also based on [...] the CDC 6600. With help from Mitch Alsup, the designer of the Motorola 68000, it has been possible to upgrade the 6600 core to multi-issue and precise exceptions with no architectural compromises."


    That statement IS peculiar.
    "Never attribute to malice what can more readily explained by incompetence"
  • »27.07.20 - 23:49
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Reduces the veracity of his claims, doesn't it?

    I wonder how much of the stuff he has said about Raptor is BS?

    And if the chip is only suited to replacing a system monitoring processor, is it that good?
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.07.20 - 15:54
    Profile
  • Paladin of the Pegasos
    Paladin of the Pegasos
    redrumloa
    Posts: 1424 from 2003/4/13
    Quote:

    Andreas_Wolf wrote:
    The claim was questioned a year ago, but the question got ignored:

    https://hardware.slashdot.org/comments.pl?sid=14281964&cid=58872238

    Instead, he's been repeating this claim to this day.


    That is a bit troubling, isn't it. I could see making a mistake once, but repeating it and and ignoring questions? That's not a flub, that's outright lying. To say that's a pretty big lie is an understatement.

    [ Edited by redrumloa 28.07.2020 - 12:22 ]
  • »28.07.20 - 16:21
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > I wonder how much of the stuff he has said about Raptor is BS?

    As far as I can tell, it's mostly true. The last quote in comment #166 does not tell the real order of events, though. In reality, the project first switched ISA from RISC-V to Power and only then was approached by Raptor. So, Raptor expressing interest was not the reason for the ISA switch, but the ISA switch was the reason for Raptor expressing interest.

    > if the chip is only suited to replacing a system monitoring processor,
    > is it that good?

    First and foremost, this chip is about being fully open, and only then about being "good" (whatever that means in particular) :-)
    The use as a board management controller for Raptor is just an initial use case for the SoC, if it happens. This doesn't mean the chip is only suited to this end. The original specs lacked some features required for a management controller. They were added to the specs at Raptor's request. The presentation description linked to in comment #168 doesn't even mention anything about management controllers or service/monitoring processors, but "tablets, smartphones, chromebooks and more".
  • »28.07.20 - 19:34
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Well, it would look better to be associated with the designers behind a successful ISA (68K), instead of one that in my opinion was a misstep by Motorola (88K).

    Funny how their probable real legacy is a design that drove Motorola to IBM's door.

    And why they mention the CDC 6600 is anyone's guess, since that's so old that it isn't likely that anything related to it is terribly relevant.

    Edit - Except for maybe trying to co-opt history, consider the significance of the processor. Appears to be the earliest implementation of silicon transistors. And three times faster than competing IBM designs.

    One thing is for certain, this guy knows his history, and where to try to catch an updraft from.

    But laying claim to 68K and 6600 heritage, while your design help is coming from an 88K designer (a design that failed to scale well), its pretty deceptive.

    I'd agree with Red, he appears to be outright lying.

    [ Edited by Jim 28.07.2020 - 15:51 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »28.07.20 - 19:40
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > I could see making a mistake once, but repeating it and and ignoring questions?

    There's always the remote possibility that he missed the question, after all he didn't post any other comment to that news item after the question was posed. Else it's probably what Jim said in the first paragraph of comment #174.
  • »28.07.20 - 19:48
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > it would look better to be associated with the designers behind a successful
    > ISA (68K), instead of one that in my opinion was a misstep by Motorola (88K).

    Exactly. Btw, according to that PDF (page 12), Alsup joined Motorola only in ca. 1981 (or even only in 1983 according to his LinkedIn profile), so for that reason alone he couldn't possibly have co-designed the 1979-released 68000.

    > their probable real legacy is a design that drove Motorola to IBM's door.

    They never claimed their design to be based on the 68k, so it's not based on the 88k either just because a designer of the 88k architecture helped them with their project. Alsup also is a designer of the 2nd generation hyperSPARC and the chief architect of the AMD K9, yet Libre-SOC is obviously not based on any of them just because of that.

    > why they mention the CDC 6600 is anyone's guess, since that's so old
    > that it isn't likely that anything related to it is terribly relevant.

    Libre-SOC's dynamic pipeline scheduling is based on the CDC 6600's scoreboarding algorithm. And that's precisely where Alsup has helped the project:

    https://libre-soc.org/3d_gpu/architecture/6600scoreboard/

    > laying claim to 68K and 6600 heritage

    I can't see where they claim 68k heritage. And the CDC 6600 heritage is real, as far as I can see.
  • »28.07.20 - 20:28
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4977 from 2009/1/28
    From: Delaware, USA
    Interesting design idea, the scoreboard.

    And Mitch seems to be fairly well versed on the 6600, from what I've seen in interviews.
    Thanks.
    "Never attribute to malice what can more readily explained by incompetence"
  • »30.07.20 - 16:33
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    Addendum:

    > Power ISA "3.0C"? Never heard of that. Does anybody have a link to that "3.0C" spec?

    Still no link to the spec, but some mention of Power ISA 3.0C in slides from ICS in June 2020 (page 2):

    "April 2020 – POWER ISA 3.0c [...]
    - Same as POWER ISA 3.0b except for
    • Compliancy Subsets
    • Custom Extension Space (Sandbox)
    • SMF Feature
    "

    (further mentions on pages 3 and 6)

    Respective presentation: https://www.youtube.com/watch?v=0zIwLCnIuqg
  • »09.09.20 - 07:48
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 545 from 2015/6/18
    From: Funeralopolis
    Quote:

    Andreas_Wolf schrieb:
    Okay, not the 405, but the pre-existing yet until now secret A2O, which compared to the well-known in-order A2I added out-of-order execution at the cost of being reduced from SMT4 to SMT2.

    Not too shabby for an embedded core. ;-) And certainly more advanced than the 405 (or the 440 of the Sam460 ex), being 32bit Power ISA v.2.03 cores (roughly POWER5), where the A2O is 64bit Power ISA v.2.07 (roughly POWER8).

    But apart from being ISA v.2.07 compatible it does not seem to feature a SIMD vector unit (Altivex, VSX) nor an MMU? (klick)
    Talos II. [Gentoo Linux] | PMac G5 11,2. PMac G4 3,6. PBook G4 5,8. [MorphOS 3.18 / Gentoo Linux] | Vampire V4 SA [ApolloOS / Amiga OS 3.2.2]
  • »18.09.20 - 23:43
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > the 405 (or the 440 [...]), being [...] Power ISA v.2.03 cores (roughly
    > POWER5), where the A2O is [...] Power ISA v.2.07 (roughly POWER8).

    I really don't get this fixation on Power ISA revisions. The PPC405 or PPC440 are nothing like the POWER5+, even if both are Power ISA v2.03. And likewise, the A2O is nothing like the POWER8, even if both are Power ISA v2.07. The option-based way the Power ISA (except v3.0/v3.0B, which gave up on optionality) spec compliancy works (v2: categories; v3.0C/v3.1: compliancy subsets) makes the ISA revision mostly irrelevant for comparison of microarchitectures/cores. To illustrate my point, see if you can find any new feature in the v2.07 A2O compared to the v2.06 A2I that was added in Power ISA v2.07.
    There's one extremely relevant thing with Power ISA versions, namely the turning point that IBM created with Power ISA v3.0 in 2015 (see comments #88, #163, #165, #167), which prevents Power ISA v2 Book III-E cores from being used commercially (i.e. hard core, ASIC) under the royalty-free OpenPOWER v3.0C or v3.1 licenses. Thus, the v2.06/2.07 A2I and A2O cores cannot be used commercially under the license by 3rd parties unless those cores be upgraded to ISA v3.0C or v3.1 level, which includes, among other things, replacing the embedded supervisor instructions (from Book III-E of Power ISA v2) by non-embedded ("server") supervisor instructions (from Book III-S of Power ISA v2, or from Book III of Power ISA v3 or pre-v2.03 PowerPC ISA). This is quite an effort.
    As it stands, the commercial usability of A2I/A2O in the OpenPOWER context is not really there. IBM could have contributed not just Power ISA v3.0C and v3.1 but also old Power ISA v2 revisions to the OpenPOWER Foundation for 3rd party use, but they decided not to do this and I'm sure they have their reasons for this decision. Btw, IBM can as well open-source any of its Power ISA v2 Book III-S cores, like POWER5+ to POWER8, or any of its old pre-v2.03 PowerPC cores, like 40x (the 440 being the first IBM core with Book-E extensions), 6xx, 7xx, 970, Cell PPU (probably subject to consent by Sony and Toshiba, though), POWER3 to POWER5. Anything from that list is more compliant with Power ISA v3 than A2I/A2O is, and I'm still hopeful with regard to this.

    > it does not seem to feature a SIMD vector unit [...] nor an MMU?

    No SIMD, but basic MMU is there.


    Edit: changed wording

    [ Edited by Andreas_Wolf 05.10.2023 - 19:26 ]
  • »19.09.20 - 03:43
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 545 from 2015/6/18
    From: Funeralopolis
    Quote:

    Andreas_Wolf schrieb:
    The PPC405 or PPC440 are nothing like the POWER5+, even if both are Power ISA v2.03. And likewise, the A2O is nothing like the POWER8, even if both are Power ISA v2.07. The modular way the Power ISA spec compliancy works (Books with optional parts and optional feature sets) makes the ISA revision mostly irrelevant for comparison of microarchitectures/cores.

    So CPUs compliant to the same ISA don't understand the same instructions? Seems a bit more complicated than I thought...
    Talos II. [Gentoo Linux] | PMac G5 11,2. PMac G4 3,6. PBook G4 5,8. [MorphOS 3.18 / Gentoo Linux] | Vampire V4 SA [ApolloOS / Amiga OS 3.2.2]
  • »19.09.20 - 22:49
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > CPUs compliant to the same ISA don't understand the same instructions?

    Exactly, the Power ISA revision usually tells nothing about the supported instructions of the microarchitecture/core declared compliant with the respective Power ISA revision. With each new Power ISA revision, new optional features/instructions were added (exception: Power ISA v3.0 which killed entire Book III-E and Book VLE). Every new Power core was simply declared compliant with the ISA revision that was recent at time of release, no matter if it supported the new optional instructions or not. Usually, the big IBM POWER processors were the ones that supported the new instructions and that the new ISA revision was released for in the first place. This way of assigning ISA revisions to cores has been legit as new instructions have always been optional. That's why a core declared compliant with a certain ISA revision is automatically compliant with all follow-up revisions (exception again: Power ISA v3.0).
    This way, the very same ISA revisions are shared by
    - cores with FPU and without
    - cores with MMU and without
    - Book III-S cores and Book III-E cores
    - Book III-E cores with SPE and Book III-E cores without
    - cores with VLE and cores without
    - VLE cores with Book I-III instructions and VLE cores without
    - cores with SIMD and cores without
    - SIMD cores with VSX and SIMD cores without
    - cores with AltiVec/VMX in both endians and cores with AltiVec/VMX only in big-endian
    - 32 bit-only cores, 64 bit-only cores and 32/64-bit cores
    - cores with decimal FP and cores without
    - cores with transactional memory and cores without

    These are just the most obvious instruction set differences. And to give you the most extreme example, both the e200z0 and the POWER5+ implement Power ISA v2.03, yet they do not have even one single instruction in common.

    > Seems a bit more complicated than I thought

    This graph is quite okay, but it has a major flaw: it implies that Power ISA v3.0 and above still contain Book III-E and Book VLE, which they do not. (As minor flaws, it falsely implies that Power ISA v3.0 and above have been released by Power.org, and it's missing Power ISA v3.0C.)
  • »20.09.20 - 00:36
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    Addendum:

    >> Power ISA "3.0C"? Never heard of that. Does anybody have a link to that "3.0C" spec?

    > some mention of Power ISA 3.0C in slides from ICS in June 2020
    > (page 2): [...] (further mentions on pages 3 and 6)
    > Respective presentation: https://www.youtube.com/watch?v=0zIwLCnIuqg

    Revised presentation from OpenPOWER Summit NA 2020:
    https://www.youtube.com/watch?v=ZGvEpd4vNK0

    Inexplicably, the occurences of "3.0c"/"3.0C" on pages 2/3 got replaced by "3.0", which is of course plain wrong as neither has Power ISA v3.0 from 2015 (or v3.0B from 2017) been contributed to the OpenPOWER Foundation nor does v3.0 (or v3.0B) have any compliancy subsets. Both things started only with v3.0C/3.1.
    These changes to the slides must have been made deliberately. What the heck is going on there?


    Edit: "V3.0C" mentioned in https://www.youtube.com/watch?v=SO8a8zcAiZc (at 13:00 and 20:04) and https://video.fosdem.org/2021/D.power/microwatt_grows_up.mp4 / https://video.fosdem.org/2021/D.power/microwatt_grows_up.webm (at 5:00 and 13:33)
    (Btw, funny how Paul Mackerras in the first video at 11:45 claims that the ISA renaming in 2006 from PowerPC ISA (v2.02) to Power ISA (v2.03) by Power.org happened because Freescale allegedly had very much stopped using the ISA so that it was pretty much just about the IBM POWER line of server CPUs at that time (and in the second video at 4:18 that it happened because IBM allegedly was the only company using the ISA or making any new CPUs with it), when in fact the opposite is true, namely that the renaming represented the incorporation of the Book-E extensions (implemented by IBM PPC440/PPC460 and Freescale e200/e500 back then, which are embedded class and thus as un-POWER as possible) into the official ISA specification.)

    [ Edited by Andreas_Wolf 18.02.2021 - 22:03 ]
  • »22.09.20 - 21:36
    Profile