cocotb VS circt

The use of cocotb and pyuvm for verification

For FPGA/HDL work, there's cocotb

At the moment, it is not possible to directly simulate synthesizable contexts. In principle, I could add a simulator to CoHDL. As a Python implementation, it would be orders of magnitude slower than other solutions. Instead, I am using Cocotb to validate the generated VHDL and for the unit tests in the GitHub repository. There is also some very, very experimental support for formal verification, but it will take some time for that to become usable.

On the topic of simulation, you don't have to restrict yourself to using Verilog or VHDL to write your test benches. For example, Verilator lets you write them in C++, cocotb lets you use Python, and if you use SpinalHDL you will drive the underlying simulator using Scala.

I know it might be difficult without much context, but this makefile is called by a top level makefile. very confused if lines 35-74 do anything. They seem to be a mix of real makefile syntax and just straight up comments. what do these lines do?

Learn more about this here: https://www.cocotb.org/

Also consider cocotb, this thread has some compelling arguments. I'd say as a student, learning industry tools isn't necessarily the best thing you could spend your time on. Getting fast at design AND verification, where you can maintain flow state and run better microexperiments means you will understand more, faster.

Have you tried looking at the mixed language example?

MLIR (https://mlir.llvm.org/) is a quickly growing compiler toolkit which attempts to synthesize the learnings of LLVM and currently powers compilers for programming languages, machine learning and circuit design (https://github.com/llvm/circt). and there are a ton of companies with real employees working on it (including Microsoft) and MLIR is at the core of Chris Lattner’s new company, ModularAI. I’d recommend taking a look at it, there are a large number of ways to get involved and a number of paths from contributor to employee.

Might be good to target the CIRCT infrastructure at some point.

Even small optimizations like removing unused pins from internal modules are often times opposed.

Chris Lattner and others are currently working on an "industry" version of firrtl as part of the CIRCT hardware compiler framework: https://github.com/llvm/circt

Did you see the work being done on CIRCT? https://github.com/llvm/circt

I remember one of the reasons you did not want to use firrtl was that its compiler is implemented in Scala and thus hard to integrate into other projexts. CIRCT will solve that problem by providing a firrtl compiler implemented in C++. Other languages like Verilog/VHDL and new high level languages for HLS-like designs are also on the todo list.

Relevant: https://github.com/llvm/circt