[HN Gopher] FPGAs Need a New Future
___________________________________________________________________
FPGAs Need a New Future
Author : thawawaycold
Score : 228 points
Date : 2025-12-19 10:29 UTC (4 days ago)
(HTM) web link (www.allaboutcircuits.com)
(TXT) w3m dump (www.allaboutcircuits.com)
| checker659 wrote:
| Cost is also such a big issue.
| fleventynine wrote:
| There are some reasonably affordable models like
| https://www.lcsc.com/product-detail/C5272996.html that are
| powerful enough for many tasks.
| jauntywundrkind wrote:
| Making FPGA's actually available (without encumbering stacks)
| would be so great. Companies IMO do better when they stop
| operating from within their moat & this would be such the amazing
| use case to lend support for that hypothesis.
|
| Gowin and Efinix, like Lattice, have some very interesting new
| FPGAs, that they've innovated hard on, but which still are only
| so-so available.
|
| Particularly with AI about, having open source stacks really
| should be a major door opening function. There could be such an
| OpenROAD type moment for FPGAs!
| omneity wrote:
| If performant FPGAs were more accessible we'd be able to download
| models directly into custom silicon, locally, and unlock
| innovation in inference hardware optimizations. The highest grade
| FPGAs also have HBM memory and are competitive (on paper) to
| GPUs. To my understanding this would be a rough hobbyist version
| of what Cerebras and Groq are doing with their LPUs.
|
| Unlikely this will ever happen but one can always dream.
| 15155 wrote:
| > highest grade FPGAs also have HBM memory
|
| The three SKUs between Xilinx and Altera that had HBM are no
| longer manufactured because Samsung Aquabolt was discontinued.
| rfv6723 wrote:
| FPGA for AI only makes sense when machine learning had diverse
| model architectures.
|
| After Transformer took over AI, FPGA for AI is totally dead
| now. Because Transformer is all about math matrix calculation,
| ASIC is the solution.
|
| Modern Datacenter GPU is nearly AISC now.
| KeplerBoy wrote:
| Yes, if you're doing what everyone else is doing you can just
| use tensor cores and libraries which optimize for that.
|
| Contrarily if you're doing something that doesn't map that
| well to tensor cores you have a problem: every generation a
| larger portion of the die is devoted to low/mixed precision
| mma operations. Maybe FGPAs can find a niche that is
| underserved by current GPUs, but I doubt it. Writing a
| cuda/hip/kokkos kernel is just soo much cheaper and
| accessible than vhdl it's not even funny.
|
| AMD needs to invest in that: Let me write a small FPGA kernel
| in line in a python script, compile it instantly and let me
| pipe numpy arrays into that (similar to cupy rawkernels). If
| that workflow works and let's me iterate fast, I could be
| convinced to get deeper into it.
| imtringued wrote:
| The primary niche of FPGAs is low latency, determinism and
| low power consumption. Basically what if you needed an MCU,
| or many MCUs but the ones in the market don't have enough
| processing power?
|
| The Versal AI Edge line is very power efficient compared to
| trying to achieve the same number of FLOPs using a Ryzen
| based CPU.
| rcxdude wrote:
| FPGA toolchains certainly could do with being pulled out of the
| gutter but I don't think that alone will lead to much of a
| renaissance for them. Almost definitionally they're for niches:
| applications which need something weird in hardware but aren't
| big enough to demand dedicated silicon, because the flexibility
| of FPGAs comes at a big cost in die area (read:price), power, and
| speed.
| anondawg55 wrote:
| No. FPGAs already have a future. You just don't know about it
| yet.
| mgilroy wrote:
| The issue with the software team using an FPGA is that software
| developers generally aren't very good at doing things in
| parallel. They generally do a poor job in implementing hardware.
| I previously taught undergraduates VHDL, the software students
| generally struggles with the dealing with things running in
| parallel.
|
| VHDL and Verilog are used because they are excellent languages to
| describe hardware. The tools don't really hold anyone back. Lack
| of training or understanding might.
|
| Consistently the issue with FPGA development for many years was
| that by the time you could get your hands on the latest devices,
| general purpose CPUs were good enough. The reality is that if you
| are going to build a custom piece of hardware then you are going
| to have to write the driver's and code yourself. It's achievable,
| however, it requires more skill than pure software programming.
|
| Again, thanks to low power an slow cost arm processors a class of
| problems previously handled by FPGAs have been picked up by cheap
| but fast processors.
|
| The reality is that for major markets custom hardware tends to
| win as you can make it smaller, faster and cheaper. The
| probability is someone will have built and tested it on an FPGA
| first.
| j-pb wrote:
| VHDL is ok, Verilog is a sin.
|
| The issue isn't the languages, it's the horrible tooling around
| them. I'm not going to install a multi GB proprietary IDE that
| needs a GUI for everything and doesn't operate with any of my
| existing tools. An IDE that costs money, even though I already
| bought the hardware. Or requires an NDA. F** that.
|
| I want to be able to do `cargo add risc-v` if I need a small
| cpu IP, and not sacrifice a goat.
| blackguardx wrote:
| You can pretty much do everything in Vivado from the command
| line as long as you know Tcl...
|
| Also, modern Verilog (AKA Systemverilog) fixes a bunch of the
| issues you might have had. There isn't much advantage to VHDL
| these days unless perhaps you are in Europe or work in
| certain US defense companies.
| exmadscientist wrote:
| The main advantage to VHDL is the style of thinking it
| enforces. If you write your Verilog or SystemVerilog like
| it's VHDL, everything works great. If you write your VHDL
| like it's Verilog, you'll get piles of synthesis errors...
| and many of them will be real problems.
|
| So if you learn VHDL first, you'll be on a solid footing.
| blackguardx wrote:
| I think this can just be summarized to "write any HDL
| like you are modeling real hardware." Both VHDL and
| Systemverilog were primarily intended for validation and
| synthesis is a second class citizen.
| pclmulqdq wrote:
| There is a trend among programmers to assume that
| everything supported by the syntax can be done. This is
| not even true in C++, but it's something people think. If
| you are writing synthesizable SystemVerilog, only a small
| subset of the language used in a particular set of ways
| works. You have to resist the urge to get too clever (in
| some ways, but in other ways you can get extremely clever
| with it).
| d_tr wrote:
| I thought that if you have some idea about how hardware
| works, it is kind of more or less obvious whether
| something is synthesizable or not.
| imtringued wrote:
| I haven't learned Verilog, only VHDL and even that with
| the explicit <register>_ff <= <register_nxt> pattern when
| I need flips flops and I never felt like there is
| anything difficult about VHDL
|
| Is the North American insistence on teaching Verilog
| what's setting up students for failure since Verilog
| looks a bit more like a sequential programming language
| at first glance?
| blackguardx wrote:
| VHDL is based on Ada, so it also inherits from sequential
| programming models.
| Cadwhisker wrote:
| # Here's the general flow for Vivado TCL projects that
| takes you from source code to a bit-file with no
| interaction. Read UG835 for details.
|
| create_project -in_memory -part ${PART}
|
| set_property target_language VHDL [ current_project ]
|
| read_vhdl "my_hdl_file.vhd"
|
| synth_design -top my_hdl_top_module_name -part ${PART}
|
| opt_design
|
| place_design
|
| route_design
|
| check_timing -file my_timing.txt
|
| report_utilization -file my_util.txt
|
| write_checkpoint my_routed_design.dcp
|
| write_bitstream my_bitfile.bit
| tverbeure wrote:
| Or you could do the right thing, ignore the GUI for 99% of
| what you're doing, and treat the FPGA tools as command line
| tools that are invoked by running "make"...
| pclmulqdq wrote:
| This is how most FPGA users interact with vivado/quartus
| these days.
| tverbeure wrote:
| One really wonders when reading some of the comments
| here...
| pclmulqdq wrote:
| I should have said "most _professional_ FPGA users"
| because I assume many people here who don't know this
| (including the author of the article) are not.
| halfdanwhitshrt wrote:
| Any good guides you'd recommend to get started? Also does
| this workflow work with the cheap Chinese FPGAs available
| on aliexpress (tang nano, etc)? I always wanted to try out
| FPGAs again and I prefer to work from command line when
| possible.
| VonTum wrote:
| Well really, the language _is_ the difficulty of much of
| hardware design, both Verilog and VHDL are languages that
| were designed for simulation of hardware, and not synthesis
| of hardware. Both languages have of similar-but-not-quite
| ways of writing things, like blocking/nonblocking assigns
| causing incorrect behavior that's incredibly difficult to
| spot on the waveform, not being exhaustive in assigns in
| always blocks causing latches, maybe-synthesizeable for
| loops, etc. Most of this comes from their paradigm of an
| event loop, handling all events and the events that those
| events trigger, etc, until all are done, and advancing time
| until the next event. They simulate how the internal state of
| a chip changes every clock cycle, but not to actually do the
| designing of said chip itself.
|
| I'm tooting my own horn with this, as I'm building my own
| language for doing the actual designing. It's called SUS.
|
| Simple things look pretty much like C: module
| add : int#(FROM:-8, TO: 8) a, int#(FROM: 2,
| TO: 20) b -> int c { c = a+b }
|
| It automatically compensates for pipelining registers you
| add, and allows you to use this pipelining information in the
| type system.
|
| It's a very young language, but me, a few of my colleagues,
| and some researchers in another university are already using
| it. Check it out => https://github.com/pc2/sus-compiler
| kevin_thibedeau wrote:
| VHDL was designed for specification. Verilog is the one
| with the warts from its simulator heritage.
| oscillonoscope wrote:
| Language really isn't the difficulty. That's why there's a
| thousand alt-HDLs that have been used for little more than
| blinking LEDs.
| makestuff wrote:
| Yeah I agree it is a lack of understanding on how to use the
| tools. The main issue I ran into in my undergrad FPGA class as
| a CS student was a lack of understanding on how to use the IDE.
| We jumped right into trying to get something running on the
| board instead of taking time to get everything set up. IMO it
| would have been way easier if my class used an IDE that was as
| simple as Arduino instead of everyone trying to run a virtual
| machine on their macbooks to run Quartus Prime.
| checker659 wrote:
| > software developers generally aren't very good at doing
| things in parallel
|
| If only hardware people would stop stereotyping. Also, do you
| guys not use use formal tools (BMC etc) now? Who do you think
| wrote those tools? Heck all the EDA stuff was designed by
| software people.
|
| I just can't with the gatekeeping.
|
| (Btw, this frustration isn't just pointed at you. I find this
| sentiment being parroted allover /r/FPGA on reddit and
| elsewhere. It's damn frustrating to say the least. Also, the
| worst thing is all the hardware folks only know C so they think
| all programming is imperative. VDHL is Ada for crying out
| loud.)
| 0xpgm wrote:
| And their cited example was students. I think students would
| struggle at something new until they 'get it'. Would a
| software developer who does FPGA development professionally
| struggle more than, say, a hardware engineer?
| lesuorac wrote:
| Sure but most of software development is about running
| single-core workflows on top of a parallel environment so
| the experience of a SWE is very heavily single-threaded.
|
| The ever so popular JS is explicitly singlely threaded.
|
| The default way of programming is with code on individual
| lines and when you run a debugger you step from one line to
| the next. This is not how code actually runs within a
| pipelined CPU though.
| mgilroy wrote:
| I was very specific in using the word generally. I taught a
| mixture of computer science and electronic engineering
| students. About three to four times more electronic students
| were competent for every computer science student over the
| years I taught.
|
| It's not a case of just stating computer scientist weren't
| capable of doing it. They struggled with the parallelism and
| struggled with the optimisations and placements when you had
| to make physical connections on chips.
|
| I'm well aware it's mostly going to be computer scientists
| writing the tools we use.
|
| For those that want FPGAs to take off like the Arduino
| platform, I agree. I'd love it. However, it isn't the tooling
| that's holding it back. The reality is it is that cheaper,
| faster and easier solutions already exist. Why would you use
| an FPGA?
| 15155 wrote:
| > EDA stuff was designed by software people.
|
| No - EDA software is built by hardware experts moonlighting
| as software engineers, which is partly why it is so obtuse.
| gnull wrote:
| > VHDL and Verilog are used because they are excellent
| languages to describe hardware.
|
| Maybe they were in the 80. In 2025, language design has moved
| ahead quite a lot, you can't be saying that seriously.
|
| Have a look at how clash-lang does it. It uses functional
| paradigm, which is much more suitable for circuits than pseudo-
| pricedural style of verilog. You can also parameterize modules
| by modules, not just by bitness. Take a functional programmer,
| hive him clash and he'll have no problems doing things in
| parallel.
|
| Back when I was a systems programmer, I tried learning system
| verilog. Had zero conceptual difficulty, but I just couldn't
| justify to myself why I should spend my time on something so
| outdated and badly designed. Hardware designers at my company
| at the time were on the other hand ok with verilog because they
| haven't seen any programming languages other than C and Python,
| and had no expectations.
| nospice wrote:
| To folks who wax lyrical about FPGAs: _why_ do they need a
| future?
|
| I agree with another commenter: I think there are parallels to
| "the bitter lesson" here. There's little reason for specialized
| solutions when increasingly capable general-purpose platforms are
| getting faster, cheaper, and more energy efficient with every
| passing month. Another software engineering analogy is that you
| almost never need to write in assembly because higher-level
| languages are pretty amazing. Don't get me wrong, when you need
| assembly, you need assembly. But I'm not wishing for an assembly
| programming renaissance, because what would be the point of that?
|
| FPGAs were a niche solution when they first came out, and they're
| arguably even more niche now. Most people don't need to learn
| about them and we don't need to make them ubiquitous and cheap.
| tyami94 wrote:
| I can't say I agree with you here, if anything FPGAs and
| general purpose microprocessors go hand in hand. It would be an
| absolute game changer to be able to literally download hardware
| acceleration for a new video codec or encryption algorithm.
| Currently this is all handled by fixed function silicon which
| rapidly becomes obsolete. AV1 support is only just now
| appearing in mainstream chips after almost 8 years, and soon
| AV2 will be out and the cycle will repeat.
|
| This is such a severe problem that even now, (20+ year old)
| H.264 is the only codec that you can safely assume every end-
| user will be able to play, and H.264 consumes 2x (if not more)
| bandwidth compared to modern codecs at the same perceived image
| quality. There are still large subsets of users that cannot
| play any codecs newer than this without falling back to (heavy
| and power intensive) software decoding. Being able to simply
| load a new video codec into hardware would be revolutionary,
| and that's only one possible use case.
| ThrowawayR2 wrote:
| And you think that a downloaded codec on an FPGA would
| perform anywhere close to custom silicon? Because it won't;
| configurability comes at a steep cost.
| checker659 wrote:
| FPGAs are more like CGRAs these days. With the right DSP
| units, it could absolutely be competitive with custom
| silicon.
| nospice wrote:
| But _why_ would it be amazing? The alternative right now is
| that you do it in software and just dedicate a couple of
| cores to the task (or even just put in a separate $2 chip to
| run the decoder).
|
| Like, I get the aesthetic appeal, and I accept that there is
| a small subset of uses where an FPGA really makes a
| difference. But in the general case, it's a bit like getting
| upset at people for using an MCU when a 555 timer would do.
| Sure, except doing it the "right" way is actually slower,
| more expensive, and less flexible, so why bother?
| fennecbutt wrote:
| Battery powered or thermally constrained devices.
| nospice wrote:
| ...which are playing back video, so they're likely
| blowing most of their power budget on the display and on
| radio. I guess my threshold of "amazing" is different.
| Again, I'm not denying some incremental utility in
| specialized uses, but most of the time, it just doesn't
| seem to be worth the pain - especially since nothing
| about the implementation will be portable or maintainable
| in the long haul.
|
| In the same vein, no one is writing a smartwatch software
| stack in 100% bare-metal assembly, although in the hands
| of a capable developer, I'm sure it could prolong battery
| life.
| pjc50 wrote:
| You definitely don't want an FPGA if those are your
| concerns.
| pjc50 wrote:
| > It would be an absolute game changer to be able to
| literally download hardware acceleration for a new video
| codec or encryption algorithm
|
| That relies on "FPGAs everywhere", which is much further out
| than "GPUs everywhere".
|
| I'm not sure where the state of the art is on this, but given
| the way that codecs work - bitstream splitting into tiles,
| each of which is numerically heavy but can be handled
| separately - how is development of hybrid codecs, where the
| GPU does the heavy lifting using its general purpose cores
| rather than fixed function decoder pipeline?
| exmadscientist wrote:
| FPGAs need their "Arduino moment". There have been so, so, so
| many projects where I've wanted just a little bit of moderately-
| complicated glue logic. Something pretty easy to dash off in VHDL
| or whatever. But the damn things require so much support
| infrastructure: they're complicated to put down on boards,
| they're complicated to load bitstreams in to, they're complicated
| to _build_ those bitstreams for, and they 're complicated to
| manage the software projects for.
|
| As soon as they reach the point where it's as easy to put down an
| FPGA as it is an old STM32 or whatever, they'll get a lot more
| interesting.
| timthorn wrote:
| Sounds like a PLD might suit your usecase? Simpler than an
| FPGA, programmed like an EEPROM, perfect for glue logic.
| exmadscientist wrote:
| "Programmed like an EEPROM" is part of the problem, any
| system that needs more than one piece of firmware to be
| wrangled during the assembly/bringup process is asking for
| pain.
|
| But, really, no one cares what's inside the box. CPLD or
| FPGA, they're all about the same. The available PLDs are
| still not really acceptable. There's a bunch of 5V dinosaurs
| that the manufacturers would obviously love to axe, and a few
| tiny little micro-BGA things where you've got to be buying
| 100k to even submit a documentation bug report. Not much for
| stuff in the middle.
| javawizard wrote:
| I wish CPLDs were more well known in the common vernacular.
|
| The industry draws a distinction between CPLDs and FPGAs, and
| rightly so, but most "Arduino-level" hobbyists think "I want
| something I can program so that it acts like such-and-such a
| circuit, I know, I need an FPGA!" when what they probably
| want is what the professional world would call a CPLD - and
| the distinction in terminology between the two does more to
| confuse than to clarify.
|
| I don't know how to fix this; it'd be lovely if the two
| followed convergent paths, with FPGAs gaining on-board
| storage and the line between them blurring. Or maybe we need
| a common term that encompasses both. ("Programmable logic
| device" is technically that, but no-one knows that.)
|
| Anyway. CPLDs are neat.
| bee_rider wrote:
| I don't know anything about this (other than doing mediocre
| in some undergrad Verilog classes one million years ago).
| Wikipedia seems to call FPGAs a type of PLD. Of course,
| everybody has heard of FPGAs; is it right to think they've
| sort of branched off, become their own thing, and eclipsed
| their superset?
| tverbeure wrote:
| I don't see how CPLDs solve anything?
|
| You write RTL for them just like you do for FPGAs, you need
| to configure them as well. The only major benefit is that
| they don't have a delay between power up and logic active?
| But that's not something that would make a difference for
| most people.
|
| CPLDs are also a dying breed and being replaced with FPGAs
| that have parallel on-board flash to allow fast
| configuration after power up. (e.g. MAX10)
| tverbeure wrote:
| The strong point of FPGAs is their versatility. If you wanted
| an FPGA that would be easy to put on a board, you'd have to
| drop support for multiple voltage rails and thus multiple IO
| standards, which is exactly what you don't want to lose.
|
| Building bitstreams is IMO not complicated. (I just copy a
| Makefile from a previous project and go from there.)
|
| Loading them is a matter of plugging in a JTAG cable and typing
| "make program".
|
| I don't know what you mean with the "manage SW projects for"?
| exmadscientist wrote:
| > you'd have to drop support for multiple voltage rails and
| thus multiple IO standards, which is exactly what you don't
| want to lose.
|
| Yes? Yes it is? 9 times out of 10, my entire board is
| LVCMOS33. I would _love_ to have the option to drop all of
| the power rail complexity in a simplified series of parts.
|
| Sometimes you need maximum I/O speed. Sometimes you need
| maximum I/O flexibility. Sometimes you need processing
| horsepower. And sometimes you need the certainty of hardware
| timing, which you get on a gate array and don't get any time
| there's a processor involved. Or, often, what I actually need
| is just a little bit of weird logic that's asynchronous, but
| too hard to do with the remnants of 74-series or 4000-series
| logic that are still available.
|
| > Building bitstreams is IMO not complicated. (I just copy a
| Makefile from a previous project and go from there.)
|
| It is not complicated for people who have spent a long time
| learning and who have past designs they can copy from. (I
| have a few of those myself.) It is nasty to explain to a new
| person and very nasty to explain well enough to reproduce in
| the future without me around.
|
| > Loading them is a matter of plugging in a JTAG cable and
| typing "make program".
|
| Yes, for you on the bench. Now program them into a product on
| an assembly line. Of course it is _possible_. It is still a
| giant headache, and quite a bit worse than just dealing with
| an MCU.
|
| > I don't know what you mean with the "manage SW projects
| for"?
|
| Two words: Xilinx ISE.
| exmadscientist wrote:
| > often, what I actually need is just a little bit of weird
| logic that's asynchronous
|
| As a concrete example of this: two weeks ago I wanted a
| 21-input OR gate. It would have been _wonderful_ if I could
| spend a little bit of money, buy a programmable thing in a
| 24-pin package, put it down, figure out some way to get the
| bitstream in (this is never pleasant in medium-volume
| manufacturing, so it 's not like we're going to solve it
| now), and get my gate function that is literally _one line
| of HDL_. One. Line.
|
| As it was, a 21-input OR gate is so much work in 74-series
| logic that I abandoned that whole thing and we did the
| bigger-picture job in a different, worse, way.
| tverbeure wrote:
| The device that you were looking was not an FPGA but a
| GAL22V10L.
| exmadscientist wrote:
| No, it wasn't. Those are mostly available in PLCC and DIP
| packages and even if you can get the SOIC/TSSOP versions
| they still cost $1.20 each at 10k volume. That's flat-out
| unacceptable for 99% of the things I do. The _entire rest
| of the board_ I was talking about was $4.60. Processor
| included. $1.20 is not going to fly.
| tverbeure wrote:
| "Reduces use case and requirements to something
| impossibly niche and low volume then yells at the
| clouds."
|
| Anyway, just tie the output of 21 emitter followers
| together, add a resistor and - tadaaa - 21 input OR!
| exmadscientist wrote:
| Hey, that was my problem from last week. And, yes, I
| agree with you -- it was best solved another way.
|
| But please don't complain when I give concrete examples
| of things I'd like to do but couldn't. (And please do
| recognize that there was a lot more context to the mess
| than just "I need an OR gate", but no one cares about the
| _real_ gory details.)
| mitthrowaway2 wrote:
| If only someone could make a single part that is very
| versatile, so that it could get production economies of
| scale while solving all the thousands of different random
| problems various people might have, whether they need a
| 21-input OR or something else. Like an array of gates,
| but field-programmable!
|
| (That's a pretty steep price target even for a small FPGA
| though. With 16 pins maybe, but with 25?)
| summa_tech wrote:
| Would a SLG46880 work for you? It has 28 GPIOs, enough
| LUTs to make a 21-input OR gate, runs off 2.3-5.5V (two
| VCCIO partitions, but you can tie them together). It
| costs like a buck in 5k quantities - they used to be much
| cheaper when you bought them directly from Silego, but
| now that they've been acquired the price has been
| _improved_.
|
| https://www.renesas.com/en/products/slg46880
| 15155 wrote:
| > and quite a bit worse than just dealing with an MCU.
|
| Unless you're using some kind of USB DFU mode (which is
| annoying on assembly lines), SWD-based flashing of an MCU
| is substantially more complicated than the JTAG sequences
| that some internal-flash FPGAs use for programming..
|
| These chips are just as easy or easier to program than any
| ARM MCU. Raw SPI NOR flash isn't "easy" to program if
| you've never done it before, either.
| exmadscientist wrote:
| It's mostly the whole "two binaries" problem.
|
| Oh look, the factory screwed up and isn't flashing the
| MCU this week! Does the board survive?
|
| Oh look, the factory screwed up and isn't flashing the
| PLD _this_ week! Does the board survive?
|
| Oh look, the factory... wait, what _is_ the factory doing
| and why are they putting _that_ sticker on _that_....
|
| You get the idea. Yes, yes, it is all solvable. I have
| never claimed it isn't. I am just claiming it is a giant
| pain in the ass and limits use of these things. I will
| _bend over backwards_ to keep boards at one binary that
| needs to be loaded.
| 15155 wrote:
| Embed the bitstream into your MCU firmware binary,
| bitbang the 50-100KB bitstream into SRAM via JTAG from
| your MCU in all of 10ms. This is <100 lines of Rust.
| exmadscientist wrote:
| Yes, it's solvable. But my whole argument is that the
| entire experience is death by a thousand cuts. I'm not
| seeing how "it's possible in 100 lines of Rust" (a
| language most people don't even use for embedded work) is
| really countering my argument.
| tverbeure wrote:
| I honestly start to wonder how in the world we survived
| flashing 3 different binaries, for years (bitstream, 2
| MCUs), without ever getting a complaint from the
| production floor.
|
| I should check my spam folder.
| tverbeure wrote:
| > sometimes ... sometimes ... sometimes ...
|
| And sometimes you need support for multiple IO standards.
|
| I don't understand what point you're trying to get across.
|
| But if all you need is LVCMOS33, why do you not use a MAX10
| FPGA with built-in voltage regulator? Or a similar FPGA
| device from GoWin that is positioned as a MAX10
| alternative? What is wrong with those?
|
| > JTAG
|
| On our production line, we use JTAG to program the FPGA? We
| literally used the same "make program" command for
| development and production. That was for production volumes
| considerably larger than 100k.
|
| > ISE
|
| ISE was end of life'd when I started using FPGAs
| professionally. That was in 2012. The only reason it still
| exists is because some hold-outs are still using Spartan 6.
| exmadscientist wrote:
| > I don't understand what point you're trying to get
| across.
|
| My point is twofold:
|
| 1. There are many niches. Your main needs are not the
| same as my main needs. And my needs are poorly met by
| existing products, so I want to see something better.
| (And I do buy chips.)
|
| 2. All of this is way, way harder than it needs to be. It
| _could_ be easy, but it isn 't. Everything is _possible_
| right now. But I wasn 't random when I used the dreaded
| A-word ("Arduino"). Arduino is a kind of horrible product
| that did not make anything possible and did not really
| invent anything. It did not make anything really hard
| suddenly become easy. Hard things before Arduino were
| still hard after Arduino. It "just" made some things that
| used to be medium-hard pains-in-the-butt actually really
| quick and easy (at a little backend complexity cost: now
| you've got the Arduino IDE around, hope it doesn't
| break!).
|
| It turns out that is very valuable.
|
| And is what I would like to see happen with FPGAs: make
| them _easy_ to drop in instead of pains in the butt. All
| pieces for this exist, nothing is new tech, no major
| revolutions need to happen. "Just" ease of use.
| 15155 wrote:
| > make them easy to drop in instead of pains in the butt
|
| How much easier does it need to be than putting down a
| single 1mm^2 LDO and a QFN IC? Is this really _that_
| difficult?
| PunchyHamster wrote:
| > It did not make anything really hard suddenly become
| easy.
|
| It did. Onboarding people onto embedded programmer.
|
| You just ran it, wrote few lines and you had working
| blinky. Write some more and you have useful toy. You
| could even technically make products with it but going
| from this to C++ was easier coz you already know what you
| could do, just needed to go thru pain of switching the
| toolchain once you're already invested.
|
| Compare that to "you need to setup compiler, toolchain,
| SDK, figure out how to program the resulting binary, map
| the registers to your devboard pins etc."
| ErroneousBosh wrote:
| > (at a little backend complexity cost: now you've got
| the Arduino IDE around, hope it doesn't break!)
|
| Doesn't really matter if it does break; just use gcc and
| a Makefile like you would for any other firmware.
|
| You probably want to replace the Arduino libraries with
| your own ones eventually anyway, because there's so much
| cruft in there that you're never going to use.
| 15155 wrote:
| > they're complicated to put down on boards
|
| https://gowinsemi.com/en/product/detail/46/
|
| - Requires just 1V2 + 3V3
|
| - Available in QFN
|
| - Bitstream is saved in internal flash or programmed to SRAM
| via a basic JTAG sequence
|
| https://www.efinixinc.com/products-trion.html
| pclmulqdq wrote:
| The Altera Max 10 devices are also relatively simple to
| support (flash on the chip, few power rails, etc.)
| exmadscientist wrote:
| > Contact Sales
|
| > Request Sample
|
| > Please login to download the document.
|
| I mean, yeah. My argument isn't that anything is
| _impossible_. My argument is that all of this is _harder than
| it needs to be_ and this is not countering me!
| 15155 wrote:
| This is your job, and it really shouldn't feel difficult.
| This is really not tedious: the minimum board design for
| these chips literally consists of just power, JTAG pins,
| and a clock (if the internal oscillator isn't good enough.)
|
| The Gowin FPGAs are available (at a massive premium) from
| Mouser, just like whatever MCU you are already using. Many
| are available for <$1-2 in China. Efinix are available from
| DigiKey, with some SKUs under <$10.
|
| All of the Gowin documentation is available on their site
| with a free, approval-less email login and no NDA, or via
| Google directly (PDFs, just like Xilinx, even numbered
| similarly.)
| mschuster91 wrote:
| > All of the Gowin documentation is available on their
| site with a free, approval-less email login
|
| The problem is trust. I'm hesitant to hand out my e-mail
| anywhere because far too often I have been hounded by
| salespeople as a result, not to mention data breaches or
| bombardment of newsletters.
| 15155 wrote:
| So just use Google to obtain the documentation? Or a fake
| email? The PDFs are pretty easily obtainable by title:
|
| https://www.google.com/search?q=gowin+user+guide+filetype
| %3A...
|
| https://www.google.com/search?q=gowin+primitives+filetype
| %3A...
|
| https://www.google.com/search?q=gowin+gw1n+filetype%3Apdf
| mschuster91 wrote:
| If I really _need_ something I 'll go that route, yes.
| But for something that is just on a "cool, that might be
| interesting" it's too much effort.
| fennecbutt wrote:
| It's basically because they're so locked down, hard to get
| docs, stupid toolchains and ides like others have mentioned.
|
| It's like fpga companies don't want people using them, much
| like others like the pixart sensor I wanted to use: NDA because
| some parasite dipshit executive or manager thinks that register
| layouts are extremely sensitive information.
|
| I've had dozens of uses for an fpga...but every single time I
| just can't be bothered. Why, when they make it a pain in the
| ass on purpose.
| 15155 wrote:
| None of these things are true for the new, cheap Chinese
| contenders.
| willis936 wrote:
| It's already happened, people just haven't realized. iCE40-UP5K
| costs a few bucks, needs minimal support circuitry, and is
| supported by FOSS toolchains (yosys). Fun packages like the
| pico-ice bring it all the way down to the entry-level arduino
| crowd. It just doesn't have the marketing mindshare.
| ithkuil wrote:
| A few times over the past decade I wanted to start with a
| side project where I design and develop a CPU.
|
| I bought a relatively cheap artic 7 board with 33kLUT and
| whatnot which I know people have used to implement risc-v
| implementations on.
|
| But then I always lost my patience on the tooling.
|
| For a side projects these days I need something comfortable.
| Something that that I can easily switch my context to without
| having to juggle VMs and installing unfriendly tools and use
| horrible IDEs
| nrhrjrjrjtntbt wrote:
| Funny enough it is available on an UPDuino board:
| https://tinyvision.ai/pages/the-upduino
| rramadass wrote:
| > FPGAs need their "Arduino moment".
|
| This is exactly it. Why hasn't some expert group produced a
| very simple open design board with a simple Arduino-like IDE
| for FPGAs? Make it easy to access and use, get it into the
| hands of makers/hobbyists and watch the apps/ecosystem explode.
|
| As an example, one could provide soft-cores for 8051/RISC-V
| etc. right out of the box with a menu of peripherals to mix and
| match. Provide a simple language library wrapper say over
| SystemVerilog (or whatever the community settles on) just like
| Arduino did (with C++) that makes it "easy" to program the
| FPGA.
|
| For apps, one good example would be putting TinyML (or any
| other ML/LLM models) on a FPGA. This would take advantage of
| the current technology wave to make this project a success.
|
| PS: Folks might find the book _FPGAs for Software Programmers
| by Dirk Koch et al._
| (https://link.springer.com/book/10.1007/978-3-319-26408-0)
| useful.
| PunchyHamster wrote:
| They can't, by nature of the proprietary bitstream. Arduino was
| only built thanks to ability to do whatever they wanted with
| open source compilers
| Cadwhisker wrote:
| This article is a rant about how bad tools are without going into
| specifics. "VHDL and Verilog are relics", well so is "C" but they
| all get the job done if you've been shown how to use them
| properly.
|
| "engineers are stuck using outdated languages inside proprietary
| IDEs that feel like time capsules from another century.". The
| article misses that Vivado was developed in the 2010's and
| released around 2013. It's a huge step-up from ISE if you know
| how to drive it properly and THIS is the main point that the
| original author misses. You need to have a different mindset when
| writing hardware and it's not easy to find training that shows
| how to do it right.
|
| If you venture into the world of digital logic design without a
| guide or mentor, then you're going to encounter all the pitfalls
| and get frustrated.
|
| My daily Vivado experience involves typing "make", then waiting
| for the result and analysing from there (if necessary). It takes
| experience to set up a hardware project like this, but once you
| get there it's compatible with standard version control, CI
| tools, regression tests and the other nice things you expect form
| a modern development environment.
| tverbeure wrote:
| > My daily Vivado experience involves typing "make", ...
|
| Exactly my experience with Quartus as well.
|
| One really can't help but wonder if those who always whine
| about the IDE/GUI just don't know any better?
| Cadwhisker wrote:
| I've managed to make nice 'make' flows for Vivado, ISE,
| Quartus and DC. Libero took a bit more poking, but it's also
| possible.
|
| The GUI interfaces are what newcomers tend to aim for
| straight away, but they're not good for any long-term
| "repeatable" build flows and they're no use for CI. I think
| this is where a lot of the frustration comes from.
| fooblaster wrote:
| I think my real problem is that xilinx pushes the gui flows
| heavily. It is extremely annoying to configure the mpsoc
| fabrics entirely outside of vivado. Same thing for using
| any of their bundled IP.
| Cadwhisker wrote:
| Yes, IP usage is awkward and tricky. You can use the GUI
| to make the initial .xci file or .tcl file, but when you
| build a project, you need to use the same version of
| Vivado that the IP core was originally created in. Xilinx
| have improved that a little with 'write_ip_tcl' and
| 'write_bd_tcl' now having flags that let you ignore the
| version (or minor version). I've not had time to try
| those yet.
| CamperBob2 wrote:
| _" VHDL and Verilog are relics", well so is "C" but they all
| get the job done if you've been shown how to use them
| properly._
|
| Or how to use an LLM properly.
| fsh wrote:
| But Vivado doesn't get the job done. The intended workflow is
| to click around in the GUI until it (hopefully) synthesizes
| something. The state is then recorded in some proprietary
| project file that cannot be version controlled or shared with
| other developers. The workaround is to generate some unholy
| mess of tcl scripts that automate the clicking, such that one
| can start from scratch for each synthesis. The scripting mess
| breaks with each minor release of Vivado, so you need to either
| never update, or have a separate (~100 GB) Vivado installation
| for every single project. And if your chip is more than a home-
| gamer ZYNQ, you hopefully like paying subscription fees for the
| experience.
| malmeloo wrote:
| One big issue with FPGAs is how annoying it is to learn how to
| use them. I did a course on embedded systems a few years ago and
| nobody could truly get to enjoy it because we spent most of our
| time downloading and installing huge toolchains, waiting for
| synthesis and PnR to complete and debugging weird IDE issues. We
| need to open up the space to allow people to develop better
| solutions than what these companies are forcing down our throats.
|
| There already exist fantastic open source tools such as Yosys,
| Nextpnr, iverilog, OpenFPGALoader, ... that together implement
| most features that a typical hardware dev would want to use. But
| chip support is unfortunately limited, so fewer people are using
| these tools.
|
| We decided to build a VSCode extension that wraps these open
| source tools (https://edacation.github.io for the interested) to
| combat this problem. Students are already using it during the
| course and are generally very positive about the experience. It's
| by no means a full IDE, but if you're just getting started with
| HDL it's great to get familiar with it. Instead of a mess of a
| toolchain that nobody truly knows how to use, you now get a few
| buttons to visualize and (soon) program onto an FPGA.
|
| There's also Lushay Code for the slightly more advanced users.
| But we need more of these initiatives to really get the ball
| rolling and make an impact, so I'd highly recommend people to
| check out and contribute to projects like this.
| delifue wrote:
| Modern large productivity software (including IDE) are often
| "fragile".
|
| Sometimes some configuration is wrong and it behave wrongly but
| you don't know which configuration.
|
| Sometimes it relies on another software installed on system and
| if you installed the incompatible version it malfunctions
| without telling you incompatibility.
|
| Sometimes the IDE itself has random bugs.
|
| A lot of time is spent workarounding IDE issues
| mikepurvis wrote:
| Building for an fpga shouldn't be any harder than building
| for cortex mcus, and there are lots of free/oss toolchains
| and configurations for those.
| SV_BubbleTime wrote:
| > shouldn't
|
| Is doing so much heavy lifting here, I need to ask; how
| much FPGA configuration you have done before?
| mikepurvis wrote:
| Very little, just student projects in undergrad.
|
| So yes, in that sense I'm talking out of my ass. But
| perhaps you can help enlighten me what it is that makes
| building FPGA firmware different from building MCU
| firmware.
| thijson wrote:
| Compiling RTL to run on an FPGA is way more complicated
| than compiling code to run on a CPU. Typically it has to
| meet timing, which requires detailed knowledge of logic
| placement. I'm not saying that's impossible, just that it's
| more complicated.
| Neywiny wrote:
| I'm all for your endeavor, but didn't see a device support list
| on your front page. Clicked the first of 2 links in your
| sidebar (docs) and got a 404. I'm not saying it's telling that
| your issues page works when your docs page doesn't, but it's
| not the foot I would have put forward.
| malmeloo wrote:
| Ha yeah, I agree the website isn't great. I set it up a while
| ago just so we have something to fill up the void. Right now
| it's just me and a professor of previously mentioned course
| who are actively involved in the project, so we've been
| mostly focused on the technical part.
|
| That said, functionally speaking the extension is 90% of the
| way there. Synthesis, PnR, simulation, visualization and more
| all work for ECP5 & iCE40 FPGAs, and to limited extent some
| others as well. We have a few more features that we're
| working on, but a very solid basis already exists.
|
| For technical reasons we have a bit of a deadline on
| finishing the project, which is likely in around ~6-7 months.
| So by then we intend to have a 1.0 release and very solid
| documentation out.
| fn-mote wrote:
| > it's just me and a professor of previously mentioned
| course who are actively involved in the project
|
| Unfortunately, past experiences I have are that a very
| small academic team = stay away, project will have too many
| rough edges.
|
| I hope your experience goes better. Tip: A revenue stream
| gives you something to work with. Failing that, carefully
| document your whole architecture so contributors will be
| willing to help.
|
| ## Irrelevant Complaining
|
| Just ran across this last year: good looking software,
| great concept, first half of features work great ... enough
| to hook me, so when I finally found out the other half was
| bug ridden I stuck it out but ouch. Needless to say, no
| design document so even fixing stuff was a pain point.
| malmeloo wrote:
| I know exactly what you mean and I share your
| frustrations with academic software. In our case I think
| it helps that our main goal is to provide a good user
| experience: we're not reinventing toolchains from
| scratch, but rather making existing ones available in a
| user-friendly way. Especially in the past year or so I've
| spent a lot of effort on reducing tech debt, modernizing
| the underlying architecture and squashing bugs. We've
| gone through several UI iterations just to see what would
| be most intuitive. Compare that to most pieces of
| academic software that should technically work, but are
| so difficult to use that nobody except the developers
| really know how to utilize it.
|
| Our intention has never been to build a full alternative
| to e.g. Quartus Prime or Vivado that suits everyone's
| needs. Our main intention is to show people that FPGA
| toolchains don't have to be so difficult to get started
| with, and that alternatives are possible. And yes, I
| agree, that absolutely means good documentation on
| several levels to allow other people to continue working
| on the project. Good thing that's part of our mission, so
| it will be done; just takes a little bit of time ;)
| random3 wrote:
| I just remembered I have a Xilinx I bought over a decade ago
| lying around somewhere. I don't remember ever plugging it in,
| but I do both the excitement of getting it and trying to figure
| out the toolchain and getting confused.
| amelius wrote:
| I agree but I think that writing yet another IDE extension is
| not going to solve the problems. An IDE will bring you one step
| further away from the actual hardware, and makes it more
| difficult to solve unexpected problems. Also, not everybody
| likes IDEs, some just prefer Vim and the commandline. An IDE is
| not the magical solution here.
|
| Instead of focusing on the IDE, maybe focus on a build system.
| Look at how PlatformIO does it.
| malmeloo wrote:
| I agree, this won't be for everyone. But if you're trying to
| learn how to use FPGAs, I think it helps a lot to have a tool
| like the one we're building. The learning process is also
| inherently very visual: it helps a lot to see what the
| individual steps look like, how Yosys synthesizes your
| Verilog code, where Nextpnr places the elements, what the
| chip looks like, what exactly your testbench is doing...
|
| People who want to stick to the command line can always just
| use the tools directly. The extension tries to stay close to
| the tools by allowing users to directly modify the command
| line arguments and making invocations visible to the user.
| Heck, you could even use our standalone 'edacation' tool to
| run tasks defined in project config files (although
| admittedly I haven't tested that in a long time, so it might
| not really work that well)
|
| Our intention has never been to build a one-size-fits-all
| solution. We want to show people that these fantastic OSS
| tools exist and can provide a viable alternative to Big
| FPGA's tools. We hope to be(come) a source of inspiration for
| what the scene could look like if we just let go of these
| massive toolchains that nobody really likes to use.
| MisterTea wrote:
| This is exactly it.
|
| The FPGA situation is the same as the microcontroller situation
| before Arduino blew open the flood gates: byzantine proprietary
| software and libraries you have to pay for to unlock hard IP
| functionality less you from scratch develop it yourself which
| can be very difficult. The Arduino gave people a solid kit:
| Simple to install IDE that wraps up a text editor, tool chain
| and libraries with matching plug and play hardware.
|
| Arduino took microcontrollers from esoteric hardware for EE's
| to mainstream "makers" - people who were not technically
| educated but wanted to makes things using technology. FPGA's
| need a solid foundation like that.
|
| I briefly worked with FPGAs and was having a lot of fun but the
| software really ruined it for me. I forget the details but I
| was moving my web license of the Xilinx tools to my desktop
| from my laptop, it kept failing and I gave up.
| misnome wrote:
| Oh christ, absolutely this. We spent some time evaluating FPGA
| for our purposes and ended up GPU instead (algorithms we
| running can be adapted to strength of either).
|
| The concepts are easy enough but learning the toolsets are an
| exercise in frustration... the documentation/onboarding is
| either nonexistent or extremely unhelpful, and getting past the
| stage of "the entire thing doesn't work because you misclicked
| a button in the gui several hours ago". In theory everything
| can be scripted, usually in TCL, but this is also unstable and
| seems liable to break every different version of the toolsets.
|
| Alongside Xilinx, we also looked at Altera/Intel OneAPI/dpcpp
| and this seemed promising until we realised we were
| encountering so many toolchain/actual compiler bugs that nobody
| else could have been actually using this, except the oneapi
| cloud platform that seemed it had been hotpatched to fix some
| of the issues. In the end, after selling us some compatible
| cards they dropped the OS and card from support. I guess this
| taught us not to trust Intel!
|
| We decided teaching to Juniors would be an exercise in
| frustration unless hiring explicitly for, and decided to go the
| GPU route.
| bakkoting wrote:
| Have you seen the YoWASP toolchain for VSCode [1]? It sounds
| pretty similar.
|
| [1] https://github.com/YoWASP/vscode
| ursAxZA wrote:
| If Jim Keller says it, I'll believe it.
|
| My Ryzen agrees -- the fans just spun up like it's hitting 10,000
| rpm.
| octoberfranklin wrote:
| The problem is that FPGA companies don't see themselves as chip
| companies.
|
| They see themselves as CAD software companies. The chip is just a
| copy-protection dongle.
| poslathian wrote:
| Pushing 20 years in industry and this is the best take I've
| heard
| jhide wrote:
| This article could've been written 20 years ago with only minor
| revisions, and it would've been true then. But it's not now. It
| is trivial, literally a day of work, to set up a build system and
| CICD environment using Verilator if you are already proficient
| with your build system of choice. Learning TCL to script a
| bitfile generation target using your FPGA vendor's tools is a few
| extra days of work. And regarding IDE support, the authors
| complain about the experience of writing code in the vendor GUI.
| They should look at one of the numerous fully featured
| systemverilog LSPs available in e.g. VS Code.
|
| The real argument for open source toolchains is much narrower in
| scope and implying its requirement for fixing a nonexistent tool
| problem is absurd
| amirhirsch wrote:
| I did write this 20 years ago
| https://fpgacomputing.blogspot.com/2006/05/methods-for-recon...
|
| The vendor tools are still a barrier to the high-end FPGA's
| hardened IP
| phendrenad2 wrote:
| It seems to me that there are exactly 3 buyers for FPGAs:
| Government contractors (who spend millions all at once), retro
| gamers (small market), and electronics hobbyists (another small
| market). It's no wonder every company has orientated itself
| towards the first one. I look to China to accidentally make chips
| that are an order of magnitude better "just because they can".
| lvoudour wrote:
| You forget network infrastructure, high frequency trading, ASIC
| prototyping and emulation. These are not hobbyist or government
| markets
| rzerowan wrote:
| On the software front as mentioned VHDL and Verilog are showing
| their age with their design as well as ther tooling
| ecosystem.Attempts such as CHISEL[1] (written in Scala)also
| havent gotten much traction - seeing also the language choice -
| would have btter have been in something more accesible like
| kotlin/ocaml.
|
| Secondly the integration with consumer devices and OS is almost
| non-ecistant - it should really be simpler to interact with ala
| GPU/Network chip and have more mainboards with lowcost integrated
| FPGAs even if they are only a couple of hundred of logic cells.
|
| [1]https://github.com/chipsalliance/chisel/blob/main/README.md
| CamperBob2 wrote:
| _Here's the first big misconception: HDL is hardware. It isn't.
| HDL is software and should be managed like software._
|
| Yes, that's certainly a big misconception. Maybe not the one the
| author meant to call out, but... yes, a big misconception indeed.
| oscillonoscope wrote:
| Its both depending on context. If HDL becomes custom silicon
| then it needs to be treated like hardware. If you can easily
| deploy field updates to your device then it's no different than
| any other firmware
| mastax wrote:
| My prediction is one of the Chinese FPGA makers will embrace open
| source, hire a handful of talented open source contributors, and
| within a handful of years end up with tooling that is way easier
| to use for hobbyists, students, and small businesses. They use
| this as an inroad and slowly move upmarket. Basically the
| Espressif strategy.
|
| Xilinx, Altera, and Lattice are culturally incapable of doing
| this. For lattice especially it seems like a no brainer but they
| don't understand the appeal of open source still.
| 15155 wrote:
| Gowin and Efinix's tools are extremely spartan compared to
| Vivado or Quartus: they're pretty much straight HDL to
| bitstream compilers. There's also a FOSS implementation flow
| available for the Gowin chips (but I haven't used it.)
|
| HDL isn't getting any easier, though, and that's where most of
| the complexity is.
| bsder wrote:
| > My prediction is one of the Chinese FPGA makers will embrace
| open source
|
| Sadly, this doesn't seem to be panning out because the Chinese
| domestic market has perfectly functional Xilinx and Altera
| clones for a fraction of the price. Consequently, they don't
| care about anything else.
|
| It irritates me to no end that Gowin won't open their bitstream
| format because they'd displace a bunch of the low end almost
| immediately.
| hmry wrote:
| Gowin seemingly doesn't even sell the chips to individuals.
| Either set up an LLC so you can request samples from a
| destributor, or desolder one from a sipeed dev kit.
| 15155 wrote:
| > It irritates me to no end that Gowin won't open their
| bitstream format because they'd displace a bunch of the low
| end almost immediately.
|
| All of their IDE/programmer/etc binaries are basically
| entirely unprotected, almost all of their chips are entirely
| implemented in https://github.com/YosysHQ/apicula - if other
| manufacturers cared to implement it, it wouldn't be hard.
| tverbeure wrote:
| Define "upmarket" ?
|
| For me, that means higher capacity and advanced blocks such as
| SERDES, high-speed DRAM interfaces etc.
|
| The bottleneck in using these kind of FPGAs has rarely been the
| tools, it's the amount of time it takes to write and verify
| correct RTL. That's not an FPGA specific problem, it applies to
| ASIC just the same.
|
| I don't see how GoWin and other alternative brands would be
| better placed to solve that problem.
| xgstation wrote:
| I imagine FPGA could just be part of general CPU that provides
| user space APIs to program them to accelerate certain work flow,
| in other words, this sounds like exactly JIT to me. People may
| program FPGA as they need to, e.g. AV1 encoder/decoder,
| accelerate some NN layers, or even a JS runtime, am I thinking
| something too wild for hardware capability or is it just the
| ecosystem isn't there yet to allow such flexible use cases?
| 15155 wrote:
| Digital logic design isn't software programming, and today's
| FPGAs are for most intents and purposes 'single-configuration-
| at-a-time' devices - you can't realistically time-slice them.
|
| The placement and routing flow of these devices is an NP-
| Complete problem and is relatively non-deterministic* (the
| exact same HDL will typically produce identical results, but
| even slightly different HDL can produce radically different
| results.)
|
| All of these use cases you've mentioned (AV1 decoders, NN
| layers, but especially a JS runtime) require phenomenal amounts
| of physical die area, even on modern processes. CPUs will run
| circles around the practical die area you can afford to spare -
| at massively higher clock speeds - for all but the most niche
| of problems.
| tverbeure wrote:
| My rule of thumb is a 40x silicon area ratio between FPGA and
| ASIC, a clock speed that is around 5x lower. And a lot more
| power consumption.
|
| If you have an application that can be done on a CPU, with lots
| of sequences dependencies (such as video
| compression/decompression), an FPGA doesn't stand a chance
| compared to adding dedicated silicon area.
|
| That's even more so if you'd embed an FPGA on a CPU die. Intel
| tried it and you got a power hungry jack of all trades, master
| of none that nobody knew what to do with.
|
| Xilinx MPSOC and RFSOC are successful, but their CPUs are
| comparatively lower performance and used as application
| specific orchestrators and never as a generic CPU that run
| traditional desktop or server software.
| imtringued wrote:
| I have yet to see the "FPGA is less power efficient" thing to
| be true. People are always comparing the same circuit in an
| FPGA Vs an ASIC but this is a nonsensical comparison because
| of three reasons:
|
| FPGAs have hard wired blocks like DSPs which do not have any
| power disadvantages vs "ASIC" (only advantages actually)
|
| the likelihood that there is an ASIC that happens to
| implement your particular design is very low
|
| and off the shelf ASICs like GPUs and CPUs have significant
| amounts of overhead for each operation. This is especially
| evident with CPUs. They perform a small number of operations
| per cycle, but they have to pay the entire fixed energy cost
| of caches, registers, instruction decoding, etc per cycle.
| This is way way worse than programmable logic if you're
| mostly using the DSP and the block RAM slices.
| dsab wrote:
| I had the misfortune of working with the Xilinx Vivado
| environment, it's a fucking garbage, the software is straight out
| of the 90s, everything is glued together with shell scripts and
| the TCL scripting language, the IDE throws thousands of warnings
| and errors while building a sample project, the documentation is
| missing or spread over 150 PDFs, if the manufacturer of your
| evaluation board prepared an example for the previous version of
| Vivado, you must have two installations, which is probably about
| 2 * 100GB, if you want to keep anything under version control,
| you have to use some external tools, it's all absurd.
| Peteragain wrote:
| Programming languages were originally designed by mathematicians
| based on a Turing machine. A modern language for FPGAs is a
| challenge for theoretical computer science, but we should keep
| computer literate researchers away from it. This is a call out to
| hard core maths heads to think about how we should think about
| parallelism and what FPGA hardware can do.
| Ericson2314 wrote:
| https://clash-lang.org/ we've already done the research!
| Circuits are just functional programming (the vast majority of
| the time).
|
| We just need the toolchains to be opened up.
| Ericson2314 wrote:
| This is a very correct article. FPGAs should indeed be really
| easy to use!
| mikewarot wrote:
| An FPGA is like a spreadsheet for bits that can recalculate at
| hundreds of millions of times per second.
|
| It's a declarative programming system, and there's a massive
| impedance match when you try to write source code for it in text.
| I suspect that something closer to flow charts, would be much
| easier to grok. Verilog is about as good at match as you are
| likely to get, if you stick with the source code approach to
| designing with them.
| pjc50 wrote:
| Very good metaphor. I'm going to use that in the future. It
| even has rows and columns.
|
| Except the spreadsheet is a really accessible technology that's
| been cloned, while the critical problem with FPGA is the
| proprietary tooling. This is the same reason that NVIDIA made a
| gazillion dollars by turning GPUs into general purpose compute:
| a proper API, CUDA.
| marcosscriven wrote:
| > An FPGA, by contrast, defines data pathways specifying how
| signals change on each clock tick based on internal states and
| external inputs. In essence, we describe global per-clock-cycle
| behavior rather than an individual act of data manipulation per
| step.
|
| I think that's the clearest explanation of FPGAs I've ever seen.
| juliangmp wrote:
| > I once hoped things would improve when Xilinx launched the Zynq
| line, combining a processor with FPGA fabric. Instead, the
| accompanying tools were so unusable that they made things worse,
| pushing developers even further away.
|
| I once tried to use Xilinx' Vitis (2025) to make a small-ish
| piece of software running on such a Zynq chip. After wrestling
| with it* for like 5 weeks, me and my colleagues decided to ditch
| the entire Xilinx suite entirely and just pick a compiler and
| make a bare-metal binary with it. The FPGA part is done by a
| separate team of course, so us traditional software devs can
| stick with decent tools. We actually opted for a Rust toolchain
| and I'm extremely glad we did this, despite the additional time
| it took.
|
| I don't know how my FPGA colleagues work with the proprietary
| toolchains and not go insane.
|
| *The IDE is effectively a wrapper with a custom python API around
| cmake and gcc. It's not very well written cmake and I also don't
| know how they configure the linker that it does the weird things
| it does.
| jonesjohnson wrote:
| I'm surprised, no one mentioned https://f4pga.org/ yet.
| lefra wrote:
| I program FPGAs professionally (Xilinx Zynq, VHDL). I agree that
| the tool's GUI is atrocious, the actual way to use it is to write
| everything in TCL scripts, and invoke the tools through a
| Makefile. I only open the GUI to look at timing issues or ask it
| for code templates.
|
| I disagree with "HDL is software" though. It's not, it's even in
| the name: "hardware description language". Yes it's a text file
| with what looks a lot like regular code in it. However what's
| being decribed is how to connect boxes of logic together, and how
| to compute the output of the boxes from their inputs. There's no
| implicit program counter that's advancing from one line to the
| next.
|
| It is (theoretically) possible to write these kind of things with
| a lot of abstraction, but every time you try that by using more
| advanced language features, you hit some bugs in the tool's
| implementation of the language. If you're lucky it'll tell you
| where you're doing undupported stuff. Often it'll crash.
| Sometimes it'll sythesize hardware that doesn't conform with the
| language spec.
|
| Finally, FPGAs are simple only when you're looking at a bird's
| eye view (just like CPUs are simple when you're looking at a
| diagram with a few boxes saying "ALU", "Cache", "Registers"). The
| actual datasheets are thousands of pages long.
|
| FPGAs are still useful though, their use case is "I need custom
| hardware and I don't have the volume to build an ASIC". For
| example, my application is a custom signal processing pipeline
| that's handling about 3.5 Gbit/s of streaming raw data. On a $40
| chip.
|
| I think my main point is that yes, the tooling is a pain to use,
| with heaps of bugs and bad language support. However a HDL is
| conceptually different from a software language and I'm not sure
| you can hide away the complexities of designing hardware behind
| "modern" language features.
|
| For those suggesting diagram-based languages, go program
| something in LabView, you'll quickly understand why that's a bad
| idea (works for trivial designs, anything complex is an opaque
| mess of boxes and lines, unsearchable, and impossible to
| integrate with version control).
| fluorinerocket wrote:
| LabVIEW FPGA was amazing, I did all kinds of things with it on
| the compactRIO controller FPGA
|
| You can write very neat and tidy code with dataflow diagram
| languages. I did it professionally for years, and there were
| many others who did as well.
|
| Same thing as any other language, you have to come up ways to
| organize the code into functions and classes that make sense.
| Vomiting everything into the top level diagram is the same as
| 10000 line of code while(1)
|
| You could always tell the exact level of proficiency someone
| had with LabVIEW immediately when opening the diagram.
|
| The dataflow model maps very well to FPGAs IMO, it's a shame it
| never became widespread. There was much potential there
| mgaunard wrote:
| There are a number of alternatives to VDHL and Verilog, many of
| which lower to Verilog, for example MyHDL.
| ImPleadThe5th wrote:
| I have an old FPGA sitting around at home and I'm relatively
| comfortable with VHDL.
|
| I've never really thought of any interesting projects to do with
| it. Anyone know of anything?
| kown7 wrote:
| That was my point as well: what can't you do with a uC or RPi?
|
| It feels the use cases are dwindling and eaten by ASICs and uC
| ab71e5 wrote:
| I knew someone who created a mandelbrot set viewer that would
| display over an VGA port, you had a game controller to move
| around and zoom into it. Something like that?
| pythonguython wrote:
| Anything RF
| Traster wrote:
| I was quite surprised the direction this article took. I wasn't
| expecting reheated whinging about the toolchain.
|
| FPGAs do need a new future. They need a future where someone
| tapes out an FPGA! Xilinx produced Ultrascale+ over a decade ago
| and haven't done anything interesting since. Their Versal devices
| went off a tangent into SoCs, NOCs, AI engines - you know what
| they didn't do? Build a decent FPGA.
|
| Altera did something ambitious back in 2014 when they proposed
| the hyper-register design, totally failed to execute on it and
| have been treading water because of the Intel cluster**. They're
| now an independent company but literally don't have anyone who
| knows how to tape out a chip.
|
| I'm less familiar with the Lattice stuff, but since their most
| advanced product is still 16nm finfet I suspect they aren't doing
| anything newer than Xilinx or Altera.
|
| We need a company that _builds an FPGA_. It doesn 't matter what
| tooling you have because the fundamental performance gap between
| a custom FPGA solution and a CPU or GPU based solution is
| entirely eaten up by the fact the newest FPGA you can buy is a
| decade old and _inexplicably_ still tens of thousands of dollars.
|
| If FPGA technology had progressed at the same rate NVidia or
| Apple had pushed forward CPU/GPU performance, thered be some
| amazing opportunities to accelerate AI (on the path to then
| creating ASICs). But they haven't, so all the scaling laws have
| worked against them and the places they have a performance
| benefit have shrunk massively.
| brador wrote:
| No mention of video game emulation on FPGA?
|
| No mention of that Brazilian company that was set to manufacture
| them to undercut the market?
| BrannonKing wrote:
| The whole place-and-route thing is completely wrong for using
| FPGAs as accelerators. We don't need an optimal layout, we need a
| tiled layout (like the GPU does). All that we need for this to
| happen is for the companies making the FPGAs to open up the board
| layout file spec. They don't need to even make/ship any software
| at all. Just ship the dang file that says where the resources &
| timings are and some instructions on how to toggle the LUT
| config.
|
| My feeling is that hardware companies do better when they ship
| the software needed to utilize their hardware for free. (You need
| a little margin in the hardware price to cover the software
| development). However, the FPGA companies haven't figured this
| out. They try to make way too much software and charge
| exhorbitant fees for it, somehow thinking that their hardware is
| useless without that. In fact, their hardware is useless because
| I can't put anything on it without a 1-to-20 hour compile time.
| That makes it impossible to use it as an accelerator. I can
| compile OpenCL for my GPU in a few milliseconds; that's what we
| need for the FPGA. Even thirty seconds would be easily tolerable
| -- there's many a game that still requires 15 seconds to load a
| level and compile its shaders.
|
| FPGAs could be much more useful than they are at present. They've
| artificially limited themselves to ASIC prototyping alone.
|
| So Intel bought an FPGA company -- nobody knows why. AMD got
| scared and did the same thing with no clue what to do with it.
| They've both let them rot. Intel did start incorporating it into
| its compiler targets, but it was only half-baked. Now they've
| wisely divested themselves of the company, but it should have
| never happened. They should have just focused on selling the
| hardware at a small margin whilst opening up the data to use it.
| almostgotcaught wrote:
| > we need a tiled layout
|
| You are presuming an existing tile IP - if you're already in
| possession of such an IP then the place and route is already
| coarse grained. There are lots of papers on this.
|
| > (like the GPU does)
|
| What exactly does the GPU _do_? Yes there are tiles but it 's
| up to you to now tile your _workload_. You understand this is
| the exact same problem you 're bemoaning re place and route -
| you need to figure out how to shuffle individual bits
| efficiently through an existing fabric (roughly it's the same
| thing as routing 32 wires at a time).
|
| > we need for this to happen is for the companies making the
| FPGAs to open up the board layout file spec
|
| What exactly is this going to do for you if you're placing
| tiles? Also you can already recover this by exhaustively
| enumerating all a->b paths (yes people really do this).
|
| To anyone else that thinks they just absolutely are certain of
| the silver bullet for digital design: download a copy of Vivado
| and report back what you discover!
| zerofor_conduct wrote:
| completely agree, it's a miserable environment for software
| developers. The Xilinx environment was a 1 GB download, EACH TIME
| they issued an update. I actually met with someone from higher up
| to give them some feedback, but they were clearly not interested
| in the slightest in making any changes.
| thijson wrote:
| I don't understand why the fpga chip vendors don't sell direct to
| customers. You typically have to go through a distributor, and
| that entails quite a bit of markup. It doesn't lend itself to the
| hobby market like raspberry pi for example.
| strfry wrote:
| Neat, but we've been in the same situation for a while. A couple
| years back, I wrote a tutorial for using an open source stack
| with the Nandland Go FPGA board: a simple Lattice board. This was
| because the FPGA book I bought from No Starch required Windows
| (shock and horror). This was 2023. Now we're coming up into 2026?
| bgnn wrote:
| I don't get the VHDL or Verilog hate. Digital IC design engineers
| have no problem with them. True, most of the industry moved to
| SystemVerilog, mainly for simulation and verification reasons.
|
| It's the weirdnesses of FPGAs though. You aren't really designing
| a gate level circuit at the end. I'm not sure Verilog or VHDL are
| to blame here. Maybe they aren't fit for purpose to begin with. I
| hate the toolchains too. They got worse (sluggish, more paid IPs
| etc) in the last 15 years. IC design tools cost A LOT more (like
| 2-3 orders of magnitude more) comparatively but they just work at
| least!
___________________________________________________________________
(page generated 2025-12-23 23:02 UTC)