02:08 <sb0_> rjo, before prepare(). prepare() may still use parameters to pre-compute things

04:29 <cr1901_modern> Looking at cheap and/or microcontroller friendly FPGA programming solutions >>

04:29 <cr1901_modern> http://en.qi-hardware.com/wiki/Milkymist_JTAG-serial_daughterboard IS this essentially "convert FTDI to the bitstream Xilinx FPGAs expect?"

04:29 <cr1901_modern> FTDI RS232*

04:33 <sb0> ftdi chips support many other modes in addition to rs232

04:35 <cr1901_modern> I only became aware of that recently, but am not sure how to do anything with that knowledge. I have a 6-pin FTDI cable. When I plug it in, Windows (and Linux/BSD) just think it's a serial port

04:37 <cr1901_modern> I guess libftdi unlocks the rest of the features

06:07 <cr1901_modern> Well that's good. It appears my FTDI cable is broken to the extent that I BSOD when I try using it. I guess paying for one of those damn JTAG cables is unavoidable.

06:09 <cr1901_modern> Unless I can be arsed to port libxsvf to NetBSD Raspberry Pi, which is looking unlikely.

06:21 <sb0> BSOD sounds more like a windows than a hardware problem

06:25 <cr1901_modern> It could go either way, at this point. Though my FTDI cable was giving me trouble before back in January. Maybe time to buy a new one soon in light of learning about the bitbang modes a few weeks ago.

06:27 <cr1901_modern> At least getting a cable for FPGA/CPLDs isn't as bad as, say, getting a programmer for GALs... those are horrible.

06:33 <sb0> does anyone still use GALs these days?

06:37 <cr1901_modern> Well, Atmel still sells them at least. I was just making an analogy that "it could be worse"

06:38 <cr1901_modern> i.e. CPLDs (and by extension FPGAs) could be as difficult to program as GALs and PALs that used to be used in their place.

07:47 <key2> io

10:06 <GitHub198> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vktDl

10:06 <GitHub198> artiq/master 4bf7875 Yann Sionneau: flash_storage: refactor + unit tests + artiq_coreconfig.py CLI + doc

10:31 <rjo> sb0: ok. so the pdb state just before prepare() is relevant for everything (modulo the experiments own modifications). and and a flush as a submission parameter would empty all three pipeline stages before taking the new snapshot and calling the respecitve prepare()

10:35 <travis-ci> m-labs/artiq#161 (master - 4bf7875 : Yann Sionneau): The build passed.

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

10:44 <GitHub3> [misoc] sbourdeauducq pushed 2 new commits to master: http://git.io/vktbY

10:44 <GitHub3> misoc/master 3f7e161 Yann Sionneau: spiflash: cleanup unnecessary parenthesis

10:44 <GitHub3> misoc/master a8b9c12 Yann Sionneau: spiflash: now using 64k sectors

10:56 <GitHub14> [artiq] fallen pushed 1 new commit to master: http://git.io/vktjQ

10:56 <GitHub14> artiq/master c32133b Yann Sionneau: flash_storage: avoid crash if a record size gets corrupted to be less than 6

10:58 <sb0> rjo, yes. shall we do that? (submission parameter and no function call)

11:00 <rjo> it makes sense if the automatic reading of the pdb happens before prepare() anyway. and a submission parameter would be the only way to affect that.

11:26 <GitHub169> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vkqtO

11:26 <GitHub169> artiq/master 0b05b54 Sebastien Bourdeauducq: test: add scheduler unittest

11:26 <travis-ci> m-labs/artiq#162 (master - c32133b : Yann Sionneau): The build passed.

11:26 <travis-ci> Build details : http://travis-ci.org/m-labs/artiq/builds/64234803

11:28 <sb0> there's no more automatic reading of the pdb at experiment creation; __getattr__ issues the requests now

11:30 <sb0> ...but without the submission parameter, some pdb reading may still happen before flush(), even if flush() is the first instruction in build(), in case the experiment creates drivers that read parameters

11:31 <sb0> unlike parameters, drivers are not created when needed by __getattr__, but all of them are created in __init__

11:54 <travis-ci> m-labs/artiq#163 (master - 0b05b54 : Sebastien Bourdeauducq): The build passed.

11:54 <travis-ci> Build details : http://travis-ci.org/m-labs/artiq/builds/64237768

11:56 <key2> hey, at what freq do you guys run misoc on a Spartan 6 ?

13:45 <sb0> 83MHz

14:06 <GitHub179> [artiq] whitequark created new-py2llvm (+1 new commit): http://git.io/vkmYt

14:06 <GitHub179> artiq/new-py2llvm c75fd6b whitequark: Replace builtin ast with pythonparser.ast.

14:13 <whitequark> sb0: how do you feel about importing `lit` into artiq tree for testing py2llvm?

14:14 <whitequark> lit is the tool LLVM uses to test its code generation. it's more or less a pattern matching tool that works well with the kind of structure .ll files have

14:14 <whitequark> (or .s for that matter)

14:24 <sb0_> whitequark, add it as external dependency? or copy its code into artiq?

14:25 <whitequark> it's not in any package management system I know of

14:25 <whitequark> in the past I have just copied it. it's like a dozen files

14:25 <sb0_> it has a setup.py

14:25 <whitequark> hm

14:25 <whitequark> oh neat it's in pypi

14:25 <whitequark> oh, 2014-10-22. recent.

14:41 <travis-ci> m-labs/artiq#164 (new-py2llvm - c75fd6b : whitequark): The build failed.

14:41 <travis-ci> Build details : http://travis-ci.org/m-labs/artiq/builds/64258569

14:55 <sb0_> so yes, sure use it

19:43 <GitHub54> [artiq] fallen pushed 1 new commit to master: http://git.io/vkOHK

19:43 <GitHub54> artiq/master 4da377e Yann Sionneau: setup/conda: update frontends

20:12 <travis-ci> m-labs/artiq#165 (master - 4da377e : Yann Sionneau): The build passed.

20:12 <travis-ci> Build details : http://travis-ci.org/m-labs/artiq/builds/64311018