Xilinx FPGA Board for Arduino
seeedstudio.com
seeedstudio.com
[0] https://youtube.com/watch?v=swVuqG9-H0E
[1] https://github.com/github/dmca/search?utf8=&q=Xilinx&type=
They promised to clam down and update their policies after the education video takedown blew up in their face back in January, but they have yet to do update their policies so as far as I can see from their legal page (which is where they said they would post the updated policy).
As the saying goes. Once bitten, twice shy.
With CPU's the modern software engineer expects a new GCC/LLVM target, so we can have a consistent experience with one code base.
I get that.
I believe the market is shifting under the FPGA's faster than they realize. Sure they're going to have large corporate customers for a while using the xilinx proprietary IP cores, etc. But someone at some company is going to get a bonus for saving the company tons of money by modifying an open source core, so they can drop the cost of using the xilinx proprietary cores.
There are enough gates to do some interesting stuff without it getting overwhelming, and you can run a RiscV softcore.
https://www.cnx-software.com/2019/08/28/orangecrab-is-an-ope...
I think the challenge, along with the promise of low latency is what attracts people.
One of the big drawbacks of using an Arduino is that it is so limited in the number of modern devices it can access (USB 3, SATA, HDMI In or Out, etc).
To that end I think LiteX maybe the most intriguing thing I've seen this year if it catches on popularity. It's an SoC builder, which would allow for DIY SoC's (including using a RISC V core).
https://github.com/enjoy-digital/litex
I'm not saying it's guaranteed, but it's looking more and more possible that FPGA's using LiteX or similar technology could disrupt the embedded micro controller market particularly for the homebrew market. You can choose the CPU you want to code for with the interfaces you're using.
Also check out the current supported litex FPGA platforms:
https://docs.google.com/spreadsheets/d/1XTHfdYXuvwoYdPXm4M6q...
It seems like that's more about having a cheap desktop computer than doing electronics? But I already have a desktop computer.
It's hard to compare working with an HDL to working with a programming language like C; they are fundamentally different. The short answer to that question is that using an FPGA can lead to massive but situational performance increases. You can't use an FPGA for everything, but when you need it, you need it.
>testing then export designs into hardware
This is another common use case. Some designs can be tested on an FPGA before committing that design for production as an ASIC. There's also the case where you may need to reconfigure the hardware, so you can never truly commit to an ASIC, and continue using the FPGA.
Whatever you go with, as a beginner you're going to want a lot of help from pre-written software. The Arduino IDE and Wiring/Arduino standard API is a good example. The mistake I made with my first purchase was not making sure that a good audio library was available for the hardware I picked. (I might consider writing one for fun, but not in C++ since I don't have much experience in that language.) But it looks like Teensy has a nice audio library, and there are other projects that look intriguing like Bela and Axoloti.
I expect (speculating) that a similar rule would apply for an FPGA; it would only be appealing to most beginners if someone more experienced came up with an interesting design that makes use of an FPGA and documented it pretty well, so you're not starting from scratch.
For many projects, people choose something higher-end than an Arduino because their project requires more compute or memory than the 8-bit microcontroller in the Arduino can provide. Common issues:
- You need to do math with larger numbers (anything > 16 bits is really slow on the Arduino), or need to do lots of math.
- Your working data exceeds the ~2 kB of RAM.
- Your project's binary exceeds the ~32 kB of flash.
With that being said, the Raspberry Pi isn't necessarily the best candidate for every project that exceeds these constraints. The Pi is basically the cheapest possible board that includes a graphics card that can handle HD video, Ethernet, and WiFi. It also has a lot of RAM compared to other single-board computers. It is weaker for "real-time" applications like signal processing - if you need to do that sort of thing you might want to look into buying a BeagleBone Black, which has two "programmable real-time units" (PRUs), which are basically small auxiliary microcontrollers that can be used to handle the real-time work.
There are other cheaper/lower power parts in between the Arduino and the Raspberry Pi/Beaglebone level of complexity, but many of them require complicated tooling and libraries that might be difficult to use if you're not already pretty familiar with embedded development.
Again, I'm not saying it's going to happen. But people were making similar arguments about linux in 1996: "Windows just works." And very similar to linux, it dropped the barrier to entry for server programming. Either you had paid through the nose for Unix, or you were coding on NT, and your company was paying through the nose for the server licenses.
Don't get me wrong, I really like FPGAs. I genuinely think they're the coolest tools in embedded engineering, full stop. However, a big part of the allure is how incredibly arcane and niche they are.
Reprogramming them is not a chore at all anymore since you can write stuff for them at a much higher level of abstraction then you can for microcontrollers. Complexity only really starts once you start having issues with timing closure or are forced to implement an DDR SDRAM controller. This all heavily depends on the toolset you are using.
Isn't that the point of LiteX and Migen though? To reduce the barrier to entry in time and budget? Before the RPi came along SBC's were fairly expensive, and the RPi was only able to offer a product at that price because of scale.
And here we have an FPGA based video processing platform for only $350 produced in low-volume. https://hdmi2usb.tv/numato-opsis/
I'm not saying you're wrong, I just don't think your argument is as much of a slam-dunk that you think it is.
https://www.ti.com/product/TUSB9261
There's a purpose-specific part from TI that's probably incredibly well supported and easy to source. It instantly adds a little under $7 to the BOM at volume (yikes), and you're not even counting the hundreds of hours of engineering time that would go in to integrating it (double yikes). Trying to do it with an FPGA would be even worse in terms of cost and engineering time.
COTS products don't fulfill every use case, and never will.
I can see people using it just for the convenience factor - if you can perform update the FPGA by loading a new bitstream via the arduino or the ESP32 (assuming that's a thing you can do) over IP or zigbee or something, you could fix mistakes remotely. Handy if you were using it for e.g. ham radio and had it mounted in a box at the top of a radio tower, and didn't feel like making the climbs to adjust it.
Maybe for the SDR crowd?
The Arduino provides power supply and maybe low-speed peripherals like GPIO... (sarc)
Still awesome feature set and price point. I'm seriously thinking about using this standalone.
Looking at their example code it just seems so far removed from hardware that I am stuck scratching my head: https://github.com/sea-s7/spartan-edge-ioex/blob/master/exam...
> Typically you'd use an fpga as a dev tool to design an asic or maybe even use the fpga outright if it's fast enough at your task to make it worthwhile.
No way. FPGA's are extremely useful for low volume alternative to asics or tasks where the logic may have to change according to end use cases. They are found everywhere you need a quick bit of complex logic and don't want an asic or need some extreme form of flexibility.
It's better to have a slitghly worse hardware that you can actually program and use than something that requites the poster child of horrible proprietary software.
I'm playing with Zynq right now, and the tooling (Vivado + Xilinx SDK) is, yes, quite unstable and not always intuitive, but I can't imagine using anything else with such a device, just because of the amount of domain knowledge buried in this bunch of TCL scripts.
- Low-end: I'm designing a board, and I have one place where I need a little bit of digital logic, but putting a sufficiently capable microcontroller would be too expensive (in money or power budget), and there's no easily available cheap ASIC that does what I need. I put a small low-end FPGA in, and write a little bit of HDL to implement the logic I need.
- High end: I have a very specific computation that I want to perform with very low latency or high throughput, and I've determined that I can design digital logic that will perform better than a general purpose processor (often via massive parallelism that wouldn't work well on a GPU for some reason and/or extremely deep pipelining beyond what a CPU would do). Because performance is so important to me, I'm willing to pay a massive up-front development cost for the digital logic that lives on the FPGA and the software that integrates with it. However, my expected volume is still low enough that getting an ASIC made would be too expensive for my budget. Examples here include packet filtering, bioinformatics, various forms of signal processing, etc. I'll choose a high-end FPGA that meets the specific needs of my application.
- Extremely high end: Same as the above, but I expect to continue to make improvements and incremental changes to the digital logic after it's been deployed. Alternatively, I'm selling my board to customers who will employ their own hardware engineers to add their own digital logic to my high-level design. I'll probably choose a very high-end FPGA that exceeds my current needs to allow space for future changes.
None of the above are likely to apply to hobbyists, so most hobbyists who are developing for FPGAs are likely doing so just because they find it very interesting. The development process is much slower than it is if you're writing code for an ARM chip, and the tools are much more cumbersome, but the process of designing digital logic systems and then having a way to actually implement them can be interesting.
> None of the above are likely to apply to hobbyists, so most
> hobbyists who are developing for FPGAs are likely doing so
> just because they find it very interesting.
I see posts on HackerDay about FPGAs and think: "What am I missing?". I build robots as part of a hobby and was wondering where on earth they fit into that pipeline. Most of the things I build are either already solved within a single chip, or are easily solved with the addition of a small micro. Developing something using a HDL would be too extreme, even for me.
One thing that I think might be of interest in the future is when the cell count is such that we can process large neural networks, although I suspect they might always lag behind GPUs and/or TPUs.