I can't speak for Schiit, obviously. But generally speaking, the benefit AND drawback of an FPGA is that the thing—fresh out the box—is just about as dumb as eight yards of dirt road. (Dumm wie acht Meter Feldweg.)
Can't tell you what Schiit products you will eventually find an FPGA inside, if any at all. But I feel relatively confident in saying that you'll definitely not see any of the chip-DACs (like the ESS chips you find in Fulla, Hel, Modi, Modius, and the ESS expansion card) be replaced by an FPGA. Those DAC chips (be it from ESS, TI, AKM, etc.) are purpose-built for the job, and while they might not be able to deliver quite the same sound quality that you can get from a really well-made discreet DAC like Schiit's Multibit (and eventually also Singularity, I would assume), you just can't beat them in terms of footprint or of cost.
Plus, just because there's an FPGA in something doesn't mean it's automatically really good. Allow me to me explain why…
[ Disclaimer: Every last bit of the following is
hugely oversimplified for the sake of … *cough*… "brevity"
]
With your good old microcontroller, everything you can do with it has already been baked into the hardware for you. It has pretty much everything you will ever need, like adders, memory controllers, the memory itself, all kinds of communication interfaces, pulse width modulation controllers, a Bluetooth and/or wifi modem, an NFC modem… The thing is essentially ready to go, you just need to write a bit of code to tell it which of the ready-made bits you want to be doing what, and when.
An FPGA doesn't really have anything ready-made baked into it. All it has is a few tens of thousands of primitive logic gates (as well as a few DA and AD converters and a timer, or four). That's pretty much it. Whatever you want to do with that thing, you first have to literally build it yourself. Need a 3 bit adder or a 12 bit comparator? Good! They're all yours! That's especially neat because a microcontroller wouldn't have those! But you'll have to build them yourself by wiring up all those basic logic gates in just the right way so that they behave just the way you want them to.
You can think of a microcontroller as something like a Swiss army knife. You can MacGyver your way out of a Russian gulag with it, but you'll quickly run into a bunch of limitations when you find yourself in a situation where you need something that your pocket-sized tool kit doesn't have.
An FPGA, on the other hand, is more like a lumber mill, chemistry set, and foundry wrapped into one. You can still do pretty much everything you want with it, but you will first have to make all the tools that you need to get the job done yourself.
So, the benefit of a microcontroller is that you can do a whole bunch of things with it right out of the box. You can get stuff running quickly and with very little effort. But you'll be limited in all kinds of ways. The most relevant limitation when you use a microcontroller is usually processing speed, because it will run your program in a serialized way, step by step, one instruction after the next.
The benefit of an FPGA is that there's almost nothing you can
not do with it, but not without having to invest a metric crap-ton of time and effort upfront. But because you have to make all the tools yourself, you have full control over how they're made, how complex or simple they will be, and how they will be controlled.
That means that if you're smart about how you approach the setup of your toolset, you can for example parallelize a lot of the tasks that you want to do. You want to create a DAC that is supposed to process two channels simultaneously? Well, with a microcontroller, you either have to find one with two or more cores, which aren't all that common, are relatively expensive to source, and get quite power hungry. Or you have to split your two data streams up into chunks and process them in series, quickly alternating between the two.
With an FPGA, you would have the ability to wire* a few thousand of your basic logic gates together so that they eventually act like a single channel DAC. The thing you just created is called a "core."
Then you apply the same bunch of code again to yet another set of a few thousand of your logic gates, and now you have created yourself two signal processing cores that do exactly what you need them to, nothing less and nothing more, and you can actually have them run in parallel!
Wanna process six channels in parallel? Good luck finding a microcontroller that has six cores, but you can wire up six audio signal processing cores in your FPGA with relative ease. (As long as you don't run out of logic gates, that is.)
Even better yet: You can split your core into as many autark sub-cores as you want, and wire* these things up so that one sub-core of your signal processor can already start chewing on the next chunk of bits while other sub-cores of the same signal processor are still busy doing their respective thing with the previous chunks!
Nifty, right?!
Yeah, if only people actually programmed their FPGAs that way…
You have a choice of two different languages to program your FPGAs: VHDL, and Verilog. Either one isn't all that difficult to learn, but doing so still requires a little bit of effort. And once you've learned one of them (or both, if you wanna feel extra geeky), you still have to painstakingly write all the code that you need so that the thing knows how to wire itself up to create those cores and sub-cores for you.
And that takes a LOT of time and effort. For something as complex as a DAC, for example? You'd be talking person-years. Plural.
To avoid having to do that, you can buy so-called "soft-cores." Those are unfortunately not X-rated, but they can still be quite enjoyable insofar as they make your life a whole lot easier. Soft-cores are chunks of code for your FPGA that let you do certain things in a somewhat more flexible way. You can think of them like knife blades and saws and files and tooth picks and can openers and little scissors and screws and leaf springs — all the fun stuff you need to make precisely the kind of pocket knife you need for the job, but another foundry has already manufactured them for you. All these separate bits and pieces are (hopefully!) already fully debugged for you, and all that's left for you to do is to put them together in such a way so that they become the pocket knife of your dreams. You can even "screw" them together and control them with so-called "glue logic" written in a more widely known language, something like C or C++.
But here's the thing: You didn't make all those bits and bobs yourself. They get the job done, but you have zero control over HOW they get the job done. Because those soft-cores have to remain quite flexible in nature, they tend to be everything but optimized. Your pocket knife does everything you dreamt of, but it's a whole lot bigger and slower than it really needs to be. And I mean a WHOLE LOT bigger and slower, not just a little bit.
And if something doesn't quite work the way you need it to, you can't really change it.
And if something breaks? Well, let's just say that I hope the author is still around, or that you can at least find a suitable replacement for that broken soft-core.
And that's why I think that the whole FPGA thing in recent years is mostly just a fad. People (and a lot of companies who use FPGAs in their products) throw around terms like "massively paralleled computing" and "mind-boggingly fast" and "fantastic performance per watt" — all of which is in theory correct — but then proceed to program and use them pretty much just like any old microcontroller. They merely end up with a bigger, more expensive chip that's not actually all that better at what they do with it than if they'd just used a microcontroller instead.
Not always, of course, but unfortunately more often than not.
Again, because it is critically important: I am
NOT speaking for Schiit here. Nor any other company in particular. It's just something that I've generally noticed once I started looking into potentially using an FPGA for a project of mine a little less than a year ago.
One good example for the use of FPGAs is Microsoft's Bing, where MS uses large arrays of FPGAs with custom code to take over certain processing tasks that can be done much faster on those things than they could be done even in high-powered general purpose CPUs.
Other applications that FPGAs can shine at are wherever you need to control and/or monitor hardware, like automated assembly lines.
Essentially any kind of task that has relatively simple computing requirements but that has to be done with as little latency as possible.
So, long story short:
Whether there's an FPGA in something or not doesn't tell you anything about whether the product is any good or not.
You can have a great DAC that uses an FPGA, just as much as you can have a really crappy one that also uses an FPGA.
But at the same time, you could have a fantastic DAC built around a "boring" microcontroller or a DSP chip, like the Multibit DACs are. Heck, even your chip-based DACs can sound fantastic if they're done well.
It's not about what kind of control architecture is used, it's all about how it's implemented that makes or breaks a DAC.
Personally, I have little doubt that whatever that Singularity thing that I saw and heard last October will eventually end up in will probably sound pretty darn good.
We're talking about Schiit, after all. They don't really seem to know how to make a bad-sounding DAC.
But I don't blame them, I certainly have my own flaws, too.
* You don't actually create any wiring inside your FPGA, but the code you write will make use of a whole bunch of lookup tables and switches to send your electrical signals to those logic gates in just the right way so that they act as if you had actually wired them together in a certain way.
I still was able to get sound from the DAC, but will drain the power and not recharge. Can’t find any work arounds or fixes yet.
