7 This section describes the workflow and some best practices for developing
8 the Libre-SOC hardware. We use nmigen, yosys and symbiyosys, and this
9 page is intended not just to help you get set up, it is intended to
10 help advise you of some tricks and practices that will help you become
11 effective team contributors.
13 It is particularly important to bear in mind that we are not just
14 "developing code", here: we are creating a "lasting legacy educational
15 resource" for other people to learn from, and for businesses and students
16 alike to be able to use, learn from and augment for their own purposes.
18 It is also important to appreciate and respect that we are funded under
19 NLNet's Privacy and Enhanced Trust Programme <http://nlnet.nl/PET>. Full
20 transparency, readability, documentation, effective team communication
21 and formal mathematical proofs for all code at all levels is therefore
24 Therefore, we need not only to be "self-sufficient" (absolutely
25 under no circumstances critically reliant on somebody else's servers
26 **or protocols**) we also need to ensure that everything (including
27 all communication such as the mailing list archives) are recorded,
28 replicable, and accessible in perpetuity. Use of slack or a "forum"
29 either actively prevents or makes that much harder.
31 # Collaboration resources
33 The main message here: **use the right tool for the right job**.
35 * mailing list: general communication and discussion.
36 * irc channel #libre-soc on irc.libera.chat: real(ish)-time communication.
37 * bugtracker: task-orientated, goal-orientated *focussed* discussion.
38 * ikiwiki: document store, information store, and (editable) main website
39 * git repositories: code stores (**not binary or auto-generated output store**)
40 * ftp server (<https://ftp.libre-soc.org/>): large (temporary,
41 auto-generated) file store.
43 Note also the lack of a "forum" in the above list. this is very
44 deliberate. forums are a serious distraction when it comes to technical
45 heavily goal-orientated development. recent internet users may enjoy
46 looking up the "AOL metoo postings" meme.
48 Note also the complete lack of "social platforms". if we wanted to tell
49 everybody how much better each of us are than anyone else in the team,
50 how many times we made a commit (look at me, look at me, i'm so clever),
51 and how many times we went to the bathroom, we would have installed a
52 social media based project "management" system.
54 ## Main contact method: mailing list
56 To respect the transparency requirements, conversations need to be
57 public and archived (i.e not skype, not telegram, not discord,
58 and anyone seriously suggesting slack will be thrown to the
59 lions). Therefore we have a mailing list. Everything goes through
60 there. <https://lists.libre-soc.org/mailman/listinfo/libre-soc-dev>
61 therefore please do google "mailing list etiquette" and at the very
62 minimum look up and understand the following:
64 * This is a technical mailing list with complex topics. Top posting
65 is completely inappropriate. Don't do it unless you have mitigating
66 circumstances, and even then please apologise and explain ("hello sorry
67 using phone at airport flight soon, v. quick reply: ....")
68 * Always trim context but do not cut excessively to the point where people
69 cannot follow the discussion. Especially do not cut the attribution
70 ("On monday xxx wrote") of something that you are actually replying
72 * Use inline replies i.e. reply at the point in the relevant part of
73 the conversation, as if you were actually having a conversation.
74 * Follow standard IETF reply formatting, using ">" for cascaded
75 indentation of other people's replies. If using gmail, please: SWITCH
76 OFF RICH TEXT EDITING.
77 * Please for god's sake do not use "my replies are in a different
78 colour". Only old and highly regarded people still using AOL are allowed
79 to get away with that (such as Mitch).
80 * Start a new topic with a relevant subject line. If an existing
81 discussion changes direction, change the subject line to reflect the
82 new topic (or start a new conversation entirely, without using the
84 * DMARC is a pain on the neck. Try to avoid GPG signed messages. sigh.
85 * Don't send massive attachments. Put them online (no, not on facebook or
86 google drive or anywhere else that demands privacy violations) and provide
87 the link. Which should not require any kind of login to access. ask the
88 listadmin if you don't have anywhere suitable: FTP access can be arranged.
90 ### Actionable items from mailing list
92 If discussions result in any actionable items, it is important not to
93 lose track of them. Create a bugreport, find the discussion in the
94 archives <https://lists.libre-soc.org/pipermail/libre-soc-dev/>,
95 and put the link actually in the bugtracker as one of the comments.
97 At some point in any discussion, the sudden realisation may dawn on one
98 or more people that this is an "actionable" discussion. at that point
99 it may become better to use <https://bugs.libre-soc.org/>
100 itself to continue the discussion rather than to keep on dropping copies
101 of links into the bugtracker. The bugtracker sends copies of comments
102 *to* the list however this is 'one-way' (note from lkcl: because this
103 involves running an automated perl script from email, on every email,
104 on the server, that is a high security risk, and i'm not doing it. sorry.)
106 ### Mailing list != editable document store
108 Also, please do not use the mailing list as an "information or document
109 store or poor-man's editor" **including not sending large images**.
110 We have the wiki for that. Edit a page and
111 tell people what you did (summarise rather than drop the entire contents
112 at the list) and include the link to the page.
114 Or, if it is more appropriate, commit a document (or source code)
115 into the relevant git repository then look up the link in the gitweb
116 source tree browser and post that (in the bugtracker or mailing list)
117 See <https://git.libre-soc.org/>
119 ### gmail "spam"ifying the list
121 See <https://blog.kittycooper.com/2014/05/keeping-my-mailing-list-emails-out-of-gmails-spam-folder/>
123 Basically it is possible to select any message from the list, create a
124 "filter" (under "More"), and, on the 2nd dialog box, click the "never
125 send this to Spam" option.
129 bugzilla. old and highly effective. sign up in the usual way. any
130 problems, ask on the list.
132 Please do not ask for the project to be transferred to github or other
133 proprietary nonfree service "because it's soooo convenient", as the
134 lions are getting wind and gout from overfeeding on that one.
140 * [Bug #1126](https://bugs.libre-soc.org/show_bug.cgi?id=1126)
142 If you have discovered a problem in Libre-SOC (software, hardware, etc.),
143 please raise a bug report!
144 Bug reports allow tracking of issues, both to make the developers lives easier,
145 as well as for tracking completed grant-funded work.
147 It is **extremely** important to link the new bug to previous ones. As Luke
148 mentioned on [this bug](https://bugs.libre-soc.org/show_bug.cgi?id=1139#c3),
149 "it is a mandatory project requirement that the graph from any bug
150 contain all other bugs (one "Group")".
152 The primary reason for this is to ensure bugs don't get buried and lost,
153 and will aid those tackling similar problems at a later time.
155 Also, for project management and financing purposes, it helps developers
156 to keep an up-to-date list of their tasks.
158 ####How to raise issues
160 1. Create a bug report.
161 2. Add in any links from the mailing list or IRC logs to the bug report for back tracking
162 (this is mandatory). Also fill in the URL field if there is a relevant wiki page.
163 3. CC in relevant team members
164 4. make absolutely sure to fill in "blocks", "depends on" or "see also" so that the
165 bug is not isolated (otherwise bugs are too hard to find if isolated from everything else)
166 5. Ping on IRC to say a bug has been created
167 6. Unless you know exactly which milestone to use, leave blank initially. This
168 also applies when editing milestone, budget parent/child, toml fields. See
169 section [[HDL_workflow#Task management guidelines]] further down.
170 7. After setting the milestone, it is **absolutely required** to run
171 [budget-sync](https://git.libre-soc.org/?p=utils.git;a=blob;f=README.txt;hb=HEAD),
172 as it will point out any discrepancies. The budget allocations will be used for
173 accounting purposes and **MUST** be correct. *Note you can only get paid for
174 stuff done **after the nlnet grant is approved** (before the MOU is signed)*
176 If a developer ever needs to check which bugs are assigned to them, go to the
177 Libre-SOC bug tracker
178 [advanced search page](https://bugs.libre-soc.org/query.cgi?format=advanced),
179 and in the "Search by People" section, check "Bug Assignee" and "contains"
180 and write your nickname (i.e. andrey etc.).
184 Runs the main libre-soc.org site (including this page). effective,
185 stunningly light on resources, and uses a git repository not a database.
186 That means it can be edited offline.
188 Usual deal: register an account and you can start editing and contributing
191 Hint: to create a new page, find a suitable page that would link to it,
192 first, then put the link in of the page you want to create, as if the
193 page already exists. Save that page, and you will find a question mark
194 next to the new link you created. click that link, and it will fire up a
195 "create new page" editor.
197 Wiki pages are formatted in [[markdown|ikiwiki/markdown]] syntax.
199 Hint again: the wiki is backed by a git repository. Don't go overboard
200 but at the same time do not be afraid that you might "damage" or "lose"
201 pages. Although it would be a minor pain, the pages can always be
202 reverted or edited by the sysadmins to restore things if you get in a tiz.
204 Assistance in creating a much better theme greatly appreciated. e.g.
205 <http://www.math.cmu.edu/~gautam/sj/blog/20140720-ikiwiki-navbar.html>
209 We use git. More on this below. We also use
210 [gitolite3](https://gitolite.com/gitolite/) running on a dedicated server.
211 again, it is extremely effective and low resource utilisation. Reminder:
212 lions are involved if github is mentioned.
214 [gitweb](https://git.wiki.kernel.org/index.php/Gitweb) is provided which
215 does a decent job. <https://git.libre-soc.org/>
217 [Git](https://en.wikipedia.org/wiki/Git) does version control, ie it
218 tracks changes to files so that previous versions can be got back or
221 Checklist page [[HDL_workflow/git_checklist]]
225 <https://ftp.libre-soc.org/> is available for storing large files
226 that do not belong in a git repository, if we have (or ever need)
227 any. Images (etc.) if small and appropriate should go into the
228 wiki, however .tgz archives (etc.) and, at some point, binaries,
229 should be on the ftp server.
231 Ask on the list if you have a file that belongs on the ftp server.
235 As an aside: all this is "old school" and run on a single core 512MB
236 VM with only a 20GB HDD allocation. it costs only 8 GBP per month from
237 mythic-beasts and means that the project is in no way dependent on anyone
238 else - not microsoft, not google, not facebook, not amazon.
240 We tried [gitlab](https://about.gitlab.com/). it didn't go well. please
241 don't ask to replace the above extremely resource-efficient services
246 RAM is the biggest requirement. Minimum 16GB, the more the better (32
247 or 64GB starts to reach "acceptable" levels. Disk space is not hugely
248 critical: 256GB SSD should be more than adequate. Simulations and
249 FPGA compilations however are where raw processing power is a must.
250 High end Graphics Cards are nonessential.
252 What is particularly useful is to have hi-res screens (curved is
253 *strongly* recommended if the LCD is over 24in wide, to avoid eyeballs
254 going "prism" through long term use), and to have several of them: the
255 more the better. Either a DisplayLink UD160A (or more modern variant)
256 or simply using a second machine (lower spec hardware because it will
257 run editors) is really effective.
259 Also it is really recommended to have a UHD monitor (4k - 3840x2160),
260 or at least 2560x1200. If given a choice, 4:3 aspect ratio is better
261 than 16:9 particularly when using several of them. However, caveat
262 (details below): please when editing do not assume that everyone will
263 have access to such high resolution screens.
267 First install and become familiar with
268 [Debian](https://www.debian.org/) ([Ubuntu](https://ubuntu.com/)
270 must) for standardisation cross-team and so that toolchain installation
271 is greatly simplified. yosys in particular warns that trying to use
272 Windows, BSD or MacOS will get you into a world of pain.
274 Only a basic GUI desktop is necessary: fvwm2, xfce4, lxde are perfectly
275 sufficient (alongside wicd-gtk for network management). Other more
276 complex desktops can be used however may consume greater resources.
278 # editors and editing
280 Whilst this is often a personal choice, the fact that many editors are
281 GUI based and run full-screen with the entire right hand side *and* middle
282 *and* the majority of the left side of the hi-res screen entirely unused
283 and bereft of text leaves experienced developers both amused and puzzled.
285 At the point where such full-screen users commit code with line lengths
286 well over 160 characters, that amusement quickly evaporates.
288 Where the problems occur with full-screen editor usage is when a project
289 is split into dozens if not hundreds of small files (as this one is). At
290 that point it becomes pretty much essential to have as many as six to
291 eight files open *and on-screen* at once, without overlaps i.e. not in
292 hidden tabs, next to at least two if not three additional free and clear
293 terminals into which commands are regularly and routinely typed (make,
294 git commit, nosetests3 etc). Illustrated with the following 3840x2160
295 screenshot (click to view full image), where *every one* of those 80x70
296 xterm windows is *relevant to the task at hand*.
298 [[!img 2020-01-24_11-56.png size=640x ]]
300 (hint/tip: fvwm2 set up with "mouse-over to raise focus, rather than
301 additionally requiring a mouse click, can save a huge amount of cumulative
302 development time here, switching between editor terminal(s) and the
305 Once this becomes necessary, it it turn implies that having greater
306 than 80 chars per line - and running editors full-screen - is a severe
307 hinderance to an essential *and highly effective* workflow technique.
309 Additionally, care should be taken to respect that not everyone will have
310 200+ column editor windows and the eyesight of a hawk. They may only have
311 a 1280 x 800 laptop which barely fits two 80x53 xterms side by side.
312 Consequently, having excessively long functions is also a hindrance to
313 others, as such developers with limited screen resources would need to
314 continuously page-up and page-down to read the code even of a single
317 This helps explain in part, below, why compliance with
318 [pep8](https://pep8.org/) is enforced, including its 80 character limit.
319 In short: not everyone has the same "modern" GUI workflow or has access
320 to the same computing resources as you, so please do respect that.
322 More on this concept is
323 [here](https://www.linuxjournal.com/content/line-length-limits).
324 Note *very pointedly* that Linus Torvalds *specifically* states that
325 he does not want Linux kernel development to become the exclusive
326 domain of the "wealthy". That means **no** to assumptions about
327 access to ultra-high resolution screens.
329 # Software prerequisites<a name="software-prerequisites"></a>
331 **Please make sure if you install manually that you install dependencies
332 in strict order. Failing to adhere to this will result in pip3 downloading
333 unauthorised older software versions. See
334 <http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-September/003666.html>**
336 Whilst many resources online advocate "`sudo`" in front of all root-level
337 commands below, this quickly becomes tiresome. run "`sudo bash`", get a
338 root prompt, and save yourself some typing.
341 * apt-get install vim exuberant-ctags
342 * apt-get install build-essential
343 * apt-get install git python3.7 python3.7-dev python3-nose
344 * apt-get install graphviz xdot gtkwave
345 * apt-get install python3-venv
346 * apt-get install python-virtualenv # this is an alternative to python3-venv
347 * apt-get install tcl-dev libreadline-dev bison flex libffi-dev iverilog
348 * return to user prompt (ctrl-d)
350 (The above assumes that you are running Debian.)
352 This will get you python3 and other tools that are
353 needed. [graphviz](https://graphviz.org/) is essential
354 for showing the interconnections between cells, and
355 [gtkwave](http://gtkwave.sourceforge.net/) is essential for debugging.
357 If you would like to save yourself a lot more typing, check out the
358 [dev-env-setup](https://git.libre-soc.org/?p=dev-env-setup.git;a=summary)
359 repository, examine the scripts there and use them to automate much of
362 If you would like just to install only the apt dependencies use
363 [install-hdl-apt-reqs](https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-hdl-apt-reqs;hb=HEAD) instead.
365 This page gives more details and a step by step process : [[HDL_workflow/devscripts]]
369 Look up good tutorials on how to use git effectively. There are so many
370 it is hard to recommend one. This is however essential. If you are not
371 comfortable with git, and you let things stay that way, it will seriously
372 impede development progress.
374 If working all day you should expect to be making at least two commits per
375 hour, so should become familiar with it very quickly. If you are *not*
376 doing around 2 commits per hour, something is wrong and you should read
377 the workflow instructions below more carefully, and also ask for advice
380 Worth noting: *this project does not use branches*. All code is committed
381 to master and we *require* that it be either zero-impact additions or that
382 relevant unit tests pass 100%. This ensures that people's work does not
383 get "lost" or isolated and out of touch due to major branch diversion,
384 and that people communicate and coordinate with each other.
386 This is not a hard rule: under special cirmstances branches can be useful.
387 They should not however be considered "routine".
389 For advice on commit messages see
390 [here](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html),
391 and [here](https://github.com/torvalds/subsurface-for-dirk/blob/master/README.md#contributing)).
395 Follow the source code (git clone) instructions here, do **not** use
396 the "stable" version (do not download the tarball):
397 <https://github.com/YosysHQ/yosys>
399 Or, alternatively, use the
400 [hdl-tools-yosys](https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=hdl-tools-yosys;hb=HEAD)
401 script (which also installs symbiyosys and its dependencies)
403 Do not try to use a fixed revision of yosys (currently 0.9), nmigen is
404 evolving and frequently interacts with yosys.
406 [Yosys](https://github.com/YosysHQ/yosys is a framework for Verilog RTL.
407 [Verilog](https://en.wikipedia.org/wiki/Verilog) is a hardware description
409 RTL [Register Transfer
410 Level](https://en.wikipedia.org/wiki/Register-transfer_level)
411 models how data moves between
412 [registers](https://en.wikipedia.org/wiki/Hardware_register).
416 To install follow the [instructions
417 here](https://symbiyosys.readthedocs.io/en/latest/install.html)
418 Once done look at [A simple BMC
419 example](https://symbiyosys.readthedocs.io/en/latest/quickstart.html)
421 You do not have to install all of those (avy, boolector can be left
422 out if desired) however the more that are installed the more effective
423 the formal proof scripts will be (less resource utilisation in certain
426 [SymbiYosys](https://symbiyosys.readthedocs.io/en/latest/) (sby) is a
427 front-end driver program for Yosys-based formal hardware verification
432 *nmigen is a registered trademark of M-Labs <https://uspto.report/TM/88980893>*
434 **PLEASE NOTE: it is critical to install nmigen as the first dependency
435 prior to installing any further python-based Libre-SOC HDL repositories.
436 If "pip3 list" shows that nmigen has been auto-installed please remove it**
438 [nmigen](https://m-labs.hk/gateware/nmigen/) may be installed as follows:
442 * git clone https://gitlab.com/nmigen/nmigen.git
445 * python3 setup.py develop
448 Testing can then be carried out with "python3 setup.py test"
450 nmigen is a Python toolbox for building complex digital hardware.
452 ## Softfloat and sfpy
454 These are a test suite dependency for the
455 [ieee754fpu](https://www.gaisler.com/index.php/products/ipcores/ieee754fpu)
456 library, and will be changed in the future to use Jacob's
457 [simple-soft-float](https://crates.io/crates/simple-soft-float) library.
458 In the meantime, sfpy can be built as follows:
460 git clone --recursive https://github.com/billzorn/sfpy.git
462 git apply /path/to/ieee754fpu/sfpy.patch
464 git apply ../softposit_sfpy_build.patch
465 git apply /path/to/ieee754fpu/SoftPosit.patch
466 cd ../berkely-softfloat-3
467 # Note: Do not apply the patch included in sfpy for berkely-softfloat,
468 # it contains the same changes as this one
469 git apply /path/to/ieee754fpu/berkeley-softfloat.patch
472 # prepare a virtual environment for building
475 # or, if you prefer the old way:
476 # virtualenv -p python3 .env
478 # install dependencies
479 source .env/bin/activate
480 pip3 install --upgrade -r requirements.txt
485 make inplace -j$(nproc)
489 deactivate # deactivates venv, optional
490 pip3 install dist/sfpy*.whl
492 You can test your installation by doing the following:
495 >>> from sfpy import Posit8
498 It should print out `Posit8(1.3125)`
500 ## qemu, cross-compilers, gdb
502 As we are doing POWER ISA, POWER ISA compilers, toolchains and
503 emulators are required.
504 Again, if you want to save yourself some typing, use the dev scripts.
505 [install-hdl-apt-reqs](https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-hdl-apt-reqs;hb=HEAD)
506 script will install the qemu;
507 [ppc64-gdb-gcc](https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=ppc64-gdb-gcc;hb=HEAD)
508 script will install the toolchain and the corresponding debugger.
509 The steps are provided below only for reference; when in doubt,
510 consider checking and running the scripts.
512 Install powerpc64 gcc:
514 apt-get install gcc-8-powerpc64-linux-gnu
518 apt-get install qemu-system-ppc
520 Install gdb from source. Obtain the required tarball matching
521 the version of gcc (8.3) from here <https://ftp.gnu.org/gnu/gdb/>,
524 cd gdb-8.3 (or other location)
527 ../configure --srcdir=.. --host=x86_64-linux --target=powerpc64-linux-gnu
531 [gdb](https://en.wikipedia.org/wiki/GNU_Debugger) lets you debug running
532 programs. [qemu](https://www.qemu.org/) emulates processors, you can
533 run programs under qemu.
535 ## power-instruction-analyzer (pia)
537 We have a custom tool built in Rust by programmerjake to help analyze
538 the OpenPower instructions' execution on *actual* hardware.
542 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
544 Make sure we have the correct and up-to-date rust compiler (rustc & cargo):
546 rustup default stable
549 Install the Python extension from git source by doing the following:
551 git clone https://salsa.debian.org/Kazan-team/power-instruction-analyzer.git pia
553 ./libre-soc-install.sh
557 As this is an actual ASIC, we do not rely on an FPGA's JTAG TAP
558 interface, instead require a full complete independent implementation
559 of JTAG. Staf Verhaegen has one, with a full test suite, and it is
560 superb and well-written. The Libre-SOC version includes DMI (Debug
563 git clone https://git.libre-soc.org/git/c4m-jtag.git/
565 python3 setup.py develop
567 Included is an IDCODE tap point, Wishbone Master (for direct memory read
568 and write, fully independent of the core), IOPad redirection and testing,
569 and general purpose shift register capability for any custom use.
571 We added a DMI to JTAG bridge in LibreSOC which is
572 directly connected to the core, to access registers and
573 to be able to start and stop the core and change the PC.
574 In combination with the JTAG Wishbone interface the test
575 [ASIC](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit)
576 can have a bootloader uploaded directly into onboard
577 [SRAM](https://en.wikipedia.org/wiki/Static_random-access_memory) and
580 [Chips4Makers](https://chips4makers.io/) make it possible for makers
581 and hobbyists to make their own open source chips.
583 [JTAG](https://en.wikipedia.org/wiki/JTAG) (Joint Test Action Group) is
584 an industry standard for verifying designs and testing printed circuit
585 boards after manufacture.
588 bus](https://en.wikipedia.org/wiki/Wishbone_%28computer_bus%29) is an open
589 source hardware computer bus intended to let the parts of an integrated
590 circuit communicate with each other.
593 See [[HDL_workflow/coriolis2]] page, for those people doing layout work.
597 A portable FPGA place and route tool.
599 See [[HDL_workflow/nextpnr]] page for installation instructions of nextpnr with ECP5 support for Lattice FPGA ECP5 series. Also see
600 [[HDL_workflow/ECP5_FPGA]] for connecting up to JTAG with a ULX3S
601 and the Lattice VERSA_ECP5.
605 An open source place and route framework for Xilinx FPGAs using Project Xray. We will use it for Xilinx 7-series FPGAs like Artix-7.
607 One of the ways to get Arty A7 100t Digilent FPGA board working.
609 See [[HDL_workflow/nextpnr-xilinx]] for installation instructions and dependencies.
614 The fastest Verilog and SystemVerilog simulator. It compiles Verilog to C++ or SystemC.
616 Advise use only v4.106 at the moment.
618 See [[HDL_workflow/verilator]] page for installation instructions.
622 GHDL is a shorthand for G Hardware Design Language. It is a VHDL analyzer, compiler, simulator and (experimental) synthesizer that can process (nearly) any VHDL design.
624 VHDL is an acronym for Very High Speed Integrated Circuit (VHSIC) Hardware Description Language (HDL), which is a programming language used to describe a logic circuit by function, data flow behavior, or structure.
626 Unlike some other simulators, GHDL is a compiler: it directly translates a VHDL file to machine code, without using an intermediary language such as C or C++. Therefore, the compiled code should be faster and the analysis time should be shorter than with a compiler using an intermediary language.
628 GHDL aims at implementing VHDL as defined by IEEE 1076. It supports the 1987, 1993 and 2002 revisions and, partially, 2008. PSL is also partially supported.
630 See [[HDL_workflow/ghdl]] page for installation instructions.
634 Icarus Verilog is a Verilog simulation and synthesis tool. It operates as a compiler, compiling source code written in Verilog (IEEE-1364) into some target format.
636 See [[HDL_workflow/iverilog]] page for installation instructions.
640 cocotb is a COroutine based COsimulation TestBench environment for verifying VHDL and SystemVerilog RTL using Python.
642 See [[HDL_workflow/cocotb]] page for installation instructions.
646 A fully open source toolchain for the development of FPGAs. Currently it targets Xilinx 7-series, Lattice iCE40 and ECP5, Quicklogic EOS S3.
648 One way to get the Arty A7 100t Digilent FPGA board working.
650 See [[HDL_workflow/symbiflow]] for installation instructions
653 ## FPGA/Board Boot-Loaders-Programmers
655 Open source FPGA/Board boot-loaders and programmers for ULX3S, ECP5 and
658 Currently these programs dfu-util, openFPGALoader, ujprog, fujprog,
659 xc3sprog and ecpprog are going to be used.
661 See [[HDL_workflow/fpga-boot-loaders-progs]] for installation instructions and dependencies.
663 ## ls2 peripheral fabric
667 # Registering for git repository access<a name="gitolite3_access"></a>
669 After going through the onboarding process and having agreed to take
670 responsibility for certain tasks, ask on the mailing list for git
671 repository access, sending in a public key (`id_rsa.pub`). If you do
672 not have one then generate it with `ssh-keygen -t rsa`. You will find it
675 NEVER SEND ANYONE THE PRIVATE KEY. By contrast the public key, on
676 account of being public, is perfectly fine to make... err... public.
678 Create a file `~/.ssh/config` with the following lines:
680 Host git.libre-soc.org
683 Test that you have access with this command:
685 ssh -v -p922 gitolite3@git.libre-soc.org
687 Please note: **DO NOT TYPE A PASSWORD** - the server gets hit by a lot of
688 port-scanning, and detection of password failures are used to instantly
691 Wait for the Project Admin to confirm that the ssh key has been added
692 to the required repositories. Once confirmed, you can clone any of the
693 repos at https://git.libre-soc.org/:
695 git clone gitolite3@git.libre-soc.org:REPONAME.git
697 Alternatively, the .ssh/config can be skipped and this used:
699 git clone ssh://gitolite3@git.libre-soc.org:922/REPONAME.git
701 Note: **DO NOT ATTEMPT TO LOG IN TO THE SERVER WITH A PERSONAL ACCOUNT**.
702 fail2ban is running and, due to repeated persistent port-scanning spammers
703 is set up to instantly ban any unauthorised ssh access for up to two weeks.
704 This keeps log file sizes down on the server (which is resource-constrained).
705 If you are wondering why this is done, it's a *lot* of port-scans.
707 Therefore, *only* ssh in to server with the gitolite3 account, *only*
708 on port 922, and *only* once the systems administrator has given you
709 the all-clear that the ssh key has been added.
713 Although there are methods online which describe how (and why) these
714 settings are normally done, honestly it is simpler and easier to open
715 ~/.gitconfig and add them by hand.
717 core.autocrlf is a good idea to ensure that anyone adding DOS-formatted
718 files they don't become a pain. pull.rebase is something that is greatly
719 preferred for this project because it avoids the mess of "multiple
720 extra merge git tree entries", and branch.autosetuprebase=always will,
721 if you want it, always ensure that a new git checkout is set up with rebase.
730 autosetuprebase = always
732 # Checking out the HDL repositories
734 Before running the following, install the
735 dependencies. This is easiest done with this script
736 <https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-hdl-apt-reqs;hb=HEAD>
738 **It is critically important to install these in STRICT order, otherwise
739 pip3 interferes and performs unauthorised downloads without informing
740 you of what it is doing**.
744 * git clone https://gitlab.com/nmigen/nmigen
745 * git clone https://gitlab.com/nmigen/nmigen-boards
746 * git clone https://gitlab.com/nmigen/nmigen-soc
747 * git clone https://gitlab.com/nmigen/nmigen-stdio
748 * git clone gitolite3@git.libre-soc.org:c4m-jtag.git
749 * git clone gitolite3@git.libre-soc.org:nmutil.git
750 * git clone gitolite3@git.libre-soc.org:openpower-isa.git
751 * git clone gitolite3@git.libre-soc.org:ieee754fpu.git
752 * git clone gitolite3@git.libre-soc.org:soc.git
754 In each of these directories, **in the order listed**, track down the
755 `setup.py` file, then, as root (`sudo bash`), run the following:
757 * python3 setup.py develop
759 The reason for using "develop" mode is that the code may be edited
760 in-place yet still imported "globally". There are variants on this theme
761 for multi-user machine use however it is often just easier to get your
762 own machine these days.
764 The reason for the order is because soc depends on ieee754fpu, and
765 ieee754fpu depends on nmutil. If you do not follow the listed order
766 pip3 will go off and download an arbitrary version without your
769 If "`python3 setup.py install`" is used it is a pain: edit, then
770 install. edit, then install. It gets extremely tedious, hence why
771 "develop" was created.
773 If you prefer you can use this script instead: of course you checked it
774 in advance and accept full responsibility.
775 <https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=hdl-dev-repos;hb=HEAD>
781 * new members, add yourself to the [[about_us]] page and create yourself
782 a home page using someone else's page as a template.
783 * communicate on the mailing list or the bugtracker an intent to take
784 responsibility for a particular task.
785 * assign yourself as the bug's owner
786 * *keep in touch* about what you are doing, and why you are doing it.
787 * edit your home page regularly, particularly to track tasks so that
788 they can be paid by NLNet.
789 * if you cannot do something that you have taken responsibility for,
790 then unless it is a dire personal emergency please say so, on-list. we
791 won't mind. we'll help sort it out.
793 Regarding the above it is important that you read, understand, and agree
794 to the [[charter]] because the charter is about ensuring that we operate
795 as an effective organisation. It's *not* about "setting rules and meting
800 for actual code development
804 * plan in advance to write not just code but a full test suite for
805 that code. **this is not optional**. large python projects that do not
806 have unit tests **FAIL** (see separate section below).
807 * Prioritise writing formal proofs and a single clear unit test that is more
808 like a "worked example".
809 We receive NLNet funds for writing formal proofs, plus they
810 cover corner cases and take far less time to write
812 ### Commit tested or zero-dependent code
814 * only commit code that has been tested (or is presently unused). other
815 people will be depending on you, so do take care not to screw up.
816 not least because, as it says in the [[charter]] it will be your
817 responsibility to fix. that said, do not feel intimidated: ask for help
818 and advice, and you'll get it straight away.
822 * commit often. several times a day, and "git push" it. this is
823 collaboration. if something is left even overnight uncommitted and not
824 pushed so that other people can see it, it is a red flag.
826 yourself thinking "i'll commit it when it's finished" or "i don't want to
827 commit something that people might criticise" *this is not collaboration*,
828 it is making yourself a bottleneck. pair-programming is supposed to help
829 avoid this kind of thing however pair-programming is difficult to organise
830 for remote collaborative libre projects (suggestions welcomed here)
832 ### Enable editor auto-detection of file changes by external programs
834 This is important. "`git pull`" will merge in changes. If you then
835 arbitrarily save a file without re-loading it, you risk destroying
838 You can avoid damaging the repositories by following some simple procedures:
840 run appropriate unit tests
842 run appropriate unit tests again (checks other people's work)
843 git diff # and actually read and review the output
844 git status # check for any missing files
845 git commit # with appropriate arguments and message
846 git push # always always always do this
848 ### Absolutely no auto-generated output
850 * **do not commit autogenerated output**. write a shell script and commit
851 that, or add a `Makefile` to run the command that generates the output, but
852 **do not** add the actual output of **any** command to the repository.
853 ever. this is really important. even if it is a human-readable file
854 rather than a binary object file.
855 * it is very common to add PDFs (the result of running `latex2pdf`) or
856 configure.in (the result of running `automake`), they are an absolute
857 nuisance and interfere hugely with git diffs, as well as waste hard
858 disk space *and* network bandwidth. don't do it.
859 * do not add multi-megabyte or multi-gigabyte "test data".
860 use shell scripts and commit that, which automatically downloads the
861 "test data" from a well-known known-good reliable location instead.
863 ### Write commands that do tasks and commit those
865 * if the command needed to create any given autogenerated output is not
866 currently in the list of known project dependencies, first consult on
867 the list if it is okay to make that command become a hard dependency of
868 the project (hint: java, node.js php and .NET commands may cause delays
869 in response time due to other list participants laughing hysterically),
870 and after a decision is made, document the dependency and how its source
871 code is obtained and built (hence why it has to be discussed carefully)
872 * if you find yourself repeating commands regularly, chances are high
873 that someone else will need to run them, too. clearly this includes
874 yourself, therefore, to make everyone's lives easier including your own,
875 put them into a `.sh` shell script (and/or a `Makefile`), commit them to
876 the repository and document them at the very minimum in the README,
877 INSTALL.txt or somewhere in a docs folder as appropriate. if unsure,
878 ask on the mailing list for advice.
880 ### Keep commits single-purpose
882 * edit files making minimal *single purpose* modifications (even if
883 it involves multiple files. Good extreme example: globally changing
884 a function name across an entire codebase is one purpose, one commit,
885 yet hundreds of files. miss out one of those files, requiring multiple
886 commits, and it actually becomes a nuisance).
888 ### Run unit tests prior to commits
890 * prior to committing make sure that relevant unit tests pass, or that
891 the change is a zero-impact addition (no unit tests fail at the minimum)
893 ### Do not break existing code
895 * keep working code working **at all times**. find ways to ensure that
896 this is the case. examples include writing alternative classes that
897 replace existing functionality and adding runtime options to select
898 between old and new code.
900 ### Small commits with relevant commit message
902 * commit no more than around 5 to 10 lines at a time, with a CLEAR message
903 (no "added this" or "changed that").
904 * if as you write you find that the commit message involves a *list* of
905 changes or the word "and", then STOP. do not proceed: it is a "red flag"
906 that the commit has not been properly broken down into separate-purpose
907 commits. ask for advice on-list on how to proceed.
909 ### Exceptions to small commit: atomic single purpose commit
911 * if it is essential to commit large amounts of code, ensure that it
912 is **not** in use **anywhere** by any other code. then make a *small*
913 (single purpose) followup commit which actually puts that code into use.
915 This last rule is kinda flexible, because if you add the code *and* add
916 the unit test *and* added it into the main code *and* ran all relevant
917 unit tests on all cascade-impacted areas by that change, that's perfectly
918 fine too. however if it is the end of a day, and you need to stop and
919 do not have time to run the necessary unit tests, do *not* commit the
920 change which integrates untested code: just commit the new code (only)
921 and follow up the next day *after* running the full relevant unit tests.
923 ### Why such strict rules?
925 The reason for all the above is because python is a dynamically typed
926 language. make one tiny change at the base level of the class hierarchy
927 and the effect may be disastrous.
929 It is therefore worth reiterating: make absolutely certain that you *only*
930 commit working code or zero-impact code.
932 Therefore, if you are absolutely certain that a new addition (new file,
933 new class, new function) is not going to have any side-effects, committing
934 it (a large amount of code) is perfectly fine.
936 As a general rule, however, do not use this an an excuse to write code
937 first then write unit tests as an afterthought. write *less* code *in
938 conjunction* with its (more basic) unit tests, instead. then, folliw up with
939 additions and improvements.
941 The reason for separating out commits to single purpose only becomes
942 obvious (and regretted if not followed) when, months later, a mistake
943 has to be tracked down and reverted. if the commit does not have an
944 easy-to-find message, it cannot even be located, and once found, if the
945 commit confuses several unrelated changes, not only the diff is larger
946 than it should be, the reversion process becomes extremely painful.
948 ### PHP-style python format-strings
950 As the name suggests, "PHP-style" is not given as a compliment.
951 Format-strings - `f"{variable} {pythoncodefragment}" are a nightmare
952 to read. The lesson from PHP, Zope and Plone: when code is embedded,
953 the purpose of the formatting - the separation of the format from
954 the data to be placed in it - is merged, and consequently become
957 By contrast, let us imagine a situation where 12 variables need to
958 be inserted into a string, four of which are the same variablename:
960 x = "%s %s %s %s %s %s %s %s %s %s %s %s" % (var1, var2, var3,
965 This is just as unreadable, but for different reasons. Here it *is*
966 useful to do this as:
968 x = f"{var1} {var2} {var3}" \
970 f"{var3} {var4} {var1}"
972 As a general rule, though, format-specifiers should be strongly
973 avoided, given that they mix even variable-names directly inside
976 This additionally gives text editors (and online web syntax
977 highlighters) the opportunity to colour syntax-highlight the
978 ASCII string (the format) from the variables to be inserted *into*
979 that format. gitweb for example (used by this project) cannot
980 highlight string-formatted code.
982 It turns out that colour is processed by the **opposite** hemisphere
983 of the brain from written language. Thus, colour-syntax-highlighting
984 is not just a "nice-to-have", it's **vital** for easier and faster
985 identification of context and an aid to rapid understanding.
987 Anything that interferes with that - such as python format-strings -
988 has to take a back seat, regardless of its perceived benefits.
990 **If you absolutely must** use python-format-strings, **only** do
991 so by restricting to variables. Create temporary variables if you
999 * all code needs to conform to pep8. use either pep8checker or better
1000 run autopep8. however whenever committing whitespace changes, *make a
1001 separate commit* with a commit message "whitespace" or "autopep8 cleanup".
1002 * pep8 REQUIRES no more than 80 chars per line. this is non-negotiable. if
1003 you think you need greater than 80 chars, it *fundamentally* indicates
1004 poor code design. split the code down further into smaller classes
1007 ### Docstring checker
1009 * TBD there is a docstring checker. at the minimum make sure to have
1010 an SPD license header, module header docstring, class docstring and
1011 function docstrings on at least non-obvious functions.
1013 ### Clear code commenting and docstrings
1015 * make liberal but not excessive use of comments. describe a group of
1016 lines of code, with terse but useful comments describing the purpose,
1017 documenting any side-effects, and anything that could trip you or other
1018 developers up. unusual coding techniques should *definitely* contain
1021 ### Only one class per module (ish)
1023 * unless they are very closely related, only have one module (one class)
1024 per file. a file only 25 lines long including imports and docstrings
1025 is perfectly fine however don't force yourself. again, if unsure,
1028 ### File and Directory hierarchy
1030 * *keep files short and simple*. see below as to why
1031 * create a decent directory hierarchy but do not go mad. ask for advice
1036 * please do not use "from module import \*". it is extremely bad practice,
1037 causes unnecessary resource utilisation, makes code readability and
1038 tracking extremely difficult, and results in unintended side-effects.
1040 Example: often you want to find the code from which a class was imported.
1041 nirmally you go to the top of the file, check the imports, and you know
1042 exactly which file has the class because of the import path. by using
1043 wildcards, you have absolutely *no clue* which wildcard imported which
1046 Example: sometimes you may accidentally have duplicate code maintained
1047 in two or more places. editing one of them you find, puzzlingly, that
1048 the code behaves in some files with the old behaviour, but in others it
1049 works. after a massive amount of investigation, you find that the working
1050 files happen to have a wildcard import of the newer accidental duplicate
1051 class **after** the wildcard import of the older class with exactly the
1052 same name. if you had used explicit imports, you would have spotted
1053 the double import of the class from two separate locations, immediately.
1055 Really. don't. use. wildcards.
1057 More about this here:
1059 * <https://www.asmeurer.com/removestar/>
1060 * <https://rules.sonarsource.com/python/RSPEC-2208>
1062 ### Keep file and variables short but clear
1064 * try to keep both filenames and variable names short but not ridiculously
1065 obtuse. an interesting compromise on imports is "from ridiculousfilename
1066 import longsillyname as lsn", and to assign variables as well: "comb =
1067 m.d.comb" followed by multiple "comb += nmigen_stmt" lines is a good trick
1068 that can reduce code indentation by 6 characters without reducing clarity.
1070 Additionally, use comments just above an obtuse variable in order to
1071 help explain what it is for. In combination with keeping the the module
1072 itself short, other readers will not need to scroll back several pages
1073 in order to understand the code.
1075 Yes it is tempting to actually use the variables as
1076 self-explanatory-comments and generally this can be extremely good
1077 practice. the problem comes when the variable is so long that a function
1078 with several parameters csn no longer fit on a single line, and takes
1079 up five to ten lines rather than one or two. at that point, the length
1080 of the code is adversely affected and thus so is readability by forcing
1081 readers to scroll through reams of pages.
1083 It is a tricky balance: basically use your common sense, or just ask
1084 someone else, "can you understand this code?"
1086 ### Reasons for code structure
1088 Regarding code structure: we decided to go with small modules that are
1089 both easy to analyse, as well as fit onto a single page and be readable
1090 when displayed as a visual graph on a full UHD monitor. this is done
1093 * using the capability of nmigen (TODO crossref to example) output the
1094 module to a yosys ilang (.il) file
1095 * in a separate terminal window, run yosys
1096 * at the yosys prompt type "read_ilang modulename.il"
1097 * type "show top" and a graphviz window should appear. note that typing
1098 show, then space, then pressing the tab key twice will give a full list
1099 of submodules (one of which will be "top")
1101 You can now fullsize the graphviz window and scroll around. if it looks
1102 reasonably obvious at 100% zoom, i.e the connections can be clearly
1103 related in your mind back to the actual code (by matching the graph names
1104 against signals and modules in the original nmigen code) and the words are
1105 not tiny when zoomed out, and connections are not total incomprehensible
1106 spaghetti, then congratulations, you have well-designed code. If not,
1107 then this indicates a need to split the code further into submodules
1108 and do a bit more work.
1110 The reasons for doing a proper modularisation job are several-fold:
1112 * firstly, we will not be doing a full automated layout-and-hope
1113 using alliance/coriolis2, we will be doing leaf-node thru tree node
1114 half-automated half-manual layout, finally getting to the floorplan,
1115 then revising and iteratively adjusting.
1116 * secondly, examining modules at the gate level (or close to it) is just
1117 good practice. poor design creeps in by *not* knowing what the tools
1118 are actually doing (word to experienced developers: yes, we know that
1119 the yosys graph != final netlist).
1120 * thirdly, unit testing, particularly formal proofs, is far easier on
1121 small sections of code, and complete in a reasonable time.
1123 ## Special warning / alert to vim users!
1125 Some time around the beginning of 2019 some bright spark decided that
1126 an "auto-recommend-completion-of-stuff" option would be a nice, shiny
1127 idea to enable by default from that point onwards.
1129 This incredibly annoying "feature" results in tabs (or spaces) being
1130 inserted "on your behalf" when you press return on one line, for your
1131 "convenience" of not needing to type lots of spaces/tabs just to get
1132 to the same indentation level.
1134 Of course, this "feature", if you press return on one line in edit
1135 mode and then press "escape", leaves a bundle-of-joy extraneous
1136 whitespace **exactly** where you don't want it, and didn't ask for it,
1137 pooped all over your file.
1139 Therefore, *please*: **before** running "git commit", get into the
1140 habit of always running "git diff", and at the very minimum
1141 speed-skim the entire diff, looking for tell-tale "red squares"
1142 (these show up under bash diff colour-syntax-highlighting) that
1143 inform you that, without your knowledge or consent, vim has
1144 "helpfully" inserted extraneous whitespace.
1146 Remove them **before** git committing because they are not part
1147 of the actual desired code-modifications, and committing them
1148 is a major and constant distraction for reviewers about actual
1149 important things like "the code that actually *usefully* was
1150 modified for that commit"
1152 This has the useful side-effect of ensuring that, right before
1153 the commit, you've got the actual diff right in front of you
1154 in the xterm window, on which you can base the "commit message".
1158 For further reading, see the wikipedia page on
1159 [Test-driven Development](https://en.wikipedia.org/wiki/Test-driven_development)
1161 This deserves its own special section. It is extremely important to
1162 appreciate that without unit tests, python projects are simply unviable.
1163 Python itself has over 25,000 individual tests.
1165 This can be quite overwhelming to a beginner developer, especially one
1166 used to writing scripts of only 100 lines in length.
1168 Thanks to Samuel Falvo we learned that writing unit tests as a formal
1169 proof is not only shorter, it's also far more readable and also, if
1170 written properly, provides 100% coverage of corner-cases that would
1171 otherwise be overlooked or require tens to hundreds of thousands of
1174 No this is not a joke or even remotely hypothetical, this is an actual
1177 The ieee754fpu requires several hundreds of thousands of tests to be
1178 run (currently needing several days to run them all), and even then we
1179 cannot be absolutely certain that all possible combinations of input have
1180 been tested. With 2^128 permutations to try with 2 64 bit FP numbers
1181 it is simply impossible to even try.
1183 This is where formal proofs come into play.
1185 Samuel illustrated to us that "ordinary" unit tests can then be written
1186 to *augment* the formal ones, serving the purpose of illustrating how
1187 to use the module, more than anything.
1189 However it is appreciated that writing formal proofs is a bit of a
1190 black art. This is where team collaboration particularly kicks in,
1191 so if you need help, ask on the mailing list.
1193 ## Don't comment out unit tests: add them first (as failures) and fix code later
1195 Unit tests serve an additional critical purpose of keeping track of code
1196 that needs to be written. In many cases, you write the unit test *first*,
1197 despite knowing full well that the code doesn't even exist or is completely
1198 broken. The unit test then serves as a constant and important reminder
1199 to actually fix (or write) the code.
1201 Therefore, *do not* comment out unit tests just because they "don't work".
1202 If you absolutely must stop a unit test from running, **do not delete it**.
1203 Simply mark it with an appropriate
1204 ["skip" decorator](https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures),
1205 preferably with a link to a URL in the [bugtracker](https://bugs.libre-soc.org/)
1206 with further details as to why the unit test should not be run.
1208 # Task management guidelines
1210 1. Create the task in appropriate "Product" section with appropriate
1211 "Component" section. Most code tasks generally use "Libre-SOC's
1213 2. Fill in "Depends on" and "Blocks" section whenever appropriate.
1214 Also add as many related ("See Also") links to other bugreports
1215 as possible. bugreports are never isolated.
1216 3. Choose the correct task for a budget allocation. Usually the parent
1218 4. Choose the correct NLnet milestone. The best practice is to check
1219 the parent task for a correct milestone.
1220 5. Assign the budget to the task in `"USER=SUM"` form, where "USER"
1221 corresponds to your username and "SUM" corresponds to the actual
1222 budget in EUR. There may be multiple users.
1223 6. When the task is completed, you can begin writing an RFP.
1224 **DO NOT submit it without explicit authorisation and review**.
1225 Leave out your bank and personal address details if you prefer
1226 when sending to the Team Manager for review.
1227 7. Once the RFP is written, notify the Team Manager and obtain their
1228 explicit approval to send it.
1229 8. Once approval is received and the RFP sent, update the `"USER=SUM"`
1230 field to include the submitted date:
1231 `"USER={amount=SUM, submitted=SDATE}"`. The SDATE is entered in
1233 9. Once the task is paid, again notify the Team Manager (IRC is fine),
1234 and update `"USER={amount=SUM, submitted=SDATE}"`
1235 to `"USER={amount=SUM, submitted=SDATE, paid=PDATE}"`. The PDATE is
1236 entered in `YYYY-MM-DD` form, too.
1238 Throughout all of this you should be using budget-sync to check the
1239 database consistency
1240 <https://git.libre-soc.org/?p=utils.git;a=blob;f=README.txt;hb=HEAD>
1242 [[!img bugzilla_RFP_fields.jpg size=640x ]]
1246 Find appropriate tutorials for nmigen and yosys, as well as symbiyosys.
1248 * Robert Baruch's nmigen tutorials look really good:
1249 <https://github.com/RobertBaruch/nmigen-tutorial>
1250 * Although a verilog example this is very useful to do
1251 <https://symbiyosys.readthedocs.io/en/latest/quickstart.html#first-step-a-simple-bmc-example>
1252 * This tutorial looks pretty good and will get you started
1253 <https://web.archive.org/web/20210123052724/http://blog.lambdaconcept.com/doku.php?id=nmigen:nmigen_install>
1254 and walks not just through simulation, it takes you through using
1256 * There exist several nmigen examples which are also executable
1257 <https://gitlab.com/nmigen/nmigen/tree/master/examples/> exactly as
1258 described in the above tutorial (python3 filename.py -h)
1259 * More nmigen tutorials at [[learning_nmigen]]