AMD announces the Spartan UltraScale+ FPGA family
cnx-software.com
cnx-software.com
Having knowledge of upcoming parts is important in hardware engineering for planning purposes.
But the flip side is most of them tell you ahead of time whether something is recommended for new designs, and how long they will guarantee production for.
Which is much more important.
In this day and age with FPGA companies being merged and spun out left and right, i doubt anyone relies on the future line announcements this second.
In more normal times I agree you want to know if you are going down a dead end path.
And you can very often prototype with either an overpowered development board or you own prototype board with another FPGA, and then downsize appropriately as the project advances. Most importantly, if you know there will be a viable version in a year, you can postpone the final decision and Xilinx get to avoid having you choosing Altera now if it's possible that their new offering will match your project.
https://www.intel.com/content/www/us/en/healthcare-it/produc...
Edit: I just realized that these are some literal killer apps. That wasn't even intentional, lol.
Yes.
> I think the biggest reason is that you can build/verify your own hardware without having to go through the expensive ASIC manufacturing.
Plus, you don't give out your secrets to fabs, too. Design, verify, launch, discard, without the need for signing an NDA.
That's a perfect answer to my question, thank you.
Also many other great answers in this thread, but I don't have much to add.
"Yessir."
"Jones, why isn't that SAM in the air?"
"Sarge, it's flashing the bitstream. The progress bar says 60%."
- High-frequency trading (executed in-fabric)
- Niche real-time video devices, etc.
- Cryptocurrency mining
- Real-time motor pulse generation for robotics
- Custom NICs and HPC devices
- RF signals processing (radar, guidance, etc.)
For instance, audio, video or other signal processing can be done by putting the algorithm "directly" into the hardware design; it will run at a constant predictable speed thereafter.
A while back I wrote an entire FPGA pipeline to recalibrate signals from optical sensors before they were passed on to the CPU. Doing this allowed us to keep up processing speed with acquisition, so it was real time. A lot of FIR filters and FFTs. But my proudest achievement was a linear interpolation algorithm which is fairly high level and tricky to implement on FPGA, which is more geared towards simpler DSP algorithms like FIR filters, and FFT (not simpler but so much effort has got into making IPs it effectively is because you don't have to implement it yourself)
But other than that, for raw bulk compute GPUs are kicking their butts in most domains.
If you need a lot of realtime processing to drive motors (think industrial robots of all kinds), FPGAs are preferred of micro-controllers.
All kinds of industrial sorting systems are driven by fpgas because the moment of measurement (typically with a camera) & the sorting decision are less than a milisecond apart.
There are many more, it's a very 'industrial' product nowadays, but sometimes an FPGA will pop up in a high-end smartphone or TV because they allow to add certain features late in the design cycle.
They are used everywhere, including some very small ones I've seen used purely for power sequencing on motherboards - usually very small FPGA with embedded memory that "boots" first on standby voltage and contains simple combinatoric logic that controls how other devices on motherboard are getting powered up faster than any MCU can do it - while taking less space than discrete components.
Glue logic, custom I/O systems (including high-end backplanes in complex systems), custom devices (often combined with "hard" components in the chip, like ARM CPUs in Zynq series FPGA), specialized filters that can be runtime updated.
Lots of uses.
I'm pretty sure there's an FPGA in most consumer devices now, but as you say they're there for some sort of glue logic - but that's a killer niche unto itself. Schematics can shift and change throughout a design cycle, and you only need to rewrite some HDL rather than go hunting for a different ASIC that's fit for purpose. It's a growing field again as their cost has come right down. They're in the Apple Vision headset, the Steam Deck, modern TVs, and a host of small form factor consumer computing products.
Just a tiny nitpick to your great answer but Nokia's 5G base station stuff (Reefshark) is built around ASICs. I would expect others do the same. There's some reasoning at https://www.electronicdesign.com/technologies/embedded/artic...
https://www.nokia.com/about-us/news/releases/2020/06/15/noki...
Very glad to hear things have improved.
I can’t think of the last time I saw an FPGA on a mainstream consumer device. MCUs are so fast and have so much IO that it’s rare to need something like an FPGA. I’ve seen a couple tiny CPLDs, but not a full blown FPGA.
I frequently see FPGAs in test and lab gear, though. Crucial for data capture and processing at high speeds.
Some FPGAs are absolutely tiny e.g. you might just use it as a fancy way of turning a stream of bits into something in parallel for a custom bit of hardware you have, other FPGAs are truly enormous and might be used for making a semi-custom CPU so you can do low latency signal processing or high frequency trading and so on.
But even a very cheap FPGA will beat any CPU/GPU on latency.
Before you had to have:
A. a PLC that ran logic with real time guarantees to tie everything together. The PLC is often user-modified to add more logic.
B. Decoders that processed several mhz encoder feedback signals, somewhere between 3 and 10 of these.
C. Something that decides what to do with the data in B
D. Encoders and motor driving, also being output at several mhz (somewhere between 3 and 10 of these as well)
Among other tasks.
These were all separate chips/boards/things that you tried to synchronize/manage. Latency could be high. But if you are moving 1200 inches per minute (easy), 100 milliseconds latency is equivalent to losing track of things for 2 inches. Enough to ruin anything being made.
Nowadays it is often just an FPGA hooked up to a host core.
(or at a minimum, a time-synchronized bus like ethercat)
Most of the ASICs with these SerDes interfaces are not for sale on the open market, only for OEM who buy MOQ of millions.
Take for example the Raspberry PI SBCs. The Raspberry Pi only got PCIe very late (compute model 4), influencer Jeff unlocked them with a lot of difficulty https://pipci.jeffgeerling.com but you still can't buy these cheap microprocessors from Broadcom.
The reason is that no cheap PCIe chips are available for hobbyists and small company buyers (below a million dollars).
'Cheap' FPGA's starting at $200+ where and still are the only PCIe devices for sale to anyone. If you want to nitpick, a few low speed Serdes are available in $27 ECP5 FPGA's, but no 10 Gbps and higher.
Another example, I sell $130 switches with 100 Gbps switching speeds and PCIe 4x8 and QSFP28 optics. But you can't buy the AWS/Amazon ASIC chips on this board anywhere, nor their competitors chips from Broadcom, Intel, MicroSemi/Microchip, Marvell.
I went as high as Intel's vice president and also their highest level account manager VPs and still got no answer on how to buy their ASIC switches or FPGAs.
High-risk operations could run the most critical stuff on these CPU’s. That would reduce the security effort from who knows how many person-years to basically spending more per unit and recompiling. Using lean, fast software would reduce the performance gap a bit.
CHERI is now shipping in ASIC’s, works with CPU’s that fit in affordable FPGA’s, and so this idea could happen again.
* Replacement parts for vintage computers * Flash cartridges and optical drive emulators for older video game consoles * High-speed, high quality analog video upscalers
Many of these things aren't produced at a scale where producing bespoke chips is not really viable. Using an FPGA lets you build your product with off the shelf parts, and lets you squish bugs in the field with a firmware update.
There is also MiSTer, an open source project to re-implement a wide range of vintage computer hardware on the Terasic DE10-Nano FPGA.
What made Spartan-6 unique was in addition to having transcievers was the hardened DDR memory controller.
If you read this announcement, DDR support is done via 'soft' memory controller, which chews up a lot of resources and makes meeting timing frustrating, forcing use of Xilinx's MIG IP.
Hey, the Spartan line is useful again!
What am i missing?
(IE It's still only pcie gen3, and this announcement doesn't change that)
Also, it looks like PCIe Gen 4. The bitrate is enough and the page says Gen4x8. Is there something I'm missing?
Similar issues as Artix Ultrascale+ where the small print says " PCIe Gen4 is available in AU10P and AU15P in the FFVB676 package. AU10P and AU15P in other packages support Gen3x8.". Same die for all these FPGAs but not same speeds at given prices. Most of the die will be disabled, 'binned'.
So Spartan 7 Ultrascale+ can theoretically support 8 lanes of PCIe Gen 4.0, but if they actually do at the price you pay is unclear and also if the PCIe 4 IP is free or very expensive and only available in the expensive toolchain under NDA?
[1] https://www.xilinx.com/products/boards-and-kits/device-famil...
It’s like USB full speed and USB high speed. They’re largely meaningless marketing terms just to differentiate generations.
Spartan is the glue-logic family for applications that either do not require any kind of CPU core at all or where some simple soft-core (MicorBlaze, x51, hand crafted state machine...) suffices.
The Zynq product family already exists.
Something "horribly" simple I hope and suppose (memory mapped command ring buffers and dma buffers?)
Then quickly getting up and running a shmol RV64 core... and I guess this is hacker paradise.
There is no DMA or command ring, you have to implement it yourself.
The FPGA bit code itself is extremely propertiary to each vendor as the nature of controlling all the logic sauces is all secret sauce. So you have to use the vendors tooling.
You will use Vivado and you will like it!
Vivado
> Then quickly getting up and running a shmol RV64 core... and I guess this is hacker paradise.