The Zcash parameter change would not give FPGAs much advantage, if any. This board in particular lacks the bandwidth

Webpack edition won’t build you Ultrascale+ bitstreams. Though I guess you could use the trial of the full version.

Most of the algorithms out there already exist published "for free" - that isn't the hard part. They'd still need expensive software licenses + lots of time and reasonable sets of skills to synthesize + deploy bitstreams for a variety of hardware. Not to mention we tend to be doing a lot of floor planning, rapid re-configuration, and other things beyond some verilog/VHDL.

Typically speaking, especially for things like this where there is a very real high cost (in software and hardware + time) to produce the bitstreams, you will get what you pay for.

There is nothing magical in ccminer. We have had our own stratum interface and “host” miner for some time.

Senseless has suggested building these boards with a “shell” that would allow encrypted bitstreams (industry standard IP protection. The traditional use of FPGAs is DoD level projects. There are lots of solutions. I would say don’t expect open source FPGA miners.

As well as others of us.

The VU9P is the chip Xilinx has chosen to use in their VCU1525 boards as well as their VCU118 dev boards. The chip used for the dev boards is usually a mid-line chip with good yield, and the volume means it almost always has a better price to performance ratio than any other chip.

Well that’s fun, as a relatively new member of this forum myself. Fixed.

If you don’t want to publically state the coin, pm me. If you’re not a programmer, or a hardware engineer, or an FPGA developer (very different from a programmer), you likely have a very steep slope to getting an efficient miner running a new algorithm.

Yep this is the big reason chain hashing doesn’t stop FPGAs - partial reconfiguration, the overhead of which can be nearly entirely latency hidden.

This is somewhat accurate. The bitstream is literally the blueprint for the exact circuit you want the FPGA to currently be wired as. Every model of FPGA is like a unique building - it needs its own tailored electrical blueprint, even though the electrical blue prints for two similarly sized datacenters might look very similar. Maybe on one the main power feed comes in on the south wall and the rows run north to south, and on the other the power comes in the east wall and rows are spaced differently running west to east.

With FPGAs you can easily rewire the whole building (but not change where the fixed resources are),  with an ASIC you’re starting from flat level ground, and once the building and wires are in they can never be changed.

With a GPU you can’t change the wires, all the machines are already installled and all the manufacturing lines are already installed in stone,  and each is only good for what it is good for, you can only tell the machines what order of operations to execute.

There are not many new customers of FPGAs. They are heavily incentivized to offer “cheap” dev kits to get a company to see the value in the chip and build a product around it. First they get you hooked, then...

In those price points you won’t see 20+kh Cryptonight and 17GH/s Keccak

You’ll also be dealing with older chips - 28nm variety Xilinx 7 series.

But - you can get performance on par with similarly priced GPUs (at 10% of power)for most of the discussed algorithms. And that’s from a relatively new platform that hasn’t had near the level of optimization. I hesitate to give exact specs yet because things can change between engineering samples and shipping products.

Overall if you have $500 to spend and want to get into FPGAs you can do it profitably, but if you have $5000 you can participate much more profitably $ for $.

CryptoNight7 and CryptoNightHeavy are two different algorithms with different power and performance characteristics.

I missed something - who said multiplication and division are the same thing?  I mean sure multiplication by a reciprocal is the same as division but who is counting.

I generally have a distaste for arguments over semantics and pedantics. It is precisely why I don’t do much in formal mathematics. I fully respect and appreciate the value of and need for such rigour, but it is a means to an end and not the end itself.

Most of the people I have spoken with are Anti-ASIC but pro general purpose acceleration hardware (such as FPGAs). There is certainly a group that has a vested interest in keeping their GPU farms running or using existing hardware that users have.

Soon we should have FPGA boards in the realm of GPU costs ($200-600) that “everyone” could buy. That may sway opinions, but I imagine some will still cling to their GPU centric goals. I can’t fault a group for making a decision and sticking to it.

I work with Avnet all the time, sadly this is normal. Hardware the backside  doesn’t move at consumer pace, very slowly. Also lead times are a few weeks now.

To be clear I am not against coins that decide from the get-go to be ASIC resistant, even those that decide to be FPGA resistant. I’m perfectly willing to design hardware to take advantage of a coins failure to actually be resistant though. The challenge alone is worth it, there are many ways to solve a problem.

What I do think is important is to hold those decisions to scrutiny. Otherwise what you have is smaller coins waving the “hey we are asic resistant!” flag as a marketing tool, hoping to be the next big GPU coin regardless of the validity of the claims.

They need to stand up to public review and get experts in the various disciplines to chime in on their decisions. From what I can tell PHI2 seems to have been developed in secret - and nothing is published on the algorithm itself, which makes me suspect. It also makes it clear that it hasn’t been broadly reviewed and given a chance to  stand on its own merits.

The group asked for my opinion and I agree. PHI2 appears to be more of the same ASIC resistance line of thinking based on some misconceptions about what makes things hard for hardware.

The fact that you lumped ASIC and FPGA resistance in one line is more telling than anything else.

To be less skeptical, show me your white paper documenting the PHI2 algorithm and decisions that were made and cryptoanalysis that was done on it to be FPGA resistant?

It also appear you’ve released the GPL miner binary, so I respectfully request the source.

I deal with a lot of complex, large FFTs on CPUs, GPUs, and FPGAs. The “only using single precision” is unfortunately true of every vendor - GPU and FPGA. Marketing wants to use the big number - and frankly so do most real world users now. Modern GPUs are horrible at double precision. It is a sad fate. Your comparison also compares a modern Stratix 10 (10 TFLOPs) to the previous generation Ultrascale (not Ultrascale+) with slower fabric and significantly fewer DSP blocks compared to the VCU1525 (XCVU9P-L2FSGD2104E) everyone has been talking about here.

Compared to even modern weak DP GPUs any normal priced CPU is horrible at double precision. A modern GPU runs circles around the Complex FFTs using double precision vs a CPU. Both become quickly memory bound. The FPGA performance is usually on par or slightly better for the double precision, but the benefits in the rest of the calculation are much better. I think you’ll be hard pressed to build a hashing algorithm that is entirely Floating Point like a synthetic benchmark.

The only place FPGAs really fall down is upfront cost.

I’m still a bit confused by why you think sqrt/reciprocal, and the transidentals are so difficult for FPGA, or that’s they are magically free on GPUs/CPUs. On at least AMD GPUs these are macro-ops that take (100s of clockcycles) EDIT: searching for my reference on this, I see these ops are quarter rate. May have been thinking of division) . On the FPGA you can devote a lot of logic to lowering the latency on these functions, or you can pipeline them nice and long with very high throughput to match what you need for the algorithms in question. You have none of that flexibility on the GPU. What you do have is a tremendous amount of power and overhead in instruction fetching, scheduling, branching, caching, etc. to a limited set of ports to implement the opcodes for each GCN/CUDA core.

I’ll see if I can dig up recent ones. A lot of people pull up the old CUDA vs FPGA academic papers that are focused on very old architectures.

As to GPU floating point performance, you don’t need a benchmark. The figures are right in the ISA documents. Single precision TFLOPs are usually given in terms of FMA unit operations though, which is a bit misleading.

The FPGAs are a bit harder to get TFLOPs numbers for given the flexibility,  it since most of the performance actually comes from the DSP blocks you can calculate those. If you’ve never read them Xilinx gives extremely detailed performance metrics for every chip for most IP blocks, as well as frequency numbers for the hard blocks in the AC/DC switching characteristic docs.  Agner Fog publishes a very detailed set of specifications for the performance of those units on most every CPU/APU available as well.

The main resource CPUs and GPUs have is instruction flexibility. Until a PoW hash truly requires most of the full instruction to be supported to implement it will be hard to keep out ASIC/FPGA.