04:30 <cr1901_modern> Well, my first exposure to C# (to port the programmer for my dev board to the command line) lulled me into a false sense of security that it would be easy to port. Spent more time debugging race conditions after turning on optimizations than I did porting the damn thing.

07:44 <GitHub159> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vI7XP

07:44 <GitHub159> artiq/new-py2llvm c89bf6f whitequark: Add support for UnaryOp.

08:18 <travis-ci> m-labs/artiq#204 (new-py2llvm - c89bf6f : whitequark): The build is still failing.

08:18 <travis-ci> Build details : http://travis-ci.org/m-labs/artiq/builds/66503141

08:21 <whitequark> travis-ci: shut uuuuup

08:39 <sb0> whitequark, can't edit travis.yml to disable non-master builds?

08:39 <whitequark> yeah I should do that

08:41 <sb0> whitequark, do you know why python list comprehensions with multiple for are in the [item for sublist in list for item in sublist] order?

08:41 <whitequark> as opposed to?

08:41 <sb0> instead of [item for item in sublist for sublist in list]

08:41 <whitequark> oh

08:44 <whitequark> I have no idea.

08:45 <whitequark> possibly for consistency with `if`?

08:45 <whitequark> the dataflow, logically, is: for..in -> if -> for..in -> if

08:45 <whitequark> (I'm assuming if predates multiple for's)

08:46 <whitequark> aha, exactly. to quote PEP-202

08:46 <whitequark> It is proposed to allow conditional construction of list literals

08:46 <whitequark> using for and if clauses. They would nest in the same way for

08:46 <whitequark> loops and if statements nest now.

08:47 <whitequark> "BDFL Pronouncement":

08:47 <whitequark> - The form [... for x... for y...] nests, with the last index

08:47 <whitequark> varying fastest, just like nested for loops.

09:43 <GitHub181> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vI53m

09:43 <GitHub181> artiq/master 86fbe38 Sebastien Bourdeauducq: gui: DDS monitor/injection (WIP)

09:59 <cr1901_modern> sb0: I think I'm missing something, but... [item for sublist in list for item in sublist], do you have a code snippet demonstrating that? It's been a while, but I thought [item for sublist in list for item in sublist] WAS correct o.0;

09:59 <cr1901_modern> or whitequark... anyone who gets it can answer this XD

10:01 <sb0> yes, it's correct

10:09 <cr1901_modern> Okay, that's what I thought. Started second guessing myself lol.

10:16 <travis-ci> m-labs/artiq#205 (master - 86fbe38 : Sebastien Bourdeauducq): The build passed.

10:16 <travis-ci> Build details : http://travis-ci.org/m-labs/artiq/builds/66515128

10:57 <cr1901_modern> sb0: Any known cases where Migen will generate invalid Verilog (or alternatively, valid Verilog where vendor tools won't accept it)?

11:12 <attie> cr1901_modern: a pretty trivial one is if you give it an invalid slicing, it'll reproduce that.

11:13 <attie> just made it spit out s[64:63] earlier by getting my loop indices wrong.

11:13 <attie> er, 63:64

11:14 <cr1901_modern> I made Migen generate a concatenation that was subsequently indexed in an assignment expression

11:15 <cr1901_modern> e.g. assign {a, b, c, d}[0] = my_wire;, where a,b,c,d are prev. defined

11:17 <sb0> cr1901_modern, can you fill in a issue on github?

11:17 <sb0> I don't guarantee I'll fix it because this sort of verilog problem tends to piss me off more than anything else, but at least those are documented

11:18 <cr1901_modern> Yea it's fine. I could also very well be doing something wrong.

11:18 <sb0> bah, {a, b, c, d}[0] = my_wire should be a valid expression

11:19 <cr1901_modern> Yea, then it's Xilinx's fault then.

11:19 <sb0> I mean, it makes sense. but the verilog standard often does not.

11:21 <cr1901_modern> For my dev board platform, I defined the GPIO/SRAM bus in terms of SRAM subsignals. As I'm writing the mux, I wanted to convert the SRAM record into a bus in Migen- manipulate it as an array. Migen is replacing EVERY instance of pads.raw_bits() with the concatenation of {a, b, c, d}.

11:21 <sb0> yeah, so?

11:21 <cr1901_modern> Well, I didn't know that was valid Verilog until 2 minutes ago >>

11:22 <cr1901_modern> and I thought the "correct" thing to do would've been to do an intermediate assignment to a bus

11:22 <cr1901_modern> e.g. my_bus = {a,b,c,d}; assign my_bus[0] = my_wire;

11:22 <sb0> that won't work because raw_bits() is bidirectional

11:24 <cr1901_modern> Oh... good point lol

11:24 <sb0> and yes, if verilog cannot slice concatenations, you have to write a transform that looks at each slicing of a concatenation, figure out the direction, and inserts appropriate intermediate signals and assignments

11:24 <sb0> which is annoying as hell for such a small detail

11:25 <cr1901_modern> And that would make the {a,b,c,d}[0] form necessary... not all of the lines with that expression fail in my example.

11:26 <cr1901_modern> And indeed: a, b, c, and d are not all the same direction

11:27 <sb0> ah yeah, for those cases it's even worse, you have to break the slice yourself...

11:31 <cr1901_modern> I'm making a test gist now (f***ing Tab Errors)

11:31 <sb0> put it in the issue tracker

11:48 <cr1901_modern> sb0: Done. Linked to relevant gist as well, as well as generated Verilog and Xilinx output, so you don't have to build it.

11:53 <sb0> cr1901_modern, ok, thanks!

15:25 <rjo_> sb0: do you have a log/link to florent's and your discussion about the shared L2 cache?

15:47 <sb0> rjo_, hmm, it was private emails in French

15:48 <sb0> but my latest email should tell you the essential points

15:50 <rjo_> ;) ok.

15:51 <rjo_> so do i get this right: you want to improve the current mailbox interface and widen it + speed it up.

15:51 <sb0> yeah, the current design is ugly (and I suspect, buggy)

15:52 <sb0> the mailbox itself is just passing pointers, the CPUs are using shared memory

15:53 <rjo_> naively i would just do a ~1.5 kB sized (ethernet frame) BRAM-backed, shared, mmapped window.

15:53 <rjo_> for data exchange

15:53 <rjo_> for code exchange still the shared/independently cached dram + flushing

15:53 <sb0> the CPUs have to share memory anyway for loading kernels

15:54 <sb0> and using the same shared memory mechanism for comms remove any need for serialization by the kernel CPU

15:54 <sb0> you can just pass any pointer to any structure

15:55 <rjo_> ok. that does break the layering principle a bit and the comms cpu now needs to understand the data to do the serialization.

15:56 <rjo_> isn't this still very much like regular DMA? how is the cache coherency thing solved in the usual DMA scenarios?

15:57 <sb0> flush the caches or access them via multiported memory to dma to/from them in parallel

15:58 <rjo_> ack. lasmi gives you the "multiport/parallel access/arbitration". and you are saying that cache flusing is expensive and could be avoided?

16:03 <sb0> ysionneau, what are cairo, cairoplot3, pycairo still doing in artiq/conda ? remove

16:03 <sb0> and pygobject

16:04 <sb0> rjo_, wishbone has it as well and is simpler

16:04 <sb0> some of the cache flushing could be avoided, yes

16:05 <sb0> all requires implementing a protocol like MSI and digging deep into the mor1kx code

16:10 <rjo_> sb0: are those L2 caches preserving the ordering of the writes (in time or in address) if they commit?

16:10 <sb0> what do you mean?

16:11 <sb0> anyway, I need to go. see you!

16:12 <rjo_> if they preserve ordering could you not just do a ring buffer style thing and then the atomicity/coherence only needs to happen in the pointers?

16:12 <rjo_> see you.

16:16 <GitHub119> [artiq] fallen pushed 1 new commit to master: http://git.io/vIFri

16:16 <GitHub119> artiq/master 2ed81f7 Yann Sionneau: conda: remove recipes we dont need anymore since the switch to Qt

16:48 <travis-ci> m-labs/artiq#206 (master - 2ed81f7 : Yann Sionneau): The build passed.

16:48 <travis-ci> Build details : http://travis-ci.org/m-labs/artiq/builds/66566391