The most accurate and fast emulator right now is Ares (https://ares-emu.net), which bundles the Vulkan-accelerated RDP emulation with a recompiler for both CPU and RSP. It is extremely accurate in many regards and in general much closer to the real hardware than any other emulators (with cen64 being a close second). Other emulators manage to run most of the game library but using several hacks, while Ares keeps a zero-hack approach, so not everything works, but it is for instance far more compatible with advanced home-brew stuff which use the hardware in ways that the Nintendo SDK did not.
The most advanced open source library for N64 development is libdragon (https://github.com/DragonMinded/libdragon) which is currently growing very advanced RSP ucodes that do things that are not possible with Nintendo SDK. For instance, it was recently merged a command list support to send commands from CPU to RSP without any lock in the happy path, and fully concurrent access from both the processors. Another example would be its DMA support for fetching data from ROM that exploits undocumented partially-broken features of the RCP that were previously unknown to allow for misaligned memory transfers.
The most accurate source of hardware documentation is the n64brew wiki, which is slowly gathering accurate, hardware-tested information on how the whole console works. https://n64brew.dev/wiki/Main_Page. Unfortunately, it's still lacking in many areas (eg: RSP). It's a painstaking long work because there are many many documents floating around with partial or completely wrong information.
But... once you get past the 16-bit consoles it all goes to shit. Something like a Sega Saturn with two CPUs and 3D hardware. Lord help me. I honestly would not want to even begin trying to emulate a PS3. Total respect to those guys writing emulators for modern consoles and actually getting them to play the software.
N64 is well understood, and there are low level emulators now available that emulate the RSP and RDP on modern GPUs implemented with compute shaders. https://www.libretro.com/index.php/category/parallel-n64/
That's relatively recent, though; the vast majority of the emulation knowledge was from reverse engineering, patents, and typical devkit leak stuff as you say.
TBH, most peoples still prefer to RE on dedicated N64 hardware (hand crafted physical CPU interrupt/inspection). The problem is Verilog source alone is not that useful as you need to “plug” it to CPU with the N64 interface.
"This far back" is not that far back. N64 came out in 1996, at which point custom ASIC design and EDA tooling was already commonplace.
Verilog appeared in 1984, and EDA tooling was in use way before that.
What's more commonplace today is the number of fabless IP companies in the semi space that focus exclusively on selling only IP, rather than selling fully made chips, like SGI, NEC, TOSHIBA, etc. did back then.
I think now all ucode are now properly documented[0][1][2].
[0]: http://gliden64.blogspot.com/2019/02/hle-implementation-of-b...
[1]: http://gliden64.blogspot.com/2018/05/hle-implementation-of-m...
[2]: http://gliden64.blogspot.com/2017/08/star-wars-rogue-squadro...