17:26 <GitHub161> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/vZBV7

17:26 <GitHub161> migen/master 6e9d6d7 Yves Delley: fixed bug in value_bits_sign of mul operatiors

17:26 <GitHub161> migen/master 07efe9d Sébastien Bourdeauducq: Merge pull request #31 from burnpanck/fix-value_bits_sign-mul...

17:30 <sb0_> _florent_, what is sim_path here? https://github.com/m-labs/migen/blob/master/mibuild/sim/verilator.py#L126

17:32 <_florent_> it's where we find the dut_tb.cpp template

17:34 <_florent_> I don't know if it's possible to package this file with migen to avoid that...

17:35 <sb0_> well, that breaks if migen is installed as a python package, doesn't it?

17:35 <sb0_> or if you run the simulations in another folder

17:36 <sb0_> this sort of hack is not acceptable

17:38 <_florent_> I know, do you have something better to suggest? (we can also have the template in a .py file, but that will be difficult to read)

17:39 <sb0_> https://github.com/m-labs/artiq/blob/master/artiq/frontend/artiq_gui.py#L25

17:39 <sb0_> compatible with setuptools: https://github.com/m-labs/artiq/blob/master/setup.py#L69

17:41 <_florent_> ok thanks

17:48 <sb0_> _florent_, do you have any argument for not using openocd as the one and only way to program your boards?

17:49 <sb0_> there is a jungle of programmers in migen right now, which afaict can all be replaced by openocd for all xilinx targets

17:51 <_florent_> not sure openocd can replace FPGALink for HDMI2USB

17:53 <GitHub176> [migen] sbourdeauducq pushed 2 new commits to new: http://git.io/vZBMb

17:53 <GitHub176> migen/new 86f34e8 Sebastien Bourdeauducq: mibuild -> migen.build

17:53 <GitHub176> migen/new 1dcd2ac Yves Delley: fixed bug in value_bits_sign of mul operatiors

17:54 <_florent_> I'd like to keep support for others programmers, but if you think it's polluting too much migen, we can remove it but please keep the possibily to use others programmers

17:54 <_florent_> (provided externally)

17:56 <sb0_> you wanted to keep impact. what do you need it for?

17:56 <sb0_> well, have

17:57 <sb0_> some special proprietary cables?

17:57 <_florent_> is openocd working on windows?

17:57 <sb0_> it should

18:03 <_florent_> I'm ok to simplify things (and eventually have proprietary programmers in external directory), can we just wait openocd to be tested on windows?

18:05 <sb0_> yes. but i wonder why you care about proprietary programmers. they bring almost nothing to the table, are a pain to install, are limited in features and are bloated.

18:07 <sb0_> xc3sprog and fpgaprog are also buggy subsets of openocd, so I guess they can go as well after openocd is integrated

18:08 <_florent_> I don't specially care about proprietary programmers, just that I don't had alternative for now

18:08 <_florent_> xc3sprog should work on windows, but last time I tried I was not able to get it working

18:09 <_florent_> if openocd work on linux and windows, then I'll use it

18:10 <sb0_> ok

18:10 <sb0_> bbl

18:38 <GitHub102> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vZRev

18:38 <GitHub102> misoc/master 31956de Florent Kermarrec: dvisampler/edid: fix sda sampling, needs to be similar to scl....

19:47 <mithro> Heyo - we could use help upvoting the Numato Opsis stuff on reddit - https://www.reddit.com/search?q=selftext%3Ahttps%3A%2F%2Fwww.crowdsupply.com%2Fnumato-lab%2Fopsis&restrict_sr=&sort=relevance&t=all and https://www.reddit.com/search?q=url%3Ahttps%3A%2F%2Fwww.crowdsupply.com%2Fnumato-lab%2Fopsis&restrict_sr=&sort=relevance&t=all

20:59 <GitHub143> [migen] sbourdeauducq pushed 1 new commit to new: http://git.io/vZR9n

20:59 <GitHub143> migen/new 91ab3f0 Sebastien Bourdeauducq: remove genlib.misc.optree (use reduce instead)

21:00 <travis-ci> m-labs/migen#78 (new - 91ab3f0 : Sebastien Bourdeauducq): The build has errored.

21:00 <travis-ci> Build details : https://travis-ci.org/m-labs/migen/builds/79739997

21:03 <rjo> sb0: reduce does left-to-right cumulative evaluation. that's not the same as optree for operators that are not associative. finite width multiplication is non-associative afaict. and thus you can not infer the same (fast) tree-structure.

21:12 <cr1901_modern> rjo: I thought fixed-point multiplication (which is finite width) was associative? Just when you relax the fixed point requirement it's no longer associative

22:04 <rjo> i am pretty certain overflow makes it non-associative.

23:53 <sb0> rjo, hmm, I didn't think of using it for multiplication. isn't it associative anyway (with overflows)?

23:57 <sb0> hmm, the modulo isn't the same for each operation