Open-source files

[codepilot]

I am pretty happy with my initial implementation and I would like to make the repo public.

My implementation is purely TypeScript right now, and works with NodeJS and Chrome, drawing using SVGs, and outputs canonical files.

I will be moving time-critical parts to C++/wasm, then webgpu for performance.

It uses the device files from rapidwright and benchmark files, routes, and draws to the screen using SVG.

Regarding the device files and benchmark files, what method of loading them into the browser, using github pages, would be permissible?

Ideally, gzipped canonical files for the device and benchmark files would have permalinks that I could use. Chrome has fast gzip functions builtin, as does node, and given that it is the browser, download time matters.

If the benchmark files could have the nets in the file sorted in order from mostly likely to be critical path first that would be even better!

Daniel

[eddieh-xlnx]

Glad to hear of your progress!

It uses the device files from rapidwright

Just to be clear: do you mean the FPGAIF device file generated using RapidWright?

Regarding the device files and benchmark files, what method of loading them into the browser, using github pages, would be permissible?

I'm not sure I understand your question. Device and benchmark files will be provided on local disk, and it will be up to you to integrate your router into our Makefile by uncommenting and modifying this recipe for example:

fpga24_routing_contest/Makefile

Lines 121 to 123 in 718a308

	## EXAMPLEROUTE
	# %_exampleroute.phys: %_unrouted.phys | fpga-interchange-schema/interchange/capnp/java.capnp
	# (/usr/bin/time <custom router here> $< $@) > [email protected] $(call log_and_or_display,[email protected])

Ideally, gzipped canonical files for the device and benchmark files would have permalinks that I could use. Chrome has fast gzip functions builtin, as does node, and given that it is the browser, download time matters.

As of release v1.1, I have uploaded xcvu3p.device as a release asset, the latest version is available:
https://github.com/Xilinx/fpga24_routing_contest/releases/latest/download/xcvu3p.device

Equivalently, the latest benchmarks.tar.gz is pulled in from a permalink set in our Makefile too:

fpga24_routing_contest/Makefile

Line 15 in 718a308

BENCHMARKS_URL = https://github.com/Xilinx/fpga24_routing_contest/releases/latest/download/benchmarks.tar.gz

Currently, these are not canonical, but with the right data supporting this change and the ability to generate (or post-process) the existing benchmarks into a canonical form, I can be convinced to include them in the next release.

If the benchmark files could have the nets in the file sorted in order from mostly likely to be critical path first that would be even better!

Alas, it would be up to the contestant router to perform that sorting! The likelihood of a net appearing on the critical-path will likely change during the router's progress, so it's best to have a dynamic method of predicting/reacting to that.

[codepilot]

Those urls are helpful, I made a new public repo and I am working my way through a cmake build process right now https://github.com/codepilot/fpga-solver

[codepilot]

It has a build step to gunzip and canonize the device and benchmark files

[eddieh-xlnx]

For the record, allow me emphasize this point:

Device and benchmark files will be provided on local disk

We'll explain the test environment in more detail shortly, but the idea is that we don't expect contestants to download the benchmark files from an external source (there will be no internet access, after all) -- they will be provided in the local environment. As for the device file, that can be provided too, but the expectation is that contestants will want to process the data contained in that file offline into a different layout that is more amenable to routing search. This preprocessed data can then be embedded into the router submission.