7 ms·
Maybe unrelated, but I must say it again: we need an arduino for the fpga world.
by marcodiego 4y ago
Maybe unrelated, but I must say it again: we need an arduino for the fpga world.
- worldsayshi 4y agoThis feels like a dump question but what is stopping the Arduino from being used as a fgpa?
- eric__cartman 4y agoYou can't emulate a real FPGA with a microcontroller
- guhidalg 4y agoThat’s true but I think that’s not the only reason. Programming an FPGA isn’t as simple as writing and deploying compiled code, you have to write in a hardware specification language. 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.
- rowanG077 4y agoYosys and nextpnr exists and work pretty well for a lot of use cases. Only some FPGAs and vendors are supported but the experience is literally light years ahead of vendor tooling.
- marcodiego 4y agoI think it is possible since you could load an sketch that emulates a fpga. Nevertheless it would surely be inconvenient. Probably performance would be sub-par.
- sgtnoodle 4y agoYou can emulate anything on a microcontroller if you're determined enough. It just won't run as fast as you might want. 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.
- duskwuff 4y ago> You can emulate anything on a microcontroller if you're determined enough. It just won't run as fast as you might want. 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_verilated_verilog_on_a_microcontroller/ https://www.reddit.com/r/FPGA/comments/r86hod/running_verila...
- stjohnswarts 4y agoIt's not dumb you're just a little ignorant of the advantages of having dedicated hardware for an FPGA but it reminds me of "would you download a car?" :) . You can emulate an FPGA on the arduino (a really small fpga) but it would be so slow that it would be useless. Imagine simulating a Video Card on your PC, it can be done, but it would be 1000-100000x (more?) slower than the actual GPU.
- jmole 4y agoi think what you mean here is, we need a better IDE for the fpga world. 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.
- teamonkey 4y ago> building a simple hardware dev board is a straightforward exercise. 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.
- trotFunky 4y agoWell, there's an Arduino FPGA board : the MKR Vidor 4000[0] 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 https://store.arduino.cc/products/arduino-mkr-vidor-4000
- duskwuff 4y ago> Well, there's an Arduino FPGA board : the 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-quartus-vhdl 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.
- trotFunky 4y agoThanks for bringing more details into light ! As I've said I don't know much about the space and sadly suspected that it wouldn't be great, but not to this degree. It's a bit sad and it's not the "easy solution" that would have made it an easy choice for me if I were to tinker with FPGAs. Not that you have an answer, but it makes me wonder what is the target audience for this board ?
- duskwuff 4y ago> 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.
- ThrowawayR2 4y agoIn what way? The hard part of using FPGAs is all the computer engineering background necessary to design and debug circuits. The janky IDEs are really the least of the hobbyist's problems and cheap student/hobbyist boards (e.g. Digilent Arty series) have been available for years.
- MisterTea 4y agoWe need sane open source fpga tool chains that can generalize building bitstreams for multiple vendor fpga's. As it stands the idea of programming them isn't that hard (well, to me), it's the damn tooling that is an ugly vendor created and maintained barrier to entry. 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.
- Lramseyer 4y agoOne of the difficulties of open sourcing bitstream generation of an FPGA is not the fabric itself, but all of the other IPs on the chip. Things like PCIe, Ethernet, memory controllers, SerDes and whatnot are often licensed from external vendors who don't want their register maps out in the open. Some FPGA vendors give you a simulation model, but I'm pretty sure you have to sign an NDA. 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.
- pabs3 4y agoHave you looked at F4PGA? They are working on exactly that. https://f4pga.org/ https://f4pga.org/
- joshka 4y agoRather than Arduino, something by the raspberry pi foundation might hit the spot and make this sort of thing ubiquitous. Perhaps call it the "Raspberry Phi"?
- moring 4y agoI found the open-soruce toolchain to be a good first step into that direction, that is, not having to jump through hoops to get the vendor toolchain to work. 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.