FPGA Competition Round 2

Round 1 Results


Congratulations to Eric Pearson for winning round 1 with a latency of 28.6 ns / sq!

All submitted designs and results from are now available in GitHub at https://github.com/supranational/vdf-fpga-round1-results

Round 2 Parameters

Start Date

17:00 EDT Oct 16

End Date

23:59:59 EDT Dec 31

Baseline Latency

28.6 ns/sq


$5000 / ns improvement over baseline

Modulus (no change)

N = 12406669568412474139879892740481443274469842712573568412813185506

Repeated squarings for latency evaluation

h = x^(2^t) mod N

t = 2^33 (~4 minutes)

Expected result for x=2


Precommit of x to be used for evaluation (sha256)


Tools/Versons (no change)

Vivado 2018.3, AWS FPGA AMI 1.6.0

Takeaways from round 1 / advice for round 2

Test on F1 hardware

The transition from synthesis to hardware is not always smooth. A number of designs had issues around clocking and power that only manifest on the real hardware.

Incorporate an MMCM

We recommend incorporating an MMCM (clock generator) into your design to ensure hitting the target clock frequency. For examples see some of the submissions from round 1 (including the entry from Eric Pearson) or https://github.com/supranational/vdf-fpga/blob/pll_cdc/msu/rtl/msu_cdc.sv . Some designs don’t run at the target frequency on F1 without this level of control.

Modify the interface (if it makes sense)

You are allowed to change the interface from the provided baseline. For timing purposes we require that precomputation related to the input be done inside the timer (https://github.com/supranational/vdf-fpga/blob/master/msu/sw/MSU.cpp#L119). For example, if you need to convert to/from Montgomery space.

Precompuation related to the modulus or the exponent does not need to be inside the timer.

Use the test portal to ensure repeatability

We need to be able to fully reproduce your results from scratch. The test portal is a good way to make sure your build results are consistently repeatable from source files.

Visualizing test portal and SDAccel results

SDAccel and the test portal produce intermediated .dcp files which are checkpoints of the design. You can open these with Vivado (vivado my_file.dcp) to view your design, run reports, etc.

Vivado Project and On-premise Correlation

Be wary of trusting Vivado in project mode as fine tuning gets into picoseconds. We’ve also seen subtle differences between an on-premise environment and the AWS AMI. Test periodically in AWS to avoid surprises.