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
<whitequark> sb0: was DHCP mentioned in any contract?
<GitHub155> [smoltcp] whitequark commented on issue #63: @dhslichter No ETA currently. https://github.com/m-labs/smoltcp/issues/63#issuecomment-347369161
<GitHub135> [smoltcp] dlrobertson commented on pull request #72 2b014ba: I took a very simple approach and added the IPv4 mapped IPv6 address case. Ipv4 Compatible addresses have been deprecated, so there is no need to add a case for them. I thought about essentially copy and pasting https://github.com/rust-lang/rust/blob/1.19.0/src/libstd/net/ip.rs#L1113-L1182, but slice pattern matching is used https://github.com/m-labs/smoltcp/pull/72#discussion_r
<GitHub150> [smoltcp] dlrobertson commented on pull request #72 2b014ba: Good catch https://github.com/m-labs/smoltcp/pull/72#discussion_r153360699
<GitHub82> [sinara] gkasprow tagged 3U_BNC/1.1rc1 at master: https://git.io/vbfEL
<GitHub130> [smoltcp] dlrobertson commented on pull request #72 2b014ba: Added `#[cfg_attr(not(feature = "proto-ipv6"), allow(dead_code))]`. Will add the `proto-ipv4` case once I move on to the `proto-ipv4` feature component of #76 https://github.com/m-labs/smoltcp/pull/72#discussion_r153360967
<GitHub94> [sinara] gkasprow tagged Zotlino/1.0rc1 at master: https://git.io/vbfuU
<GitHub69> [smoltcp] whitequark commented on pull request #72 32ef6f6: Maybe...... https://github.com/m-labs/smoltcp/pull/72#discussion_r153363581
<GitHub60> [smoltcp] whitequark commented on pull request #72 32ef6f6: Maybe...... https://github.com/m-labs/smoltcp/pull/72#discussion_r153363581
<GitHub129> [smoltcp] whitequark commented on pull request #72 32ef6f6: Seems weird to stringify those since we cannot parse them. It should be one or the other. https://github.com/m-labs/smoltcp/pull/72#discussion_r153363746
<sb0> whitequark, yes rip it
<sb0> whitequark, no dhcp planned
<GitHub166> [artiq] sbourdeauducq commented on issue #854: No packet can be transmitted or received. When the PHY is clocked, and my cable is not broken (the SATA hack is very fragile), then autonegociation succeeds. https://github.com/m-labs/artiq/issues/854#issuecomment-347377877
<GitHub103> [artiq] sbourdeauducq closed pull request #855: Label masters with friendly name, store dashboard config per master (closes #848) (master...multidashboard-config) https://github.com/m-labs/artiq/pull/855
<GitHub72> [artiq] sbourdeauducq pushed 10 new commits to master: https://github.com/m-labs/artiq/compare/cfb41e71a89d...1426ecad649b
<GitHub72> artiq/master 2852e79 Chris Ballance: dashboard: store separate configuration data for each master, keyed by server and port
<GitHub72> artiq/master fafabac Chris Ballance: master: add friendly name
<GitHub72> artiq/master 84b5e68 Chris Ballance: dashboard: use master's friendly name in dashboard title
<bb-m-labs> build #922 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/922
<bb-m-labs> build #1806 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1806 blamelist: Chris Ballance <chris.ballance@physics.ox.ac.uk>
[X-Scale] has joined #m-labs
X-Scale has quit [Ping timeout: 255 seconds]
[X-Scale] is now known as X-Scale
FelixVi has quit []
rohitksingh_work has joined #m-labs
<GitHub98> [smoltcp] dlrobertson commented on pull request #72 32ef6f6: After thinking about this again, adding IPv4 mapped addresses could be a good follow up PR. AFAIK `From<Ipv4Address>` should be implemented for `Ipv6Addr`, we should be able to parse IPv4 mapped addresses, and we should print them differently. I'll remove this for now https://github.com/m-labs/smoltcp/pull/72#discussion_r153392553
FelixVi has joined #m-labs
FelixVi2 has joined #m-labs
FelixVi has quit [Ping timeout: 276 seconds]
FelixVi2 has quit []
<sb0> what should be the signal level on the sayma clock input?
rohitksingh_work has quit [Ping timeout: 276 seconds]
rohitksingh_work has joined #m-labs
cedric has quit [Ping timeout: 240 seconds]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
<sb0> why is sayma rtm using a 8-output clock buffer with only one of those outputs used? (ic46) ...are there really no smaller clock muxes?
sb0 has quit [Ping timeout: 248 seconds]
sb0 has joined #m-labs
<GitHub15> [artiq] kesht123 commented on issue #845: Sorry for the delay,... https://github.com/m-labs/artiq/issues/845#issuecomment-347503425
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
hartytp has joined #m-labs
<hartytp> sb0: re muxes
<hartytp> 1. For better or worse, the decision was made to design Sayma to have the highest performance to ensure that it won't limit even really high fidelity quantum logic gates.While there are lots of clock muxes about
<hartytp> most of them either don't specify the phase noise + propagation delay temp co, or do specify it and it's bad
<hartytp> If you want a mux with the kind of performance of those ADI/HMC LVPECL chips then your choices are v limited. (note also that we don't want anything with an internal phase shifter, as those tend to have crap propagation delay temp cos)
<hartytp> If you can find a more suitable IC and do a noise/stability analysis to show that it's good enough, then that'd be great. But, IIRC, a few of us looked at all the manufacturers and concluded that there was nothing better. NB IIRC ADI/HMC don't offer LVPECL muxes with < 8 channels
<hartytp> 2. The power consumption is dominated by the output stages. So for the unused channels, which aren't biased, there is essentially no power consumption
<hartytp> 3. When one takes into account bulk purchase discounts + the cost of adding extra BOM lines, it's generally cheaper to use the same mux IC everywhere, even if it's over specified in most places
<hartytp> 4. Probably everyone agrees that the Sayma clock distribution is overly complex; the only way we could get everyone to agree in the design stage was to support pretty much every possibility one can imagine. This isn't a major issue, but does have (relatively small) downsides in terms of cost/complexity/power consumption
<hartytp> My hope (assumption) is that once people have started using the boards they will relax a bit and agree to let us drop a couple of clocking options so we can remove a mux or two. This is something we can trivially do in v2.
hartytp has quit [Quit: Page closed]
hartytp has joined #m-labs
<hartytp> sb0: <sb0> what should be the signal level on the sayma clock input?
<hartytp> assuming you mean the ADCLK parts or those LTC sine-square things, 0dBm - 10dBm is typical
<sb0> the clock input goes through the LTC sine-square thing
<hartytp> although, they can take quite a bit more, and will generally also work down to pretty small clock voltages (albeit with worse phase noise)
<sb0> and a transformer
<hartytp> we're driving differential IIRC. they recommend 0.2V to 2V (0.8V typical) differential signals
<hartytp> (Vpp that is)
<hartytp> transformer gives a sqrt(2) step-up (50Ohm to 100Ohm conversion). You can ignore the loss (a bit under a dB IIRC). So input would typically be 0dBm
<hartytp> anyway, the data sheets for those ICs are pretty good, and should have all the info you need.
hartytp has quit [Quit: Page closed]
<sb0> yes, i was mostly unsure about the transformer
rohitksingh has quit [Quit: Leaving.]
<sb0> _florent_, with your new settings, does the hmc7043 expect 600MHz or 1.2GHz?
cr1901_modern has quit [Read error: Connection reset by peer]
<sb0> it's 1.2GHz right? and the divider is 2, not 1 as you wrote in the comments?
cr1901_modern has joined #m-labs
FelixVi has joined #m-labs
<GitHub45> [artiq] jonaskeller opened issue #857: ARP storm fix for Artiq 3 https://github.com/m-labs/artiq/issues/857
mumptai has joined #m-labs
mumptai has quit [Quit: Verlassend]