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
+We will add an IRC channel at some point when there are enough people
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.
+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.
-note also the complete lack of "social platforms". if we wanted to tell everybody how much better each of us are than anyone else in the team, how many times we made a commit (look at me, look at me, i'm so clever), and how many times we went to the bathroom, we would have installed a social media based project "management" system.
+Note also the complete lack of "social platforms". if we wanted to tell everybody how much better each of us are than anyone else in the team, how many times we made a commit (look at me, look at me, i'm so clever), and how many times we went to the bathroom, we would have installed a social media based project "management" system.
## Main contact method: mailing list
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:
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
-see <https://blog.kittycooper.com/2014/05/keeping-my-mailing-list-emails-out-of-gmails-spam-folder/>
+See <https://blog.kittycooper.com/2014/05/keeping-my-mailing-list-emails-out-of-gmails-spam-folder/>
-basically it is possible to select any message from the list, create a "filter" (under "More"),
+Basically it is possible to select any message from the list, create a "filter" (under "More"),
and, on the 2nd dialog box, click the "never send this to Spam" option.
## Bugtracker
## 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.
Hint: to create a new page, find a suitable page that would link to it,
first, then put the link in of the page you want to create, as if the
-page already exists. Save that page, and you will find a questionmark
+page already exists. Save that page, and you will find a question mark
next to the new link you created. click that link, and it will fire up a
"create new page" editor.
+Wiki pages are formatted in [[markdown|ikiwiki/markdown]] syntax.
+
Hint again: the wiki is backed by a git repository. Don't go overboard
but at the same time do not be afraid that you might "damage" or "lose"
pages. Although it would be a minor pain, the pages can always be
## git
-we use git. more on this below. we also use gitolite3 running on a
-dedicated server. again, it is extremely effective and low resource
-utilisation. reminder: lions are involved if github is mentioned.
+We use git. More on this below. We also use [gitolite3](https://gitolite.com/gitolite/) running on a dedicated server. again, it is extremely effective and low resource utilisation. Reminder: lions are involved if github is mentioned.
+
+[gitweb](https://git.wiki.kernel.org/index.php/Gitweb) is provided which does a decent job. <https://git.libre-soc.org/>
-gitweb is provided which does a decent job. <http://git.libre-riscv.org>
+[Git](https://en.wikipedia.org/wiki/Git) does version control, ie it tracks changes to files so that previous versions can be got back or compared.
## 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
+any. Images (etc.) if small and appropriate should go into the
wiki, however .tgz archives (etc.) and, at some point, binaries,
should be on the ftp server.
-ask on the list if you have a file that belongs on the ftp server.
+Ask on the list if you have a file that belongs on the ftp server.
## server
-as an aside: all this is "old school" and run on a single core 512MB
+As an aside: all this is "old school" and run on a single core 512MB
VM with only a 20GB HDD allocation. it costs only 8 GBP per month from
mythic-beasts and means that the project is in no way dependent on anyone
else - not microsoft, not google, not facebook, not amazon.
-we tried gitlab. it didn't go well. please don't ask to replace the
-above extremely resource-efficient services with it.
+We tried [gitlab](https://about.gitlab.com/). it didn't go well. please don't ask to replace the above extremely resource-efficient services with it.
# Hardware
What is particularly useful is to have hi-res screens (curved is
*strongly* recommended if the LCD is over 24in wide, to avoid eyeballs
-going "prism" through longterm use), and to have several of them: the
+going "prism" through long term use), and to have several of them: the
more the better. Either a DisplayLink UD160A (or more modern variant)
or simply using a second machine (lower spec hardware because it will
run editors) is really effective.
# Operating System
-First install and become familiar with Debian (ubuntu if you absolutely
+First install and become familiar with [Debian](https://www.debian.org/) ([Ubuntu](https://ubuntu.com/) if you absolutely
must) for standardisation cross-team and so that toolchain installation
is greatly simplified. yosys in particular warns that trying to use
Windows, BSD or MacOS will get you into a world of pain.
# editors and editing
Whilst this is often a personal choice, the fact that many editors are
-GUI based and run fullscreen with the entire right hand side *and* middle
+GUI based and run full-screen with the entire right hand side *and* middle
*and* the majority of the left side of the hi-res screen entirely unused
and bereft of text leaves experienced developers both amused and puzzled.
-At the point where such fullscreen users commit code with line lengths
+At the point where such full-screen users commit code with line lengths
well over 160 characters, that amusement quickly evaporates.
-Where the problems occur with fullscreen editor usage is when a project
+Where the problems occur with full-screen editor usage is when a project
is split into dozens if not hundreds of small files (as this one is). At
that point it becomes pretty much essential to have as many as six to
eight files open *and on-screen* at once, without overlaps i.e. not in
[[!img 2020-01-24_11-56.png size=640x ]]
(hint/tip: fvwm2 set up with "mouse-over to raise focus, rather than
-additionally requiring a mouseclick, can save a huge amount of cumulative
+additionally requiring a mouse click, can save a huge amount of cumulative
development time here, switching between editor terminal(s) and the
command terminals).
Once this becomes necessary, it it turn implies that having greater
-than 80 chars per line - and running editors fullscreen - is a severe
-hindance to an essential *and highly effective* workflow technique.
+than 80 chars per line - and running editors full-screen - is a severe
+hinderance to an essential *and highly effective* workflow technique.
Additionally, care should be taken to respect that not everyone will have
200+ column editor windows and the eyesight of a hawk. They may only have
continuously page-up and page-down to read the code even of a single
function, in full.
-This helps explain in part, below, why compliance with pep8 is enforced,
-including its 80 character limit. In short: not everyone has the same
-"modern" GUI workflow or has access to the same computing resources as
+This helps explain in part, below, why compliance with [pep8](https://pep8.org/) is enforced, 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
-commands below, this quickly becomes tiresome. run "sudo bash", get a
+Whilst many resources online advocate "`sudo`" in front of all root-level
+commands below, this quickly becomes tiresome. run "`sudo bash`", get a
root prompt, and save yourself some typing.
* sudo bash
* 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.
+This will get you python3 and other tools that are needed. [graphviz](https://graphviz.org/) is essential for showing the interconnections between cells, and [gtkwave](http://gtkwave.sourceforge.net/) 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
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.
+
+[Yosys](http://www.clifford.at/yosys/) is a framework for Verilog RTL.
+[Verilog](https://en.wikipedia.org/wiki/Verilog) is a hardware description language.
+RTL [Register Transfer Level](https://en.wikipedia.org/wiki/Register-transfer_level) models how data moves between [registers](https://en.wikipedia.org/wiki/Hardware_register).
## symbiyosys
the formal proof scripts will be (less resource utilisation in certain
circumstances).
+[SymbiYosys](https://symbiyosys.readthedocs.io/en/latest/) (sby) is a front-end driver program for Yosys-based formal hardware verification flows.
+
## nmigen
-nmigen may be installed as follows:
+[nmigen](https://m-labs.hk/gateware/nmigen/) may be installed as follows:
* 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
* ctrl-d
-testing can then be carried out with "python3 setup.py test"
+Testing can then be carried out with "python3 setup.py test"
+
+nmigen is a Python toolbox for building complex digital hardware.
## 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
+These are a test suite dependency for the [ieee754fpu](https://www.gaisler.com/index.php/products/ipcores/ieee754fpu) library, and
+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
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
+
+[gdb](https://en.wikipedia.org/wiki/GNU_Debugger) lets you debug running programs.
+[qemu](https://www.qemu.org/) emulates processors, you can run programs under qemu.
+
+## 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`).
+
+## 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/git/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](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit) can have a bootloader uploaded directly into onboard [SRAM](https://en.wikipedia.org/wiki/Static_random-access_memory) and execution begun.
+
+[Chips4Makers](https://chips4makers.io/) make it possible for makers and hobbyists to make their own open source chips.
+
+[JTAG](https://en.wikipedia.org/wiki/JTAG) (Joint Test Action Group) is an industry standard for verifying designs and testing printed circuit boards after manufacture.
+
+The [Wishbone bus](https://en.wikipedia.org/wiki/Wishbone_%28computer_bus%29) is an open source hardware computer bus intended to let the parts of an integrated circuit communicate with each other.
+
## Coriolis2
-See [[coriolis2]] page, for those people doing layout work.
+See [[HDL_workflow/coriolis2]] page, for those people doing layout work.
# Registering for git repository access
After going through the onboarding process and having agreed to take
responsibility for certain tasks, ask on the mailing list for git
-repository access, sending in a public key (id_rsa.pub). If you do
-not have one then generate it with ssh-keygen -t rsa. You will find it
-in ~/.ssh
+repository access, sending in a public key (`id_rsa.pub`). If you do
+not have one then generate it with `ssh-keygen -t rsa`. You will find it
+in `~/.ssh`
NEVER SEND ANYONE THE PRIVATE KEY. By contrast the public key, on
account of being public, is perfectly fine to make... err... public.
-Create a file ~/.ssh/config with the following lines:
+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
# Checking out the HDL repositories
+Before running the following, install the dependencies. This is easiest
+done with this script <https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-hdl-apt-reqs;hb=HEAD>
+
* 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:
+`setup.py` file, then, as root (`sudo bash`), run the following:
* python3 setup.py develop
The reason for the order is because soc depends on ieee754fpu, and
ieee754fpu depends on nmutil
-If "python3 setup.py install" is used it is a pain: edit, then
+If "`python3 setup.py install`" is used it is a pain: edit, then
install. edit, then install. It gets extremely tedious, hence why
"develop" was created.
# Development Rules
-team communication:
+Team communication:
* new members, add yourself to the [[about_us]] page and create yourself a home page using someone else's page as a template.
* communicate on the mailing list or the bugtracker an intent to take
then unless it is a dire personal emergency please say so, on-list. we
won't mind. we'll help sort it out.
-regarding the above it is important that you read, understand, and agree
+Regarding the above it is important that you read, understand, and agree
to the [[charter]] because the charter is about ensuring that we operate
as an effective organisation. It's *not* about "setting rules and meting
out punishment".
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
- that, or add a Makefile to run the command that generates the output, but
+ that, or add a `Makefile` to run the command that generates the output, but
**do not** add the actual output of **any** command to the repository.
ever. this is really important. even if it is a human-readable file
rather than a binary object file.
- it is very common to add pdfs (the result of running latex2pdf) or configure.in (the result of running automake), they are an absolute nuisance and interfere hugely with git diffs, as well as waste hard disk space *and* network bandwidth. don't do it.
+ it is very common to add pdfs (the result of running `latex2pdf`) or configure.in (the result of running `automake`), they are an absolute nuisance and interfere hugely with git diffs, as well as waste hard disk space *and* network bandwidth. don't do it.
### Write commands that do tasks and commit those
* if you find yourself repeating commands regularly, chances are high
that someone else will need to run them, too. clearly this includes
yourself, therefore, to make everyone's lives easier including your own,
- put them into a .sh shell script (and/or a Makefile), commit them to
+ put them into a `.sh` shell script (and/or a `Makefile`), commit them to
the repository and document them at the very minimum in the README,
INSTALL.txt or somewhere in a docs folder as appropriate. if unsure,
ask on the mailing list for advice.
is **not** in use **anywhere** by any other code. then make a *small*
(single purpose) followup commit which actually puts that code into use.
-this last rule is kinda flexible, because if you add the code *and* add
+This last rule is kinda flexible, because if you add the code *and* add
the unit test *and* added it into the main code *and* ran all relevant
unit tests on all cascade-impacted areas by that change, that's perfectly
fine too. however if it is the end of a day, and you need to stop and
### 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.
-it is therefore worth reiterating: make absolutely certain that you *only*
+It is therefore worth reiterating: make absolutely certain that you *only*
commit working code or zero-impact code.
-therefore, if you are absolutely certain that a new addition (new file,
+Therefore, if you are absolutely certain that a new addition (new file,
new class, new function) is not going to have any side-effects, committing
it (a large amount of code) is perfectly fine.
-as a general rule, however, do not use this an an excuse to write code
+As a general rule, however, do not use this an an excuse to write code
first then write unit tests as an afterthought. write *less* code *in
conjunction* with its (more basic) unit tests, instead. then, folliw up with
additions and improvements.
-the reason for separating out commits to single purpose only becomes
+The reason for separating out commits to single purpose only becomes
obvious (and regretted if not followed) when, months later, a mistake
has to be tracked down and reverted. if the commit does not have an
easy-to-find message, it cannot even be located, and once found, if the
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: 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: 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 massive 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.
+Really. don't. use. wildcards.
### Keep file and variables short but clear
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
+Regarding code structure: we decided to go with small modules that are
both easy to analyse, as well as fit onto a single page and be readable
when displayed as a visual graph on a full UHD monitor. this is done
as follows:
show, then space, then pressing the tab key twice will give a full list
of submodules (one of which will be "top")
-you can now fullsize the graphviz window and scroll around. if it looks
+You can now fullsize the graphviz window and scroll around. if it looks
reasonably obvious at 100% zoom, i.e the connections can be clearly
related in your mind back to the actual code (by matching the graph names
against signals and modules in the original nmigen code) and the words 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