Comment by bsder | Hacker News Reader

Comment by bsder | Hacker News Reader

Parent Full thread

> EE and FPGA jobs don't pay well.

The problem is that EE/FPGA jobs have to compete with FAANGs.

However, hardware, by and large, isn't VC funded. Hardware also has a fairly objective criterion for success.

So, you're not going to get offered $200K unless you actually know what you're doing and bring direct business value. And, if you don't know what you're doing, that's going to be apparent real quick.

As for the ZipCPU author:

1) I don't have to make interviewees go through projects. A simple state machine is enough to separate the wheat from the chaff in Verilog. Practically every online tutorial gets non-blocking and blocking assignment wrong--so interviewees who get that right have demonstrated that they have been bitten by real experience.

2) Quoting Bible verses is a GIGANTIC red flag for me, personally. All the businesses I have dealt with that have done this have been owned by absolutely terrible people with only a single exception to the contrary.

> The problem is that EE/FPGA jobs have to compete with FAANGs.

Too bad. That is the free market. The market is not obligated to provide companies with labour, just like companies are not obligated to provide people with jobs.

No argument.

But the flip side is that I'm also not required to hire someone either.

However, programmers don't get to complain that the FAANGs are gatekeeping/discriminating/etc. when the programmers decided that FAANG jobs are the only ones paying salaries they're willing to work for.

I'm curious about FPGAs but don't have any background in stuff like that. How many weeks would it take to build something useful?

It can take as little as a couple of days--most of the tools even let you draw simple logic schematics. But this is useful only if you have something that fits the use cases for FPGAs.

The problem with FPGAs is that they're only really useful in very narrow niche applications--generally with hard real-time constraints. So ... motor controllers, high-speed ADC/DAC interfacing (think software defined radio), weird processing algorithms that don't work well on a DSP, safety interlocks, etc.

Most people are far better off learning a microcontroller family in depth (think: STMF32 series, for example). You can really bend the functional units of a microcontroller a long way from their intended usages in order to abuse them to do what you need under most circumstances.

I don't reach for FPGAs much anymore as an embedded engineer. Normally I trawl through the various microcontrollers to see if I can make something do what I need. If those don't work, the next layer is to look at SoCs like the AM3359 from the BeagleBone Series which have stronger processors to run Linux (Linux provides larger storage, CPU, and lots more communication options) but have hard real-time units (the PRUs).

Finally, if even those don't work, then I'll start thinking about a cheap FPGA in concert with an external microcontroller.

One unusual thing is that I'm an absolute bigot about not putting microcontrollers inside my FPGA (neither soft nor hard cores). Even the worst microcontroller toolchain is better than the best FPGA toolchain so I am adamant about external microcontrollers.

Reply on news.ycombinator.com