sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
fengling has joined #m-labs
key2 has quit [Ping timeout: 246 seconds]
folkert has quit [*.net *.split]
mumptai has joined #m-labs
fengling has quit [Ping timeout: 276 seconds]
fengling has joined #m-labs
mumptai has quit [Remote host closed the connection]
_florent_ has joined #m-labs
<GitHub149> [artiq] fallen pushed 1 new commit to master: http://git.io/vI8oK
<GitHub149> artiq/master d66117e Yann Sionneau: pxi6733: cleanup
key2 has joined #m-labs
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#197 (master - d66117e : Yann Sionneau): The build passed.
travis-ci has left #m-labs [#m-labs]
fengling has quit [Quit: WeeChat 1.1.1]
_florent_ has quit [Ping timeout: 264 seconds]
_florent_ has joined #m-labs
<sb0> i wonder if this http://hexagon.physics.wisc.edu/papers%20and%20pubs/papers%20in%20pdf/2006/PhysRevA_74_023816.pdf can be used to make a bell test with a KTP doubler crystal from a laser pointer (hundreds of times cheaper than the thorlabs&co stuff, and you get the proper laser source as well)
<sb0> also, green photons, unlike IR, ones can be easily detected with PMTs off taobao instead of 10x more expensive SPADs from annoying suppliers who rarely answer email or phone
<sb0> China actually has PMT factories with the prices you'd expect, but not avalanche photodiodes afaict
<sb0> and 10x is giving the western factories too much credit
<sb0> mh, i have a lot to learn from this paper...
<GitHub0> [artiq] fallen pushed 1 new commit to master: http://git.io/vIBdc
<GitHub0> artiq/master 6c094b5 Yann Sionneau: pxi6733: fix type issue
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#198 (master - 6c094b5 : Yann Sionneau): The build passed.
travis-ci has left #m-labs [#m-labs]
<ysionneau> sb0: do we want to allow using both ttl_simple and ttl_k7 phys in the same design?
mumptai has joined #m-labs
<sb0> i don't see why there would be any problem with that
<ysionneau> at the moment the RTIO module takes the phy_clk as parameter and creates a cd_rio_phy clock domain with it
<ysionneau> but if we use both ttl_simple and ttl_k7 we have 2 different phy clocks, one at 125 MHz and one at 1 GHz
<sb0> and "k7" is a bad name for it as it would be compatible with artix and virtex. use e.g. 7series
<ysionneau> ah yes
<sb0> if you have to touch anything inside the rtio core you are probably doing it wrong
<sb0> you can leave the 8x clock free-running from the PLL without dealing with the RTIO reset stuff - that won't hurt
<ysionneau> ok
<sb0> and assume that the user provides a rio_phy8x clock somewhere in the design
<sb0> and that "somewhere" will be rtiocrg, which also needs to take care of any required PLL reset when clocks are switched
<ysionneau> yep that's what I'm doing now (not pushed yet)
<sb0> also, the unmultiplied clock is not necessarily 125MHz - it can go up to 146
<sb0> if the PLL is fine without reset and will relock itself when the new clock is reapplied, don't implement the reset. check the 7-series datasheets to find out...
<ysionneau> for now I have one BUFGMUX connected to a PLLE2_BASE, maybe I should replace both with just one PLLE2_ADV
<ysionneau> and use the CLKINSEL
<sb0> did they document the previously hidden clock switch inside the pll in the 7-series?
<sb0> and which has lowest jitter? IO->BUFGMUX->PLL or IO->PLL CLKINSEL?
<ysionneau> they just say that for PLL_ADV and MMCM where you have CLKIN1/CLKIN2/CLKINSEL ports, the PLL is likely to lose lock when switching input clock
<ysionneau> therefore you need to reset the PLL
<sb0> well sure it will lose lock
<sb0> the relevant question is, will it relock correctly without a reset?
<ysionneau> I just quoted the doc
<sb0> i'd think removing the bufgmux might improve jitter a very small bit, unless there are weird things going on with the IO->PLL routing
<sb0> "MMCM/PLL is likely to lose LOCKED and automatically lock onto the new clock. Therefore, once the clock switches, the MMCM/PLL must be reset."
<sb0> this is bullshit
<sb0> either it locks automatically and doesn't need a reset, or the opposite
<sb0> i'd bother xilinx tech support with it, unless the answer is already in a forum post/answer record/whatever
<ysionneau> ah yes I didn't see the illogic, I just saw "likely to lose LOCKED" followed by "Therefore you must reset" which sounded logical
<ysionneau> -_-
<ysionneau> elsewhere in the doc, in description of the RST port it says: A reset is required when the input clock conditions change (for
<ysionneau> example, frequency).
<ysionneau> wonder if "clock condition" includes switching clock =)
<sb0> probably yes
<ysionneau> ah got it
<sb0> but that's still contradictory with "automatically lock onto the new clock"
<ysionneau> the CLKINSEL port says it clearly : The CLKINSEL signal controls the state of the clock input MUXes, High = CLKIN1,
<ysionneau> Low = CLKIN2 (see Reference Clock Switching). The MMCM/PLL must be held in RESET
<ysionneau> during clock switchover.
<ysionneau> so the automatically lock onto the new clock seems bullshit
<sb0> "likely to lose LOCKED" is also confusing. it will always lose lock when reset I think.
<ysionneau> anyway, I think it's clear now, hold reset, switch clock (change CLKINSEL value), release reset
<sb0> you can probably have another CSR for reset and have the CPU deal with that
<sb0> also, put a AsyncResetSynchronizer driven by the PLL LOCKED that resets the RTIO unmultiplied domain
<ysionneau> yep, easiest solution I guess
<ysionneau> ah yes
<sb0> the multiplied clock does not need a reset
<ysionneau> yes it's only clocking the SerDes
_florent_ has quit [Ping timeout: 255 seconds]
kmehall has joined #m-labs
kmehall_ has quit [Ping timeout: 276 seconds]
aeris has quit [Read error: Connection reset by peer]
aeris has joined #m-labs
ohama has quit [Ping timeout: 256 seconds]
ohama has joined #m-labs
mumptai has quit [Remote host closed the connection]