Gate time is trivial, but AD9783 support is simply not possible. The board itself is not wired for LVDS support. The data traces are not routed in length matched pairs and the pins they are connected to are not paired off correctly. For example, P1D0 is connected to IO_L33N_0 and P1D1 is connected to IO_L34P_GCLK19_0. P1D0 corresponds to D8N and P1D1 corresponds to D8P. L33N can be paired with L33P, but not with L34P. So it is simply not possible to switch the DACs without laying out a new board.
I remember someone mentioning AD9783 being pin compatible, that's why I thought it may be possible to use this part with the open source firmware. Too bad the traces don't match, thanks for checking that.
On the repo I think we may need multiple repositories linked together with git submodules. One for the FPGA stuff, other for base OS (u-boot, kernel, libraries etc) services and another one for the actual Qt software. Each of these submodules would have subdirectories for components (for FPGA, e.g: memory interface, PicoBlaze (?), DDS, Frequency Counter etc., for the firmware, e.g.: GUI, Hardware Access API, Remote Protocols API (USB - TMC/ETH - LXI) etc.). Each submodule and preferably component would have tests subdirectory for GTest/GMock unit/components tests. FPGA has simulation testbenches for that.
We might need to be careful with putting Xilinx CoreGen outputs in GitHub, I remember I saw one open source project that had to remove them as Xilinx generated stuff is under different license. Shouldn't be a problem to keep precompiled bitsteams I suppose.
I'm thinking about getting this dev. board next month and I'll try to cross-compile minimal Gentoo and see how this embedded Qt works. Or, if I remember correctly from the original thread, the u-boot in the AWG allows booting from the microSD - might be good for initial tests of the base OS image and I would save some money this way
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)