chisel VS cocotb

My first instinct was to ask "Does this play well with CIRCT?" And thankfully they answer that right away in the README.

I'm personally of the opinion that there is a LOT of room for improvement in the hardware design tooling space, but a combination of market consolidation, huge pressure to meet deadlines, and an existing functional pipeline of Verilog/VHDL talent is preventing changes.

That's not to say "Verilog/VHDL are bad", because clearly they've been good enough to support nearly all of the wonderful designs powering today's devices. But it is to say, "the startup scene for hardware will continue to look anemic compared to the SaaS scene until someone gives me all of the niceties I have for building SaaS tools in software."

A huge amount of ideas (and entire designs) start off as software sims, which enables kernel/compiler engineers to start building out support for new hardware before it's manufactured.

There is some interesting work going on at SiFive building hardware with Chisel[1], as well as some interesting work lead by a professor at William and Mary to improve simulations[2].

1: https://www.chisel-lang.org

2: https://github.com/sarchlab/akita

Inspired by Scala. Which can do a whole lot more, and worse. The currently biggest competitor to decades old hardware description languages is a Scala DSL.

Already mentioned Chisel: https://www.chisel-lang.org/

I'm also a hobbyist. There are a number of alternative HDLs out there, and as hobbyists we can deviate more from the mainstream of (System)Verilog and VHDL if we desire, though you'll still need to be able to read them. In the past I've done Verilog, but lately I've been using SpinalHDL and have been really enjoying it. Its close relative Chisel also makes appearances in the RISC-V space.

What are your thoughts on other HDLs like Chisel or BlueSpec when it comes to better type checking?

I started playing with FPGAs and HDLs a couple years ago with no hardware design background (I'm mostly a software architect/engineer) and in the end found that a "higher-level" HDL suited me better.

I chose Chisel (https://www.chisel-lang.org/) an HDL based on Scala (technically a Scala DSL) which can provide many facilities to hardware generation.

I'd highly advise looking into it although also knowing Verilog helps a lot.

But some go further and ask "what if when we add a soldering station on top of it?"

In recent years Chisel HDL, RISC V, and SiFive came out of their architecture group, to name a few.

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?