ProgPow ASIC possibilities evaluated by 2 experts

[MoneroCrusher]

SChernykh/CryptonightR#1 (comment)

In fact, a carefully designed ASIC could still outperform GPU by spending more resource/area on the bottlenecks. The memory bandwidth can be greatly improved using more smaller DRAM partitions and parallel memory controllers with address interleaving. The random math cannot utilize GPU’s float point ALUs, tensor cores and certain on chip memory, which occupies much more area than the tiny integer ALUs. An ASIC implementation could just build more simplified integer ALUs, multi-bank RFs with a very simple decoder for better TLP. It is also possible to achieve chained operations with reconfigurable ALU-array.

What's IfDefElse's take on this?

[jean-m-cyr]

No argument, but you understate the complexity of such an ASIC. What you are talking about is a set of integer math or DAG accessing logic blocks with programmable sources and destination. These blocks would need to be programmatically sequenced to form the necessary computational chain. When I say programmatically, I don't mean it in terms of software control, but rather in terms of digital logic block inputs.

ASICs achieve efficiency by maximizing logic block usage with a technique called pipelining. Imagine applying it to progpow. Each stage of the pipe will need to carry its own copy of the mix array, the sequencer state and the multiple transform block inputs. Then of course you need to manage multiple stages competing for dag access. Order of magnitude more complicated than an ethash ASIC!

[salanki]

To be able to fully assess any specialized chip manufacturing, we need to know not only potential power efficiency improvement, but all of the following:

• Development Cost
• Development Time (part of cost)
• Manufacturing cost
• Performance per manufacturing or purchase $

The analysis in here, except for the DRAM statement (that I will let someone more knowledgeable than me answer) seems to be in line with the potential optimizations that IfDefElse have already outlined. We have seen different claims (10%, 20%, 50%, 800%) of potential efficiency improvement. What I have not seen from anyone is an analysis of the actual effort to build all of this.

[ifdefelse]

I had not looked into CryptonightR before. It looks promising but has some limitations. The basis is similar to ProgPoW in that a random sequence of math is generated every few minutes and compiled offline. This is unlike RandomX where every hash has a unique random sequence. RandomX is actually more ASIC-friendly because of the per-hash sequence, which requires online compilation that an ASIC could directly implement.

This comment I think is extremely good, showing that simple changes like Ethash 1a, which just change a constant, will not be effective as ASIC manufacturers can easily anticipate small tweaks like that and build flexibility into their designs:
SChernykh/CryptonightR#1 (comment)
https://eips.ethereum.org/EIPS/eip-1355

The quoted comment is given in the context of CryptonightR, not ProgPoW. Cryptonight does tiny accesses to DRAM, which are exceptionally inefficient for existing GPU memory controllers. Cryptonight V2 is better after it increased the access from 16 bytes to 64 bytes, but it's still wasting memory bandwidth. ProgPoW increases Ethash's 128 byte access to 256 bytes in order to be efficient on all existing GPU memory controllers.

ProgPoW makes use of a GPU's shared (aka local) memory while CryptonightR does not. Both CryptonightR and ProgPoW do not make use of floating point, tensor cores, L2 cache, graphics stuff (like textures), etc. However this underutilized portions of the GPU should not have any significant effect on power consumption. An ASIC that removed these portions would be have a smaller die size, but not otherwise be meaningfully more efficient.

I don't think a chained ALU array is practical to implement for either ProgPoW or CryptonightR. This is especially the case for ProgPoW where the mix state is 16 * 32 * 32-bits and about 1/3rd of the instructions need to access random locations in the cache.

[tevador]

RandomX is actually more ASIC-friendly because of the per-hash sequence, which requires online compilation that an ASIC could directly implement

JIT compilation of RandomX code takes less than 0.5% of the time (~10 μs per hash). A ProgPoW ASIC can get a bigger efficiency gain than this just by having a native 32x32 multiplier [1].

The advantage of "online" compilation is that is forces an ASIC to dedicate die area to instruction decoders and dispatchers (which the CPU already has) rather than using a small FPGA to handle the slowly changing part of the algorithm.

[jean-m-cyr]

@tevador The notion of 'using a small FPGA to handle the slowly changing part of the algorithm' is not a workable solution. Compiling a bit stream to program an FPGA is an hour long process running on a high end system, for even the simplest algorithm. Furthermore, it requires the use of vendor specific proprietary tools that could not run on individual miner platforms.

[tevador]

@jean-m-cyr I'm no expert in this field, but are you suggesting it's impossible to design a custom ASIC with hardwired operation blocks (such as multiplication, addition and popcnt) and only program a small SRAM block that specifies how operations are ordered and what their inputs are?

Based on the description of the ProgPoW loop, the 'bit stream' for ProgPoW would be roughly 400 bits [1] long, which is many orders of magnitude less than a typical bit stream for a big FPGA chip like Xilinx VCU 1525 (several megabytes).

[1] 12 cache loads with a random source and destination and one of 4 merge methods = 225792840² * 4¹² total options. 20 math operations with a random source, destination, one of 11 operations and one of 4 merge methods = (32*31*4*11)²⁰ total options. Estimated ~388 bits of entropy in total.

[jean-m-cyr]

400 bits sounds low given that the FPGA would need a RAM interface for DAG access (or at least a bus to the main ASIC) ... Nevertheless, how would you generate that bit stream on the fly? Using which tool set?

388 bits of entropy != 388 bit stream.

Not to mention that FPGAs are notoriously power inefficient.

[tevador]

RAM interface for DAG access

RAM interface would be hardwired, not part of the FPGA.

Nevertheless, how would you generate that bit stream on the fly? Using which tool set?

Probably a custom toolset developed by the company that is designing the ASIC. Given the relative simplicity, it could run on the ARM controller which would precompile bit streams in advance.

388 bits of entropy != 388 bit stream

True, but I don't think the bit stream would need to be more than the order of ~1 kilobit.

[jean-m-cyr]

RAM interface would be hardwired, not part of the FPGA.

Even if the RAM ctlr. is on the main ASIC, the FPGA still requires high speed access to the DAG via the ASIC's mem controller. This implies a wide data bus that supports addressing between the FPGA and ASIC. Going off-chip with a high speed bus is expensive in terms of power.

Probably a custom toolset developed by the company that is designing the ASIC. Given the relative simplicity, it could run on the ARM controller which would precompile bit streams in advance.

FPGA tools contain highly proprietary algorithms that require large amounts of RAM and processing power. I think you underestimate the complexity involved with generating an FPGA bit stream.

True, but I don't think the bit stream would need to be more than the order of ~1 kilobit.

I doubt it! In your entropy calculation you speak of 11 arithmetic ops. and assign 4 bits of entropy. Each of those 11 blocks will require far more than 4 bits in the stream to specify and interconnect the required FPGA elements.

[tevador]

This implies a wide data bus that supports addressing between the FPGA and ASIC.

'FPGA' and 'ASIC' here are not two separate chips. Everything is on a single die. Only the interconnects would use FPGA-style LUTs. The execution units themselves would be hardwired for maximum efficiency.

Each of those 11 blocks will require far more than 4 bits in the stream to specify and interconnect the required FPGA elements.

You have a pair of 32-bit datapaths, which can go into one of 11 execution units. I imagine you can use a multiplexer with 4 bits of SRAM to select the path to the execution engine. Am I wrong?

[ifdefelse]

are you suggesting it's impossible to design a custom ASIC with hardwired operation blocks (such as multiplication, addition and popcnt) and only program a small SRAM block that specifies how operations are ordered and what their inputs are?

You have a pair of 32-bit datapaths, which can go into one of 11 execution units. I imagine you can use a multiplexer with 4 bits of SRAM to select the path to the execution engine. Am I wrong?

You're essentially describing how classical CPUs, GPUs, DSPs, etc are designed. A handful of fixed function datapaths and then some muxes that route data between the register file, caches, and datapaths. Whether those muxes are controlled on-the-fly by instructions or semi-statically via a few bits of FPGA-style SRAM doesn't make a meaningful difference.

FPGAs gain significant efficiency when you can create a dataflow pipeline, where intermediate results are never stored but are directly consumed by the next step of the pipeline. This structure doesn't work for ProgPoW. ProgPoW requires a large amount of state (16 lanes * 32 words * 32 bits = 2 kilobyte) that needs to last across many cycles (at least 12 cycles for the 12 cache accesses). Setting up a pipeline to directly compute the random ProgPoW sequence would result in a massive duplication of compute resources (would need all 11 options available for every compute stage, even though only 1 is used) and repeating mix data that mostly doesn't change.

Once the mix data is stored in a register file any design is going to look a lot like a CPU's SIMD unit or a GPU.

[Sonia-Chen]

https://medium.com/@Linzhi/eip-1057-progpow-open-chip-design-for-only-1-cost-power-increase-eip-1057-progpow-d106d9baa6eb

// Random math between two input values
uint32_t Math(uint32_t a, uint32_t b, uint32_t r)
{
switch (r % 11)
{
case 0: return a + b;
case 1: return a * b;
case 2: return mul_hi(a, b);
case 3: return min(a, b);
case 4: return ROTL32(a, b);
case 5: return ROTR32(a, b);
case 6: return a & b;
case 7: return a | b;
case 8: return a ^ b;
case 9: return clz(a) + clz(b);
case 10: return popcount(a) + popcount(b);
}
}

*) modulo 11 operation, this is quite small logic, ~400gate, 1ck latency, can be a parallel process during mix read so we can hide this latency.
*) 32-bit Add, simple logic, ~300gate for a fast one.
*) 32-bit Multiplier, mature IP, ~20Kgate for a fast one, since multiplier only have ~4/11 activity rate, we can use a two cycle multiplier to half the area, small possibility to increase delay.
*) Rotation operation can easily map to a multiplier, for example I want to calculate ROTL(0x12345678, 8), I can do 0x12345678 * 0x00000100 = 0x0000001234567800, then we just need to OR higher word and lower word together to get 0x34567812. so just cost ~160gate extra logic
*) logic operation, A&B only cost 32 gate, A|B 32 gate, A^B 96 gate, it looks like three different instructions but actually extremely small on silicon (<30um²)
*) clz and popcount are also very small
*) We only need a multiplexer to select output.
*) Total size of Math() is about 0.0015mm² on a TSMC16ULP process.
*) Merge() is similar but even smaller, only shifter, adder, and tiny logic (no multipliers because constant multiply can be mapped into adder).
*) Size of Merge() is roughly ~0.0005mm².

4-stage pipeline
CK1: Mix regfile read, two operators in parallel (calculate %11 at same time)
CK2: Math()
CK3: Merge()
CK4: Mix write back to regfile

Task latency is 4 cycles, but we can have 4 independent threads so we can make this pipeline fully loaded.
Mix Regfile we use a 1W2R (1 write port, 2 read port) Regfile, mature IP, 8KB (for 4 threads), single cycle read/write, 1GHz operation.
If you want load/unload mix data on the fly without disturbing the pipeline, we can upgrade to a 12KB 2W3R Regfile. We then have extra read/write ports for load/unload, and 12KB is enough for 6 tasks (4 running, 1 loading, 1 unloading).
An ASIC can implement 10K sets of that block:

*) running at 1GHz frequency
*) 0.55V voltage (typical voltage for TSMC16ULP)
*) generating ~10T Math() + Merge() throughput per second
*) Power estimate roughly 3mW each pipeline, 30W in total.
*) No customized circuit/layout
*) All standard cells, auto placement route
*) Use mature IP only
*) No aggressive overclocking
*) No aggressive under voltage
*) ~8.4K Merge() and ~4.8K Math() per hash
*) pipeline includes 1 Merge() and 1 Math()
*) pipeline is only the logic part, not the memory part
*) the xGB memory are not included
*) we have 10T throughput on single chip asic, divided by 8.4K Merge() per hash, means 1.2GHash
Performance
*) increases die cost/power by about 1%, and causes a die increase of <1mm²

The design (logic part only) can provide 1.2 GHash ProgPoW performance at 30W power.
Nvidia GTX1070Ti can provide 15.7 MHash at 115W, but including memory.

[solardiz]

@Sonia-Chen Interesting.

How many instances of the 8 KB (or 12 KB) register file would you need for "10K sets of that block"? Wouldn't that be significant die area to include in your estimates and conclusions, which doesn't appear to be included now?

The modulo operations in Math and Merge are compile-time. While you could be generating the inputs to them on the fly, I doubt you'd want to - you'd more likely have a pre-compiled ProgPoW program uploaded to your ASIC from host, like it's done when ProgPoW is run on GPUs.

[salanki]

Thank you for this technical argument, greatly appreciated. It’s above my head, but on the first glance there are two things that stand out to me:

• The kiss99 computations are missing.
• You cannot compare the performance of a “PoW loosely based on ProgPoW without DAG access” to ProgPoW performance. The performance comparisons you state with a 1070Ti are completely invalid.