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
Prize
$5000 / ns improvement over baseline
Modulus (no change)
N = 12406669568412474139879892740481443274469842712573568412813185506
49768953373091389100150712146576743094431494074574934345790638408
41220334555160125016331040933690674569571217337630239191517205721
31019760838723984636436085022089677296497856968322944926681990341
4117058030106528073928633017118689826625594484331
Repeated squarings for latency evaluation
h = x^(2^t) mod N
t = 2^33 (~4 minutes)
Expected result for x=2
102368256386169916359827365612800571792365666301971312977995942354617846025386596143391712431433358166688211010309822125361475467257804936503087482716987502673006764711075137383009101195873723994385994119348575002235023711748852168885234742589374906487480494375925647710743732548371509509281989775853398350838
Precommit of x to be used for evaluation (sha256)
a09374efbe0b2dba7a779fb1c7768479d004beff1bf05030dbd03d54c4f3fdcf
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.