# HDL workflow
This section describes the workflow and some best practices for developing
-the Libre-SoC hardware. We use nmigen, yosys and symbiyosys, and this
+the Libre-SOC hardware. We use nmigen, yosys and symbiyosys, and this
page is intended not just to help you get set up, it is intended to
help advise you of some tricks and practices that will help you become
effective team contributors.
and formal mathematical proofs for all code at all levels is therefore
paramount.
+Therefore, we need not only to be "self-sufficient" (absolutely under no circumstances critically reliant on somebody else's servers **or protocols**) we also need to ensure that everything (including all communication such as the mailing list archives) are recorded, replicable, and accessible in perpetuity. Use of slack or a "forum" either actively prevents or makes that much harder.
+
# Collaboration resources
The main message here: **use the right tool for the right job**.
* mailing list: general communication and discussion.
+* irc channel #libre-soc: real(ish)-time communication.
* bugtracker: task-orientated, goal-orientated *focussed* discussion.
* ikiwiki: document store, information store, and (editable) main website
* git repositories: code stores (**not binary or auto-generated output store**)
-* ftp server (<http://ftp.libre-riscv.org>): large file store.
+* ftp server (<https://ftp.libre-soc.org/>): large (temporary,
+ auto-generated) file store.
we will add an IRC channel at some point when there are enough people
-to warrant having one.
+to warrant having one (and it will be publicly archived)
note also the lack of a "forum" in the above list. this is very deliberate. forums are a serious distraction when it comes to technical heavily goal-orientated development. recent internet users may enjoy looking up the "AOL metoo postings" meme.
public and archived (i.e not skype, not telegram, not discord,
and anyone seriously suggesting slack will be thrown to the
lions). Therefore we have a mailing list. Everything goes through
-there. <http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev>
+there. <https://lists.libre-soc.org/mailman/listinfo/libre-soc-dev>
therefore please do google "mailing list etiquette" and at the very
minimum look up and understand the following:
using phone at airport flight soon, v. quick reply: ....")
* Always trim context but do not cut excessively to the point where people
cannot follow the discussion. Especially do not cut the attribution
- ("On monday xxx wrote")
+ ("On monday xxx wrote") of something that you are actually replying
+ to.
* Use inline replies i.e. reply at the point in the relevant part of
the conversation, as if you were actually having a conversation.
* Follow standard IETF reply formatting, using ">" for cascaded
If discussions result in any actionable items, it is important not to
lose track of them. Create a bugreport, find the discussion in the
-archives <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/>,
+archives <https://lists.libre-soc.org/pipermail/libre-soc-dev/>,
and put the link actually in the bugtracker as one of the comments.
At some point in any discussion, the sudden realisation may dawn on one
or more people that this is an "actionable" discussion. at that point
-it may become better to use <http://bugs.libre-riscv.org>
+it may become better to use <https://bugs.libre-soc.org/>
itself to continue the discussion rather than to keep on dropping copies
of links into the bugtracker. The bugtracker sends copies of comments
*to* the list however this is 'one-way' (note from lkcl: because this
Or, if it is more appropriate, commit a document (or source code)
into the relevant git repository then look up the link in the gitweb
source tree browser and post that (in the bugtracker or mailing list)
-See <http://git.libre-riscv.org>
+See <https://git.libre-soc.org/>
### gmail "spam"ifying the list
## ikiwiki
-Runs the main libre-riscv.org site (including this page). effective,
+Runs the main libre-soc.org site (including this page). effective,
stunningly light on resources, and uses a git repository not a database.
That means it can be edited offline.
dedicated server. again, it is extremely effective and low resource
utilisation. reminder: lions are involved if github is mentioned.
-gitweb is provided which does a decent job. <http://git.libre-riscv.org>
+gitweb is provided which does a decent job. <https://git.libre-soc.org/>
## ftp server
-<http://ftp.libre-riscv.org> is available for storing large files
+<https://ftp.libre-soc.org/ is available for storing large files
that do not belong in a git repository, if we have (or ever need)
any. images (etc.) if small and appropriate should go into the
wiki, however .tgz archives (etc.) and, at some point, binaries,
"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
* apt-get install build-essential
* apt-get install git python3.7 python3.7-dev python-nosetest3
* apt-get install graphviz xdot gtkwave
+* apt-get install python3-venv
+* apt-get install python-virtualenv # this is an alternative to python3-venv
* return to user prompt (ctrl-d)
This will get you python3 and other tools that are needed. graphviz is
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
git apply /path/to/ieee754fpu/berkeley-softfloat.patch
cd ..
- # install dependencies
+ # prepare a virtual environment for building
python3 -m venv .env
- . .env/bin/activate
+
+ # or, if you prefer the old way:
+ # virtualenv -p python3 .env
+
+ # install dependencies
+ source .env/bin/activate
pip3 install --upgrade -r requirements.txt
# build
- make lib -j8
+ make lib -j$(nproc)
make cython
- make inplace -j8
+ make inplace -j$(nproc)
make wheel
# install
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 -j$(nproc)
+ make install
+
+## power_instruction_analyzer (pia)
+
+We have a custom tool built in rust by programmerjake to help analyze
+the power instructions execution on *actual* hardware.
+
+Note: a very recent version of pip3 is required for this to work.
+
+Install rust:
+
+ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
+
+Make sure we have the correct and up-to-date rust compiler (rustc):
+
+ rustup default stable
+ rustup update
+
+Use rust's package manager *cargo* to install the rust-python build tool maturin:
+
+ cargo install maturin
+
+Install from git source by doing the following:
+
+ git clone https://salsa.debian.org/Kazan-team/power-instruction-analyzer.git pia
+ cd pia
+ maturin build --cargo-extra-args=--features=python-extension
+ python3 -m pip install --user target/wheels/*.whl
+
+Note: an ongoing bug in maturin interferes with successful installation. This can be worked around by explicitly installing only the .whl files needed rather than installing everything (*.whl).
+
## Coriolis2
-See [[coriolis2]] page, for those people doing layout work.
+See [[HDL_workflow/coriolis2]] page, for those people doing layout work.
+
+## Chips4Makers JTAG
+
+As this is an actual ASIC, we do not rely on an FPGA's JTAG TAP interface, instead require a full complete independent implementation of JTAG. Staf Verhaegen has one, with a full test suite, and it is superb and well-written. The Libre-SOC version includes DMI (Debug Memory Interface):
+
+ git clone https://git.libre-soc.org/c4m-jtag.git
+
+Included is an IDCODE tap point, Wishbone Master (for direct memory read and write, fully independent of the core), IOPad redirection and testing, and general purpose shift register capability for any custom use.
+
+We added a DMI to JTAG bridge in LibreSOC which is directly connected to the core, to access registers and to be able to start and stop the core and change the PC. In combination with the JTAG Wishbone interface the test ASIC can have a bootloader uploaded directly into onboard SRAM and execution begun.
# Registering for git repository access
Create a file ~/.ssh/config with the following lines:
- Host git.libre-riscv.org
+ Host git.libre-soc.org
Port 922
Wait for the Project Admin to confirm that the ssh key has been added
to the required repositories. Once confirmed, you can clone any of the
-repos at http://git.libre-riscv.org:
+repos at https://git.libre-soc.org/:
- git clone gitolite3@git.libre-riscv.org:REPONAME.git
+ git clone gitolite3@git.libre-soc.org:REPONAME.git
Alternatively, the .ssh/config can be skipped and this used:
- git clone ssh://gitolite3@git.libre-riscv.org:922/REPONAME.git
+ git clone ssh://gitolite3@git.libre-soc.org:922/REPONAME.git
# git configuration
* mkdir ~/src
* cd !$
-* git clone gitolite3@git.libre-riscv.org:nmutil.git
-* git clone gitolite3@git.libre-riscv.org:ieee754fpu.git
-* git clone gitolite3@git.libre-riscv.org:soc.git
+* git clone gitolite3@git.libre-soc.org:nmutil.git
+* git clone gitolite3@git.libre-soc.org:ieee754fpu.git
+* git clone gitolite3@git.libre-soc.org:nmigen-soc.git
+* git clone gitolite3@git.libre-soc.org:soc.git
In each of these directories, in the order listed, track down the
setup.py file, then, as root (sudo bash), run the following:
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
### Do not break existing code
-* keep working code working **at all times**. find ways to ensure that this is the case. examples include writing alternative classes that replace existing functionality and adding runtime optiobs to select between old and new code.
+* keep working code working **at all times**. find ways to ensure that this is the case. examples include writing alternative classes that replace existing functionality and adding runtime options to select between old and new code.
### Small commits with relevant commit message
### 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.
+
+really. don't. use. wildcards.
+
### Keep file and variables short but clear
* try to keep both filenames and variable names short but not ridiculously
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
## 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.
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](https://bugs.libre-soc.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.
+* 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