Claire Xen  🏳️‍⚧️ 🏳️‍🌈 🧙🏻‍♀️ BLM  🏴 🚩

I'd probably go with number of tiles or possibly config frames on Artix 7, with categories something along line of SLICEL only, SLICEL+SLICEM and "free for all" (DSP+BlockRAM). Figuring out the rules and how to evaluate entries is a large part of the effort I think?

Number of tiles and number of frames are *very* different metrics! A bram column contains 28+128=156 frames and 10 tiles. A logic column contains 36 frames and 50 tiles. So either a bram column is 4x *more* expensive than logic (frames) or 5x *less* expensive (tiles).

Related: In the free-for-all category, have points for "worst abuse of hard IP". Example: using a GP_COUNT8 with count=1 as a R-S FF (RST=R, CLK=S) when you run out of flipflops

What I /think/ I'm after is a RISC-V processor which is small enough that dedicating a whole core/CPU to doing bitbanging I2C or other similar low speed peripheral makes sense. RISC-V because of existing tooling for C programming.

i2c is between 100 kbit/s and 3.2 Mbit/s. You won't be able to bitbang that on a core that takes up to hundreds of cycles for each RISC-V instruction. But you'd probably have performance like that with "an 8-bit CPU running an emulator for RISC-V", as you suggested.

If the 8-bit CPU is running at 100MHz (ops) and 100 ops per instruction that is still 1MHz CPU which feels fast enough to bit bang I2C at 100kbit/s? On the RISC-V - I would actually be fine with any architecture that has mainline GCC support.

AVR has good GCC/G++ support, partly because of Arduino and also because it has architecture designed with C in mind. There are already some AVR-compatible FPGA softcores out there, not sure what the legal situation is with them though (trademarks etc)