4 ms·
Parallelizing SHA256 Calculation on FPGA
- 15155 1y agoNow try a fully unrolled/pipelined design that emits one hash per clock cycle for actual parallelization.
- 01HNNWZ0MV43FF 1y ago[flagged]
- deleted 1y ago[deleted]
- Retr0id 1y agoSo what's the overall hashrate with this approach? I'll try to calculate it from the information given. 12 parallel instances at a clock speed of 62.5MHz, with 68 clock cycles per hash. 62.5MHz * 12 / 68 = ~11MH/s That seems... slow? Did I do the math right? How big of an FPGA do you need before this would compete with a GPU, and how much would it cost? For reference, an RTX 4090 can do 21975.5 MH/s according to hashcat benchmarks.
- picture 1y agoQuite slow. It's largely due to the author using FPGAs wrong. Clocking down a 7-series Artix to 62.5 MHz means the design is not pipelined correctly/enough. My friend got 1 SHA256 hash per cycle at 300 MHz on 7 series, but slightly fewer of the design fit on a chip. Thruput would easily be in the GH/s range. Keep in mind RTX4090 is 5 nm process node and has a lot more transistors and memory than XC7A100T, which is 28 nm. That's a huge difference in terms of dynamic performance. Also, the two are also released 10 years apart. If you compare RTX4090 against a similarly modern UltraScale part from Xilinx, I believe the FPGA can be notably faster than RTX4090.
- benlivengood 1y agoI'm assuming this space has already been heavily optimized by the Bitcoin miners on their way to ASICs.
- picture 1y agoYes, hard silicon will be another magnitude more performant than FPGAs and GPUs, but ASICs properly take on negative value when they're no longer profitable to mine with. (Note that efficiency won't be much better at the same process node. You can just pump more power through each ASIC die) Edit - I misread your comment. ASIC designers will use FPGAs to test their design but it won't be optimized for FPGAs which have a different logic-and-memory characteristic than ASICs. There aren't many great SHA256 FPGA implementations, largely because there's not that much demand for one
- d00mB0t 1y agoMore posts like this please! How about a crypto accelerator on FPGA that's integrated with OpenSSL?
- 15155 1y agoUnless you're talking about niche algorithms (and even then), the FPGA will get smoked by a CPU for most common tasks one would use OpenSSL for.
- d00mB0t 1y agoYes--obviously modern CPUs have crypto extensions that would be faster than an FPGA,this would be for educational purposes.
- 15155 1y agoEven without the extensions, by the time you've moved the workload to the FPGA and back, the CPU has already completed whatever operation your FPGA was going to complete with OpenSSL. FPGA cryptographic acceleration is about batch task bandwidth, OpenSSL has few places where this is required.
- toast0 1y agoIf you want to do crypto acceleration for TLS, there's two places to do it. Handshake/signature/key agreement, which could maybe work, but hasn't been the bottleneck in a long time, eliptic curve dramatically reduces the work for the server and most clients can do it; but maybe shipping the data around for that is fine. The other part is bulk encryption. CPUs have lots of acceleration for that, but clear text is still faster, so the win is not to ship data to an accelerator and then back to the cpu and then out to the NIC, but to ship to the accelerator and from there to the NIC without touching the CPU or often the accelerator is integrated with the NIC. It works even better if the data never has to touch the CPU.
- 1y ago
- qdotme 1y agoGreat job! For alternative design/writeup, check out http://nsa.unaligned.org http://nsa.unaligned.org
- deleted 1y ago[deleted]
- projektfu 1y agoThat seems to be the inverse function for SHA-1 and MD5.