Planet Guix

Remote #ci is the way to go in #modernhw digital design testing. In this #ciseries, let’s see it in practice with some detail using two of the most popular forges out there.

How to seek, detect, be notified, analyze logs, understand and react to the different possible kind of issues one may encounter in a digital design is a vast topic of research, well beyond the scope of this modest post. But there are a couple of things we may state about here, though: automatizing issue detection is the way to go. Continuous integration (#ci) testing is a practice to adopt in #modernhw as a way to ensure that our design complies with its constraints. Let’s see this in more detail.

Creating something new from scratch implies a certain ratio of unpredictable issues (loosely defined in the scope of this post: new errors, regressions, warnings, ... any unexpected behavior one may encounter). Most important, a digital design developer needs to define somehow what he considers to be a project issue, before even thinking about how to react to it. Luckily, in #modernhw a few usual tools are available to ease the process as a whole. Let’s overview some of them.
Here on the electronics digital design side of life, we have mainly three #freesoftware fine tools (among many others) to perform code checking to a large extent: osvvm, cocotb and vunit. They are all compatible with the ghdl compiler, and they are all available from my own #guix electronics channel (cocotb and vunit will hopefully get merged on guix upstream at some point). Each departs from the rest, adopting a different paradigm about how digital design testing should be understood: verification, cosimulation and unit testing are master keywords here.
They are all complementary, so you’ll be able to combine them to test your designs. However, you’ll need to be careful and check twice what you’re doing, as some of their features overlap (random treatment, for example). You’ve been warned.

Guix reveals as a practical means of handling dependencies. However, the amount of information available to start using it may appear as a bit overwhelming for a beginner, letting the feeling of a tool reserved to a reduced community or experts. Far from that. Here you’ll find everything you need to get started with guix, with a light touch on using it for #modernhw.
We will concentrate in the use of #guix as an external package manager on top of a #linux distribution based on #systemd. We’ll let aside using and referring to #guixsystem as a full operating system by itself (which I never used anyway). This way, in the context of #modernhw, we may keep on using our favorite tools, environment and workflow. As an addition, we have everything that guix provides at our disposal, without affecting our local packages configuration: guix acts as an extra layer on top of our current OS, without any interference with it. You’ll have the possibility to install any guix software, remove it afterward or make use of the fancy features guix has to offer, without your host OS ever noticing what’s going on.
All what follows is roughly based on the guix reference manual and the guix cookbook, so refer to them for more on depth explanations. This article is strongly influenced by my personal experience as a daily driver, so next topics are necessarily biased towards my own needs.
There is much more to say about guix, but this is just an introductory crash course, right ?

A lot has happened with respect to the Hurd since our Childhurds and GNU/Hurd Substitutes post. As long as two years ago some of you have been asking for a progress update and although there have been rumours on a new blog post for over a year, we were kind of waiting for the rumoured x86_64 support.

High-speed network interconnects are a key component of supercomputers. The challenge from a software packaging viewpoint is to provide an MPI stack able to get the performance out of that specialized networking hardware. As packagers, our approach has been to provide MPI packages that get the best performance of the underlying interconnect, be it Omni-Path, InfiniBand, or any other type of interconnect.

We are pleased to announce Guix-Jupyter 0.3.0, a long-overdue release of our Guix-powered Jupyter kernel for self-contained and reproducible notebooks.

In a previous post I mentioned the way I use Emacs Org code blocks and the so-called Noweb syntax as a templating mechanism. The idea is to have a template version of a document containing a certain number of placeholders and a separate file to store the placeholders' values. The template and the data file are then fed into a build process that recombines things and produces the final document.

I've been noodling on structural editing for a while now. I'm fully bought into Lisps myself, but most of my friends and coworkers are skeptical, and I think a lot of their skepticism has to do (as usual) with all the parens. One of the points I make frequently is that with Lisp code being written as a nested data structure, the textual representation is just one of many possible representations. But it can be hard to get across what that means without concrete examples.

People from Guix London gave me the chance to describe this process.