sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
_whitelogger has joined #m-labs
<sb0> larsc: what happens if we double the SYSREF frequency (with the DAC in one-shot synchronization mode)?
<sb0> I want to DDMTD the SYSREF going into the FPGA, but the MMCM needs at least 10MHz
<sb0> I could double the FPGA SYSREF only, but it makes things a bit more complex
X-Scale` has joined #m-labs
X-Scale has quit [Ping timeout: 244 seconds]
X-Scale` is now known as X-Scale
<sb0> or maybe a better idea is to DDMTD a 150MHz output, use the DDMTD results to align that to the RTIO clock, and then align SYSREF (with a known number of 7043 slips) to the RTIO counter
<sb0> then there are no issues with minimum MMCM PFD frequencies, and the MMCM parameters are generally more reasonable
<sb0> we can even get crazy resolutions easily and then we know exactly how bad ultrascale is
futarisIRCcloud has joined #m-labs
rohitksingh_work has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/cc9420d2c8ee1e30f93f6d0511f00f089f7e343a
<GitHub-m-labs> artiq/master cc9420d Sebastien Bourdeauducq: hmc7043: fix divider programming
<sb0> after fixing above bug, DACs are syncing at 2.4GHz
<sb0> this bug also broke the HMC_SYSREF_DIV value and potentially caused chaos in the HMC, btw
<sb0> so, if the DDMTD SYSREF/RTIO synchronization works, we could keep the 7043
<sb0> the DAC SYSREF window is unexpectedly large though, i'm not sure if it is explained by the 7043 analog delay tolerances
<bb-m-labs> build #2341 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2341
<bb-m-labs> build #2342 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2342
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/6902e6fa03bc11b665ed260861d2e0960f030c82
<GitHub-m-labs> migen/master 6902e6f Sebastien Bourdeauducq: sayma_amc: remove outdated and inaccurate comment
<bb-m-labs> build #366 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/366
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/4941fb33005cbe4694a66596338fabe0ef4fc171
<GitHub-m-labs> artiq/master 4941fb3 Sebastien Bourdeauducq: sayma: 2.4GHz DAC clocking (4X interpolation)...
futarisIRCcloud has joined #m-labs
m4ssi has joined #m-labs
<larsc> sb0: as long as it is is lower than the max sysref that should be OK
<larsc> max sysref = lmfc
<larsc> the only requirement is that the distance between two sysref edges is a multiple of 1 / lmfc
<larsc> it does not even have to be the same distance for each edge
m4ssi has quit [Remote host closed the connection]
<sb0> ddmtd measures sysref slips exactly as they should be :)
<sb0> that's 150MHz DDMTD with N=64, measuring consecutive slips of the 2.4GHz clock
m4ssi has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/3356717316ae6b90611588927d805c058b1a3346
<GitHub-m-labs> artiq/master 3356717 Sebastien Bourdeauducq: sayma: DDMTD SYSREF measurement demonstration
<sb0> okay, now I can take the other SYSREF, set it to the normal frequency and oversample it with ISERDES to validate s/h
<sb0> since we have the fine RTIO clock from the DRTIO transceiver now, that should be straightforward
<sb0> the only sayma-behavior so far is the unexpectedly large SYSREF window at the DACs
<sb0> larsc: thanks
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0> yay, that works too :)
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/cb04230f8675f754bb1ea3cdf90b88ef4ddf3645
<GitHub-m-labs> artiq/master cb04230 Sebastien Bourdeauducq: sayma: SYSREF setup/hold validation demonstration...
<bb-m-labs> build #1010 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/1010
<bb-m-labs> build #2870 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2870
<bb-m-labs> build #2343 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2343
<bb-m-labs> build #2344 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2344
<bb-m-labs> build #2871 of artiq is complete: Failure [failed python_unittest_3] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2871 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
futarisIRCcloud has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<key2_> whitequark: when generating something with nmigen, is there a way to define the name of the top module ?
<key2_> There are signals that I don't want that end up there, and some signal that I want that are names foo$123 instead of their real name, (they come from Records())
futarisIRCcloud has joined #m-labs
<whitequark> key2_: yes, you can use rtlil.convert(name="...")
<whitequark> as for signals that end up in ports, there is nothing that can be done right now other than tying them to reset value explicitly
<whitequark> (this is a bug that needs to be fixed)
<key2_> name="..." being ?
<key2_> the names of the signals you want ?
<key2_> ah na
<key2_> when you do ports=[...]
<key2_> there is no way to keep only those port and keep their name ?
<key2_> or rather a dict
<key2_> would be a good option
<key2_> something like port={"signame" : foo.bar}
<sb0> hartytp: what kind of DAC sync issues did you get at 2.4GHz exactly and what was the sync window like?
<sb0> (sync window == timing range in which you can move SYSREF without affecting sync)
<whitequark> key2_: no, "name" is for calling top module
rohitksingh has joined #m-labs
<key2_> yeah, i figured, i was talking about port then
<key2_> question is how could we have (only) the signals we requested on the port ?
<whitequark> you currently cannot
<key2_> and how can we have the name we want, especially when there is collision with this name
<key2_> is it possible to force the name to be deterministic ?
<whitequark> you currently cannot
<GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/cb04230f8675...9966e789fcb7
<GitHub-m-labs> artiq/master 359fb1f Sebastien Bourdeauducq: sayma: fix DDMTD STA
<GitHub-m-labs> artiq/master 9966e78 Sebastien Bourdeauducq: sayma: simplify Ultrascale LVDS T false path...
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Ping timeout: 250 seconds]
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
<_whitenotifier-c> [m-labs/nmigen] whitequark pushed 3 commits to master [+0/-0/±3] https://git.io/fhKTt
<_whitenotifier-c> [m-labs/nmigen] whitequark eeb023a - compat.genlib.fifo: adjust _FIFOInterface shim to not require fwft=.
<_whitenotifier-c> [m-labs/nmigen] whitequark 1782b84 - lib.fifo: in FIFOInterface.read(), check readable on the right cycle.
<_whitenotifier-c> [m-labs/nmigen] whitequark b5d3960 - back.pysim: fix behavior of initial cycle for sync processes.
<_whitenotifier-c> [nmigen] Failure. The Travis CI build failed - https://travis-ci.org/m-labs/nmigen/builds/484531094?utm_source=github_status&utm_medium=notification
<_whitenotifier-c> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/fhKkI
<_whitenotifier-c> [m-labs/nmigen] whitequark 7b25665 - back.pysim: fix behavior of initial cycle for sync processes.
<_whitenotifier-c> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/484535192?utm_source=github_status&utm_medium=notification
<_whitenotifier-c> [nmigen] Success. 83.25% (+0%) compared to 2c80f35 - https://codecov.io/gh/m-labs/nmigen/commit/7b25665fde81be7c08a0996f2bff5035680b7ebd
<_whitenotifier-c> [nmigen] Success. 100% of diff hit (target 83.25%) - https://codecov.io/gh/m-labs/nmigen/commit/7b25665fde81be7c08a0996f2bff5035680b7ebd
_whitelogger has joined #m-labs
mumptai has joined #m-labs