(no commit message)

[libreriscv.git] / HDL_workflow.mdwn

diff --git a/HDL_workflow.mdwn b/HDL_workflow.mdwn
index ba30514b1ce5cb1e4ffc905d15b55b77e0e00bbd..47732a4c8f40f70a7a8c3098e4aba269a718278c 100644 (file)
--- a/HDL_workflow.mdwn
+++ b/HDL_workflow.mdwn
@@ -243,6 +243,13 @@ including its 80 character limit.  In short: not everyone has the same
 "modern" GUI workflow or has access to the same computing resources as
 you, so please do respect that.
 
+More on this concept is
+[here](https://www.linuxjournal.com/content/line-length-limits).
+Note *very pointedly* that Linus Torvalds *specifically* states that
+he does not want Linux kernel development to become the exclusive
+domain of the "wealthy".  That means **no** to assumptions about
+access to ultra-high resolution screens.
+
 # Software prerequisites
 
 Whilst many resources online advocate "sudo" in front of all root-level
@@ -316,7 +323,7 @@ testing can then be carried out with "python3 setup.py test"
 ## Softfloat and sfpy
 
 These are a test suite dependency for the ieee754fpu library, and
-will be changed in the future to use Jacob's algorithmic numeric
+will be changed in the future to use Jacob's [simple-soft-float](https://crates.io/crates/simple-soft-float)
 library.  In the meantime, sfpy can be built as follows:
 
     git clone --recursive https://github.com/billzorn/sfpy.git
@@ -358,6 +365,28 @@ You can test your installation by doing the following:
 
 It should print out `Posit8(1.3125)`
 
+## qemu, cross-compilers, gdb
+
+As we are doing POWER ISA, POWER ISA compilers, toolchains and
+emulators are required.
+
+Install powerpc64 gcc:
+
+    apt-get install gcc-9-powerpc64-linux-gnu
+
+Install qemu:
+
+    apt-get install qemu-system-ppc
+
+Install gdb from source.  Obtain the latest tarball, unpack it, then:
+
+    cd gdb-9.1 (or other location)
+    mkdir build
+    cd build
+     ../configure --srcdir=.. --host=x86_64-linux --target=powerpc64-linux-gnu
+    make -j16
+    make install
+
 ## Coriolis2
 
 See [[coriolis2]] page, for those people doing layout work.
@@ -553,7 +582,7 @@ and follow up the next day *after* running the full relevant unit tests.
 
 ### Why such strict rules?
 
-the reason for all the above is because python is a weakly typed language.
+the reason for all the above is because python is a dynamically typed language.
 make one tiny change at the base level of the class hierarchy and the
 effect may be disastrous.
 
@@ -619,6 +648,12 @@ than it should be, the reversion process becomes extremely painful.
   causes unnecessary resource utilisation, makes code readability and
   tracking extremely difficult, and results in unintended side-effects.
 
+example: often you want to find the code from which a class was imported.  nirmally you go to the top of the file, check the imports, and you know exactly which file has the class because of the import path.  by using wildcards, you have absolutely *no clue* which wildcard imported which class or classes.
+
+example: sometimes you may accidentally have duplicate code maintained in two or more places.  editing one of them you find, puzzlingly, that the code behaves in some files with the old behaviour, but in others it works.  after a nassive amount of investigation, you find that the working files happen to have a wildcard import of the newer accidental duplicate class **after** the wildcard import of the older class with exactly the same name.  if you had used explicit imports, you would have spotted the double import of the class from two separate locations, immediately.
+
+really.  don't.  use.  wildcards.
+
 ### Keep file and variables short but clear
 
 * try to keep both filenames and variable names short but not ridiculously
@@ -627,6 +662,12 @@ than it should be, the reversion process becomes extremely painful.
   m.d.comb" followed by multiple "comb += nmigen_stmt" lines is a good trick
   that can reduce code indentation by 6 characters without reducing clarity.
 
+Additionally, use comments just above an obtuse variable in order to help explain what it is for.  In combination with keeping the the module itself short, other readers will not need to scroll back several pages in order to understand the code.
+
+Yes it is tempting to actually use the variables as self-explanatory-comments and generally this can be extremely good practice.  the problem comes when the variable is so long that a function with several parameters csn no longer fit on a single line, and takes up five to ten lines rather than one or two. at that point, the length of the code is adversely affected and thus so is readability by forcing readers to scroll through reams of pages.
+
+it is a tricky balance: basically use your common sense, or just ask someone else, "can you understand this code?"
+
 ### Reasons for code structure
 
 regarding code structure: we decided to go with small modules that are
@@ -731,6 +772,21 @@ However it is appreciated that writing formal proofs is a bit of a
 black art.  This is where team collaboration particularly kicks in,
 so if you need help, ask on the mailing list.
 
+## Don't comment out unit tests: add them first (as failures) and fix code later
+
+Unit tests serve an additional critical purpose of keeping track of code
+that needs to be written.  In many cases, you write the unit test *first*,
+despite knowing full well that the code doesn't even exist or is completely
+broken.  The unit test then serves as a constant and important reminder
+to actually fix (or write) the code.
+
+Therefore, *do not* comment out unit tests just because they "don't work".
+If you absolutely must stop a unit test from running, **do not delete it**.
+Simply mark it with an appropriate
+["skip" decorator](https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures),
+preferably with a link to a URL in the [bugtracker](http://bugs.libre-riscv.org)
+with further details as to why the unit test should not be run.
+
 # TODO Tutorials
 
 Find appropriate tutorials for nmigen and yosys, as well as symbiyosys.