<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1129: Also, is there an easy-enough way we can disconnect SYSREF for both DACs from the HMC7043, and connect them to the FPGA directly? That certainly will work for 600MHz and perhaps 2000MHz since the FPGA IOs are advertised to support 2133Mbps DDR4. Note that DDR4 uses source-synchronous clocking with DQS, and they probably have a lower-noise clocking path inside the
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1129: Also, is there an easy-enough way we can disconnect SYSREF for both DACs from the HMC7043, and connect them to the FPGA directly, in a HP bank? That certainly will work for 600MHz and perhaps 2000MHz since the FPGA IOs are advertised to support 2133Mbps DDR4. Note that DDR4 uses source-synchronous clocking with DQS, and they probably have a lower-noise clocking pa
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1129: Also, is there an easy-enough way we can disconnect SYSREF for both DACs from the HMC7043, and connect them to the FPGA directly, in a HP bank? That certainly will work for 600MHz and perhaps 2000MHz since the FPGA IOs are advertised to support 2133Mbps DDR4. Note that DDR4 uses source-synchronous clocking with DQS, and they probably have a lower-noise clocking pa
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1129: Also, is there an easy-enough way we can disconnect SYSREF for both DACs from the HMC7043, and connect them to the FPGA directly, in a HP bank? That certainly will work for 600MHz and perhaps 2000MHz since the FPGA IOs are advertised to support 2133Mbps DDR4. Note that DDR4 uses source-synchronous clocking with DQS, and they probably have a lower-noise clocking pa
<GitHub-m-labs>
[artiq] hartytp commented on issue #1129: @sbourdeauducq that might well work, but I’m still a bit concerned with how far the gateware design from ARTIQ is diverging from the way that *everyone* else does this and turning into a NIH reinvention of the wheel.... https://github.com/m-labs/artiq/issues/1129#issuecomment-414580481
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1129: The only drawback that I see with the FPGA technique is PVT skew/jitter issues that can become problematic at high sample rates and may require the use of that trashy "native" I/O block to mitigate. Not "NIH". https://github.com/m-labs/artiq/issues/1129#issuecomment-414584087
Zombie24 has joined #m-labs
Zombie24 has quit [Remote host closed the connection]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 272 seconds]
<GitHub-m-labs>
[artiq] hartytp commented on issue #1129: Let’s discuss this more next week when I’m back in the office, but I’m confident we can find a good solution with the 7044 if we want to. I can also use an eval board to test as much of this as possible to make sure it will work properly.... https://github.com/m-labs/artiq/issues/1129#issuecomment-414629987
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1129: Sure, but what should the timing relationship be between RFSYNCIN and the input clock at the 7044 pins? Do you trust what HMC tells you, with their datasheets that show AC-coupled RFSYNCIN and tell you to read registers that return nonsense such as 0x007d?... https://github.com/m-labs/artiq/issues/1129#issuecomment-414631376
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
nikivi0 has joined #m-labs
nikivi0 has quit [Remote host closed the connection]
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1129: I don't necessarily want to do it that way, as I pointed out the native Ultrascale I/O is also full of garbage (and so is the GTH transceiver which would be a third solution for driving SYSREF) - I'm just pointing out that the 7044 should be treated with caution. Basically there is no good option unless silicon vendors get their act together. https://github.c