Maybe unrelated, but I must say it again: we need an arduino for the fpga world.
However I'm not sure how much people use it and if it really has the simplicity that Arduino brought to tinkering with microcontrollers. I read and hear a lot that the FPGA dev tooling is usually not really great to use and very vendor-specific, but it's something I haven't tinkered with yet so I don't really know much !
[0]: https://store.arduino.cc/products/arduino-mkr-vidor-4000
It's an Arduino with an FPGA on it, yes. But the FPGA is practically a hood ornament: there is no support whatsoever for building gateware in the Arduino IDE, only for using a set of prebuilt demonstration bitstreams, and what little documentation Arduino has provided on using the FPGA (e.g. https://docs.arduino.cc/tutorials/mkr-vidor-4000/vidor-quart...) is extremely vague and is missing a lot of critical information.
(Additionally, some of the product specifications for the board are highly misleading -- for example, some pages refer to the edge connector as "mini PCI Express" and suggest that it can be used "to creat [sic] your own PCI interfaces", but the FPGA on the board does not support PCIe.)
You're much better off with a dedicated FPGA development board. Arduino hasn't brought anything useful to the table here.
Not that you have an answer, but it makes me wonder what is the target audience for this board ?
I have a feeling that the primary audience for this product was Arduino's own management team, rather than any actual customer needs.
building a simple hardware dev board is a straightforward exercise.
building an IDE that lets a novice do anything useful on an fpga, outside of a very basic state machine, is an entirely different problem in both scope and structure.
The vast majority of HDL blocks you'd need to make such a thing more useful than a $4 microcontroller are closed source, nontrivial to build, and require careful thought in terms of integrating them into a workable system, not to mention very specific and application dependent PHYs: Things like HDMI, ethernet, USB, etc.
I think what most people would prefer is a fast general purpose CPU with pluggable, low-latency memory mapped peripherals without the hassle of having to know linux systems programming to make it work.
I would argue that you can make your own microcontroller dev board easily enough too. An RP2040 or similar, a USB programmer, some kind of voltage converter, etc.
The joy that Arduino bright to microprocessors was that it was a device that was useful for a lot of projects straight out of the box, accessible to those with only high school knowledge of circuits or programming.
I want a gcc or LLVM like compiler ecosystem that can handle multiple vendor backends and language front ends so we can use vhdl, verilog or a new hdl in a project. Let me write portable modularized logic files that let me abstract the underlying hardware so I can target different vendors and devices. Decouple layout and let the community create as many textual or graphical layout tools as needed. Then let me write a makefile to handle the build process. I don't want to worry about switching gigabytes of tooling so I can move from a Xilinx to Lattice or Microchip FPGA or SoC. These tools will be a boon to devs using those awesome FPGA SoC's as you can self-host the toolchain on the SoC itself.
I did a bunch of fpga self learning around 2012 and spent a lot of time fighting with getting ISE to run on Linux. I then tried Altera and then fought with fought with Quartus (though from memory I think it was easier to setup). Then ISE was replaced by vivaldo and I felt discouraged by having to adopt a new IDE contraption with more licensing woes. Then my hard drive died and I've never bothered with wrestling fpgas since. The two fpga boards, a Digilent Nexus 3 and Terasic de0 nano collect dust. I gave up because the tools sucked and i wasnt using them to make money.
Also IPs sometimes have errata in them that need to be worked around. With an FPGA, you can usually fix it in soft logic, but vendors don't like giving that out either.
For some smaller FPGAs without complex IPs, they are starting to open up their bitstream generation algorithms. Though bitstream generation is pretty trivial compared to synthesis and place & route.
It's only a first step though. Still needed: an Arduino-like IDE where you can click-and-run your design; examples that match the board you are using; examples to use peripherals(1) without having to resort to vendor IP blackboxes.
We're also eternally stuck with HDLs that are either crappy, niche-only, or add loads of complexity -- but I'm not really sure how bad this is for a beginner. Getting Verilog syntax right is probably only half bad if you have good IDE support.
(1) talking to an SDRAM is easy, getting DDR3 timing right on an ECP5 isn't. A simple "this is how you do it" example would be priceless, not being stuck between blackboxes from Lattice and Migen exception stacktraces.
You could certainly use a microcontroller to implement arbitrary digital (or even analog) logic within a circuit. You'll be limited by the CPU speed. The trick is to avoid interrupts, and spin the CPU in a tight poll loop instead. An Arduino Uno's MCU can run an instruction perhaps every 150ns on average. You could implement some simple logic that runs upwards of 1Mhz. If you use a cortex-m CPU, you could do fairly complex logic at several Mhz.
That's a silly way to use an MCU, though. You're supposed to use the peripherals to offload enough complexity from the CPU that you have plenty of cycles to implement your application logic in a straightforward, maintainable way.
You can absolutely compile Verilog to C using Verilator and run it on a microcontroller. The performance is abysmal, and it completely misses the point of using HDL, but it does work. :)
https://www.reddit.com/r/FPGA/comments/r86hod/running_verila...
Actually you can get the same experience with an FPGA if you pay for the FPGA development tools, maybe what you’re asking for is a low cost version of Quartus or similar tools. I would like it if that existed but I fear FPGA makers deliberately want to keep their tooling expensive and hard-to-learn to promote lock-in.