Since you’re reading Hackaday, we’re pretty sure CERN needs no introduction, so we’ll get right to it– they’re giving back again, this time with a VHDL library called “colibri” containing over 100 components, functions, and procedures to help jumpstart your next FPGA project.
Like a lot of what CERN gives away under its CERN Open Hardware Licence, this library and the functions in it were developed in house to make CERN run better– specifically to streamline the development of gateway devices. As you might imagine, with the prodigious amount of data CERN’s various experiments spit out, FPGAs have become a key part of many of them. The best part is that because the fine folks at CERN don’t want to get locked in, everything here is vendor-independent and has been tested on multiple platforms. Speaking of tested, you get self-checking testbenches in there to make sure everything’s working, and there’s even formal verification, at least for some things. We’ve seen formal verification in software compilers, but its not common in the FPGA world. The whole thing is on GitLab if you want to take a look.
While CERN’s library might not have much to help you make a ternary processor or bus controller with everyone’s favourite programmable silicon, much like software libraries you can save some time at least not implementing say, SPI or i2c– both of which are in colibri, along with a whole lot more.
Thanks to [Alberto Perro] for the tip!
CERN are a shining example of how ALL taxpayer funded research should be handled. It should be opened to the public and offered for free.
Personally, I think the same should apply to all government grants and subsidies. If your business relies on taxpayer funds, your IP should be open source. Otherwise, do it on your own.
Great idea.
Except maybe for the whole ending the universe thing. 😉
Well the creation of the universe upset a fair few people, don’t forget it was widely regarded as a bad move from the get go.
lol
I feel like if they accidentally invented e.g. a method to build a pure fusion weapon with no plutonium they wouldn’t open-source that part ;)
TBF if someone has the resources to build a DIY Large Hadron Collider at home from open sourced plans there’s probably other issues that would come up sooner.
I’m not ruling out the idea that Colin Furze might do it if supplied with sufficient tea and biscuits.
100% agree. For the most part this is SUPPOSED to already be the case. It’s covered by “the nelson memo” from 2022, and when I worked at a national lab we were required to pony up the extra publication costs to pay for open-access journal options. That said, to my knowledge there aren’t any enforcement teeth, so I don’t know how rigorously followed that directive is.
This is so awesome. I’ve always been so frustrated at how high the barrier to entry is playing FPGAs. Especially considering they should be basically the most flexible and open devices out there….
This is such a great step on the VHDL side towards lowering that barrier to entry and divorcing the crappy vendor IP from the hardware. Even VHDL as a language has so much potential that has completely stagnate I because vendors just don’t see a reason to care.
In the name vein I’ll make a shameless plug at my on-going attempt to an actually useful AND affordable hobby level FPGA board.
https://hackaday.io/project/205055-the-crystal-board
FPGA noob here, excuse me if my question is daft : so is this release will end the debate about which of Verilog and VHDL is best? I mean, if CERN has chosen VHDL it’s because it has more upsides than Verilog?
Not really. There is a place for both. Verilog is generally closer to the hardware (that you are synthesizing), and simpler to understand (and my favourite where possible). However, VHDL is better in a “formal” implementation, where you have a lot of component inheritance, and inclusion of external components from many sources (say something like a microprocessor PoC). What I also sometimes do, is do my individual components in Verilog, do a unit-test, and then wrap the components in VHDL, and tie it all together with VHDL. The open source toolchains are much more flexible when deciding how, and where to do things…it is only the Altera support that I miss in open source…
However, in this case I suspect VHDL was chosen as it is more suitable for distribution as a library (for the previous reason). Whole project verification becomes easier.
Thanks Johan for this detailled explaination!
VHDL has always had more traction among European academic colleagues.
I should also say SystemVerilog support is significantly better now and at the very least with Xilinx/AMD stuff at least name the files “.sv” to get some of the improved basic language support, although if you asked me for an example I’m not sure I could give one since I’ve been doing “.sv” for so long now.
Yeah, I agree…Verilog is favoured in the US, and VHDL in European Universities. However, that rule does not hold in professional engineering.
Even though I like Verilog more, doing Verilog where there is a lot of boundary abstraction can become a verification nightmare pretty quickly (our little minds can only process so many simultaneous logical connections at once). In such cases, VHDL just makes more sense. VHDL against Verilog, is like C++ against C…one has more of an abstract nature than the other. I think you should know both, and whatever you use just depends on the complexity of your design.
The VHDL tricks to simplify interconnects limits you entirely to VHDL and forces stuff like IP core wrappers, though. And being entirely in VHDL eliminates some testbench tooling from vendors that’s only available in SystemVerilog.
That’s why I said above you just need to understand both of them, and use whichever one is the least barrier for the task you’re doing.
Personally I find I can’t really afford the task switch penalty that comes from having to jump from programming (which is basically entirely C operator syntax) to VHDL (which is Ada operator syntax). Keyword changes, sure, whatever, but don’t make me think “wait what’s the not equal sign here?”
Also VHDL has this wacko obsessive hatred of a standardized preprocessor (it’s been mentioned a bunch and the response from longtime VHDL types is always “I don’t see the need” – yeah, that’s the point).
You need to know both, at least at a basic level, and ideally avoid things that make cross-language things break (module boundaries should have simple ports, no custom types, for instance).
You’re not going to ever avoid vendor IP at some level (the hard IP is unavoidable and vendors frequently use IP as a way to bugfix the hard IP) and you may have to trudge through some of their code to figure things out.
This is more Europe vs US thing. In US you will be more likely to be thought Verilog in digital design classes at uni, in Europe it will be more likely VHDL. They have same feature set (almost), VHDL is more verbose. At the end is is good old Emacs vs VI forever battle.
I am in the VHDL crowd myself (though i never vent into digital design, stayed in sw engineering). CERN is in Europe. Most people working there at engineering level are from european universities, so VHDL it is.
I’d like to point you to DESY’s FPGA Framework. This isn’t just a library of VHDL modules but a whole build toolchain. All open source, battle tested (we’re using it at GSI) and with a community around it.
https://gitlab.desy.de/fpgafw/lib/desy_vhdl (the library)
https://gitlab.desy.de/fpgafw/ (the whole ecosystem)
This isn’t to say what CERN is doing isn’t great. On the contrary: the more the merrier.
It is to say: Have a look at all available toolkits and choose which one works best for you.