Nuked-MD-FPGA VS independence-day

The reality is that the vast majority of these FPGA-based clones don't actually perfectly emulate the logic. They're using the same reverse engineering techniques the traditional emulator developers used and sometimes even the same community documentation. The results are often quite good, but they're making a new implementation that matches the observed behavior of the original system to the best of their abilities.

Now there are some exceptions. Nuked MD FPGA[0] is a recent example of an FPGA recreation that is a fairly direct translation of the original logic using silicon die analysis. In this case, the logic is basically identical, but as you guessed the physical layout is different. Generally speaking, you write FPGA "gateware" in a language like Verilog or VHDL. These don't intrinsically have any information about the physical layout of the logic which is handled by the toolchain instead. As wmf says, this is generally not a problem most of the time. For synchronous logic, either the total propagation delay is small enough for a single cycle or it isn't. The toolchain will estimate this delay and report whether you met timing or not for the configured clockspeed.

Not everything you can do in silicon translates well to FPGAs (both clock edges is also generally not well supported for instance), but for the most part these things are easy enough to work around.

[0] https://github.com/nukeykt/Nuked-MD-FPGA

Kinda, sorta? This is like saying "a computer is not enough, you need a binary." What's here is the source code in Verilog. This produces a netlist (set of gates) which is synthesized into an actual bitstream (proprietary gate configuration file) for a specific FPGA hosted on a specific board.

In this case, the project isn't very documented but it looks like fairly generic Verilog without a lot of vendor specific extensions. So, what you need is a Verilog toolchain which can synthesize the source code into a netlist, and then into a bitstream, and the right set of extra code to target an actual physical piece of hardware.

Right now, it looks like the only board support that's checked into the repository is for the Icarus Verilog simulation environment: https://github.com/nukeykt/Nuked-MD-FPGA/tree/main/icarus .

But, the overall setup looks pretty simple and generic, so it should (hopefully) be possible to synthesize to your board of choice by reimplementing run.v and memstubs.v towards an actual hardware configuration.

More $GNOT details that were shared by Manfred Touron https://twitter.com/moul - $GNOT #airdrop may be released later in 2022; if not it's because it makes sense to wait as the platform is developed further - CEX addresses will be removed from calculations before launch - Part of Gnoland may be releasing later in 2022; TBD - Some projects backed by the Gno chain may be released this year as well - Team is focused on making the platform robust for developers - @adenaapp is developed by an independent team - An external contributor started working on a Keplr integration - Team expects to have multiple $GNOT claiming options on #airdrop day - There will be an official method to claim that will be promoted by the team - For #airdrop allocation you can use the http://gnoland.space tool based on the current version of the airdrop which is available here: https://github.com/gnolang/independence-day - Team detected inconsistencies in the airdrop file so for now consider that the checker returns an invalid value - Team is still defining some parts of the project; will make announcements later via @_gnoland - http://gnoland.space is not official the website of Gno, but most of the information is based on things team shared with the webmaster and is still accurate - The current official way to interact with the chain is « gnokey », the built-in CLI Thread: https://twitter.com/Airdrops\_one/status/1564009094805176320