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
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
# 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
# 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
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).
-
-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.
-
-Some example code (the IR is likely to change somewhat):
-
-```
-# this is a comment, comments go from the `#` character
-# to the end of the line.
-
-fn function1[] -> ! {
- # declares a function named function1 that takes
- # zero parameters and doesn't return
- # (the return type is !, taken from Rust).
- # If the function could return, there would instead be
- # a list of return types:
- # fn my_fn[] -> [i32, i64] {...}
- # my_fn returns an i32 and an i64. The multiple
- # returned values is inspired by Lua's multiple return values.
-
- # the hints for this function
- hints {
- # there are no inlining hints for this function
- inlining_hint: none,
- # this function doesn't have a side-effect hint
- side_effects: normal,
- }
-
- # function local variables
- {
- # the local variable is an i32 with an
- # alignment of 4 bytes
- i32, align: 0x4 -> local_var1: data_ptr;
- # the pointer to the local variable is
- # assigned to local_var1 which has the type data_ptr
- }
-
- # the function body is a single block -- block1.
- # block1's return types are instead attached to the
- # function signature above
- # (the `-> !` in the `fn function1[] -> !`).
- block1 {
- # the first instruction is a loop named loop1.
- # the initial value of loop_var is the_const,
- # which is a named constant.
- # the value of the_const is the address of the
- # function `function1`.
- loop loop1[the_const: fn function1] -> ! {
- # loop1 takes 1 parameter, which is assigned
- # to loop_var. the type of loop_var is a pointer to a
- # function which takes no parameters and doesn't
- # return.
- -> [loop_var: fn[] -> !];
-
- # the loop body is a single block -- block2.
- # block2's return value definitions are instead
- # attached to the loop instruction above
- # (the `-> !` in the `loop loop1[...] -> !`).
- block2 {
-
- # block3 is a block instruction, it returns
- # two values, which are assigned to a and b.
- # Both of a and b have type i32.
- block block3 -> [a: i32, b: i32] {
- # the only way a block can return is by
- # being broken out of using the break
- # instruction. It is invalid for execution
- # to reach the end of a block.
-
- # this break instruction breaks out of
- # block3, making block3 return the
- # constants 1 and 2, both of type i32.
- break block3[1i32, 2i32];
- };
-
- # an add instruction. The instruction adds
- # the value `a` (returned by block3 above) to
- # the constant `increment` (which is an i32
- # with the value 0x1), and stores the
- # result in the value `"a"1`. The source-code
- # location for the add instruction is specified
- # as being line 12, column 34, in the file
- # `source_file.vertex`.
- add [a, increment: 0x1i32]
- -> ["a"1: i32] @ "source_file.vertex":12:34;
-
- # The `"a"1` name is stored as just `a` in
- # the IR, where the 1 is a numerical name
- # suffix to differentiate between the two
- # values with name `a`. This allows robustly
- # handling duplicate names, by using the
- # numerical name suffix to disambiguate.
- #
- # If a name is specified without the numerical
- # name suffix, the suffix is assumed to be the
- # number 0. This also allows handling names that
- # have unusual characters or are just the empty
- # string by using the form with the numerical
- # suffix:
- # `""0` (empty string)
- # `"\n"0` (a newline)
- # `"\u{12345}"0` (the unicode scalar value 0x12345)
-
-
- # this continue instruction jumps back to
- # the beginning of loop1, supplying the new
- # values of the loop parameters. In this case,
- # we just supply loop_var as the value for
- # the parameter, which just gets assigned to
- # loop_var in the next iteration.
- continue loop1[loop_var];
- }
- };
- }
-}
-```
+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).
+
+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).
# OpenPOWER Conference calls
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
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
Yehowshua is a student at Georgia Tech currently pursuing a Masters in
Computer Engineering - to graduate this summer. He had started working
-on LibreSOC in December and wanted to to get LibreSOC more funding so
+on Libre-SOC in December and wanted to to get Libre-SOC more funding so
I could work on it full time.
He originally asked if the ECE Chair at Georgia Tech would be willing
to fund an in-department effort to deliver an SOC in collaboration
-with LibreSOC(an idea to which he was quite receptive). Through Luke,
+with Libre-SOC(an idea to which he was quite receptive). Through Luke,
Yehowshua got in contact with Chistopher Klaus who suggested Yehowshua
should look into Klaus's startup accelerator program Create-X and perhaps
-consider taking LibreSOC down the startup route. Robert Rhinehart, who
-had funded LibreSOC a little in the past (*note from Luke: he donated
+consider taking Libre-SOC down the startup route. Robert Rhinehart, who
+had funded Libre-SOC a little in the past (*note from Luke: he donated
the ZC706 and also funded modernisation of Richard Herveille's excellent
[vga_lcd](https://github.com/RoaLogic/vga_lcd) Library*)
also suggested that Yehowshua
-incorporate LibreSOC with help from Create-X and said he would be willing
+incorporate Libre-SOC with help from Create-X and said he would be willing
to be a seed investor. All this happened by February.
As of March, Yehowshua has been talking with Robert about what type of
-customers would be interested in LibreSOC. Robert is largely interested in
+customers would be interested in Libre-SOC. Robert is largely interested in
biological applications. Yehowshua also had a couple meetings with Rahul
-from Create-X. Yehowshua has started the incorporation of LibreSOC. The
-parent company will probably be called Systèmes-Libres with LibreSOC
+from Create-X. Yehowshua has started the incorporation of Libre-SOC. The
+parent company will probably be called Systèmes-Libres with Libre-SOC
simply being one of the products we will offer. Yehowshua also attended
-HPCA in late February and had mentioned LIbreSOC during his talk. People
+HPCA in late February and had mentioned Libre-SOC during his talk. People
seemed to find the idea quite interesting
He will later be speaking with some well know startup lawyers that have
many - layers of NDAs and reducing NREs and unnecessary and artificial
barriers for ASIC development: I helped him put in the submission, and
he was really happy to do the Cell Libraries that we will be using for
-LibreSOC's 180nm test tape-out in October 2020.)
+Libre-SOC's 180nm test tape-out in October 2020.)
# Public-Inbox and Domain Migration
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.
-
-# Build Servers
-
-TODO
+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
+
+(*written kindly by Cole*)
+
+Over the past month, Jacob, and a new project member Cole, set up a new
+build server for the project. The build server is an old computer that
+Jacob wasn't using anymore, that he decided to make available to the
+project for running continuous integration (CI) testing for the many
+modules and submodules of the project. The build server is a gitlab test
+runner instance using a Docker backend. As Luke has taken pains to make
+clear
+[many times](https://libre-riscv.org/HDL_workflow/),
+very large and complex python projects are guaranteed
+to fail without proper, extensive test coverage. This new build server
+will allow us to
+[automate](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-April/005687.html)
+the running, monitoring, and reporting of these
+tests, giving us the ability to push a commit and have it automatically
+"verified" as cohesive with the existing codebase. Automating feedback,
+will help provide more confidence to the engineers that their code isn't
+breaking some other functionality in a codebase they are working on,
+and should also help improve the ease of long-term maintainability
+of the code. The more we can automate the menial tasks that have to
+be repeated frequently, and are important for success of the project
+but are not related to progressing the engineering of the Libre-SOC,
+the more productive project members can be.
+
+To help continue to ease such administrative burdens on the engineers,
+Cole is also working on a repository of setup automation scripts. The first
+script is one that will replicate the setup of Jacob's build server,
+so that others who want to contribute computational resources to the
+project may do so easily. Cole is also working on a collection of modular
+scripts to automate the setup of the development environment for the
+HDL workflow and the layout of the SOC, including the installation of
+development branches of a substainal number of very complex pieces of
+software. This should help ease the process of onboarding new members
+to the project, especially some interns that we have coming onboard in
+the next few months to do the layout of the chip. These scripts will be
+available via the git.libre-riscv.org repository dev-env-setup, at the
+[following link](http://git.libre-riscv.org/?p=dev-env-setup.git)
# Conclusion
projects / crowdsupply.git / blobdiff