sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit []
mauz555 has quit []
mauz555 has quit []
mauz555 has quit []
mauz555 has quit []
futarisIRCcloud has joined #m-labs
futarisIRCcloud has joined #m-labs
futarisIRCcloud has joined #m-labs
futarisIRCcloud has joined #m-labs
futarisIRCcloud has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has quit [Remote host closed the connection]
mauz555 has quit [Remote host closed the connection]
mauz555 has quit [Remote host closed the connection]
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 244 seconds]
mauz555 has quit [Ping timeout: 244 seconds]
mauz555 has quit [Ping timeout: 244 seconds]
mauz555 has quit [Ping timeout: 244 seconds]
mauz555 has quit [Ping timeout: 244 seconds]
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
mauz555 has joined #m-labs
_whitelogger____ has joined #m-labs
_whitelogger has quit [Ping timeout: 250 seconds]
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger_ has joined #m-labs
_whitelogger_ has joined #m-labs
_whitelogger_ has joined #m-labs
_whitelogger__ has joined #m-labs
_whitelogger__ has joined #m-labs
_whitelogger__ has joined #m-labs
_whitelogger__ has joined #m-labs
_whitelogger___ has joined #m-labs
_whitelogger___ has joined #m-labs
_whitelogger___ has joined #m-labs
_whitelogger___ has joined #m-labs
_whitelogger___ has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1219: @drewrisinger ping https://github.com/m-labs/artiq/issues/1219#issuecomment-450796187
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1219: @drewrisinger ping https://github.com/m-labs/artiq/issues/1219#issuecomment-450796187
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1219: @drewrisinger ping https://github.com/m-labs/artiq/issues/1219#issuecomment-450796187
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1219: @drewrisinger ping https://github.com/m-labs/artiq/issues/1219#issuecomment-450796187
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1219: @drewrisinger ping https://github.com/m-labs/artiq/issues/1219#issuecomment-450796187
rohitksingh has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has joined #m-labs
<sb0> ah of course, siphaser is borked on the RTM as the fabric signal is LVDS and the IO bank has the wrong voltage to receive it
<sb0> ah of course, siphaser is borked on the RTM as the fabric signal is LVDS and the IO bank has the wrong voltage to receive it
<sb0> ah of course, siphaser is borked on the RTM as the fabric signal is LVDS and the IO bank has the wrong voltage to receive it
<sb0> ah of course, siphaser is borked on the RTM as the fabric signal is LVDS and the IO bank has the wrong voltage to receive it
<sb0> ah of course, siphaser is borked on the RTM as the fabric signal is LVDS and the IO bank has the wrong voltage to receive it
<sb0> I guess i'll implement synchronizer autocalibration
<sb0> I guess i'll implement synchronizer autocalibration
<sb0> I guess i'll implement synchronizer autocalibration
<sb0> I guess i'll implement synchronizer autocalibration
<sb0> I guess i'll implement synchronizer autocalibration
<sb0> hartytp/cjbe: how exactly did you measure the drtio timing stability?
<sb0> hartytp/cjbe: how exactly did you measure the drtio timing stability?
<sb0> hartytp/cjbe: how exactly did you measure the drtio timing stability?
<sb0> hartytp/cjbe: how exactly did you measure the drtio timing stability?
<sb0> hartytp/cjbe: how exactly did you measure the drtio timing stability?
<sb0> synchronizer autocal may break things
<sb0> synchronizer autocal may break things
<sb0> synchronizer autocal may break things
<sb0> synchronizer autocal may break things
<sb0> synchronizer autocal may break things
lkcl has quit [Excess Flood]
lkcl has quit [Excess Flood]
lkcl has quit [Excess Flood]
lkcl has quit [Excess Flood]
lkcl has quit [Excess Flood]
lkcl has joined #m-labs
lkcl has joined #m-labs
lkcl has joined #m-labs
lkcl has joined #m-labs
lkcl has joined #m-labs
<sb0> whitequark: irclog.whitequark.org is logging irc messages multiple times
<sb0> whitequark: irclog.whitequark.org is logging irc messages multiple times
<sb0> whitequark: irclog.whitequark.org is logging irc messages multiple times
<sb0> whitequark: irclog.whitequark.org is logging irc messages multiple times
<sb0> whitequark: irclog.whitequark.org is logging irc messages multiple times
mauz555 has quit []
mauz555 has quit []
mauz555 has quit []
mauz555 has quit []
mauz555 has quit []
_whitelogger has joined #m-labs
<sb0> hm, driving the clock into the si5324 will be more annoying
<sb0> hopefully the si5324 will tolerate DIFF_SSTL18_I instead
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh_work has joined #m-labs
<GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/3d919ddca4587d720c2c7c193936acbcd6de8fa6
<GitHub-m-labs> migen/master 3d919dd Sebastien Bourdeauducq: sayma_amc: add master SATA connector pins
<bb-m-labs> build #360 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/360
<GitHub-m-labs> [artiq] sbourdeauducq pushed 5 new commits to master: https://github.com/m-labs/artiq/compare/48793b7ecf70...f5cda3689e36
<GitHub-m-labs> artiq/master 7a6bdcb Sebastien Bourdeauducq: nix: fix m-labs URLs
<GitHub-m-labs> artiq/master d42d607 Sebastien Bourdeauducq: nix: add microscope
<GitHub-m-labs> artiq/master ec52a10 Sebastien Bourdeauducq: nix: add jesd204b
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<bb-m-labs> build #2167 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2167
<bb-m-labs> build #2168 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2168 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #2777 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2777 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
lkcl has quit [Ping timeout: 250 seconds]
m4ssi has joined #m-labs
_whitelogger has joined #m-labs
lkcl has joined #m-labs
uberardy has joined #m-labs
uberardy has quit [Client Quit]
uberardy has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
uberardy has quit [Client Quit]
uberardy has joined #m-labs
uberardy has quit [Client Quit]
uberardy has joined #m-labs
_whitelogger has joined #m-labs
X-Scale has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/cc58318500ecfa537abf24127f2c22e8fe66e0f8
<GitHub-m-labs> artiq/master cc58318 Sebastien Bourdeauducq: siphaser: autocalibrate skew using RX synchronizer...
rohitksingh has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/cc58318500ec...77126ce5b384
<GitHub-m-labs> artiq/master ab9ca0e Sebastien Bourdeauducq: kasli: use 150MHz for DRTIO by default (Sayma compatibility)
<GitHub-m-labs> artiq/master 77126ce Sebastien Bourdeauducq: kasli: use hwrev 1.1 by default for DRTIO examples
<bb-m-labs> build #2169 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2169
<bb-m-labs> build #2170 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2170
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1166: The problem is **not** present with the DRTIO satellite target (@hartytp please confirm). So this looks like a clocking gateware/firmware bug, or more HMC7043 shenanigans (with DRTIO satellite, the JESD transceivers are clocked by the Si5324 and not the HMC).... https://github.com/m-labs/artiq/issues/1166#issuecomment-450898678
rohitksingh has quit [Remote host closed the connection]
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1166: The problem is **not** present with the DRTIO satellite target (@hartytp please confirm). So this looks like a clocking gateware/firmware bug, or more HMC7043 shenanigans (with DRTIO satellite, the JESD transceivers are clocked by the Si5324 and not the HMC).... https://github.com/m-labs/artiq/issues/1166#issuecomment-450898678
rohitksingh has joined #m-labs
<GitHub-m-labs> [artiq] jordens commented on issue #1166: Ha. The glitches are every 40 ns. That's an even 6 coarse RTIO periods and 5 periods of 125 MHz. That's why they look random on the ram and periodic on the sine. There isn't that much (anything?) driven at 125 MHz in DRTIO satellites, but quite a bit in master bitstreams. This could be some fabric or external crosstalk due to the beat and thus PI/SI issues. Or a gatewar
<GitHub-m-labs> [artiq] jordens commented on issue #1166: Ha. The glitches are every 40 ns. That's an even 6 coarse RTIO periods and 5 periods of 125 MHz. That's why they look random on the ramp and periodic on the sine. There isn't that much (anything?) driven at 125 MHz in DRTIO satellites, but quite a bit in master bitstreams. This could be some fabric or external crosstalk due to the beat and thus PI/SI issues. Or a gatewa
<GitHub-m-labs> [artiq] jordens commented on issue #1166: Ha. The glitches are every 40 ns. That's an even 6 coarse RTIO periods and 5 periods of 125 MHz. That's why they look random on the 600/4/16 MHz ramp and periodic on the 600/4/3 MHz sine. There isn't that much (anything?) driven at 125 MHz in DRTIO satellites, but quite a bit in master bitstreams. This could be some fabric or external crosstalk due to the beat and thus
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1166: The satellite has the CPU with satman + SDRAM at 125MHz. https://github.com/m-labs/artiq/issues/1166#issuecomment-450915262
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1166: We can test this theory by changing the system frequency in the master bitstream. I'll try that tomorrow. https://github.com/m-labs/artiq/issues/1166#issuecomment-450915414
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more?]
<bb-m-labs> build #2778 of artiq is complete: Failure [failed python_unittest_3] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2778 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
m4ssi has quit [Remote host closed the connection]
mumptai has joined #m-labs
rohitksingh has quit [Ping timeout: 272 seconds]
rohitksingh has joined #m-labs
<bb-m-labs> build #2171 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2171
<GitHub-m-labs> [artiq] jordens commented on issue #1166: Ack. The difference could still be due to the reduced amount of 125 MHz logic (kernel cpu and associated logic). But this is definitely at the beat. If this is PI, one might naively expect a significant "intermodulation" product on the power supplies at 25 MHz. If it is SI, then we should look at how the 125 MHz clock is getting into the 150 MHz/JESD domain. Could also
<bb-m-labs> build #2172 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2172 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #2779 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2779 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
X-Scale has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #m-labs
cjbe has joined #m-labs
kristianpaul has quit [Quit: leaving]
kristianpaul has joined #m-labs
hartytp has joined #m-labs
<hartytp> rjo: do you understand the ADF[45]356 init sequence?
<hartytp> maybe I'm not reading it correctly, but the data sheet doesn't seem clear to me
<hartytp> afaict the VCO calibration doesn't work with PFD frequencies > 75MHz (which is the regime we'd normally want to operate since higher PFD freq gives bette noise performance)
<hartytp> hence the requirement to first lock at half pfd frequency
<hartytp> but I don't really get what the ADC is doing, or how the temperature compensation works.
<hartytp> the init sequence specifies a time between writing to register 10 (the ADC configuration) and writing to register 0. however. that seems odd since the ADC clock is a divided version of the PFD clock, and the PFD clock is configured by register 4, which is the next one written to
<hartytp> moreover, there is no specification of the default values for most registers
<hartytp> anyway, maybe I'm missing something silly but I know you've thought about this PLL IC so I thought I'd ask
<hartytp> NB there seem to be a few issues with using these PLLs with differential inputs.
<cjbe> sb0: I measured the DRTIO timing stability by looking at the master and slave Kasli clock outputs on a good scope and taking statistics.
<cjbe> I also looked at the RTIO outputs via a DIO board, but the output jitter of the DIO boards is quite bad (~300ps IIRC), so it is harder to get good statistics like this.
<cjbe> sb0 / whitequark: any suggestions on how to preallocate / store a DMA sequence handle?
<hartytp> also, it's not clear to me whether the CE pin reliably resets registers to power on defaults. if not, does this change the requirements for the init sequence?
<cjbe> I have a class that generates and records a DMA sequence, and I want it to have a play method that is fast (hence does not call get_handle() on the critical path). Here is what I currently have: https://hastebin.com/ogusovayuh.rb
<cjbe> If I try and preallocate a tuple I get a type mismatch - code: https://hastebin.com/esuhadiwum.rb error: https://hastebin.com/otocoxeriq.rb
<cjbe> any ideas?
<hartytp> it's also not clear to me why calibrating the VCO at temperatures away from 25C results in worse phase noise, despite the fact that the device includes a temperature sensor as part of the calibration setup (I think this is what the ADC is for)...
<cjbe> hartytp: I would not expect the CE to touch the shift register state at all - I think this just intended to shut off the power-hungry parts of the chip (cf the software shutdown).
<cjbe> The datasheet seems fairly explicit that the correct way to initialise it is to write a known value to every register.
<hartytp> cjbe: yes.
<hartytp> it's the timing constraints I don't get
<hartytp> "Ensure that >16 ADC_CLK cycles have elapsed between the write of Register 10 and Register 0."
<hartytp> ADC_CLK cycle time depends on register 4
<hartytp> also, what triggers the ADC sampling? Is this just a one-off temperature measurement that only occurs when register 10 is written to?
<hartytp> " The ADC uses a clock that is equal to the output of the R counter (or the PFD frequency) divided by ADC_CLK_DIV." also not really true, as it's ADC_CLK_DIV*4+2. Basically, I read it as the thermometer ADC needing a 100kHz clock,
<hartytp> which the max clock divider being 255
<hartytp> so one needs to set an appropriate PFD frequency before the conversation takes place which, AFAICT, is immediately after writing to get 10
mumptai has quit [Quit: Verlassend]
<cjbe> hartytp: yeah - that is ugly! At least you have an eval board to look at the timings AD used...
<hartytp> yes
<cjbe> FYI there is a way to readout the VCO state via the MUXOUT pin https://www.analog.com/media/en/technical-documentation/application-notes/AN-1353.pdf
<hartytp> yes, I saw that
<hartytp> undocumented diagnostic modes does seem to be a favourite with PLL ICs
<cjbe> documentation is hard...
<hartytp> yes
<hartytp> + expensive and boring
<hartytp> the concern would be that it will most likely lock with the init sequence incorrect, but may give bad phase noise/loose lock from time to time due to incorrect VCO calibration
<hartytp> or, we'll find that it works fine the first time when configured from power on default values, but if it's reconfigured without a power cycle then will behave oddly.
<cjbe> surely at the worst case you can just run the init sequence twice? For the first one the ADC clock might be off, but for the second you know it is correct
<hartytp> yes, or just program reg 4 first
<hartytp> well, I think
<hartytp> I'd feel more confident saying that if I actually understood what's going on. As I said, it's not clear to me how the init sequence works.
<hartytp> if f_ref > 75MHz then when reg 10 is written to, which seems to be the temperature conversion trigger, the R divider is 1
<hartytp> (assuming the power on default state)
<hartytp> so the ADC clock wouldn't be correct
<hartytp> anyway, I guess the sequence in the data sheet must work so if we stick to that it should be fine, I just like to understand what I'm doing
hartytp has quit [Ping timeout: 256 seconds]
futarisIRCcloud has joined #m-labs