Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MicroFPGA – A coming revolution in small electronics (2019) [video]

youtube.com

Post reply on HN
Print view View original

31–40 of 57 posts

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#31

Post by metaphor »

jvanderbot wrote: post #24

Q for the community. FPGA seems to be used for three things: 1) Custom I/O or high performance interfaces that aren't widely standardized 2) Prototyping boards / processor cores 3) Blazing fast implementations of algorithms that are hard to run otherwise. Is that about right? If even close, (3) is very interesting to me for a variety of reasons. Is my understanding correct that this is a reasonable use of FPGAs and t…

I offer 3 different reasons why FPGAs might make sense to consider:

1. (general) application reconfigurability where the benefits of SRAM performance, integrated hard IP, fabric real estate, and/or cycle-accurate RTL control cannot be easily replaced by other roughly asymptotic solutions;

2. (general) offloading massively/embarassingly parallel compute architectures where commodity GPGPUs are either physically incompatible and/or power-wise too inefficient;

3. (enterprise) overall volume/performance/budget/schedule objectives fall short of the sort needed to justify pushing a bespoke ASIC design through process pipeline.

Relatively speaking, "blazing fast implementations of algorithms" is possible iff the compute bottleneck can be effectively parallelized; I'm not certain what was meant by "hard to run otherwise".

To put this into perspective, reliably clocking a non-trivial FPGA application at 200 MHz is objectively hard in a way that hobbyist types outside of the professional domain can't seem to understand (or arrogantly dismiss). And yet for the right class of problems, such an application may have the potential to put a GPGPU clocked in the GHz to shame on both compute throughput and power consumption fronts.

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#32

Post by FPGAhacker »

pclmulqdq wrote: post #11
metaphor wrote: post #9

This talk struck me as conflicting in a sort of have-your-cake-and-eat-it-too kind of way. The wrinkles part[1] summarizes a lot of what this individual is advocating. Paraphrasing (with equivalent liberal handwaving of details as the talk does): I want to write FPGA code like any other high-level programming language ( but quickly dismiss that the hard part of developing native HDL is in fact that it's fundamentally…

FPGA evangelists like this really need a reality check. Programming in RTL is not easy, and it's not really a skill that most people need, so it doesn't make a lot of sense as an educational tool. The "killer app" for hobbyist FPGAs might be some sort of "SoC builder" tool that lets you build a specific microcontroller around a few high-performance cores, and then program it like software. But don't worry. Since 2000…

Personally I think "programming" RTL is dead simple. It's so simple, in fact, that it's not even interesting. But I've been doing it forever so my perspective is skewed.

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#33

Post by FPGAhacker »

canada_dry wrote: post #26
pclmulqdq wrote: post #11

Earlier quoted context omitted.

FPGA evangelists like this really need a reality check. Programming in RTL is not easy, and it's not really a skill that most people need, so it doesn't make a lot of sense as an educational tool. The "killer app" for hobbyist FPGAs might be some sort of "SoC builder" tool that lets you build a specific microcontroller around a few high-performance cores, and then program it like software. But don't worry. Since 2000…

> Since 2000, mainstream FPGA programming has been right around the corner. As an avid technologist I dabble in everything from electronics to assembler. But, every time I try dipping my toe into FPGA programming I quickly retreat! The tools are too complex and the whole process has a learning curve that far out weigh using a stock CPU/SoC.

> The tools are too complex and the whole process has a learning curve that far out weigh using a stock CPU/SoC.

Sadly this is true, although the open source tools are gaining ground pretty quickly from what I understand. https://symbiflow.github.io/getting-started.html

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#34

Post by snvzz »

ozmaverick72 wrote: post #8

The talk mentioned a number of small flag boards. Can someone recommended one of them to get started playing with fpgas ?

Open synth/route stack supports Lattice iCE40 and ECP5 the best.

iCE40 are a relatively simple, cheap and easy to work with architecture with a focus on low power usage. iCESugar + nanoDLA (cheap sigrok-friendly logic analyzer) is a good cheap set to get started on FPGAs with. These are cheap on aliexpress.

ECP5 are much larger, much more complex and powerful enough to fit a whole computer (e.g. the minimig open Amiga implementation) in. I don't recommend going anywhere near this until you've already got started with iCE40, but a high-density and price-effective development board is the ULX3S.

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#35

Post by snvzz »

analog31 wrote: post #14
ozmaverick72 wrote: post #8

The talk mentioned a number of small flag boards. Can someone recommended one of them to get started playing with fpgas ?

Haven't gotten very far yet but TinyFpga BX was easy to get set up and running "LED blink" which is the hardware version of hello world. I've used microcontrollers since forever and want to expand my options.

I have one of these and love it, but unfortunately the tinyfpga team is MIA and getting the boards has been hard to impossible for a long time now.

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#36

Post by jvanderbot »

metaphor wrote: post #31
jvanderbot wrote: post #24

Q for the community. FPGA seems to be used for three things: 1) Custom I/O or high performance interfaces that aren't widely standardized 2) Prototyping boards / processor cores 3) Blazing fast implementations of algorithms that are hard to run otherwise. Is that about right? If even close, (3) is very interesting to me for a variety of reasons. Is my understanding correct that this is a reasonable use of FPGAs and t…

I offer 3 different reasons why FPGAs might make sense to consider: 1. (general) application reconfigurability where the benefits of SRAM performance, integrated hard IP, fabric real estate, and/or cycle-accurate RTL control cannot be easily replaced by other roughly asymptotic solutions; 2. (general) offloading massively/embarassingly parallel compute architectures where commodity GPGPUs are either physically incomp…

For "hard", I was implicitly referring to applications where existing compute throughput doesn't support the algorithm you want to run (which the example I was thinking of [1] is precisely case 2 you have)

1. https://ieeexplore.ieee.org/abstract/document/5747245 Implementation of pin point landing vision components in an FPGA system for NASA stuff

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#37

Post by swiley »

pclmulqdq wrote: post #11
metaphor wrote: post #9

This talk struck me as conflicting in a sort of have-your-cake-and-eat-it-too kind of way. The wrinkles part[1] summarizes a lot of what this individual is advocating. Paraphrasing (with equivalent liberal handwaving of details as the talk does): I want to write FPGA code like any other high-level programming language ( but quickly dismiss that the hard part of developing native HDL is in fact that it's fundamentally…

FPGA evangelists like this really need a reality check. Programming in RTL is not easy, and it's not really a skill that most people need, so it doesn't make a lot of sense as an educational tool. The "killer app" for hobbyist FPGAs might be some sort of "SoC builder" tool that lets you build a specific microcontroller around a few high-performance cores, and then program it like software. But don't worry. Since 2000…

Meh. HDL isn't that hard and there are good books on it. The main reason FPGA programming is unpopular is because the tools are pretty hideous. Icestorm makes things a lot better but it supports like 5 parts and they're not very powerful ones.

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#39

Post by pclmulqdq »

FPGAhacker wrote: post #32
pclmulqdq wrote: post #11

Earlier quoted context omitted.

FPGA evangelists like this really need a reality check. Programming in RTL is not easy, and it's not really a skill that most people need, so it doesn't make a lot of sense as an educational tool. The "killer app" for hobbyist FPGAs might be some sort of "SoC builder" tool that lets you build a specific microcontroller around a few high-performance cores, and then program it like software. But don't worry. Since 2000…

Personally I think "programming" RTL is dead simple. It's so simple, in fact, that it's not even interesting. But I've been doing it forever so my perspective is skewed.

I think you are thinking of different types of tasks. A lot of RTL is brainless, but if you are actually trying to compute with it, it can get tough.

A mediocre C++ programmer can write a (bad) hash table in C++ in a few hours. How fast can you give me one in Verilog?

Re: MicroFPGA – A coming revolution in small electronics (2019) [video]

#40

Post by g_p »

pclmulqdq wrote: post #13
g_p wrote: post #7

Earlier quoted context omitted.

> Anyone got stats on how FPGA ecosystems have fared vs. MCUs over chipageddon? No data I can offer as such, but anecdote from several suppliers who integrate some big name FPGAs into their products. They've seen supply dry up like other chips, causing several months of delays to lead times. It's not "zero supply", but a significant reduction in supply. The vendor-specific toolchains and supply chain security issues…

Bitstream encryption is okay, but someone still has yet to make an FPGA that is truly secure. As far as I know, bitstream encryption on the Xilinx Ultrascale+ devices has been broken, so there isn't a lot of protection there against sophisticated actors.

I've not had much experience with modern allegedly "secure" FPGAs, but the scenario I see here is if your synthesis tools get compromised by a bad update (or another attack), they could add a little bit of "side logic" to every design. Solarwinds style.

With encrypted output and what I understand to be no ability to carry out QA/evaluation on the bitstream (with encryption meaning binary comparisons shouldn't be meaningful), you can't really gain assurance that the output is as expected.

Of course you could argue that you compare the encrypted bitstream with your "final version", but this only works until you need to use the field programmable aspect to update something, and now you have to take a leap of faith and flash the bitstream, and hope your build environment is good, as there's no real way to check.

Post reply on HN