I'm designing a custom FPGA board, for something low-cost like a Xilinx Spartan 6. I want to perform research about solving memory-intensive algorithms in an FPGA.

As we all know, memory bandwidth is often a bottleneck, especially in low-cost solutions like Spartan 6. However a middle-end GPU has 150+ GB/s of memory bandwidth.

Is there any way to increase bandwidth in a low-cost FPGA to near-GPU levels?

I see only few ways:

  • Connecting high-bandwidth memory like DDR4 to GPU chip and connecting all to the FPGA (kinda strange solution and I don't know if it's feasible and, if it is, won't the bandwidth between GPU and FPGA become a bottleneck?)
  • Using multiple wide and fast memory interfaces to connect off-chip memory to FPGA
  • Using custom controllers, connections or something else, optimized especially for this task to improve bandwidth

I care for at least 100 GB/s. On a low-cost Spartan 6 FPGA, this bandwidth would be success. Or it's impossible with this piece of hardware at all?

  • \$\begingroup\$ Achieving 100GigaBytes on anything "low cost" just isn't going to happen without an ASIC, but, achieving 100Gigabits is doable, QDRIV SRAM chips have a pair of bi-directional 36bit busses, affordable FPGAs top out at ~1.4gbits per pin (slowst QDRIV chip I've seen is 1.333Gbit), this gives ~96Gbits of (low latency, low overhead) bidirectional bandwidth without the complexity of a very wide DDR3 bus \$\endgroup\$
    – Sam
    Feb 19, 2018 at 20:08
  • \$\begingroup\$ Spartan 6 came out it 2009. Current Virtex Ultrascale+ parts can be bought with High Bandwidth Memory (HBM) which gets you 460GB/s or Hybrid Memory Cubes (HMC) for 160GB/s. xilinx.com/support/documentation/white_papers/wp485-hbm.pdf \$\endgroup\$
    – ks0ze
    Feb 19, 2018 at 20:50
  • \$\begingroup\$ @Sam, but the OP clearly said GB not Gb so...? \$\endgroup\$
    – TonyM
    Feb 19, 2018 at 22:40
  • \$\begingroup\$ Are you making a cryptocurrency miner? (I have no reason for asking this beyond wondering if my guess is correct) \$\endgroup\$
    – user253751
    Feb 20, 2018 at 4:19
  • \$\begingroup\$ @TonyM True, but the number of times I've seen GB instead of Gb... the question was asking about hitting 100GB on a spartan 6 which is far in excess of what any spartan 6 could realistically achieve so I thought I'd offer some advice just in case it was supposed to be 100Gb. \$\endgroup\$
    – Sam
    Feb 21, 2018 at 7:55

1 Answer 1


I care for at least 100GB/s. On low-cost Spartan 6 FPGA this bandwidth would be success. Or it's impossible with this piece of hardware at all?

Impossible. Let's assume you're using a 512-bit memory interface, consisting of 8 memory modules in parallel. This would be very close to the maximum user I/Os on the largest available Spartan-6 part (540 user I/Os on the XC6SLX150T), and even then you might run over the limit with control signals. Even assuming this memory interface was possible, 100 GB/sec would require an I/O clock rate of ~1.5 GHz (assuming 100% efficient memory access!), which is unlikely to be attainable on a Spartan-6.

For memory-heavy applications, a GPU is often a surprisingly good solution.

  • \$\begingroup\$ I thought so. So I need a GPU high memory bandwidth and FPGA speed in order to create extreme hardware for extreme memory tasks? Is this combination feasible? \$\endgroup\$ Feb 19, 2018 at 19:43
  • 3
    \$\begingroup\$ No, you just need to remove the "low-cost" constraint. FPGAs with HBM (high-bandwidth memory) exist; they're just orders of magnitude more expensive than the devices you're currently looking at. \$\endgroup\$
    – user39382
    Feb 19, 2018 at 19:48
  • 4
    \$\begingroup\$ There is one more caveat for FPGA regarding wide bus switching: FPGAs usually have a limit on how many pins can be toggled in parallel, due to limits in internal power distribution and resulting current starvation of I/O ring. \$\endgroup\$ Feb 19, 2018 at 20:37

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .