<GitHub-m-labs>
[artiq] hartytp commented on issue #1124: @sbourdeauducq what's the status of this? Is there anything else we should do before finalising plans for hardware v2.0? Do you think it's likely this could be a gw/fw bug, or do you think it's almost certainly a hw issue? https://github.com/m-labs/artiq/issues/1124#issuecomment-442353677
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1142: Supporting injection everywhere is quite complicated with all the details and different ways to set frequency (different DDS chips, SPI/parallel, su-servo, upcoming AD9910 RAM mode, AD9914 fractional FTW, etc) https://github.com/m-labs/artiq/issues/1142#issuecomment-442361759
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1124: Yeah, let's make more boards and see what happens. The current lack of usable boards is making trench warfare against bugs like this particularly difficult anyway. https://github.com/m-labs/artiq/issues/1124#issuecomment-442385086
<GitHub-m-labs>
[artiq] jordens commented on issue #1197: The problem you mention would be a bug and might have other consequences (not booting is a grave one but could just as well be much more subtle problems if the flash is corrupted). I haven't seen this. Could you file an issue and next time you observe it, dump the entire flash contents in the broken state (using openocd) and do your clear-flash combo and dump it again.
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #1197: > Could you file an issue and next time you observe it, dump the entire flash contents in the broken state (using openocd) and do your clear-flash combo and dump it again. Then we can debug the actual issue.... https://github.com/m-labs/artiq/pull/1197#issuecomment-442400732
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1197: Sometimes with some builds on Sayma, there is no output at all on the UART (@hartytp has also seen it), but I suspect this is only due to the bitstream (and likely a Vivado bug, or perhaps the legendary Ultrascale I/O timing instability across PVT and bitstream builds) and not the flash itself. https://github.com/m-labs/artiq/pull/1197#issuecomment-442401738
<bb-m-labs>
build #2728 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2728 blamelist: Pawe? K <marmeladapk@users.noreply.github.com>
<sb0>
whitequark: what about the syscall arg change?
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<GitHub-m-labs>
[artiq] hartytp commented on issue #1197: What I have seen on Kasli is that sometimes it stops giving me any output on the UART. Power cycling while leaving the USB connected and also `artiq_flash -t kasli start` do not help. Removing power and USB fixes the issue. https://github.com/m-labs/artiq/pull/1197#issuecomment-442451343
<acathla>
I think I found the bug, it's from the python code that sends bytes to the serial port... yeah I'm a noob in python too.
<GitHub-m-labs>
[artiq] jordens commented on issue #1199: This also happens (IIRC) if you want to use one Urukul with `sync_device` specified and another without or if you have a `AD9910` channel with `sw_device` and another without. https://github.com/m-labs/artiq/issues/1199#issuecomment-442521578
<GitHub-m-labs>
[artiq] jordens commented on issue #1199: Something similar happens (IIRC) if you want to use one Urukul with `sync_device` specified and another without or if you have a `AD9910` channel with `sw_device` and another without. https://github.com/m-labs/artiq/issues/1199#issuecomment-442521578
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1199: RPCs should be special cased and this should not happen here, the compiler should not know about the type of the controller client class. @whitequark https://github.com/m-labs/artiq/issues/1199#issuecomment-442536178
dlrobertson has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
lkcl has quit [Read error: Connection reset by peer]
lars__ has joined #m-labs
lkcl has joined #m-labs
<whitequark>
sb0: that change looks good to me
<whitequark>
it is definitely a typo i made
<GitHub-m-labs>
[artiq] whitequark commented on issue #1199: > RPCs should be special cased and this should not happen here, the compiler should not know about the type of the controller client class.... https://github.com/m-labs/artiq/issues/1199#issuecomment-442586655
<whitequark>
sb0: is there a reason migen doesn't support asynchronous resets in clock domains?
<cr1901_modern>
Last I asked the same question, it's b/c they destroy timing/are too difficult to use correctly. Of course you don't care if metastability occurs when you assert reset (as long as you hold it for more than one clock cycle). >>
<cr1901_modern>
But you still need synchronizing circuitry for when you release it
<whitequark>
yeah, I would use it with AsyncResetSynchronizer
<cr1901_modern>
I guess my q is why do you need one?
* cr1901_modern
needed it for vintage chip emulation, go figure