lion VS cocotb

I've been starting to dabble with digital logic design via Clash (https://clash-lang.org/), and there is a very cool-looking RISC-V SoC project done in that tool that looks fairly serious: https://github.com/standardsemiconductor/lion.

That’s fascinating about the M1. In retrospect it seems like kind of a no-brainer but I doubt I would have thought of it.

SPARC had different memory models at different ISA revs IIRC: it’s been like 20 years since I was dealing with SPARC so I might be misremembering the details. Alpha would have been a better example.

RISC-V is really interesting. I’ve been slowly working through this: https://github.com/standardsemiconductor/lion, highly recommend!

Interesting. Actually, you may be just the person to answer my question: Is it possible/plausible to run a Cardano node on Lion OS on a RISC-V machine? IMO, it would be great for the community if we could run all Cardano stake pools on end to end formally verified machines using open source core and hardware.

Lion: A formally verified, 5-stage pipeline RISC-V core\ (30 comments)

In addition, you can actually set the riscv-formal suite to verify correctness by k-induction: https://github.com/SymbioticEDA/riscv-formal/pull/28 https://symbiyosys.readthedocs.io/en/latest/quickstart.html#beyond-bounded-model-checks although I concur that by looking at https://github.com/standardsemiconductor/lion/blob/main/lion-formal/app/Main.hs the lion core is only verified with BMC.

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?