I wont say its 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 .Thats 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 isnt on the 1525 board) has 360Mbit URAM, 96Mbit BRAM, and 48Mbit Distributed RAM, holding a theoretical 63 MB of pipelines, assuming you didnt 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 youd still only clear 20KH against external memory and that isnt even real bandwidth.
Even if you took the biggest part with 128x32 Gbps transceivers to SERDES memory youd only have 16kH limit from bandwidth.
Unless you break the algorithm itself, theres no where to find the bandwidth + storage space for 64khs on a single FPGA.
You have 1280 URAM blocks of 288kb by 72 bit interface dual ported in the biggest configuration .Thats 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 isnt on the 1525 board) has 360Mbit URAM, 96Mbit BRAM, and 48Mbit Distributed RAM, holding a theoretical 63 MB of pipelines, assuming you didnt 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 youd still only clear 20KH against external memory and that isnt even real bandwidth.
Even if you took the biggest part with 128x32 Gbps transceivers to SERDES memory youd only have 16kH limit from bandwidth.
Unless you break the algorithm itself, theres no where to find the bandwidth + storage space for 64khs on a single FPGA.
You're missing a really big part of the ultraram. One of the most attractive things that ultraram has to offer. True dual port single clock read/write. Also, when you chain ultrarams together it increases the bus width proportionally to the amount it increases the latency. I never completed monero but my estimates were in the 4-8Kh/s per board range at 100W.
I wasnt missing it - the true dual port is truly the reason it works as well as it does - write completion before read in the dependency chaining. The issue (at least with cryptonight) isnt the bandwidth at all, it is the amount available. Ultraram is great in general.
There's also a bunch of block ram and distributed ram. AES itself is tiny (<30K luts) and the secondary hashes don't need to be completed on the FPGA (meaning, you don't really need to put groestl, jh, etc on the fpga, you can just read the 8Kh/s and complete the secondary on CPU). While I have those completed (the secondaries), I had never intended on putting them on the fpga for cryptonight.
Im not sure you actually read my posts on the topic, as youre repeating a few things I already stated - such as I dont do secondary hashes on the FPGA. 30k LUTs for AES? Thats a huge amount more than my cores...
I was going through all the threads and scanning. I'll admit I didn't read everything. And ya, I'm a little
high on my aes size estimate. How many are you currently operating or are you mainly leasing?
It's kind of funny, I would lurk the aws forums and see all the questions from people who were obviously mining. No one would admit it, or talk about it, for fear of revealing the secret. Now it's out and it can be talked about
-- Btw, to the op, you're wrong about AWS caring that people mine on their servers. You're not allowed to use shared resources for mining. Dedicated resources you can do whatever you want with. I've been mining on AWS and in regular contact with the AWS engineers running the F1 project since June 2017. I was also in the beta program.