Why you should use Free and Open Source Software to design your hardware

Author : Javier Serrano Date : August 5, 2022

When you design hardware, it is very likely that you want to share your design files with others. At the very least, you may want to open your files and edit them in the future. This blog entry explains the advantages of using Free and Open Source Software (FOSS) if you want to make sure you always have access to your files.

Layout of a circuit using KiCad, a FOSS tool to design Printed Circuit Boards

Commercial not the opposite of FOSS

‘Commercial software’ is not the opposite of ‘FOSS’. The opposite of ‘FOSS’ is ‘proprietary software’.  A proprietary program is one for which you do not have meaningful access to the source code. You can buy support for FOSS, and then it’s commercial FOSS. In fact, many argue that it’s a winning combination: you avoid lock-in situations because it’s open-source, but you contribute to the sustainability of the project and you don’t expect people to work for free, which unfortunately is often the case with open-source projects. 

The problem with proprietary tools

The most important issue with proprietary tools is the dependency on an external entity, typically a software company, to be able to open and edit the content you created to begin with. We are so used to accepting this that we don’t see anymore how unnatural it is. Imagine you kept a hand-written diary. Some of these diaries come with a lock for privacy reasons. Now imagine that every time you wanted to open your diary you had to ask a company for the key to the lock. The company could ask you for regular payments to continue giving you the key every time you asked for it, and if you stopped paying you would not have access anymore to the years of content you might have already written in those pages. Even if you were willing to pay, the company could go belly-up, or their priorities could change, and you might lose access to your diary. Sounds ludicrous, right? Yet, this is what we accept every time we generate content using a proprietary tool. The current trend for design software to be ‘in the cloud’ and for licensing to be subscription-based gives tool providers even more control over who can access files and when.

But my EDA vendor gives me this super-good deal!

Some people invoke low prices of a given proprietary Electronic Design Automation (EDA) tool as a reason not to worry too much. Versions of the tools with limited capabilities are sometimes even available for free! EDA vendors can give extreme discounts to users as part of their commercial strategy. For example, academic institutions often get very good deals because vendors know that these tools have a steep learning curve and once a user has developed the muscle memory to be super-efficient, they are very likely to ask for the same tool in their next job, which may be in a company paying the full standard license fee. 

Does that mean that you are safe provided you work in an academic institution? Ask people working there, and you will find out that changes in the strategy of EDA providers (for example as a result of new management) can easily result in abrupt license fee increases. The feeling of helplessness in those cases is hard to describe, especially if you already have a huge number of designs done with that tool.

Zero or very-low license fees create the illusion that you will not lose much if you have to change tools as a result of a price increase, because you never paid them much to begin with. This may be true unless you and your colleagues have invested a big effort learning the tool and creating content you may not be able to access again. For example, a single PCB design might have taken hundreds of hours and multiple iterations to be completed; you might still have the Gerber files for production, but if you need to make a small modification, there is a significant cost to starting the whole layout project again.

If, on the other hand, you think that you may be willing to accept a steep increase in fees to be able to keep access to your files, I have bad news for you: your EDA vendor may be doing that very calculation for you as you read this. One cannot blame a commercial company for wanting to make more money. That’s what companies do. Whether your interests and theirs are aligned enough for you to purchase a proprietary license to their software is for you to judge. At this point it is worth noting that many users absolutely want to pay in exchange for the assurance that they will get technical support if they need it. This is a reasonable expectation when one uses a tool for important design work. As I mentioned earlier, it is very possible to buy that kind of support for an open-source tool. It is also an excellent way to help the project, funding software development work while maintaining the benefits of FOSS. Proprietary licenses typically conflate two aspects which are largely independent: the ability to open and edit your files on one hand, and the support if anything goes wrong on the other. You can certainly get the latter without compromising on the former.  

Call to action

Every designer wants to be able to share designs with their future self. If, in addition, you are designing Open Source Hardware (OSHW), your motivation to use FOSS should be even stronger. Open-source tools are sometimes lacking in features and quality. This may be partially explained by the fact that developers are often volunteers who join a project to ‘scratch their own itch’. As a result, conceptual integrity and user experience may get less priority than they should. You can help develop a good open-source tool in your domain (mechanics, electronics or other) in many ways. Contributing code, helping fund development or steering these projects to make them more organized and scalable are just some of the ways people are already doing this. In software development, many of the best tools are open-source. Awareness of the importance of FOSS in guaranteeing easy sharing and absence of lock-in is a first step. This blog entry, necessarily limited in scope and depth, is meant to raise this awareness. A longer version, describing Printed Circuit Board (PCB) design to make things more concrete and tackling the important subject of file formats, is available here. So, what next? If you would like to discuss further and see how we can get organized and reach critical mass in this important endeavor, feel free to post your questions, ideas, suggestions, etc. in the OSHWA Forums. Let’s make FOSS the standard way of sharing OSHW designs!

Guidelines for sharing FPGA designs published

Author : Javier Serrano Date : October 3, 2021

OSHWA is concerned with all types of hardware designs. This includes designs which target Field Programmable Gate Arrays (FPGAs), typically expressed using Hardware Description Languages (HDLs) like VHDL, Verilog and SystemVerilog.

While finding a place on the Web to host your HDL code is straight-forward, reusability of these designs has in some cases suffered from a number of issues. These include absence of ancillary files, lack of high-quality testbenches and documentation, awkward licensing choices and publishing of all-rights-reserved code automatically generated by the tools provided by FPGA vendors.

OSHWA has teamed up with the FOSSi Foundation to provide a set of guidelines to help designers share HDL code efficiently. For those of you who are starting with FPGA design, the document provides an introduction and a short section on nomenclature before moving on to the best practices proper. These guidelines may become the basis for an HDL certification program in the future. For the time being, we hope they are useful to all FPGA designers and we invite you to post questions and comments in the forums to help us make them better.

Open Source Hardware (and Gateware) for 5G

Author : Javier Serrano Date : March 15, 2021

OSHWA recently sent a response to the 5G Challenge Notice of Inquiry published by the National Telecommunications and Information Administration (NTIA) in the US. The Notice of Inquiry focuses on the development of an open-source software stack for 5G wireless communication. In our response we highlighted the role that Field-Programmable Gate Arrays (FPGAs) can play in the path from the radio receiver to the 5G software stack and conversely from the software stack to the radio transmitter. FPGAs can cope with very high data rates, for which pure software solutions can be suboptimal.

It is therefore important that FPGA designs are made part of the challenge, and also that these designs be open-source for the same reasons that it makes sense to open-source the software stack. FPGA design is typically done using Hardware Description Languages (HDLs). HDL code is fed to synthesis, place & route and bitstream generation tools. The bitstream file then configures the FPGA, so its logic gates and flip-flops implement the circuit specified in the design. HDL code is sometimes called “gateware” (a reference to the logic gates it targets) to distinguish it from software.

If researchers and developers are going to collaborate on common open-source gateware and software, they would ideally do so using an open hardware platform. This would democratize access, enlarging the talent pool which can contribute to the effort. It would also protect the development against vendor lock-in and save time and effort on porting to different imperfectly-compatible platforms.

Finally, this could be an opportunity to improve the Free and Open Source Software tools for gateware design. There are thriving communities of open-source software-defined radio and FPGA tool developers, and we believe including them in this challenge and having hardware and gateware in the picture will result in a better 5G for everyone.