Looks to be plenty of general high-level serdes ideas and theory in that xilinx pdf. But it is 20 years old (in addition to FPGA being some years behind state of the art).
>"Goals are for Games. Constraints are for Worlds.
A goal is a win condition. Constraints are the rules of the game. But not all games are worth playing. And some of the most powerful forms of progress emerge from people who stopped trying to win and started building new game boards entirely.
[...]
Richard Feynman didn’t get his Nobel Prize by pursuing "win a Nobel Prize" as a goal. He played with problems, often placing arbitrary limits on himself: what if we assume this system has no dissipation? What if we ignore spin?
He looked for elegance within boundaries, not outcomes.
>"This debugger is divided into two parts: the debugger (written entirely in assembly and running on the hardware being debugged) and the bridge, written in C and running on [a second PC running] Linux.
The debugger is the injectable code, written in 16-bit real-mode, and can be placed within the BIOS ROM or any other real-mode code. When executed, it sets up the appropriate interrupt handlers, puts the processor in single-step mode, and waits for commands on the serial port.
[...]
BREAD can also debug arbitrary code in real-mode, such as bootable code or DOS programs too."
There's a brilliant idea here, beyond just BIOS debugging -- that idea is that you don't run (don't need to run!) an entire debugger with all of its code, lookup tables, complexity and GUI dependencies on one PC (where running such code has a greater chance to interfere with the program being debugged -- this is especially true in non-multitasking, non-multiuser, pre-OS, pre-Protected Mode boot environments), you run them on a second PC, and you only run the absolute minimum amount of code on the debugged PC, only enough to send the smallest amount of binary information to the debugger on the second PC, where it can perform all of the necessary processing (lookup assembly instructions, convert them from binary to human readable, display them on its GUI, allow mouse movements, etc., etc.)
Which has applications beyond mere BIOS debugging, which the author points out.
Barrelfish is “multikernel” operating system [3]: it consists of a small kernel running on each core (one kernel per core), and while rest of the OS is structured as a distributed system of single-core processes
atop these kernels. Kernels share no memory, even on a machine with cache-coherent shared RAM, and the rest of the OS does not use shared memory except for transferring messages and data between cores, and booting other cores."
Was I the only one confused by this? It wasn't just me right? I love when I see things like this. "The cool thing about our kernel is that you cannot share memory! It's super secure. Except for, you know, ..." then list nearly everything. What were they trying to provide/gain with this proposal?
Designing a custom datatype (which turns out to be based on balanced ternary trees!) to implement optimized FFT evaluation -- absolutely brilliant, IMHO!
Even if other people/groups are doing something like this, either now and/or in the future, I don't think there ever would be or could be enough software tools which act as the intermediary between different AI's and perform different value-added functions relative to the AI's so interacted with.
The original author has named a few of these ideas so far, i.e., "The system compares their outputs and synthesizes them", "The feedback loop learns not only from right/wrong outputs, but from what kind of disagreements lead to deeper truth", etc., etc. -- but there are (or should!) exist many many more!
Point is, if there is value to be created in creating software abstractions on top of other software abstractions (for example, container orchestration software, which acts as a software abstraction on top of other software abstractions, i.e., containers A.K.A. "virtual(ized) machines"/"virtual software environments") -- then there's value to be created in creating software abstractions on top of multiple different AI's!
To the original author: I think you've got a good set of ideas going on, and I wish you much success with your ideas and software, both now and in the future!
(Now, I must temper all that I say (in the new age/era of AI) with a generalized reminder to all of the creators/implementors of AI, of Joel Spolsky's excellent essay on "Leaky Abstractions" -- https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... -- but I'd also like to temper that idea with the idea that all software is based on abstraction, and software abstractions can add a lot value (Microsoft Word anyone?) while leaking (failing to do what the user wants) very little, or potentially not at all... so there's a fine line between too much and too little abstraction, relative to what users may desire from their software and AI's...)
Anyway, generally speaking, I think it would be great to have some software which performs different value added tasks -- with multiple AI's!
