Meh it’s a Xilinx part. They are too lawyer heavy for my liking, issuing takedowns on educational vids [0] and file DMCA takedowns of reverse engineering [1]
It's not quite ready yet, but the Orangecrab looks really exciting- 85K LUTs, all IO broken out, feather form factor, 8gb RAM, Lipo connector, open source toolchain.
There are enough gates to do some interesting stuff without it getting overwhelming, and you can run a RiscV softcore.
I looked at the DCMA takedowns and they were all for either license files, or encryption keys. I'm not sure what you expect a company that sells software to do in these circumstances. This very different from the sort of reverse engineering that e.g. project X-Ray is doing.
Who Xilinx choose to set their lawyers on is up to Xilinx.
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).
I think you have an excellent point. Why bother with a company if they sick their lawyers on hobbyists and experimenters?
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.
I don't understand why people believe that the "year of the maker FPGA" is ever going to happen. An FPGA is by its very nature a technology that many embedded engineers (let alone hobbyist maker types) will never take advantage of in earnest. I'd imagine that if you're developing hardware that requires an FPGA, odds are high that you don't need or want an Arduino bolt-on.
Right now, the homebrew electronics industry is buzzing like linux and open source was in 1996. PCB design and manufacturing has been opened up to millions by cost reductions and open source software in the past few years. FPGA development is following suit as well.
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).
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:
You are ignoring price point. Small FPGA board from Digilent costs as much as Raspberry Pi 4 4 GB. Development on Raspberry Pi is much more convenient, it is powerful and it already has decent CSI-2, 4K HDMI, Ethernet. Comparable FPGA board goes for hundreds $/€. Because decent CSI-2 with high frame rate and resolution as well as 4K HDMI need decent FPGA with transceivers. Add long hardware development cycles and this gets really boring really fast for most hobbyists.
Is that because the FPGA boards aren't really mass produced like the RPi is? Could you imagine a world where if FPGA's get popular in the electronics market it could change? Could you imagine what might happen if a cheap FPGA platform came in to the market like the RPi did for SBC's?
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.
It's largely because an FPGA is inferior to a microcontroller in many common use cases; they truly are a niche tool. They are nowhere near as flexible as a microcontroller is, and reprogramming them for a different purpose is a huge investment from a development standpoint. When you try to alleviate these issues by pre-canning a microcontroller with configurable peripherals, the resulting FPGA configuration will get trounced by a microcontroller in both performance AND ease-of-use.
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.
>> They are nowhere near as flexible as a microcontroller is, and reprogramming them for a different purpose is a huge investment from a development standpoint.
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.
FPGA are WAY more flexible then a microcontroller is. You can literally just use your FPGA as a microcontroller if you want.
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.
I'm just getting started on electronics for an audio project, but the Arduino setup of compiling code on my regular computer and uploading it over USB to firmware seems pretty nice? Since I'm never going to connect it to the Internet or even a monitor, why does Ethernet or HDMI matter? Let alone 4K HDMI.
It seems like that's more about having a cheap desktop computer than doing electronics? But I already have a desktop computer.
If you're going to do serious audio signals processing, you're probably going to very quickly find out that an 8bit Arduino and the Arduino environment are nowhere near powerful enough for your needs. If you really stick with it, you'll upgrade to something significantly more powerful (both hardware and tooling wise). If you start to push the limits of a 32bit microcontroller or DSP, but are still sensitive to price/power consumption/footprint/etc, then you will truly understand what the need for an FPGA is. That's my point; you as an embedded beginner (which is what most of the "maker" market is) are multiple revelations away from even beginning to understand why you would want to use an FPGA, let alone know how to work with one.
Oh sure, I don't know why anyone would start with an 8-bit Arduino considering that much faster 32-bit CPU's seem to be about the same price?
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.
I've done three years of an electronic engineering degree with a digital design on FPGAs course and I'm still not entirely sure why one would want to use an FPGA for anything - am I right in guessing that what you write in HDL for an FPGA will be faster than what you write in C? Or do you use the FPGA for testing then export designs into hardware?
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.
You don't need to do your development on the Raspberry Pi, and I wouldn't recommend doing so. It's pretty easy to develop code on your desktop and push it to your Pi via SSH/SCP/etc. You might also be able to set up a connection to push via USB but that might end up being more complicated anyway.
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.
Yeah, I meant that more genetically as something that works with the Arduino IDE, certainly not an 8-bit processor. I'm considering a higher-end Teensy or PocketBeagle. Does Raspberry Pi have any particular advantages for audio compared to them?
The Arduino is limited in regards to capabilities because it's a heavy ecosystem (usually) running on a wildly anemic device; you're out of your mind if you're expecting HDMI enc/dec, USB host controller, etc. on an 8-bit microcontroller. The usefulness of LiteX is severely mitigated by just using more powerful microcontrollers coupled with purpose-specific parts.
So explain to me why the RPi doesn't have SATA on board directly then, rather than forcing one to use some kludegy USB to SATA interface. Surely there are purpose built parts for it.
Because the RPi is a budget SBC where the most common use case is running it off an SD card, and they apparently didn't consider a SATA controller a priority feature. For many users (maybe even a large majority), that assumption was correct.
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 think it's wishful thinking. I loved the class I had in undergrad where we worked with them extensively. One of my favorite projects was making Pong on an FPGA --- complete with a direct VGA output. I've yearned for a project that would let me use one again, but I just haven't found anything that requires that kind of performance.
>I'd imagine that if you're developing hardware that requires an FPGA, odds are high that you don't need or want an Arduino bolt-on.
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.
Honestly, I see benefits. For one, I have done dev work in higher level languages since I started. Learning and practicing bit level operations has been super interesting, and a great experience. I've gotten pretty good at FSM's, had to learn pipe-lining, and now have an overall better grasp of how the computer I'm writing for actually works.
I think the challenge, along with the promise of low latency is what attracts people.
FPGAs are pretty amazing for all kinds of signal processing, and that's what I use them for pretty extensively in my hobbies, but I don't really know how prevalent that is in the Maker community (especially beyond a level where you could use DSPs instead).
I bought a virtex 5 board to fuck around with just a few weeks ago. I probably won't do much at all with it that I couldn't do with a boring old microcontroller but I'm having a blast. Maybe it truly is the year.
A little weird to design this board as an Arduino shield when both of the parts on the board (the FPGA and the ESP32) are dramatically more powerful than the microcontroller on the host Arduino board.
I think the point is that the FPGA can handle very high speed IO in hardware, the ESP32 can host the application software and handle the communications.
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.
Well... medium speed I/O. "High speed" in an FPGA context would imply a 5+ Gbit SERDES, which the Spartan-7 doesn't have and the connectors on this board wouldn't support anyway.
Think of it as an ESP32 + FPGA with the arduino as a bag on the side providing features not available to the other two (e.g. power, standardized IDE, etc...)
Can someone explain the appeal of this to me? I love playing with fpgas but if you're not working in an hdl then what is the value? 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. By issuing commands via arduino scratch code, you toss all practical value out the window as far as I can tell.
> 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.
Yeah this seems pretty useless to me. Controlling pins on an FPGA from a microcontroller... Why not just control the pins on the microcontroller directly?
I wish they had used something like the lattice ice40.
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.
As someone who has had to walk through broken glass with Xilinx toolchain I can garantee that you do not want any tool/utility created or 'maintained' by this company.
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.
I've been hearing about FPGAs for the last few years or so, what would be the benefit to using one over something like a Raspberry Pi? What's the killer application?
- 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.
Thank you for your explanation. I guess your last point is why I thought I was missing something:
> 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.
[0] https://youtube.com/watch?v=swVuqG9-H0E
[1] https://github.com/github/dmca/search?utf8=&q=Xilinx&type=