[exmadscientist]

> 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]

> 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.

[summa_tech]

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

[exmadscientist]

The Silego stuff has been really attractive at high volume. This is what I think about when some of the other posters in this thread sniff at my cost expectations: this stuff can get real cheap if you have volume behind it.

It was not a fit for this use case (on this product I am literally counting tenths of pennies, so, no go), and I dread dealing with Renesas in any form, but it's the right fit for something.

[tverbeure]

The device that you were looking was not an FPGA but a GAL22V10L.

[exmadscientist]

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]

“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]

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]

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?)

[tverbeure]

> 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]

> 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.

[PunchyHamster]

> 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."

[exmadscientist]

Ah, but that's only medium hard on my difficulty scale ;)

[15155]

> 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?

[ErroneousBosh]

> (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]

> 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]

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]

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]

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]

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.