07:59 <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

08:20 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1124: No idea. https://github.com/m-labs/artiq/issues/1124#issuecomment-442359103

08:30 <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

09:45 <GitHub-m-labs> [artiq] hartytp commented on issue #1124: @sbourdeauducq so, are you happy for us to press on with v2.0 as things are now? Or, is there anything else you want us to do first? https://github.com/m-labs/artiq/issues/1124#issuecomment-442384164

09:48 <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

09:51 <GitHub-m-labs> [artiq] hartytp commented on issue #1124: Sounds like a good plan. https://github.com/m-labs/artiq/issues/1124#issuecomment-442386066

10:24 <GitHub-m-labs> [artiq] marmeladapk opened pull request #1197: Added clear command to artiq_flash to erase flash memory (master...clear_flash) https://github.com/m-labs/artiq/pull/1197

10:30 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1197: Nitpicking but I would call it "erase" since OpenOCD already calls it "erase". https://github.com/m-labs/artiq/pull/1197#issuecomment-442398183

10:33 <GitHub-m-labs> [artiq] marmeladapk commented on issue #1197: Done https://github.com/m-labs/artiq/pull/1197#issuecomment-442399274

10:34 <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.

10:36 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1197: FWIW, I have also never seen it. Kasli has always flashed and booted reliably IME. https://github.com/m-labs/artiq/pull/1197#issuecomment-442400079

10:38 <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

10:41 <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

10:45 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1197: https://github.com/m-labs/artiq/issues/1064 https://github.com/m-labs/artiq/pull/1197#issuecomment-442402828

10:45 <GitHub-m-labs> [artiq] sbourdeauducq reopened issue #1064: Sayma: UART silence https://github.com/m-labs/artiq/issues/1064

10:45 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1064: Check I/O timing numbers (reported by Vivado) at the flash pins. https://github.com/m-labs/artiq/issues/1064#issuecomment-442402949

11:06 <bb-m-labs> build #2093 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2093

11:12 <GitHub-m-labs> [artiq] marmeladapk commented on issue #1064: AFAIK in case of @bradbqc it's the same bitstream that worked before and didn't work after flash.... https://github.com/m-labs/artiq/issues/1064#issuecomment-442410279

11:24 <bb-m-labs> build #2094 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2094

11:27 <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>

11:58 <sb0> whitequark: what about the syscall arg change?

13:45 <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

14:55 <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.

15:30 <GitHub-m-labs> [artiq] hartytp opened issue #1198: malformed device_db entries break artiq_ctlmgr https://github.com/m-labs/artiq/issues/1198

16:56 <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

16:58 <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

17:36 <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

20:04 <whitequark> sb0: that change looks good to me

20:04 <whitequark> it is definitely a typo i made

20:07 <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

20:12 <whitequark> sb0: is there a reason migen doesn't support asynchronous resets in clock domains?

20:27 <GitHub-m-labs> [artiq] jordens commented on issue #1199: I think that's correct. https://github.com/m-labs/artiq/issues/1199#issuecomment-442592801

20:31 <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). >>

20:31 <cr1901_modern> But you still need synchronizing circuitry for when you release it

20:32 <whitequark> yeah, I would use it with AsyncResetSynchronizer

20:44 <cr1901_modern> I guess my q is why do you need one?

21:01 <whitequark> cr1901_modern: multiple clock domains

21:01 <whitequark> resetting async fifo

21:01 <whitequark> even if the producer side is not running

21:12 <cr1901_modern> whitequark: If the producer side's clock is not running, how can you use an AsyncResetSynchronizer to reset the producer CD?

21:13 <cr1901_modern> anyways, my guess is sb0 will say "use an instance of Verilog code", like he did last time I asked for a D-latch :P

21:15 <whitequark> cr1901_modern: ARS uses an async reset

21:15 <whitequark> internally

21:15 <whitequark> that's why it's a Special

21:15 <whitequark> erm

21:15 <whitequark> async set

21:16 <cr1901_modern> AsyncResetSynchronizer requires a clock though to propogate that reset

21:17 <cr1901_modern> So if you're producer clk isn't running, your reset will not be propogated

21:17 <cr1901_modern> I must be missing something

21:32 <whitequark> it doesn't

21:32 <whitequark> look at how it's implemented

21:51 <cr1901_modern> https://github.com/m-labs/migen/blob/master/migen/build/lattice/common.py#L69-L77 There's a clock domain as input to both DFFS

21:52 <whitequark> SB_DFFS

21:52 <whitequark> D Flip-Flop with Asynchronous Set

21:52 <whitequark> so, reset assertion is propagated, reset deassertion is not (without clock)

21:53 <whitequark> as it should be

21:58 <cr1901_modern> Ahhh, oops

22:11 <cr1901_modern> Might be worth adding AsyncClockDomain() constructor to Migen?

22:11 <cr1901_modern> or async_reset=False to ClockDomain() constructor?

22:11 <cr1901_modern> Should be "easy" enough to change the code generated

22:12 <cr1901_modern> (simulator more difficult)