The OpenPOWER ISA EULA Draft Published - Generous For Libre Hardware

[SystemCrasher]

yes. as long as you "do what the arrogant fascists dictate", you're fine.

Er, are they THAT bad? And well, HW development may eventually need a bit of this - for the sake of compatibility and well-thought designs, so once finalized, it doesn't have to get touched in a python-style webmonkeys manner. If everyone starts e.g. extending instruction sets their ways, we'll end up with tons of similar, but essentially incompatible hardware, and it would be rather bad if it all named in similar manner, causing total confusion. And how we are supposed to develop code for things like that if it happens?

[pkese]

If everyone starts e.g. extending instruction sets their ways, we'll end up with tons of similar, but essentially incompatible hardware, and it would be rather bad if it all named in similar manner, causing total confusion. And how we are supposed to develop code for things like that if it happens?

And yet, RISC-V foundation left a considerable amount of instruction encoding space unallocated and specifically intended for user-defined extensions.

I guess anyone is free to use that space to work on their own ISA extensions and build a proof of concept before proposing those ISA extensions to be included into the official spec.

[SavageX]

i'm really pleased to hear that people are "getting it". that it took my own personal money and that of NLNet (which is charitable donations) - really pisses me off. the ******s who include patterson telling me "i should quit For The Benefit Of The RISC-V Community" which was deeply shocking and absolutely inappropriate - have a hell of a lot to answer for.

some day i will publish the full message patterson sent me. or perhaps i will be required to do so as part of an EU anti-trust investigation.

As observer: I'm not really good at this, but my rudimentary spider senses seem to detect a lot of personal friction. I see you using words such as "facist" and "cartel" in the general direction of the RISC-V Foundation. Those are rather abrasive terms. Personally, I don't see anything in the Foundation's documents about establishing a far-right, authoritarian ultra-nationalist state-regime somewhere on this or any other planet and/or moon, so I don't feel that "facist" is an accurate description. My (very) limited experience leads me to believe, though, that calling someone "facist" is a rather effective way to preclude further interaction on friendly terms.

Note that any standards-body needs to be in somewhat exclusive control of whatever standard they're in charge of. ISO, ECMA, IEEE, ITU, MPEG, W3C (that list goes would go on and on), but also RISC-V Foundation and OpenPOWER will eventually decide on what is adopted and what is not. They all have rules on how to participate - and sadly those are not always obvious or well-documented (for varying reasons, but not always out of ill-intent). Some standards-bodies have low barriers for participation (for instance, IETF comes to my mind), others are in practice near-exclusive to "global players" if you want proper voting-rights. In nearly all organizations some sort of diplomacy is involved to move things forward. Sometimes it feels that "corporate nepotism" is in play, for instance if a formerly closed standard is "opened" (but commercial interest is high).

In short: It's complicated.


Now, the project-name "libreriscv" seems to indicate that in the past, you saw good alignment between your goals and those of the RISC-V project. This does not appear to be the case anymore and I assume that a prolonged and frustrating process changed your evaluation of that assumption. I don't know when or if exchanges of opinion got heated and strong expressions saw use, but depending on thresholds that usually are not well-documented, sooner or later any community will prefer to eject members, which often is not a quiet or graceful process.

me too. well, luckily, the "trail has been blazed". OpenPOWER can pretty much cookie-cut what the RISC-V Foundation has done (Compliance Suites, WGs, Platform Specs), except do it in a properly inclusive and transparent fashion.

In my book the more open, the better. I wish OpenPOWER the best.

As for the draft EULA:

1. Modifications to the Power ISA

2.1 Recipient shall have the right to submit Contributions to the Power ISA through a prospectively authorized process by OPF, but shall not implement such Contributions until fully approved through the prospectively authorized OPF process.

2.2 Recipient may create Custom Extensions as described and permitted in the Power ISA. Recipient is encouraged, but not required, to bring their Custom Extensions through the authorized OPF process for contributions. For clarity, Custom Extensions cannot be guaranteed to be compatible with another third party’s Custom Extensions.

This could be (mis-)read as meaning that as soon as something is submitted (but not yet authorized), it cannot be implemented until OPF came to a descision. Imagine you start with a Custom Extension (as in 2.2) and then submit it (as in 2.1) - you certainly don't want to destroy your prototypes to comply to the restriction in 2.1. For clarity it may be beneficial to add that Custom Extensions (I assume there's a reserved opcode space for those?) do not fall into the scope of 2.1.

[SystemCrasher]

And yet, RISC-V foundation left a considerable amount of instruction encoding space unallocated and specifically intended for user-defined extensions.

Have they stated it's intended use case? Also there're some extensions that are likely to become "official" once finalized I guess? Like e.g. SIMD, etc. Furthermore, if its a case, the only safe option could be to build code that doesn't uses any extensions for the fear of facing "undefined behavior" across different CPUs from various suppliers. And I'm pretty sure nobody can prevent using reserved space in custom designs in anyhow efficient manner. Guess now its relatively unique situation where freedom to do arbitrary changes clashes vs freedom to run anyhow meaningful code on resulting designs without facing undefined behavior.

[pkese]

Have they stated it's intended use case?

According to RISC-V Specification document "Major opcodes in the 32-bit base instruction format have been allocated for user-defined custom extensions."
Feel free to search for 'custom extensions' in that document. The rest of your question is also answered there.

[pkese]

As observer: I'm not really good at this, but my rudimentary spider senses seem to detect a lot of personal friction. I see you using words such as "facist" and "cartel" in the general direction of the RISC-V Foundation. Those are rather abrasive terms.

...

Hats down and kudos for that whole comment - there's some admirable level of emotional intelligence in there.

[curaga]

However, whether OpenPOWER is suitable for microcontrollers IMO depends on how the ISA will be split into "must implement" and "optional" parts. Is a FPU mandatory? Is a vector unit mandatory? A MMU? Depending on what is needed to be compliant, microcontrollers might be within reach - or not. POWER is not exactly "slim" if implemented to full spec.

From LWN Aug 21, 2019: four levels of compatibility. Int, float, Linux server, AIX server.

[bridgman]

Doesn't change the fact that there's an extreme barrier to entry to fabbing your own hardware, a cost that only companies can really stand to bear.

Companies or groups of like-minded individuals.

There's a reason there's been no serious efforts to do this.

Agree that it's prohibitively expensive for one individual, but IIRC a typical MPW run gives 100 or so chips per project so you would divide the costs accordingly. If you divide the cost of a single MPW project by the number of chips that comes out the per-chip cost is pretty reasonable.

That said, if you are aiming for an inexpensive MPW project you aren't going to be making 8-core 4 GHz parts with it, but if the goal is full control of the implementation you should still be able to make some pretty useful parts.

The bigger challenge I see is that while we have a number of open source CPU designs the rest of the system / SOC doesn't seem to be in anywhere near as good a state.

Don't be absurd. FPGAs and virtual processors are cute, but let's not play pretend that they're actually useful in these kinds of endeavours because their performance is absolute garbage. Nobody wants a GPU that can only manage 25FPS @ 720p, which are their own numbers at how terrible this thing really is. If there is no user interest because it is so garbage then consequently there will be no independent developer interest in any way that can be considered meaningful. Which means we come back to needing real ASICs, which are prohibitively expensive for even software developers to afford getting produced... which means we get back to this underlying problem that user driven open hardware rather than corporate driven open hardware (POWER, SPARC, RISC-V) is nothing more, and nothing less than a pipe dream that is unlikely to catch on in any meaningful sense. Though to be clear I don't think this is a bad thing any more than the fact that the Linux Kernel is really driven by corporations rather than individuals, just to a far less extreme.

You might be moving the goalposts here - the discussion was about a user and developer community for CPUs, not GPUs.

An FPGA implementing a random-logic CPU is probably never going to be competitive with a custom chip for volume production, but for developer work and even some production it's pretty handy.

I managed a small company that shipped FPGA-based graphics cards successfully for a number of years, although this was back in the early Macintosh days where acceleration requirements were very light, basically a 2D blitter. Even 30 years ago high end FPGAs were too expensive for volume production but the smaller parts on older processes were surprisingly cost-effective.

The same analogy applies for 3D printing of physical parts - compared to the cost of a volume produced part 3D printing is much more expensive, but it shines in places where the demand for volume produced parts does not exist or is not yet accessible.

Just to be clear, I would be really happy if low-cost personal ASIC production became a thing... in principle it is possible via direct electron-beam writing... but given where the current costs are in ASIC production it seems to me that ignoring multi-project wafers (with or without direct e-beam lithography) and FPGAs means missing out on a lot of opportunities.

The challenge IMO in the short term is finding and organizing people who are willing to pay a price (higher cost and/or lower performance) for other benefits like security and confidence in implementation. One could argue that modern CPUs are massive overkill for most security-critical applications other than maybe design workstations, and to me that means opportunity for smaller semi-custom parts.

[lkcl]

Er, are they THAT bad?

look up the number of people who have given up on RISC-V. Professor Michael Taylor amongst them. the problem is that very few people are actually in a position where their "standing" would not be completely destroyed (employers, university funding) by speaking out. consequently they are effectively intimidated into silence.

And well, HW development may eventually need a bit of this - for the sake of compatibility and well-thought designs, so once finalized, it doesn't have to get touched in a python-style webmonkeys manner. If everyone starts e.g. extending instruction sets their ways, we'll end up with tons of similar, but essentially incompatible hardware, and it would be rather bad if it all named in similar manner, causing total confusion. And how we are supposed to develop code for things like that if it happens?

eexactly. you've described it very well. this is what a *well-managed* Trademark is designed to do: be the "Atomic Arbiter", to prevent chaos for everyone.

to their credit, what they've got is extremely good - it is extremely well managed. the problem is that their "filters" for excluding people (excluding the webmonkeys) fall outside of what is legally permitted under Trademark Law.

[lkcl]

As observer: I'm not really good at this, but my rudimentary spider senses seem to detect a lot of personal friction. I see you using words such as "facist" and "cartel" in the general direction of the RISC-V Foundation.

yes. this is because i am extremely pissed off at having spent personal funds - and charitably-donated funds from NLNet - 18 months worth of money when i'm on an income level of *BELOW* USD 15,000 a year - dealing with prominent high-profile "well-respected" people who absolutely should know better and should know their obligations under Trademark Law.

i've also had to deal with defamation attacks by extremely highly-paid employees of SiFive, who will be earning well over ten times what i do.

Those are rather abrasive terms. Personally, I don't see anything in the Foundation's documents about establishing a far-right, authoritarian ultra-nationalist state-regime somewhere on this or any other planet and/or moon, so I don't feel that "facist" is an accurate description.

you want "definition 2" under urbandictionary.com. not definition 1

My (very) limited experience leads me to believe, though, that calling someone "facist" is a rather effective way to preclude further interaction on friendly terms.

i'm not in the slightest bit interested in being on friendly terms, and, interestingly, Trademark Law does not say anything about being "friends" either.

Note that any standards-body needs to be in somewhat exclusive control of whatever standard they're in charge of. ISO, ECMA, IEEE, ITU, MPEG, W3C (that list goes would go on and on), but also RISC-V Foundation and OpenPOWER will eventually decide on what is adopted and what is not.

absolutely. there has to be an "Atomic Arbitrator". this is all recognised and codified in Trademark Law.

They all have rules on how to participate - and sadly those are not always obvious or well-documented (for varying reasons, but not always out of ill-intent). Some standards-bodies have low barriers for participation (for instance, IETF comes to my mind), others are in practice near-exclusive to "global players" if you want proper voting-rights. In nearly all organizations some sort of diplomacy is involved to move things forward. Sometimes it feels that "corporate nepotism" is in play, for instance if a formerly closed standard is "opened" (but commercial interest is high).

In short: It's complicated.

i had to study it, in order to become a Certification Mark Holder. so i know how it works. whilst patents are known for needing to be "FRAND", it is not very well known that Trademark Holders *also* are required to operate on FRAND principles.

Now, the project-name "libreriscv" seems to indicate that in the past, you saw good alignment between your goals and those of the RISC-V project.

indeed. like many others, i saw the eco-system and went, "WOW! i can short-cut the development time of an entire chip - to market - because the test infrastructure, compliance tests, compilers, bootloaders, everything's there! and FPGA boards and everything!"

then we have to actually heavily modify the ISA because, as you've probably seen (from Larabee and Nyuzi), a software-vector-processor is completely inadequate as a 3D GPU.

and that's the point at which the s*** hit the fan.

This does not appear to be the case anymore and I assume that a prolonged and frustrating process changed your evaluation of that assumption.

18 months of continuous, persistent failures on the part of the RISC-V Foundation - all of which are public and all of which are cc'd to the Director of the RISC-V Foundation - to respond to "in good faith" and perfectly reasonable requests to participate in the *INNOVATION* behind RISC-V, in a fashion that did not completely destroy the BUSINESS reasons - not stupid "we're moronic religious fervent wannabes wanna do libre becuz waa, waaa, i want my mummy and Dr Stallman to pwotect me, waaaa" reasons - for keeping full transparency.

I don't know when or if exchanges of opinion got heated and strong expressions saw use, but depending on thresholds that usually are not well-documented, sooner or later any community will prefer to eject members, which often is not a quiet or graceful process.

yep. except it's more complicated than that, because the *entire* public community is *already* excluded, and made to feel completely unwelcome.

In my book the more open, the better. I wish OpenPOWER the best.

yes. it's perfectly doable.

As for the draft EULA:

This could be (mis-)read as meaning that as soon as something is submitted (but not yet authorized), it cannot be implemented until OPF came to a descision. Imagine you start with a Custom Extension (as in 2.2) and then submit it (as in 2.1) - you certainly don't want to destroy your prototypes to comply to the restriction in 2.1. For clarity it may be beneficial to add that Custom Extensions (I assume there's a reserved opcode space for those?) do not fall into the scope of 2.1.

there's reserved opcodes and there are ones which you can but really shouldn't use. yes this is an area i've raised with Hugh. for RISC-V several people helped out in the development of something called "ISAMUX / ISANS". it's basically a hardware version of c++ "using namespace". it took *months* to explain. ironically, like everything else, it was completely ignored by the RISC-V Foundation.

ISANS is basically an assembly escape-code sequence which either temporarily *or indefinitely* modifies / introduces new opcodes. if you never call the escape sequence, the processor remains entirely POWER compliant.

one of those namespaces can be made an entirely foreign ISA, such as MIPS, x86 and so on. we will be using this trick to do a Dual ISA.

i have pointed out to Hugh that this is going to be absolutely essential to ensure that the clash that you describe does not occur. imagine if the vendor releases actual hardware, which becomes popular, prior to submission as in 2.1. they are then in the embarrassing position of telling IBM and the other OpenPower Foundation members, "um, we're really sorry, but it's too late, you basically need to rubber-stamp what we did".

but - here's where it gets serious: what if *another* vendor does *exactly* the same thing? and with the latency (and secrecy) and the insane high costs of processor development, you think both of them (or more of them) are going to back down?

it'll be Altivec all over again, won't it?

so that's what ISAMUX / ISANS is *specifically* designed to avoid. everyone is POWER compliant, everyone registers for a "namespace bit" (in an atomic fashion), and when calling a special instruction with their *UNIQUE RESERVED* namespace bit called, the processor drops into "unique custom extension mode".

exactly like c++ "using namespace"