You read that right. Their build system outputs source code, generated from another C code base, using macros to feature gate bug fixes depending on who the customer is. The account managers would sent a list of bugs that a given client had experienced and the backoffice engineers would make a build that fixed only those bugs.

Forget about collaboration and sharing. They haven't even figured out the basic business processes that many software engineers take for granted.

Makes perfect business sense! Those customers didn't pay to get those bugs fixed, so why should they get the fixes??? /s

Holy moly.

This approach is wrong on many levels, but fixing the real cause is often a bit more work than "a hundred junior dev hours". In the meantime, you have to deliver to customers.

Edit:fixed a typo.

The "move stuff and break stuff" crowd forgets there's a market for "move slow and rarely break stuff" too.

So if you have qualified hardware w/ a certain driver version, you don't just ship a bunch of code fixes to a customer, you ship the bare minimum change set required to fix any specific issues they experience. Because you're sure as hell not recertifying every part revision with every driver version.

The problem in the hardware industry is far more insidious. Unlike with software dev, there is no concept of "full stack" or "devops" in manufacturing. The entire field is so hyperspecialized that youve got people dedicated to tuning reflow temperatures to +-5C depending on humidity and local weather. No one person can have a proper big picture view of the situation so the entire industry is dominated by silos each with their own micro-incentives and employees competing with each other for notoriety.

We were, however, an established client of Qualcomm and working on a new design so we explicitly asked for all bug fixes and they refused except for the ones we could name. We got "lucky" in that no other client had needed both bug fixes at the same time and when the build system broke, the one guy responsible for it was MIA so we got the whole source dump (they didn't even test their fixes together until a client found problems).

I've used other Qualcomm products with different engineering support teams that are much better at source control, testing, and even devops but it's a very rare sight within the industry.

It stinks badly, but is a sad reality.

It'd probably be around today and up to date if it was open source. A shame it isn't. I don't even know who owns the rights to it these days, or if whoever owns it even knows they have the rights to it, due to spinoffs and mergers.

Perhaps you can ask the professor for who has the copyright on ABEL now? So we can ask the holder if it can be open sourced.

Miracles like this do happen - last year Symantec allowed the Symantec C++ compiler to be fully open sourced!

https://www.xilinx.com/support/documentation/sw_manuals/xili...

Perhaps not entirely. We had one lab session dedicated to it during my junior year in college. That was ten years ago but apparently they haven't changed that[0] (course description in english at the bottom of the page).

[0] http://studia.elka.pw.edu.pl/pl/18L/s/eres/eres/wwersje$.sta...

Needless to say, the ABEL projects were frustrating...indeed a shame that it's not open source.

Some more info (I'm surprised at the response here!):

https://en.wikipedia.org/wiki/Advanced_Boolean_Expression_La...

"The ABEL concept and original compiler were created by Russell de Pina of Data I/O's Applied Research Group in 1981." This is false. I don't know what de Pina did, but ABEL was developed from scratch by the 7 member team listed in Wikipedia, and the grammar and semantics were designed by myself.

Is there some "copyright" printed on it? Before 1989 it was apparently "required" and if not printed apparently it matters if "the author made diligent attempts to correct the situation":

https://fairuse.stanford.edu/overview/faqs/copyright-protect...

"you should assume that every work is protected by copyright unless you can establish that it is not. As mentioned above, you can’t rely on the presence or absence of a copyright notice (©) to make this determination, because a notice is not required for works published after March 1, 1989. And even for works published before 1989, the absence of a copyright notice may not affect the validity of the copyright — for example, if the author made diligent attempts to correct the situation.

The exception is for materials put to work under the “fair use rule.” This rule recognizes that society can often benefit from the unauthorized use of copyrighted materials when the purpose of the use serves the ends of scholarship, education or an informed public. For example, scholars must be free to quote from their research resources in order to comment on the material. To strike a balance between the needs of a public to be well-informed and the rights of copyright owners to profit from their creativity, Congress passed a law authorizing the use of copyrighted materials in certain circumstances deemed to be “fair” — even if the copyright owner doesn’t give permission."

It's not simple, but maybe an interesting starting point... Maybe, if there's if it is not a product actually being sold or even used as such anymore, there's reasonable chance that the copyright holder wouldn't be interested to enforce the protection of the "historical material"?

http://www.swtpc.com/mholley/PLD_History/ABEL_project/Russ_d...

http://walterbright.com/

But my degree is ME, not CS nor EE.

I'll have popcorn ready for the eventuality where IP blocks are widely available under GPL type of FOSS licenses and Intel|AMD|ARM|TI|... is eventually found to include one or more of those open sourced blocks with incompatible license in their chips.

In software you can always replace a library that had incompatible license with another. Not sure how this would work with a chip.

As for attempts to modernize EDA industry, I welcome that in open arms. And if in the process we end up open sourcing a lot of current IP blocks (think of USB, HDMI, etc. designs) - all the better.

Intuitively I'd thought something similar, but IANAL and could be completely wrong, of course :)

First off, the RISC-V community is based on the open ISA. There are several open implementations of the ISA. And the RISC-V community is meaking good headways in developing open tools, peripheral cores etc.

https://riscv.org/

Secondly there are at least two attempts at collecting and tracking open cores for FPGA- and ASIC-implementations.

LibreCores is the newer project. They have collected quite a few projects:

https://www.librecores.org/ https://www.librecores.org/project/list

Related to LibreCores is the SoC-builder and core package handler Fusesoc by Olof Kindgren. Fusesoc makes creating your SoC easy:

https://github.com/olofk/fusesoc

The older project is OpenCores. OpenCores has been quite tightly related to the OpenRISC CPU core, the wishbone set of on-chip interconnect solutions. They have been used in many FPGAs and ASICs

https://opencores.org/ https://openrisc.io/

Then you have projects like Cryptech that develops a complete, totally open, Hardware Security Module capable of doing certificate signing, OpenDNSSEC signing etc. The Cryptech Alpha design from PCB to FPGA cores and SW including pkcs11 handling is open. The project has amassed quite a few cores. The PCB design is available in kiCAD. (disclaimer: I'm part of the Cryptech core team doing a lot of the FPGA design work.)

https://cryptech.is/ https://trac.cryptech.is/wiki/GitRepositories

Speaking of tools like KiCAD, there are aqtually quite a few open tools for HW design. For simuation there are Icarus Verilog, Verilator, cver for example. They might not be as fast as VCS by Synoptsys. But they do work. I use them daily.

http://iverilog.icarus.com/ https://www.veripool.org/projects/verilator/wiki/Intro

For synthesis, P&R the state is less good. For implementation in Altera and Xilinx devices you currently have to use the cost free tools from the vendors. But there is work ongoing to reverse engineer Xilinx Spartan devices. I don't know the current state though.

But what has been reverse engineered are the ICE40 FPGA devices from Lattice. And for these you can use the open tool Yosys by Clifford Wolf (also mentioned below by someone else).

http://www.clifford.at/yosys/

And if you are looking for open implementations of crypto functions etc I have quite a few on Github and try to develop more all the time:

https://github.com/secworks

The sha256 and aes cores has been used in quite a few FPGA and ASIC designs. Right now I'm working on completing cores for the Blake2b and Blake2s hash functions.

I agree that we in the HW community is waay behind the SW community in terms of open tools, libraries (i.e. cores). But it is not totally rotten, and it is getting better. RISC-V is to me really exciting.

Unfortunaly, while the tool is pretty nice, it never resulted in major adoption (qualcom has some tool using it internally and a few others) and we haven't seen the idea of making reusable libs and components florish.

Somebody would need to find this project and up it to python 3.6. With current tooling, it would make writting code in it really nice and ease the creation of reusable components.

Reusability in raw verilig is hard

Every CAD system I know of supports ways of group circuits into modules and libraries for multiple Instantation. And those libraries are distributable.