[libre-riscv-dev] openpower conversation regarding ISANS/ISAMUX

[Luke Kenneth Casson Leighton]

just had a call with hugh and my friend alain who will be helping with the
standards development.  notes writeup below. wanted to make sure it's
recorded.

hugh is very kindly looking for the right technical people to speak to
because we are on a tight deadline, Oct 2020, for the 180nm tapeout.

---


great to speak, summary tapped out on phone follows

* escape sequence allocation (just the one) critical to projected high
profile mass volume nature of libre-soc project.

* esc seq is effectively "hidden bits 33,4,5.." in the instruction decoder.

* kernel has its own separate "known good" CSR separate from userspace esc
seq CSR.

* IANA style allocation good for entire Power ecosystem.

* other vendors have the opportunity to emulate other vendors esc seqs
fully in software *if they want to*

* "official" esc seqs can be used to "fix" issues with the *official* ISA,
and thanks to the proper allocation this includes "clean" managed software
emulation even for legacy hardware.

this latter works only on hardware that - right now - correctly raises
"illegal instruction trap" for all illegal encodings.

some embedded processors may not do that (because it costs quite a few
gates to do so) and they are unfortubately the caveat.  however as
"embedded" processors they are highly unlikely to matter.


we can do everything we need behind the *ONE* escape sequence.

this will include calling yet more escape sequences!

however that is "our problem" to manage :)


the idea of the esc-seq applying for a limited number of instructions, i
really like it.  however it uses up precious instruction encoding space to
do so and we will need to think it through carefully.

everything i previously designed was based on the allocation of a CSR only
(because no actual new instruction need be allocated to the scheme, for
that to work).

the CSR is written to and IMMEDIATELY goes directly into the 33rd, 34th,
35th etc hidden bits of the instruction decode engine.

if designed properly it can be done even without a pipeline stall.

that was the plan, happy to talk with engineers about alternatives, because
i really love this stuff :)


alain, where at the early stages i can think through the technical details
and potential implications even to several decades of scenarios that help
everyone to avoid major pitfalls, i simply have so much to do i cannot
handle the "completion and followthrough" if you know what i mean.

your role here is to help facilitate with people, communication, common
sense, write up, follow through, keeping an eye on the official OpenPower
Standards development process, and asking sensible questions and being
considerate etc. of the wider picture and of the OpenPower Foundation
members and so on.

and for hitting me with a clue bat when the occasion arises.


thank you to you both.

l.




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