Comment by bsder | Hacker News Reader

Comment by bsder | Hacker News Reader

Parent Full thread

> When would you choose FPGA over something like an STM32?

The answer is "almost never". Qualifications below.

Learn the Cortex-M4 ecosystem first. You can do a remarkable amount of stuff by abusing microcontroller systems in weird ways. The tools for dealing with microcontrollers are MUCH better than the FPGA ecosystem tools (which suck--and that's on a good day).

If you need an FPGA, generally you know it. The first sign is: "There's no way to do this with my microcontroller." That step is generally followed by: "Is there a different microcontroller that could do this?" followed by asking the old greybeard "Is there really no way to do this on a microcontroller?" And finally, "Crud, this can't be done on a microcontroller"--at that point you can consider an FPGA.

As someone who has been dealing with this for mumble too many years, I've been slowly migrating functionality of my clients away from their FPGAs and into the microcontrollers more and more. It's just way easier on too many fronts--and they don't have to learn Verilog/VHDL. The FPGAs will never go away, but they will have the minimum functionality we can get away with.

> I've no experience with FPGA, but would like to learn.

I'm likely to get some static for this, but get an actual supported dev board and not an open-source hacker board. I would recommend something like this that has an academic version:

https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=...

Use the manufacturer tools (which, in this instance, are free) as using an "open-source toolchain" is NOT for beginners.

Once you understand FPGA's a bit more thoroughly, then you can take the leap to the open source stuff.

100%, all the recommendations to "start" with the FOSS toolchain are totally bogus.

"You want to learn FPGAs! Let's simulate with Verilator. No, it can't simulate delays, or your vendor's IP library. No, it's not mixed language - hope all your IP is Verilog! And you'll need to know C or C++ to write your test bench, but that's ok right? The examples online involve templates (ZipCPU), so you're OK with Makefiles, and templated C++, obviously. Now, you have the FOSS P&R tools! They use a primitive simulated annealing placement algorithm that's like what we did in the 90's. Yeah, that's terrible, but don't worry, it works fine because the only parts you can target are really, really tiny Lattice parts! No, you can't even use all the hard blocks on the 7 series Xilinx parts - you can fit ONE whole RISC-V superscalar OoO core on the $3500 VC707 (https://github.com/csail-csg/riscy-OOO), running at ~120MHz - but I'll bet you'll do some primitive microcontroller RISC-V instead, something that fits on these really, really, REALLY tiny parts. Then you'll obviously want to augment that with Migen - don't you also know Python? Or Chisel! How great is Scala right? Yeah, it couldn't simulate a simple tri-state until version 2, but you're OK with the concept of domain specific languages already, right? You love the first-class functions and code as data concept! I know, I know. No, nobody in industry cares about any of this stuff, they're too busy using actual FPGA knowledge to like build real systems and circuits. Yeah, a microcontroller-level RISC-V style processor is a handful of undergraduate labs, but RISC-V IS OPEN! Anyway, back to FPGAs...hey where are you going?!"

>Use the manufacturer tools (which, in this instance, are free) as using an "open-source toolchain" is NOT for beginners.

As someone who learned the ropes with the open toolchain, I have to strongly disagree.

It's perfectly feasible, and from what I've seen (videos and such), the closed toolchains are way messier and do not provide much in terms of tools unless you pay for time-limited licenses. No thanks.

I disagree, but please don't downvote stuff like this--respond with a thought out comment, thanks. I upvoted you.

Perhaps Xilinx-land is different, but I have seen an intern go from blank Windows machine to "blink an LED" on an Altera board in about an hour or so with no Verlog/VHDL.

I have never seen this with the open-source toolchains.

Your experience differs. YMMV. Disclaimers. etc.

For the record, just months ago I installed the open tools and did get to the led blinking in less than 10 minutes, with no prior Verilog experience.

I could count the time to "install open tools", too, but it would be even less favorable to the proprietary toolchain. It was, after all, a single command (on Arch Linux) that finished in a few seconds at worst.

There's a lot of tutorials these days based on iCE40 and open toolchain.

Then I went on to read yosys's documentation, and learned a great deal about how the flow from verilog to hardware works in a very short amount of time, by just doing so.

It really depends on your prior experience. If you're a programmer that's used to working with a command line-based Unix environment, the open tools will feel a lot more familiar than the proprietary ones.

That's actually a really good point.

When someone says "beginner", I never think of someone who already knows the Unix command line.

I've been doing this for far too many years, and I'm struggling to think of anybody I know who does FPGA work and knows the UNIX command line--even among the experienced hands.

I think us "old hats" using GNU/Linux from the 90s are increasingly getting interested in the hardware side of things.

You are likely too biased in the Windows world, which is exactly what HN is not (probably! I have no data to prove that, just a hunch based on the discussions I took a part of on HN).

Well, my beard is very grey an I am a recovering sysadmin ... as they say. :)

However, none of my colleagues in hardware design really know UNIX--neither junior nor senior.

And what's with the downvoters in this thread? Stop downvoting people because you disagree with them--COMMENT, DAMMIT.

I'm beginning to suspect that the HN "You're posting too fast" limit gets hit too quickly and people can only upvote/downvote so they default to that.

I think many people default to downvote-when-disagree. It's partially the "like/dislike" culture, but I think it's mostly because it's the opposite of upvote-when-agreeing.

I agree with you that downvotes are useless when one simply disagrees and don't help the author or the reader learn. With the "flag" feature though, I am not sure I see the point of downvoting at all (other than when someone repeats the same disproven argument in the thread): upvoting is there to indicate "me too", but any such thing turns into a popularity context.

I think it took me about that long using the open tools. There is a 2 hour self-hosted beginner workshop for the icebreaker that gets you a little further than blinking.

Installation instructions (basically just extract the folder somewhere): https://github.com/im-tomu/fomu-toolchain

Workshop: https://github.com/esden/wtfpga

I mean. The time for an intern to go from nothing to a blinking LED is not an interesting metric at all for a professional tool.

Professional tools are judged by such metrics. Manufacturers put tremendous effort into onboarding neophytes because they know whichever stack of tools get the job done with the lowest cost labor will grab a lot of market. The old heads that can write Verilog from memory are trapped in zoom meetings dealing with 'managers.'

Sadly this frequently manifests as huge, Eclipse based bloatware with byzantine installation processes and comical fragility. Precious few understand the value of lightweight, robust tools and confuse elaborate graphical wizards and code generators with quality.

Typically you just use the tool the vendor provides. Vivado if you're using Xilinx. Quartus if you're using Altera. I agree that the tools are bloated monstrosities whichever one you're using.

Source: I'm an FPGA engineer (sometimes).

> The time for an intern to go from nothing to a blinking LED is not an interesting metric at all for a professional tool.

This is highly dependent upon how often you use the tool.

If I do an FPGA project once every two years and the scope is less than 3 months, user-friendliness is very much a useful metric for my tools.

If I'm doing an FPGA project that is going to take 15 months, then lack of user-friendliness certainly won't stop me (but it will make me grouchy).

I'm just going to chime in as well. OSS tools were a breeze to set up. And the compile loop is so very quick comparatively.

I'm currently learning programming FPGAs using open source toolchain, my idea is to completely go away from MCUs towards cheap FPGAs and RISC-V. This is actually my third attempt to mess with FPGAs. Several years ago I tried Xilinx, before that I tried Altera. But their proprietary bloatware made me sick. Maybe I'm too much used to command line hence cannot comprehend their world-wide recognizable goodies. On the opposite I pretty much like Yosys, Verilator and SpinalHDL (I didn't like nMigen because of python). In my opinion, nMigen, SpinalHDL and other higher level HDLs are much more freindly to beginners than Verilog to which you are bound if you decide to go conventional way.

if you're more comfortable with the CLI, you should take a look at the apio project (https://github.com/FPGAwars/apio). It neatly bundles all the required tools. Regarding HDLs, I'm still learning so can't offer any good advice on that.

I appreciate the direct answer - it sounds like it might still be worth learning from an academic perspective. Most of my project ideas are readily done with a Cortex-M and programmed in Rust, but I'm curious about Verilog/VHDL, even if just to expand horizons.

Reply on news.ycombinator.com