From ad7b014bf37cb7d33ea7bfe7c34d5e55c81cde4b Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sat, 28 Mar 2020 18:31:34 +0000 Subject: [PATCH] add openpower section and isa/decoder/simulator section --- ...23_2020mar26_decoder_emulator_started.mdwn | 87 ++++++++++++++++++- 1 file changed, 85 insertions(+), 2 deletions(-) diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn index 19e14fb..072de1d 100644 --- 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 -- 2.30.2