nerves_system_osd32mp1 VS hardcaml

I don't know much about it, but is this configuration useful?

title: Accelerating zk-SNARKs - MSM and NTT algorithms on FPGAs with Hardcaml

Any reason the title deviates so much from original? Is it because of all the cool acronyms and code words? Here's a decoder:

zk-SNARK: zero-knowledge Succinct Non-Interactive Argument of Knowledge

MSM: Multi-Scalar Multiplication

Hardcaml: OCaml lib for hardware: https://github.com/janestreet/hardcaml

NTT: Number Theoretic Transform

Perhaps peripheral (the original site has been hugged to death).

Both clashlang: https://clash-lang.org/

And Hardcaml: https://github.com/janestreet/hardcaml

have personally fueled my interest in hardware.

Dan Luu speaks eloquently and at length about how better options are needed for logic design. I would recommend both of the above to the enthusiastic novice.

Join JS and you can program FPGAs in a strongly typed, expressive, high level programming language (OCaml): https://github.com/janestreet/hardcaml

[1] https://github.com/janestreet/hardcaml

> You can put all the functions/tasks you want in that module.

Coming from a software background, the testing strategies available in Verilog seem very clunky and overly verbose. In comparison, Hardcaml's ASCII waveform expect-test solution feels extremely elegant and simple: https://blog.janestreet.com/using-ascii-waveforms-to-test-ha....

> And all of my development and that of my team happens through gitlab-CI.

That's probably more of a gap in my education than a fault of the ecosystem then.

---

Among other qualities, I prefer languages that let fewer mistakes slip through, and allow the developer to focus on the system they intend to build rather than avoiding bugs/misunderstandings that would be easy to catch otherwise. You bring up a lot of really good points, and I suspect that if we were doing Verilog "the right way", we would have probably run into fewer issues. But at the end of the day, developing in Hardcaml was a much more ergonomic experience: testing was straightforward, most "stupid mistakes" were impossible, setup was pretty easy, and the library provided a lot of really useful abstractions. For example, Hardcaml interfaces make it easy to represent practically any data structure that can be serialized to/from a bit vector, and the Always API allows for some pretty interesting non-trivial functional logic.

https://github.com/janestreet/hardcaml/blob/master/docs/hard...

A few months ago, I came across the Signals and Threads Programmable Hardware episode. I really liked the idea of Hardcaml: a library to write and test hardware designs in OCaml. Representing circuits as functions felt like a good abstraction, and I’ve been wanting to learn OCaml for a while.