<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #947: @cjbe Are the two local TTLs necessary to reproduce the bug? Can their pulses be replaced with delays? Is there any modification of this experiment that can make the write underflows more frequent? https://github.com/m-labs/artiq/issues/947#issuecomment-372182549
<GitHub-m-labs>
[artiq] cjbe commented on issue #947: Removing the local TTLs and making the remote output events more frequent increases the rate of errors to ~ 1/s on my setup, which consists of 2x Kasli v1.0 connected by a 10m fiber:... https://github.com/m-labs/artiq/issues/947#issuecomment-372231755
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: Note that while the mem test does pass on @marmeladapk's board, the eyes look really quite bad. So, I suspect it's really just a matter of luck that it works on his board and not on mine. Neither really look like eye scans on a working board AFAICT. https://github.com/m-labs/artiq/issues/908#issuecomment-372251258
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: My best guess here is that there is something wrong like a missing/incorrect timing constraint, an output drive not being set optimally, etc. AFAICT, Vivado is struggling to meet timing with the SAWG in place, so I wouldn't be surprised if it's doing something funny here, so it's important to have everything optimally set up and fully constrained. Also, if there is anyth
<rjo>
marmelada: way too much metadata in the name for me. kasli is also an "adapter" as are the DIO_BNC etc. my recommendation would be to either choose an opaque name or just call it "backplane".
<marmelada>
3U_Backplane? to distinguish it from MTCA
<rjo>
good! names that start with numbers are sometimes problematic. Backplane3U?
<rjo>
the DIO_* only start with 3U where greg calles them like that. in the wiki, in the releases and in the code it is never 3u (for the reasons i mentioned).
<GitHub109>
[sinara] marmeladapk tagged Backplane_Adapter_3U/v1.0 at c1b519f: https://git.io/vxvxp
marmelada has quit [Quit: Page closed]
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: Looking again at the "bad" eyes, with errors in the working region, AFAICS, the problems are all with the read leveling rather than the write leveling. I wonder if there is something wrong with the IDELAY code. Could we fuz this by looping an OSERDES to an ISERDES and sweeping the IDELAY for different ODELAYs? https://github.com/m-labs/artiq/issues/908#issuecomment-3
<GitHub-m-labs>
[artiq] jbqubit commented on issue #944: Vivado is working very hard to achieve closure and seems on the edge of not finding a solution. If the Xilinx model for Kintex UltraScale were slightly off, Vivado may claim timing closure but produce a .bit that is borderline. Do you have reason to suspect this? ... https://github.com/m-labs/artiq/issues/944#issuecomment-372343276
<GitHub-m-labs>
[artiq] hartytp commented on issue #944: > If the Xilinx model for Kintex UltraScale were slightly off, Vivado may claim timing closure but produce a .bit that is borderline. Do you have reason to suspect this?... https://github.com/m-labs/artiq/issues/944#issuecomment-372347760