From: Luke Kenneth Casson Leighton Date: Fri, 3 Apr 2020 19:41:40 +0000 (+0100) Subject: reformat, add links X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=3e891fc3f8ac5f012942d89827912e8ecab342c4;p=crowdsupply.git reformat, add links --- diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn index 81bdafe..ec95373 100644 --- a/updates/023_2020mar26_decoder_emulator_started.mdwn +++ b/updates/023_2020mar26_decoder_emulator_started.mdwn @@ -189,8 +189,8 @@ fields from an instruction. To test the decoder, we initially verified it against the tables we extracted, and manually against the [POWER ISA specification](https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0). Later -however, we came up with the idea of [verifying the -decoder](https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/decoder/test/test_decoder_gas.py;h=9238d3878d964907c5569a3468d6895effb7dc02;hb=433ab59cf9b7ab1ae10754798fc1c110e705db76) +however, we came up with the idea of +[verifying the decoder](https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/decoder/test/test_decoder_gas.py;h=9238d3878d964907c5569a3468d6895effb7dc02;hb=433ab59cf9b7ab1ae10754798fc1c110e705db76) 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 @@ -209,8 +209,8 @@ 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](https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/test_sim.py;h=aadaf667eff7317b1aa514993cd82b9abedf1047;hb=433ab59cf9b7ab1ae10754798fc1c110e705db76) +some experimentation using this technique to verify a +[rudimentary simulator](https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/test_sim.py;h=aadaf667eff7317b1aa514993cd82b9abedf1047;hb=433ab59cf9b7ab1ae10754798fc1c110e705db76) of the SOC backend, and it seemed to work quite well. *(Note from Luke: this automated approach, taking either other people's @@ -220,6 +220,8 @@ correct and does not contain transcription errors).* # simple-soft-float Library and POWER FP emulation +(*written kindly by Jacob*) + The [simple-soft-float](https://salsa.debian.org/Kazan-team/simple-soft-float) library is a floating-point library Jacob wrote with the intention of being a reference implementation of IEEE 754 for hardware testing @@ -282,6 +284,9 @@ sponsorship, from individuals, Foundations (such as NLNet) and Companies # Kazan Getting a New Shader Compiler IR +(*written kindly by Jacob, a dedicated update on Kazan will definitely +feature in the future*) + After spending several weeks only to discover that translating directly from SPIR-V to LLVM IR, Vectorizing, and all the other front-end stuff all in a single step is not really feasible, Jacob has switched to [creating a new @@ -301,18 +306,22 @@ The IR uses structured control-flow inspired by WebAssembly's control-flow constructs as well as [SSA](https://en.wikipedia.org/wiki/Static_single_assignment_form) but, instead of using traditional phi instructions, it uses block and loop parameters and -return values (inspired by [Cranelift's EBB -parameters](https://github.com/bytecodealliance/wasmtime/blob/master/cranelift/docs/ir.md#static-single-assignment-form) -as well as both of the [Rust](https://www.rust-lang.org/) and [Lua](https://www.lua.org/) programming languages). +return values (inspired by +[Cranelift's EBB parameters](https://github.com/bytecodealliance/wasmtime/blob/master/cranelift/docs/ir.md#static-single-assignment-form) +as well as both of the [Rust](https://www.rust-lang.org/) and +[Lua](https://www.lua.org/) programming languages). -The IR has a single pointer type for all data pointers (`data_ptr`), unlike LLVM IR where pointer types have a type they point to (like `* i32`, where `i32` is the type the pointer points to). +The IR has a single pointer type for all data pointers (`data_ptr`), +unlike LLVM IR where pointer types have a type they point to (like `* +i32`, where `i32` is the type the pointer points to). -Because having a serialized form of the IR is important for any good IR, like -LLVM IR, it has a user-friendly textual form that can be both read and -written without losing any information (assuming the IR is valid, comments are -ignored). A binary form may be added later. +Because having a serialized form of the IR is important for any good IR, +like LLVM IR, it has a user-friendly textual form that can be both read +and written without losing any information (assuming the IR is valid, +comments are ignored). A binary form may be added later. -Some example IR is [available in the Kazan repo](https://salsa.debian.org/Kazan-team/kazan/-/blob/master/docs/Shader%20Compiler%20IR%20Example.md). +Some example IR is +[available in the Kazan repo](https://salsa.debian.org/Kazan-team/kazan/-/blob/master/docs/Shader%20Compiler%20IR%20Example.md). # OpenPOWER Conference calls @@ -447,12 +456,12 @@ So, as I mentioned USD $25,000, we're happy with USD $10 million. It's really up to you guys, at Epic Games, as to what level you'd like to see us get to, and how fast. -USD $600,000 for example we can instead of paying USD $1million to a proprietary -company to license a DDR3 PHY for a limited one-time use and only a 32-bit -wide interface, we can contract SymbioticEDA to *design* a DDR3 PHY for us, -which both we *and the rest of the worldwide Silicon Community can use -without limitation* because we will ask SymbioticEDA to make the design -(and layout) libre-licensed, for anyone to use. +USD $600,000 for example we can instead of paying USD $1million to a +proprietary company to license a DDR3 PHY for a limited one-time use and +only a 32-bit wide interface, we can contract SymbioticEDA to *design* +a DDR3 PHY for us, which both we *and the rest of the worldwide Silicon +Community can use without limitation* because we will ask SymbioticEDA +to make the design (and layout) libre-licensed, for anyone to use. USD 250,000 pays for the mask charges that will allow us to do the 40nm quad-core ASIC that we have on the roadmap for the second chip. USD @@ -481,7 +490,8 @@ required between five (minimum) and *ninteen* separate and distinct tasks, a call with Michiel and Joost turned into an unexpected three hour online marathon, scrambling to write almost fifty bugreports as part of the Schedule to be attached to each Memorandum of Understanding. The mailing list -got a [leeetle bit busy](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/005003.html) +got a +[leeetle bit busy](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/005003.html) right around here. Which emphasised for us the important need to subdivide the mailing list into @@ -669,7 +679,8 @@ parser which read the packet formats *from the IETF Draft Specification*, and outputted c-code. This leaves me wondering, as I mention on the HDL list, if we can do the same -thing with large sections of the POWER Spec. +thing with large sections of the POWER Spec (*answer as of 3rd April 2020: +[yes](https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/decoder/power_pseudo.py;h=f2e575e8c5b707e7ec2f8d2ea6ca6d36060e08ad;hb=af3c6727c8bb59623bf5672b867407b5516e8338)*) # Build Servers, Process Automation, and Reducing Cognitive Load