chiselverify
amaranth
Our great sponsors
chiselverify | amaranth | |
---|---|---|
1 | 7 | |
130 | 1,434 | |
2.3% | 4.0% | |
2.2 | 9.6 | |
17 days ago | 8 days ago | |
Scala | Python | |
BSD 2-clause "Simplified" License | BSD 2-clause "Simplified" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
chiselverify
-
Chisel/Firrtl Hardware Compiler Framework
Chisel is not HLS. It is a Scala library that lets you generate circuits on an RTL abstraction level. That means that you explicitly define every state element like registers and memories. But you can generate N registers inside a loop (or a map/foreach) instead of only 1 at a time. In HLS the compiler needs to somehow infer your registers and memories.
That said, I think one of the problems the google team was struggling with is that in traditional HW development there is design and a separate verification team. The design team bought into Chisel since it would let them generate hardware more quickly, but the verification team just tried to apply their traditional verification methods on the _generated_ Verilog. This is almost like trying to test the assembly that a C++ compiler generates instead of trying to test the C++ program since all your testing infrastructure is setup for testing assembly code and that is "what we have always been doing".
In order to catch verification up to modern Hardware Construction Languages [0] we need more powerful verification libraries that can allow us to build tests that can automatically adapt to the parameters that were supplied to the hardware generator. There are different groups working on this right now. The jury is still out on how to best solver the "verification gap". In case you are interested:
- https://github.com/chiselverify/chiselverify
amaranth
-
Why are there only 3 languages for FPGA development?
He probably meant Amaranth.
-
VRoom A high end RISC-V implementation
As an aside, the latest and active development of nMigen has been rebranded a few months ago to Amaranth and can be found here: https://github.com/amaranth-lang/amaranth . In case people googled nMigen and came to the repository that hasn't been updated in two years.
- NMigen – A Python toolbox for building complex digital hardware (FPGAs)
-
Facts every web dev should know before they burn out and turn to painting
Hmm. A followup question: are there any cheats/hacks that would make it possible (if painful) to for example explore the world of USB3, PCIe, or Linux on low-end-ish ARM (eg https://www.thirtythreeforty.net/posts/2019/12/my-business-c..., based on the 533MHz https://linux-sunxi.org/F1C100s), without needing to buy equipment in the mid-4-figure/low-5-figure range, if I were able to substitute a statistically larger-than-average amount of free time (and discipline)?
For example, I learned about https://github.com/GlasgowEmbedded/glasgow recently, a bit of a niche kitchen sink that uses https://github.com/nmigen/nmigen/ to lower a domain-specific subset of Python 3 (https://nmigen.info/nmigen/latest/lang.html) into Verilog which then runs on the Glasgow board's iCE40HX8K. The project basically makes it easier to use cheap FPGAs for rapid iteration. (The README makes a point that the synthesis is sufficiently fast that caching isn't needed.)
In certain extremely specific situations where circumstances align perfectly (caveat emptor), devices like this can sometimes present a temporary escape to the inevitable process of acquiring one's first second-hand high-end oscilloscope (fingers-crossed the expensive bits still have a few years left in them). To some extent they may also commoditize the exploration of very high-speed interfaces, which are rapidly becoming a commonplace principal of computers (eg, having 10Gbps everywhere when USB3.1 hits market saturation will be interesting) faster than test and analysis kit can keep up (eg to do proper hardware security analysis work). The Glasgow is perhaps not quite an answer to that entire statement, but maybe represents beginning steps in that sort of direction.
So, to reiterate - it's probably an unhelpfully broad question, and I'm still learning about the field so haven't quite got the preciseness I want yet, but I'm curious what gadgetry, techniques, etc would perhaps allow someone to "hack it" and dive into this stuff on a shoestring budget? :)
-
Awesome Lattice FPGA Boards
Worth knowing that are two "nmigen"s nowadays - the one originated in M-Labs and one under a project also called nmigen:
https://github.com/nmigen/nmigen
It's a fork, made for reasons, but more actively developed. whitequark (long time author/contributor) works on this fork, and no longer the M-Labs version.
- Chisel/Firrtl Hardware Compiler Framework
-
Unifying the CUDA Python Ecosystem
Sounds like nmigen might be a good open source successor to the project that you describe: https://github.com/nmigen/nmigen
What are some alternatives?
SpinalHDL - Scala based HDL