02:07 <GitHub> [artiq] sbourdeauducq commented on issue #670: > Is it possible to update the main as well?... https://github.com/m-labs/artiq/issues/670#issuecomment-284118491

02:14 <sb0> hm the 2GHz DAC frequency plans has a DRTIO serialization ratio of 40... surely this will be another trash fire

02:21 <sb0> whitequark, I had a look at the wishbone arbiter and it turns out you can starve other masters if you keep cyc asserted at all times

02:21 <sb0> maybe this is what happens when the DMA core freezes the SoC

02:22 <sb0> try changing "reqs = [m.cyc for m in masters]" into "reqs = [m.cyc & ~m.ack for m in masters]" in misoc wishbone.py

03:35 <sb0> "Qt is suitable due to its multi-platform GUI toolkit that provides good Python bindings [21, 22] and makes it possible to separate the GUI design from the implemented functionality. Also, Qt’s multi-thread ability ensures good scalability and parallel processing, which are essential requirements for complex experiments. Furthermore, Qt implements a signal-slot mechanism [23] that is very useful for concurrency, modular design, and interaction b

03:35 <sb0> etween GUI modules and logic modules"

03:36 <sb0> the Qudi people are optimists. just use a QTreeview with some automatic layout features enabled, and watch the "good Python bindings" melt and crap out.

03:36 <sb0> and threads for scalable, parallel processing in python? good one.

03:38 <sb0> and what's so special about signal/slots? it's just a callback list. and I wish it was actually a python list.

03:38 <whitequark> the signal/slot mechanism was revolutionary in C++

03:39 <whitequark> it predates support for closures or std::bind or even boost by many years

03:39 <whitequark> it's not really special in modern context outside of C-land

03:48 <rrika> hi, there's a "//8" in this line and I don't really get why: https://github.com/m-labs/misoc/blob/master/misoc/interconnect/wishbone.py#L256

03:49 <sb0> rrika, there is one bit of wishbone sel signal for 8 bits of data

03:49 <rrika> shouldn't both sides of the ":" have a //8 then?

03:50 <sb0> hm, yes, there's a problem here

03:51 <sb0> _florent_, ^

03:53 <sb0> I guess this doesn't cause any problem in practice, because the upper bound is truncated by the assignment

03:54 <rrika> sb0, I guess that means .eq doesn't warn for unequal widths then

03:55 <sb0> no it doesn't, there would be too many such warnings otherwise, e.g. on x.eq(x+1)

03:56 <rrika> I see. I just randomly started reading a .py file from the repo

03:56 <rrika> learning this dsl and wishbone at the same time

03:58 <GitHub104> [misoc] sbourdeauducq pushed 1 new commit to master: https://git.io/vyWTu

03:58 <GitHub104> misoc/master 9899efc Sebastien Bourdeauducq: wishbone: fix DownConverter sel upper bound...

03:59 <bb-m-labs> build #207 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/207

08:39 <whitequark> sb0: incidentally

08:39 <whitequark> analyzer.rs has this code:

08:39 <whitequark> let last_addr = &mut BUFFER.data[BUFFER_SIZE - 1] as *mut _ as usize;

08:39 <whitequark> csr::rtio_analyzer::dma_last_address_write(last_addr as u64);

08:39 <whitequark> is it bad that dma_last_address is not aligned?

08:50 <sb0> the core will realign it by setting its LSBs to 0

08:52 <sb0> DMA address registers in ARTIQ/MiSoC have the LSBs read-only and hardwired to 0

09:15 <whitequark> oh, that's a bug then

09:32 <sb0> the last address is inclusive

09:34 <sb0> so if BUFFER_SIZE is a multiple of the SDRAM word size (as it should), it's not a bug

09:35 <sb0> (also assuming that the buffer starts on a SDRAM word)

09:40 <whitequark> oh, hm

09:40 <whitequark> okay

09:43 <GitHub> [artiq] whitequark pushed 3 new commits to master: https://github.com/m-labs/artiq/compare/f121ca20fe15...218046d96c71

09:43 <GitHub> artiq/master 218046d whitequark: artiq_devtool: fix an infinite loop on network error.

09:43 <GitHub> artiq/master 924ae73 whitequark: firmware: fix DMA trace alignment and flush caches.

09:43 <GitHub> artiq/master 30ac42d whitequark: ksupport: fix an exception safety issue....

09:46 <sb0> whitequark, the data cache is write through, there is no need to flush it when you send data *to* the gateware

09:46 <sb0> (the CPU data cache)

09:46 <sb0> but you do need to flush L2

09:46 <whitequark> hm

09:47 <GitHub> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/98454e9bdaba90f91e59249230f21d3bd490fb07

09:47 <GitHub> artiq/master 98454e9 whitequark: runtime: remove unnecessary dcache flush....

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

10:13 <bb-m-labs> build #1367 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1367 blamelist: whitequark <whitequark@whitequark.org>

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

10:41 <bb-m-labs> build #1368 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1368 blamelist: whitequark <whitequark@whitequark.org>

11:57 <sb0> why is chrome a CPU hog when loading pages over a crappy wireless network (or, equivalently, a broadcom wireless driver)?

11:59 <whitequark> are you sure it's chrome specifically?

11:59 <whitequark> I'd be inclined to blame synchronous AJAX

12:07 <sb0> it does that even on wikipedia ...

12:08 <whitequark> that seems suspicious

12:08 <whitequark> what exactly consumes cycles (shift+esc) ?

12:08 <sb0> i'll have a look next time the broadcom driver craps out...

12:08 <whitequark> it seems unlikely that this is an outright bug in chrome, given that chrome specifically has a mode for emulating slow connections

12:08 <whitequark> you'd think any obvious bugs like that will be sorted out

12:09 <whitequark> I'm not even going to suggest stracing it because the amount of useless syscalls it does is beyond belief

12:30 <cr1901_modern> Is broadcom synonymous w/ crappy in this channel :)?

12:33 <whitequark> no, it is just synonymous with crappy

13:36 <sb0> whitequark, it's "browser" and "gpu process"

13:36 <whitequark> oh.

13:37 <whitequark> just turn off accelerated rendering.

13:37 <whitequark> advanced settings -> Use hardware acceleration when available

13:37 <whitequark> it's kind of buggy, on my previous laptop it leaked gigabytes of GPU buffers

13:37 <whitequark> well I'm not sure if it's buggy

13:38 <whitequark> it's probably graphics drivers but the result is the same

14:04 <cr1901_modern> whitequark: "it seems unlikely that this is an outright bug in chrome, given that chrome specifically has a mode for emulating slow connections" <-- it does? I mean, that's extremely useful, but I didn't know about this

14:04 <cr1901_modern> Maybe it's not in Opera

14:05 <whitequark> it's in developer tools

14:06 <cr1901_modern> Ahhh, under Network->Throttling Presets?

14:10 <whitequark> I think so

14:16 <rrika> what happens if I do "comb += [If(x, a.eq(0)), If(y, a.eq(1))]" and both x and y are true in the same cycle?

14:17 <sb0> same as verilog, last assignment is taken

14:19 <rrika> what a worrying default

14:21 <sb0> ?

14:21 <sb0> in your case a=1. what is the problem with that?

14:23 <rrika> I'd expect a crash during simulation telling me I tried to assign twice

14:24 <rrika> In hardware, of course there has to be a tie-breaker, I see that.

14:33 <sb0> no, this is actually useful

14:33 <sb0> it's not a tie-breaker - the last statement executed wins

14:34 <sb0> e.g. in a FSM you can insert "next_state.eq(state)" at the beginning, then the default behavior of the FSM is to stay in the current state

14:35 <rrika> that's super implicit though

14:35 <rrika> what's wrong with: next_state = MultiAssignableSignal()

14:37 <rrika> besides, I'm unsure what is considered "last" in a case like "class Foo(Module): def __init__(self, external, trigger): self.internal=Signal() self.comb += [If(trigger, external.eq(self.internal))]" … "external=Signal(); a = Foo(external, trigger0); b= Foo(external, trigger0)"

14:38 <rrika> does it depend on the order of "a" and "b" in self.submodules?

14:38 <rrika> what if they're in different parts of the hierarchy

14:56 <sb0> well it's pretty clear, considering that the logic is created in the submodules' __init__ functions

14:57 <sb0> there is also an implicit assignment to the comb signal's reset value, which means latches are always avoided with migen ...

14:58 <rrika> sb0, if trigger0 goes true, is b.internal is written to external?

14:59 <sb0> in http://www.feynmanlectures.caltech.edu/I_44.html it says: "It is also easy to see that the heat Q1 must be proportional to QS." (equation 44.9). this seems very obscure to me and not easy at all. any ideas?

15:01 <sb0> rrika, yes

15:02 <rrika> wait, instantiating Foo() a second time modifies 'external'?

15:02 <rrika> (as in, it remembers a new thing attached to it?)

15:03 <sb0> instantiating Foo calls its __init__ method that adds things to comb, so yes

15:03 <sb0> the first time you instantiated it it also "modified" external

15:03 <rrika> ugh, still better than learning verilog

15:04 <rrika> at least it's easy to remember

15:04 <sb0> I don't see what the problem is

15:04 <rrika> there is none, just having a culture shock

15:04 <rrika> thanks for the explanations

15:19 <topo> hi there!

15:19 <topo> I'm using migen with a minispartan6 board from scarab labs

15:21 <topo> when using the create_programmer() method from class Platform it passes 'minispartan6' as cable parameter but there is no cable named like that on programmer xc3sprog

15:22 <topo> the cable parameter should be changed to 'ftdi' as default, right? and even better if the method create_programmer() could accept a cable parameter

15:25 <topo> the parmeter part is not escencial but the default cable name should be changed to at least an actual existing cable in that programmer