It's not the only correct answer. There are multiple perfectly valid ways to accomplish this task as I mentioned above - just as there are in essentially every engineering task. Try telling a team of engineers in industry, "This is the one and only correct way to accomplish this task" and you'll get some good laughs.lidnariq wrote:Injecting the correct 768×32000 Hz clock is the only correct answer.
But assuming by "injecting" you mean tapping into the console's 24.576MHz osc and hooking it up to the FPGA you can certainly do that like I said earlier (with caveats), but you probably don't want to drive the actual HDMI/SPDIF controller/output using that source clock. In fact, if you're using an external HDMI output controller chip you're guaranteed it's going to require some very specific clock input that is very likely not 24.576MHz. Lol. So no matter what you do you're going to have to cross clock domains at some point. Therefore, the best design practice would be to capture the samples into a bi-synchronous FIFO/RAM within the FPGA at the source sampling rate and then read those samples out of the FIFO using a completely separate clock generated internal to the FPGA using one of the FPGA's internal PLL cores so you can get a nice clean, accurate, and stable clock source to drive it out to its next destination.