02:23 <mtrbot-ml> [mattermost] <sb10q> @cjbe why did you set a different tool_triple for the Cortex A9 target? you wrote code to pass "armv7-unknown-linux-gnueabihf" to LLVM while using "arm-linux-gnueabihf-xxx" for binutils

02:23 <mtrbot-ml> [mattermost] <sb10q> but LLVM seems just fine with "arm-linux-gnueabihf"

02:26 <mtrbot-ml> [mattermost] <sb10q> armv7 adds some optimizations?

02:27 <mtrbot-ml> [mattermost] <sb10q> this looks redundant with the "CPU features" list...

02:36 <mtrbot-ml> [mattermost] <sb10q> binutils is also fine with armv7-unknown-linux-gnueabihf...

02:36 <mtrbot-ml> [mattermost] <sb10q> is the discrepancy just because you copied binutils binary from somewhere else?

02:37 <sb0> whitequark: is there a difference between armv7-unknown-linux-gnueabihf and armv7-linux-gnueabihf?

03:09 <whitequark> sb0: the first "unknown" is a "platform"

03:09 <whitequark> the only time i've seen it matter is with mingw

03:09 <whitequark> so i'm gonna say no

03:12 <sb0> ok thanks

03:22 <sb0> hm, rustc insists on the -unknown

03:22 <whitequark> the triple is technically made out of four parts

03:22 <whitequark> (yes, I know, sounds absurd)

03:23 <whitequark> LLVM will fill in the missing parts with basically its best guess

03:23 <whitequark> I suspect rustc wouldn't?

03:23 <whitequark> the 2nd triple is actually more like armv7--linux-gnueabihf, and the -- is the same as -unknown-

03:31 <whitequark> 2nd part of the triple*

09:58 <_whitenotifier> [m-labs/nmigen] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fjA4L

09:58 <_whitenotifier> [m-labs/nmigen] whitequark b4b5d9e - vendor.lattice_ecp5: revert default toolchain to Trellis.

09:58 <_whitenotifier> [m-labs/nmigen] whitequark 8de00a0 - back.verilog: bump Yosys version requirement to 0.9.

09:59 <_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjA4t

09:59 <_whitenotifier> [m-labs/nmigen] whitequark 2168ff5 - back.verilog: bump Yosys version requirement to 0.9.

09:59 <_whitenotifier> [nmigen] whitequark closed issue #55: Should nMigen check Yosys version? - https://git.io/fjkxp

10:12 <_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/576743072?utm_source=github_status&utm_medium=notification

10:12 <_whitenotifier> [nmigen] Success. 80.51% (+0.15%) compared to 72cf4ca - https://codecov.io/gh/m-labs/nmigen/commit/8de00a07a89b5d6f7f2bbc9da881492c02b45683

10:12 <_whitenotifier> [nmigen] Failure. 66.66% of diff hit (target 80.36%) - https://codecov.io/gh/m-labs/nmigen/commit/8de00a07a89b5d6f7f2bbc9da881492c02b45683

10:13 <_whitenotifier> [nmigen] Success. 80.36% remains the same compared to 72cf4ca - https://codecov.io/gh/m-labs/nmigen/commit/8de00a07a89b5d6f7f2bbc9da881492c02b45683

10:13 <_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/576743072?utm_source=github_status&utm_medium=notification

10:14 <_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/576743570?utm_source=github_status&utm_medium=notification

10:14 <_whitenotifier> [nmigen] Success. 80.51% (+0.15%) compared to 72cf4ca - https://codecov.io/gh/m-labs/nmigen/commit/2168ff512bfe04806b35c09d3b1d265a16c4ddbc

10:14 <_whitenotifier> [nmigen] Failure. 66.66% of diff hit (target 80.36%) - https://codecov.io/gh/m-labs/nmigen/commit/2168ff512bfe04806b35c09d3b1d265a16c4ddbc

10:18 <mtrbot-ml> [mattermost] <cjbe> @sb10q it was a dirty hack to get around some issues with my crappy toolchain - I was in a hurry to get a proof-of-concept working, so I did not investigate.

10:25 <_whitenotifier> [nmigen] Success. 80.36% remains the same compared to 72cf4ca - https://codecov.io/gh/m-labs/nmigen/commit/2168ff512bfe04806b35c09d3b1d265a16c4ddbc

10:25 <_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/576743570?utm_source=github_status&utm_medium=notification

12:10 <sb0> whitequark: is Glasgow able to stream samples into a computer without bugs or much fuss, at what speed, and how can I get one?

12:11 <sb0> all USB hosts appear to be affected by this sigrok/fx2 bug, just with different probablilites...

12:11 <whitequark> sb0: you can stream up to full USB2 bandwidth, i've never had any problem with the USB part of that code, and ... well, they're not mass produced yet

12:11 <whitequark> i can bring one of mine to the lab i think

12:12 <whitequark> do you want me to do it today?

12:12 <whitequark> (re USB part, if you want soft realtime response to events in python it can become a lil tricky but still doable on a fast PC)

12:12 <sb0> I just need streaming at a constant rate and low jitter, latency does not matter

12:13 <sb0> (constant rate for the samples, latency variations don't matter either)

12:13 <whitequark> sure, it does that easily

12:13 <whitequark> is 48 Msps enough?

12:14 <sb0> it's better than the shitty 6Msps I'm getting out of fx2 right now because anything higher crashes

12:14 <whitequark> if not the CDC code is affected by the bug in migen/nmigen where AsyncFIFOBuffered is translated to FFRAM

12:17 <cr1901_modern> sb0: >all USB hosts appear to be affected by this sigrok/fx2 bug, just with different probablilites.

12:17 <cr1901_modern> You mean the thing where you'll all of a sudden stop getting all 24MHz bandwidth and have to do 16 or even 12 to get reliable samples?

12:17 <sb0> really reliable is 6, but yes

12:17 <cr1901_modern> Can duplicate on Windoze too :P

12:18 <whitequark> cr1901_modern: libusb on windows works like shit in first place

12:18 <whitequark> i never got windows performance of glasgow quite to the point of the linux version

12:18 <whitequark> winusb is especially bad but libusbK isn't too great either

12:20 <cr1901_modern> switching to a different USB port gets me back to full 24MHz bandwidth (especially if not attached to my powered 2.0 hub) most of the time.

12:21 <cr1901_modern> whitequark: Anyways, tbh I don't have any working 3.0 ports on this laptop- they died long ago. But even sacrificing some channels to get more bandwidth from Glasgow on 2.0 would be a nice alternative to fx2lafw

12:21 <sb0> how did they die?

12:22 <cr1901_modern> Damned if I know- some trace integrity seems to be going? The laptop is 8 years old.

12:23 <cr1901_modern> Bluetooth and fingerprint reader sometimes goes to hell and falls of the internal USB for the same reason

12:43 <whitequark> wtf