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
[X-Scale] has joined #m-labs
X-Scale has quit [Ping timeout: 245 seconds]
[X-Scale] is now known as X-Scale
ardavast has quit [Read error: Connection reset by peer]
ardavast has joined #m-labs
<sb0>
whitequark, no, just reload the bitstream
<whitequark>
ok
ardavast has quit [Read error: Connection reset by peer]
ardavast has joined #m-labs
futarisIRCcloud has joined #m-labs
<sb0>
is it OK to connect two Kasli EEM connectors together with an IDC cable? I can't see why not, but with 12V around I'd rather double-check than do something dumb
rohitksingh_work has joined #m-labs
ardavast has quit [Read error: Connection reset by peer]
<GitHub104>
[smoltcp] dlrobertson commented on pull request #218 5298144: This repr doesn't need `length` or `segments_left` they will always be 2 and 1 respectively. It is an invalid packet if they are not. https://github.com/m-labs/smoltcp/pull/218#discussion_r189965200
ardavast has quit [Remote host closed the connection]
ardavast has joined #m-labs
<GitHub155>
[smoltcp] hjr3 commented on pull request #218 5298144: I went back and forth on this. I decided to leave them explicit as I imagined that downstream code would not want these values implicit. If I remove those fields, should I provide methods on the Repr that return the number of length and number of segments left?... https://github.com/m-labs/smoltcp/pull/218#discussion_r189968694
<GitHub-m-labs>
[artiq] whitequark commented on issue #1009: No, this isn't supposed to be supported--`len` is currently only defined for builtin types, and `__len__` is ignored. Same for `__iter__`. https://github.com/m-labs/artiq/issues/1009#issuecomment-391090977
ardavast has quit [Read error: Connection reset by peer]
ardavast has joined #m-labs
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: @jbqubit I definitely agree with you that this all needs more documentation. However, I don't think that much of it is SU-servo specific. e.g. Kasli, Urukul and Sampler all need proper docs (as do the other EEMs), explaining the connections they need in a way that physicists understand. We also need some higher-level docs explaining how the Kasli/EEM ecosystem works and
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: Oh, and I'd generally tend to run Urkul's system clock at 1GHz. But, IIRC, you can use more or less any Urukul clock frequency you want with the servo. Essentially, the servo just takes control of the SPI port on Urkul, but leaves everything else alone. The SPI port is independent of the clock frequency IIRC (but, in case of doubt/questions, refer to the AD9910 data shee
<whitequark>
rjo: nope, can't fix #1007 until tomorrow
<whitequark>
the transformation I need really wants to be an LLVM pass, but we don't have any infrastructure for ARTIQ-specific LLVM passes
<whitequark>
actually, why on earth is test_clock_generator_loopback using FP at all?
<whitequark>
ah right, frequency is in FP. but 2**acc_width could be 1<<acc_width instead...
<whitequark>
it doesn't help very much though
<GitHub-m-labs>
[artiq] jordens commented on issue #1008: d446a3293ec2869aef4b2ec846b553975a38a01d also removes `aqctl_corelog`. That's a controller which is used throughout the examples. That was probably unintentional and needs to be reverted or fixed.... https://github.com/m-labs/artiq/issues/1008#issuecomment-391147028
<bb-m-labs>
build #2370 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2370 blamelist: whitequark <whitequark@whitequark.org>, Robert Jordens <jordens@gmail.com>