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

    > schedule from the business plan:
    > - Q2/2021: 130nm test chip (Google/SkyWater MPW shuttle program)
    > - Q4/2021: 180nm QFP SoC
    > - Q2/2022: 28nm or 20nm quad-core SoC for BMC and SBC use; USB-C and
    > PCIe host/device controllers, i.e. also usable as peripheral GPU
    > - Q2/2023: then-latest process node; targetting smartphones, netbooks, tablets,
    > IoT and IPTV

    Most recent schedule update*:
    - 202X: 300 MHz single-core
    - 202X+2: quad-core
    - 202X+4: 8-core
    - 202X+6: 64-core

    (* The notion that VSX is 15 years old is incorrect. VSX was first specified in Power ISA v2.06 in 2009 and first implemented in POWER7 in 2010.)


    Edit: "Quad and 8 1.5+ ghz on the roadmap over the next 3 years"

    [ Edited by Andreas_Wolf 20.07.2021 - 01:47 ]
  • »15.04.21 - 20:34
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 545 from 2015/6/18
    From: Funeralopolis
    Ah, finally we are getting somewhere! At least the 'quad-core as SBC' looks interesting. But we'll have to wait and see how this translates to available products in 202X+2. ;-)

    @Andreas_Wolf: Thanks for your continuous updates! Looking at the schedule update you posted I gather that VMX/VSX will not be implemented (too much work?) for the time being?
    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]
  • »15.04.21 - 21:30
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > I gather that VMX/VSX will not be implemented (too much work?)
    > for the time being?

    Yes, correct. Their long-term plan is however to not implement VMX/VSX ever but instead somehow convince IBM and the OpenPOWER Foundation to abandon VSX in favour of Libre-SOC's non-SIMD SimpleV (or Simple-V, seems they can't decide on one spelling variant) vector augmentation.
  • »15.04.21 - 23:03
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 545 from 2015/6/18
    From: Funeralopolis
    Lets hope this thing won't turn up in BMCs only...
    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]
  • »04.06.21 - 10:23
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > Lets hope this thing won't turn up in BMCs only...

    Which one? RED's Libre-SOC, ChipEleven's PythonWatt/SuperPOWER, or LibreBMC's A2P? :-)
  • »04.06.21 - 12:00
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 545 from 2015/6/18
    From: Funeralopolis
    Any of the above. ;-)
    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]
  • »04.06.21 - 15:21
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > First test chip tape-out (180nm) is claimed to be a mere 5 days away

    Took a little longer: https://openpowerfoundation.org/libre-soc-180nm-power-isa-asic-submitted-to-imec-for-fabrication/

    The Libre-SOC test ASIC is claimed to be "implementing a fixed-point subset of the v3.0B OpenPOWER ISA", which is strange considering that compliancy subsets were introduced only with v3.0C of the ISA. There are no subsets in v3.0 or v3.0B.

    Fun fact: "The Cell Library used, FlexLib, […] was developed by Staf Verhaegen of Chips4Makers […]." This happens to be MorphZone member Fats.

    And of course, also this significant event doesn't come without some dubious statements from the project lead:

    "Libre-SOC […] is the first wholly-independent Power ISA ASIC outside of IBM to go Silicon in 12 years."
    Well, during the last 12 years, Freescale/NXP has released more than a dozen different e200-based ASIC products (not counting variants of those), the most recent one being the 16nm S32R294 released this year. Also, the entire QorIQ T family and most of the QorIQ P family are younger than 12 years. Would be interesting to know which 2009-ish non-IBM Power ISA ASIC with IBM-independent microarchitecture he's referring to here in particular, and why he doesn't accept all those later NXP/Freescale ASICs to meet his mentioned criteria.**

    "they had to go through some serrioous review to get OpenPOWER out the door and into the OPF, ironically it's been ongoing for something like a decade, long before RV existed."
    To contrast this with the timeline as it took place in the real world:
    2010: RISC-V project started
    2011: first version of RISC-V ISA released
    2013: OpenPOWER Foundation founded (as OpenPOWER Consortium)
    2015: RISC-V Foundation founded, Power ISA v3.0 released*,***


    * Edit1: more of this nonsense

    ** Edit2: He tried again and failed once more:
    "our […] test ASIC […] is […] the world's first Power ISA 3.0 [ASIC] outside of IBM to reach Silicon in over 12 years."
    How can there have been a Power ISA v3.0 ASIC over 12 years ago when Power ISA v3.0 was published only 6 years ago? Which ASIC is he referring to with this statement? Unless I missed something, Libre-SOC is the first Power ISA v3.0+ ASIC outside of IBM ever.

    *** Edit3: even more of this nonsense:
    "Power ISA [...] pre-dates the RISC-V instruction set by a long way. As does interestingly their intention to open up the ISA, which was initiated about 10 years ago"

    [ Edited by Andreas_Wolf 02.05.2023 - 23:50 ]
  • »08.07.21 - 19:14
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    Update:

    > POWER10

    Seems it will be Power10 instead of POWER10:

    https://www.rpgpgm.com/2021/07/ibm-updates-power-branding.html
    https://www.itjungle.com/2021/08/02/no-more-shouting-the-name-power-well-except-in-our-title-here/
    https://www.ibm.com/it-infrastructure/power/power10

    …which in my humble opinion is a stupid decision for the following reason:
    So far, Power has been (since superseding PowerPC in 2006) the name of the instruction set architecture (ISA), while POWER has been the name of IBM's line of server CPU microarchitectures (POWER1…9, with POWER3…5 implementing PowerPC ISA and POWER5+…9 implementing Power ISA). This means that so far, the (non-)capitalization of the word can be used for distinction between ISA and microarchitecture. With Power10, this will be no more. The ISA and the IBM server CPU microarchitecture will both go by the very same name: Power. So what will be the correct answer to the question whether 440/460/470, A2, e200, e500, e5500, e6500, PA6T or any of the new (soft)cores discussed in this thread are Power? Well, it will depend on what the questioner has in mind, making room for misunderstandings. The correct answer will be 'yes' for Power [ISA], but it will be 'no' for Power [microarchitecture].
  • »07.08.21 - 13:25
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 545 from 2015/6/18
    From: Funeralopolis
    Nice! Thanks for your constant updates on this topic @Andreas_Wolf!
    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.11.21 - 00:50
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    Update:

    > Looks like the RED Semiconductor company has been established
    > for the purpose of commercializing the Libre-SOC technology:
    > https://www.redsemiconductor.com

    "The processor [...] will be able to run x86 code in native mode thanks to emulation capabilities, according to David Calderwood, chairman of the company. [...] The x86 emulation capability may be the result of technology that came to IBM when it acquired Transitive Corp. in 2008."
    https://www.eenewsanalog.com/en/uk-startup-is-raising-funds-for-open-power-processor/

    Wait, "native mode" or "emulation", which one is it? If the former, I'm not sure the actual developers of the CPU are aware of this capability announced by the company chairman. The article author's reference to long-abandoned, 32-bit-only QuickTransit/PowerVM Lx86, which is probably pulled out of thin air, implies a purely software-based emulation, in which case I'm not sure what this would have to do with the actual CPU design. Furthermore, I doubt that IBM would grant free use of this technology.


    Edit: RED Semiconductor is now OpenPOWER Foundation member.
    Edit2: https://redsemiconductor.com/red-semiconductor-joined-the-openpower-foundation/

    [ Edited by Andreas_Wolf 02.10.2022 - 02:01 ]
  • »10.03.22 - 08:58
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    ernsteiswuerfel
    Posts: 545 from 2015/6/18
    From: Funeralopolis
    binutils got LibreSOC support recently (klick). And it looks like it got Altivec + VSX support too (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]
  • »11.08.22 - 23:17
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12058 from 2003/5/22
    From: Germany
    > it looks like it got Altivec + VSX support

    There's no way on earth that Libre-SOC implements VSX or VMX/AltiVec, or ever will (see also comment #202). The Libre-SOC development lead absolutely despises the SIMD concept, as opposed to true vector processing.

    "Libre-SOC will be compliant with the Scalar Floating-Point Subset (SFFS) i.e. is not implementing VMX/VSX […]. Prior to the formation of the Compliancy Levels first introduced in v3.0C and v3.1 the progressive historic development of the Scalar parts of the Power ISA assumed that VSX would always be there to complement it. However With VMX/VSX not available in the newly-introduced SFFS Compliancy Level, the existing non-VSX conversion/data-movement instructions require a Vector of load/store instructions (slow and expensive) to transfer data between the FPRs and the GPRs. For a modern 3D GPU this kills any possibility of a competitive edge. Also, because SimpleV needs efficient scalar instructions in order to generate efficient vector instructions, adding new instructions for data-transfer/conversion between FPRs and GPRs multiplies the savings. […] (The existing Scalar instructions being FP-FP only is based on an assumption that VSX will be implemented, and VSX is not part of the SFFS Compliancy Level. An earlier version of the Power ISA used to have similar FPR<->GPR instructions to these: they were deprecated due to this incorrect assumption that VSX would always be present)."
    https://libre-soc.org/openpower/sv/int_fp_mv/

    "Scalar bitmanipulation is justifiable for the exact same reasons the extensions are justifiable for other ISAs. The additional justification for their inclusion where some instructions are already (sort-of) present in VSX is that VSX is not mandatory, and the complexity of implementation of VSX is too high a price to pay at the Embedded SFFS Compliancy Level."
    https://libre-soc.org/openpower/sv/vector_isa_comparison/

    "Vectorisation of the VSX Packed SIMD system makes no sense whatsoever, the sole exceptions potentially being any operations with 128-bit operands […]. SV effectively replaces the majority of VSX, requiring far less instructions, and provides, at the very minimum, predication (which VSX was designed without)."
    https://libre-soc.org/openpower/sv/svp64/appendix/

    "When combined with SV, scalar variants of bitmanip operations found in VSX are added so that the Packed SIMD aspects of VSX may be retired as "legacy" in the far future (10 to 20 years). Also, VSX is hundreds of opcodes, requires 128 bit pathways, and is wholly unsuited to low power or embedded scenarios."
    https://libre-soc.org/openpower/sv/bitmanip/

    "Whilst SVP64 is only 5 instructions the heavy focus on VSX for the past 12 years has left the SFFS Level anaemic and out-of-date compared to ARM and x86. This is very much a blessing, as the Scalar ISA has remained clean, making it highly suited to RISC-paradigm Scalable Vector Prefixing. Approximately 100 additional (optional) Scalar Instructions are up for proposal to bring SFFS up-to-date. None of them require or depend on PackedSIMD VSX (or VMX)."
    https://libre-soc.org/openpower/sv/
  • »12.08.22 - 00:26
    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:
    > it looks like it got Altivec + VSX support

    There's no way on earth that Libre-SOC implements VSX or VMX/AltiVec, or ever will. The Libre-SOC development lead absolutely despises the SIMD concept, as opposed to true vector processing.

    Sounds reasonable. But if you are correct the binutils definition for LibreSOC
    "libresoc", (PPC_OPCODE_PPC | PPC_OPCODE_ISEL | PPC_OPCODE_64 | PPC_OPCODE_POWER4 | PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7 | PPC_OPCODE_POWER8 | PPC_OPCODE_POWER9 | PPC_OPCODE_ALTIVEC | PPC_OPCODE_VSX | PPC_OPCODE_SVP64)
    must stand for something else?
    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]
  • »12.08.22 - 17:26
    Profile