"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
essential for showing the interconnections between cells, and gtkwave
is essential for debugging.
+If you would like to save yourself a lot more typing, check out the
+[dev-env-setup](https://git.libre-soc.org/?p=dev-env-setup.git;a=summary)
+repository, examine the scripts there and use them to automate much of
+the process below.
+
## git
Look up good tutorials on how to use git effectively. There are so many
Follow the source code (git clone) instructions here:
<http://www.clifford.at/yosys/download.html>
-Do not try to use a fixed revision (currently 0.9), nmigen is evolving
-and frequently interacts with yosys
+Or, alternatively, use the
+[yosys-et-al](https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=yosys-et-al;hb=HEAD)
+script (which also installs symbiyosys and its dependencies)
+
+Do not try to use a fixed revision of yosys (currently 0.9), nmigen is evolving
+and frequently interacts with yosys.
## symbiyosys
* mkdir ~/src
* cd !$
-* git clone https://github.com/m-labs/nmigen.git
+* git clone https://github.com/nmigen/nmigen.git
* cd nmigen
* sudo bash
* python3 setup.py develop
## 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
avoid this kind of thing however pair-programming is difficult to organise
for remote collaborative libre projects (suggestions welcomed here)
+### Enable editor auto-detection of file changes by external programs
+
+This is important. "git pull" will merge in changes. If you then
+arbitrarily save a file without re-loading it, you risk destroying
+other people's work.
+
### Absolutely no auto-generated output
* **do not commit autogenerated output**. write a shell script and commit
### 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.
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.
+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.
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.
+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.
+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?"
+it is a tricky balance: basically use your common sense, or just ask
+someone else, "can you understand this code?"
### Reasons for code structure
## Unit tests
+For further reading, see the wikipedia page on
+[Test-driven Development](https://en.wikipedia.org/wiki/Test-driven_development)
+
This deserves its own special section. It is extremely important to
appreciate that without unit tests, python projects are simply unviable.
Python itself has over 25,000 individual tests.
Find appropriate tutorials for nmigen and yosys, as well as symbiyosys.
+* Robert Baruch's nmigen tutorials look really good:
+ <https://github.com/RobertBaruch/nmigen-tutorial>
* Although a verilog example this is very useful to do
<https://symbiyosys.readthedocs.io/en/latest/quickstart.html#first-step-a-simple-bmc-example>
* This tutorial looks pretty good and will get you started
* There exist several nmigen examples which are also executable
<https://github.com/m-labs/nmigen/tree/master/examples/> exactly as
described in the above tutorial (python3 filename.py -h)
-* Robert Baruch's nmigen tutorials look really good:
- <https://github.com/RobertBaruch/nmigen-tutorial>
+
projects / libreriscv.git / blobdiff