It is possible to contribute to improving #guix as the need for new functionalities, packages, fixes or upgrades arise. This is one of the strongest points in open communities: the possibility to participate on the development and continuous improvement of the tool. Let’s see how it goes when it comes to guix.

Using #git is not the whole picture on #modernhw version control landscape. Git is great when one decides to locally follow changes, take diffs, create branches and so on. When it comes to collaboration with other people or to create a community around a common project, the need for extra tooling arises, and it becomes evident that git alone is not enough. A #gitforge fills this gap.

Putting new ideas in community, exchanging opinions, replying to someone's else impressions, sharing public experiences, showing feelings about modern way of living, writing down notes on what’s going on from one’s side ... So many interesting and useful content around to share. The question is, how to do so simply and without complications ? How not to expend way too much time messing with tooling ? Is it yet possible to concentrate on what really matters, contents ? Here I summarize the way I’ve found to contribute to this blog, which fits best with my workflow.

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.

Tools and techniques towards modern digital electronics design

Modern digital hardware design (#modernhw) in research implies using the right tools. But this is not necessarily always the case.

Once upon a time, in digital electronics design, we were used to moving huge zip files around including project data, code and all ancillary stuff along with it. We were doing backups, snapshots and versioning our code with help of compressed files. That’s the way it was, I knew that time, and you, young reader, would not believe me if I told you about the whole picture. This is not acceptable anymore.

#guix includes the concept of channels, or git repositories of package definitions. This gives a chance for anyone to complete the collection of packages provided by the distribution, in case this is not enough. Keep reading for an intro on how to create your own channels, or how to use the most popular third party guix channels around.

As one understands with time and a bit of experience, keeping track of the whole bunch of #dependencies necessary to handle daily when doing digital hardware design may reveal as an error-prone task. And yet, this is not to speak about regressions, incompatibilities and most important, #reproducibility of results. Luckyly enough, this is precisely the problem that #guix intends to solve, in an elegant, minimalistic and open way, using only #freesoftware.

#modernhw, and in particular digital electronics design implies, for the most of it, writing #plaintext files. Creating code, scripts, configurations, documentation, emails, taking notes, handling bibliographic references, etc., all of these tasks involve writing in plain text files. Whether these files are created or modified, editing plain text is a must. An, when it comes to editing text, it is really worth investing some time on learning a bit more than the basics of a good text editor.