<GitHub-m-labs>
[artiq] mingshenli commented on issue #977: well， I 'm not sure what happened, maybe there are too many version artiq on my computer so the artiq-new raise some error. However, now I remove all the old artiq and install the 3.6 and all the problem solved. https://github.com/m-labs/artiq/issues/977#issuecomment-381104509
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #977: Good. Are you in the new ARTIQ Wechat group? There are other Chinese-speaking users there who might help you, especially WIPM who have a rather developed ARTIQ installation. If not give me your ID and I will add you. https://github.com/m-labs/artiq/issues/977#issuecomment-381106189
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #967: This is not expected. If serwb initializes correctly then the version should be printed; this does not require additional RTM FPGA voltages. https://github.com/m-labs/artiq/issues/967#issuecomment-381108949
<GitHub-m-labs>
picam/master e9c6dff Robert Jordens: misc fixes, test em, all parameters, roi
<GitHub-m-labs>
picam/master ee7d0d3 Robert Jordens: simplify instructions for picam.py
<sb0>
hartytp, i'm testing the new serwb on the hkg boards right now...
hartytp has joined #m-labs
<hartytp>
sb0: great
<hartytp>
let me know how you get on
<hartytp>
it looks like there is a hw issue on my board (maybe due to all the travelling it's done) so I'm not reading too much into ser-wb issues on my board atm
<sb0>
hartytp, the problem is not present on the HK boards
rohitksingh_wor1 has quit [Ping timeout: 265 seconds]
<greni>
Hi, is there any Migen forum?
<sb0>
greni, you can use the mailing list, or this channel
<greni>
ok, thanks
<GitHub84>
[smoltcp] whitequark commented on issue #191: Thanks for the PR! Since `icmpv6.rs` contains only "base" ICMPv6 packets right now, with `ndisc.rs` containing NDISC packet code, do you think you can move out `Repr` (which of course cannot be easily split) into `icmpv6repr.rs`? https://github.com/m-labs/smoltcp/pull/191#issuecomment-381125687
<GitHub105>
[smoltcp] whitequark commented on pull request #190 91fdc1f: I think it's fine to have fragmentation in default features as it's required in IPv4. API consumers can always not initialize the FragmentSet (which will happen by default), so this would only impact code size, and anyone conscious about code size should already turn off unused features. https://github.com/m-labs/smoltcp/pull/190#discussion_r181381
<hartytp>
sb0, rjo: can I run a thought past you re WR/clock recovery for sinara
<hartytp>
?
rohitksingh has joined #m-labs
rohitksingh1 has joined #m-labs
rohitksingh1 has quit [Client Quit]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
mumptai_ has quit [Quit: Verlassend]
<GitHub-m-labs>
[artiq] gkasprow commented on issue #967: Can I hold it for a while. I want to make sure that Ethernet works. I have 2 AMC boards and on each of them Ethernet PHY works in different manner :) https://github.com/m-labs/artiq/issues/967#issuecomment-381158640
<rjo>
greni: swap RHS and LHS on platform.request(...).eq(dut.input[...])
<rjo>
hartytp: sure
<hartytp>
rjo: so, here is the short(ish) summary
<hartytp>
I like the Si5324 setup for a few reasons (cost, complexity, it's a common part, etc)
<hartytp>
but, it has a few disadvantages (e.g. phase is non-deterministic at teh ~10ps level so it can't be used for SC1 data converters)
<hartytp>
I've been thinking about ways of going to a WR setup
<hartytp>
but want to minimize cost/complexity/breaking changes
<GitHub-m-labs>
[artiq] gkasprow commented on issue #967: Can I hold it for a while? I want to make sure that Ethernet works. I have 2 AMC boards and on each of them Ethernet PHY works in different manner :) https://github.com/m-labs/artiq/issues/967#issuecomment-381158640
<hartytp>
also, the whole DAC + VCO thing seems nasty to me -- once you go digital, you want to stay there.
greni has joined #m-labs
<hartytp>
Also, VCO tends to be more expensive and lower performance than XO
<hartytp>
so, was starting to think along the lines of using an XO + DDS instead, but that's quite a lot of complexity
<hartytp>
so...
<hartytp>
here is the idea
<hartytp>
replace the Xtal with a Si549
<hartytp>
(essentially a XO, PLL and DDS in a single package, and cheap)
<hartytp>
give it a dedicated I2C bus to Kasli
<hartytp>
if you set the default frequency to 114MHz then it will work in the current setup with no changes to firmware
<hartytp>
and isn't much more expensive than the current Xtal
<hartytp>
but, it then gives you the option of running the X0 at 125MHz and using the Si5324 in freerun mode
kmehall has quit [Remote host closed the connection]
<hartytp>
you can then do a digital frequency lock on the Si549 with >100Hz of BW using a DDMTD on the FPGA
<hartytp>
essentially, you do a digital WR with the Si549 and use the Si5324 as a buffer inside the loop. the wr loop removes all phase non-determinism/noise/drift from the two si components
<hartytp>
cheap, simple, backwards compatible
greni has quit [Read error: Connection reset by peer]
<hartytp>
what do you think?
<hartytp>
we've tested most components already (e.g. measured Si5324 phase noise when using a 100MHz Wenzel oscilator instead of the Xtal and having a 100MHz output)
greni has quit [Read error: Connection reset by peer]
greni has joined #m-labs
<rjo>
hartytp: i think parts of that won't work. the si5324 won't work with the si549 as a "crystal" (connected to xa/xb).
<hartytp>
rjo: why?
<hartytp>
(i.e. I've done it)
<rjo>
because it's not a crystal.
<hartytp>
well, okay, that probably does require a small fw change
<GitHub-m-labs>
[artiq] gkasprow commented on issue #854: @jbqubit if the LINK LED is off, there is no chance for Ethernet to work. If GMIICR register dump shows sensible content this means that the media converter did not manage to establish the link. https://github.com/m-labs/artiq/issues/854#issuecomment-381170448
<hartytp>
but, the Si5324 can take either XO or Xtal inputs
<hartytp>
but, you're correct, that I believe my assertion that it's strictly no firmware changes is incorrect
<hartytp>
(I have a noise spectrum of using the Si5324 with a 100MHz wenzel in and a 100MHz output, as well as a 125MHz OCVCXO input and a 125MHz output. They both look very clean)
<hartytp>
both in free run mode
<rjo>
what do we need the si5324 for at all? if we lock the si549 digitally then we are good to go.
<hartytp>
backwards compatibility
<hartytp>
and fanout
<hartytp>
but, basically nothing
<hartytp>
the idea would be that this is a change we can make to any sinara board with minimal work and essentially no extra expense
<hartytp>
we can then develop the gw/fw while users are using the boards and enable it once we're happy with it.
<rjo>
yes. the mux/fanout. but i'd develop the bare concept first and then make it bakwards compatible if that turns out to be beneficial.
<hartytp>
that's basically our plan
<hartytp>
(unless you can see an objection)
<hartytp>
we'll dead bug the components onto Kasli
<rjo>
the prototype for that would be to implement clock recovery using an fpga and the si549.
<hartytp>
but, even if we do go down that route, I don't see the harm in having the Si5324.
<hartytp>
we need fanout and it's not really more expensive than any other decent fanout buffer
<hartytp>
and it gives us more options
<hartytp>
+ it's a known quantity
<hartytp>
the other question I have is how you'd feel about adding something like this to Kasli
<hartytp>
atm Kasli can't be used as a DRTIO master/repeater upstream of anything that needs really good timing accuracy from the recovered clock
<hartytp>
which isn't the end of the world
<rjo>
i don't think it's good to have that many components interacting in a multilevel triply cascaded PLL.
<hartytp>
but, my thinking is that if we can get WR to work on Sayma we can push to only support SC1 operation with the DAC clocked from the recovered clock
<hartytp>
which could make life a lot easier
<hartytp>
so, I'm generally keen on WR
<hartytp>
in which case, it's nice to have it supported on Kasli as well if it can be done without significant cost/complexity
<hartytp>
anyway, something to think about
<hartytp>
re the Si5324: yes, I know what you mean, but I do think that in this case it's fine
<hartytp>
it has enough BW and a low enough noise floor that putting it in the loop won't degrade things
<hartytp>
(we think based on measurements and modelling)
<hartytp>
but, we'll know for sure once we demonstrate it using a hacked version of Kasli
<rjo>
i think it's a good idea to prototype and evaluate. and right now my guess is that apart from the hassle (implement, debug DDMTD) it should work. but it seems premature to to decide on adding/replacing that on kasli.
<hartytp>
sure
<hartytp>
well, I think we'll start prototyping now
<hartytp>
and hold off buying more Kasli for the time being
<hartytp>
(not just because of this -- I want to let the dust settle on a few other issues like grounding before we buy a large stack of them)
<rjo>
ack.
<hartytp>
(FWIW, I'm really happy with Kasli as an overall design)
<GitHub-m-labs>
[artiq] whitequark commented on issue #919: @jbqubit Right now there is the problem that the clock generator we have been using in the lab died, so I'm figuring out how to set up NVSynth. https://github.com/m-labs/artiq/issues/919#issuecomment-381175478
<GitHub-m-labs>
[artiq] gkasprow commented on issue #854: These converters do not always follow the SFP specification. I remember 2 LEDs on with Ethernet working. Anyway, I will look at this. Thanks. Right now I have also 2 LEDs on on the converter. https://github.com/m-labs/artiq/issues/854#issuecomment-381176695
<greni>
rjo, I still cannot get the correct verilog output, could you give me a hint
<rjo>
greni: well. don't swap the dut.output line. "eq()" is an assignment.
<greni>
rjo: no it does not, but well my migen code is incorrent, I've been reading about migen 2nd day but I still don't fully understand it...
<greni>
and unfortunatelly this part is not yet included in the doc
<greni>
rjo: thanks for the last hint now it looks much better
<greni>
rjo: one more question how I can remove clk from my simple example?
hartytp has quit [Quit: Page closed]
<rjo>
greni: don't know from the top of my head.
<greni>
rjo: ok no problem , thanks, maybe I will figure this out
greni has quit [Ping timeout: 260 seconds]
<GitHub-m-labs>
[artiq] jbqubit commented on issue #967: I built from master today using ```--without-sawg```. serwb is successful over 10 reboots of Sayma (s/n 8). Great work @enjoy-digital!... https://github.com/m-labs/artiq/issues/967#issuecomment-381198865
<GitHub-m-labs>
[artiq] jbqubit commented on issue #967: Continue test using same build of master with --without-sawg on Sayma (s/n 7). I am successfully loading RTM gateware. serwb is successful over 10 rounds of issuing ```artiq_flash -t sayma -f sayma.config storage start```. This board also does not show ```RTM gateware version...```. ... https://github.com/m-labs/artiq/issues/967#issuecomment-381210182
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #967: @enjoy-digital Are you implementing all the tricks that were found to be necessary for the Ultrascale IO garbage to behave with SDRAM into serwb? https://github.com/m-labs/artiq/issues/967#issuecomment-381265196