add openpower section and isa/decoder/simulator section

diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn
index 19e14fb6f212bf9738bc6358d702be8709f2aec4..072de1d684ffdfb8395b25b0ebddc798c5306cd0 100644 (file)
--- a/updates/023_2020mar26_decoder_emulator_started.mdwn
+++ b/updates/023_2020mar26_decoder_emulator_started.mdwn
@@ -168,7 +168,50 @@ Now if only we could actually go to a conference and talk about it.
 
 # POWER ISA decoder and Simulator
 
-TODO
+*(kindly written by Michael)*
+
+The decoder we have is based on that of IBM's
+[microwatt reference design](https://github.com/antonblanchard/microwatt).
+As microwatt's decoder is quite regular, consisting of a bunch of large
+switch statements returning fields of a struct, we elected not to
+pursue a direct conversion of the VHDL to nmigen. Instead, we
+extracted the information in the switch statements into several
+[CSV tables](https://libre-riscv.org/openpower/isatables/),
+and leveraged nmigen to construct the decoder from these
+tables. We applied the same technique to extract the subfields
+(register numbers, branch offset, immediates, etc.) from the
+instruction, where Luke converted the information in the POWER ISA
+specification to text, and wrote a module in python to extract those
+fields from an instruction.
+
+To test the decoder, we initially verified it against the tables we
+extracted, and manually against the power ISA specification. Later
+however, we came up with the idea of verifying the decoder against the
+output of the GNU assembler. This is done by selecting an instruction
+type (integer reg/reg, integer immediate, load store, etc), and
+randomly selecting the opcode, registers, immediates, and other
+operands. We then feed this instruction to GNU AS to assemble, and
+then the assembled instruction is sent to our decoder. From this, we
+can then verify that the output of the decoder matches what was generated
+earlier.
+
+We also explored using a similar idea to test the functionality of the
+entire SOC. By using the [QEMU](https://www.qemu.org/) powerpc
+emulator, we can compare the execution of our SOC against that of the
+emulator to verify that our decoder and backend are working correctly.
+We would write snippets of test code (or potentially randomly generate
+instructions) and send the resulting binary to both the SOC and
+QEMU. We would then simulate our SOC until it was finished executing
+instructions, and use Qemu's gdb interface to do the same. We would
+then use Qemu's gdb interface to compare the register file and memory
+with that of our SOC to verify that it is working correctly. I did
+some experimentation using this technique to verify a rudimentary
+simulator of the SOC backend, and it seemed to work quite well.
+
+*(Note from Luke: this automated approach, taking either other people's
+regularly-written code or actual PDF specifications, not only saves us a
+vast amount of time, it also ensures that our implementation is
+correct and does not contain transcription errors).*
 
 # simple-soft-float Library and POWER FP emulation
 
@@ -231,7 +274,47 @@ sponsorship, from individuals, Foundations (such as NLNet) and Companies
 
 # OpenPOWER Conference calls
 
-TODO
+We've now established a routine two-week conference call with Hugh Blemings,
+OpenPOWER Foundation Director, and Timothy Pearson, CEO of Raptor CS.  This
+allows us to keep up-to-date (each way) on both our new venture and also
+the newly-announced OpenPOWER Foundation effort as it progresses.
+
+One of the most important things that we, Libre-SOC, need, and are
+discussing with Hugh and Tim is: a way to switch on/off functionality
+over a limited 32-bit opcode space, so that we have one mode for
+"POWER 3.0B compliance" and another for "things that are absolutely
+essential to make a decent GPU".  With these two being strongly
+mutually exclusively incompatible, this is just absolutely critical.
+
+POWER 3.0B does not have c++ style LR/SC atomic operations for example,
+and if we have half a **million** data structures **per second** that need
+SMP-level inter-core mutexes, and the current POWER 3.0B multi-instruction
+atomic operations are used, we're highly likely to use 10 to 15 **percent**
+processing power consumed on spin-locking.
+
+Adding new and essential features that could well end up in a future version
+of the POWER ISA *need* to be firewalled in a clean way, and we've been
+asked to [draft a letter](https://libre-riscv.org/openpower/isans_letter/)
+to some of the (very busy) engineers with a huge amount of knowledge
+and experience inside IBM, for them to consider.  Some help in reviewing
+it would be greatly appreciated.
+
+These and many other things are why the calls with Tim and Hugh are a
+good idea.  The amazing thing is that they're taking us seriously.  I believe
+I may have mentioned (at least on the mailing list), that there have been
+several people inside IBM and other places, working quietly for a long time
+to get OpenPOWER in place - and, critically, *done right*.  I believe Hugh
+mentioned that it was quite amusing that several people contacted him to
+say "why aren't you doing what RISC-V is doing, being open and all?" whilst
+he and others had been quietly spearheading an effort to that for some time!
+
+Other nice things we learned (more on this below) is that Epic Games
+and RaptorCS are collaborating to get POWER9 supported in Unreal Engine.
+And that the idea has been very tentatively considered to use our design
+for the "boot management" processor, running
+[OpenBMC](https://github.com/openbmc/openbmc).  These are early days,
+it's just ideas, ok!  Aside from anything, we actually have to get a chip
+done, first.
 
 # OpenPower Virtual Coffee Meetings