I was thinking PCIe spec backplanes, but I see what you’re referring to. I would be surprised if the edge connectors electromechanical could support higher than 16 per transceiver, they’re a pretty loose fit. I’ve seen how much engineering goes into things like sea-ray connectors but as you said BER may remain acceptable for losses crypto mining. I also forgot PCIe is bi-directional as well, so 16 TX + 16 RX pairs as much as ~400Gbps each way in a ring. still 1/16th of what would be available with a dedicated 128 transceiver design, and those parts are in the ballpark of a VCU1525 in quantity. Take a look at some of the ASIC verification setups based on 4+ VUP parts. HTG I believe has some.

I wouldn’t say an all out attack on GPUs by FPGAs. A good portion of my work has been on FPGA “accelerators” that augment GPUs. GPUs still have way more memory bandwidth than FPGAs after the cache-sized blocks. I have developed some interesting FPGA coprocessor that replace inefficient GPU calculations with FPGA work but still do the memory hard loops on GPU, for overall hashrate and power gains. I expect that hardware to be ready midsummer. Remains to be seen if it will still be viable.

I won’t say it’s impossible, but I would be really genuinely surprised. 32MB / hash of total bandwidth (read + write) is needed, and 2MB or so of stashes per hashcore.

You have 1280 URAM blocks of 288kb by 72 bit interface dual ported in the biggest configuration .That’s an incredible amount of internal bandwidth but you can only store 23 or so simultaneous Cryptonight7 2MB blocks in that. The absolute biggest part (which isn’t on the 1525 board) has 360Mbit URAM, 96Mbit BRAM, and 48Mbit Distributed RAM, holding a theoretical 63 MB of pipelines, assuming you didn’t need a single bit of that for the rest of your logic (you do).

The external memory at say 4x64 DIMMs @2666 is only 85GB/s, or 2.6 KH worth of bandwidth with a perfect access pattern.

Even if you could imaginarily use all 2000+ balls on the FPGA for 2666 MT/s DDR style  speeds you’d still only clear 20KH against external memory and that isn’t even real bandwidth.

 Even if you took the biggest part with 128x32 Gbps transceivers to SERDES memory you’d only have 16kH limit from bandwidth.

Unless you break the algorithm itself, there’s no where to find the bandwidth + storage space for 64khs on a single FPGA.

PCIe, even 4.0 for which backplanes are not yet available, is 8 or 16Gbps per transceiver vs 28 Gbps in the QSFP28s

I wasnt referring to 1525s though, I was speaking about other boards with 56+ transceivers exposed.

That’s a pair of 6xQSFP28 adapter that connects to the FPGA transceivers, with 100Gbps Direct attach cables.

Aka as 6x100Gbps worth of interconnect between two more typical Virtex development boards.

Still working on it, it “runs” 22kH but not completely convinced a good portion of that isn’t spitting errors. I’m using a relaxed definition of correct to squeeze higher hashrate out while allowing some rare corner cases to be incorrect. Currently more hashes than expected are incorrect.

Keccak @ 11 GH, ~500Mhz 22 full pipelines, but I wasn’t strictly targeting Keccak directly so I didn’t push it to the limit.

For CryptoNightV7 I do the finalizer off FPGA because it’s hardly worth the area for the other SHA-3 candidates.

Kramble was trying to milk real power out of very tiny FPGAs and use lots of them. This isn’t efficient any more, vs this which is using very high end FPGAs that are designed for this type of crunching. They work very well at it, I’ve been doing this for a while.

If you’re not constrained to the 1525 (though most non-FPGA devs will be), use something like this and you have 600Gbps between boards or 300Gbps chain.

[quote author=Wolf0 link=topic=2647654.msg31357143#msg31357143 date=
You can back up the accusation of being stolen from open source, I take it? I rewrote my Ethash over a dozen times. At least four of them was in pure GCN assembly without a starting template.
[/quote]

That was meant more anecdotally than accusitorily, in general I don’t think code or binaries were copied directly so much as techniques. Ethash isn’t that complicated so there are only so many ways to write it. I do believe I’ve seen higher level stratum and other code that very much looks like someone started with an ethminer fork though. I don’t necessarily think this is wrong as much as standing on shoulders of existing work.

I am also very active in the low level side of this, and have also dumped both kernels at a mock hardware level and can absolutely confirm Claymore’s post. Private kernels developed to match specific hardware can be developed that are faster than Claymore’s, but significant work has gone into those kernels. They are absolutely rights  of Claymore and stolen in this case. Never mind all originally stole from open source...