sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<cr1901_modern> sb0: When you did REing for the Ikos Pegasus did you get as far as extracting the XC2xxx (I think they were) bitstreams?
<rqou> not sure what the context is, but XC2 bitstream parsing for RE purposes is actually done, just undocumented
<cr1901_modern> Where? (And I was mistaken they were xc4xxx)
<cr1901_modern> Or I mean who did it? Are you referring to digshadow's comments in ##openfpga?
<rqou> xc2jed2json plus appropriate use of yosys "techmap"
<rqou> this is for xc2 only, not 4000/9500
<cr1901_modern> rqou: Apparently xc2c32 is a coolrunner part?
<rqou> yes
<cr1901_modern> I meant "xc2064"/"xc2016" which are the first FPGAs Xilinx produced
<cr1901_modern> I was not aware that Xilinx reused "xc2" for Coolrunner
<rqou> no those aren't the same thing
<cr1901_modern> I noticed you combined 4000/9500. Are they also CPLDs
<cr1901_modern> ?*
<cr1901_modern> well 9500 certainly is, but xc4000?
<rqou> no, 4000 is an fpga
<cr1901_modern> Ahh okay then. So the context is that IKOS Pegasus is an ASIC emulator that you'll occassionally see pictures of on Wikimedia. I found out in the past, sb0 did RE work on it,
<cr1901_modern> and right now it's sitting in storage at Electrolab in France
<cr1901_modern> I was wondering if the RE work got as far as REing what was already stored on the FPGAs/bitstream format
<sb0> I suppose you'd load your asic design in there...
<cr1901_modern> I thought some of them were used for control purposes/glue logic
<GitHub181> [artiq] sbourdeauducq commented on issue #854: @gkasprow ping. https://github.com/m-labs/artiq/issues/854#issuecomment-353699512
<rqou> man i really need to spend some time living in Europe :P
<rqou> all the cool stuff and people seem to be over there
<sb0> rqou, the artiq boards in hk have more LUTs than this thing
<sb0> faster too
<rqou> yes of course
<rqou> but it's always cool to see hardware that _looks_ really fancy and expensive
<rqou> hmm, i suppose m-labs meets that criteria too :P
<cr1901_modern> more chips == more impressive (perceptually anyway)
<GitHub81> [smoltcp] dlrobertson commented on pull request #98 bcbdef3: After looking at the tests, I'm not sure how a set of mock IP addresses would work. So I added the `ipv4` specific stuff in a `ipv4_locals` module. Would it be an public mock `IpAddress` be an `IPv6` variant if `proto-ipv6` was enabled and `IPv4` if not? Or would we have a public collection of mock IPv4 addresses and a public collection of IPv6 addresses
<GitHub86> [smoltcp] dlrobertson opened issue #99: ICMP sockets should not use ICMPv4 specific structures. https://github.com/m-labs/smoltcp/issues/99
kuldeep has quit [Ping timeout: 264 seconds]
<GitHub177> [smoltcp] dlrobertson commented on pull request #98 bcbdef3: After looking at the tests, I'm not sure how a set of mock IP addresses would work. So I added the `ipv4` specific stuff in a `ipv4_locals` module. Would the public mock `IpAddress` be an `IPv6` variant if `proto-ipv6` was enabled and `IPv4` if not? Or would we have a public collection of mock IPv4 addresses and a public collection of IPv6 addresses. 
kuldeep has joined #m-labs
<GitHub119> [artiq] jonaskeller commented on issue #877: I'm afraid I can't do any tests right now, because I've already left for the holidays. Will do so once I'm back Jan 4th. https://github.com/m-labs/artiq/issues/877#issuecomment-353703854
dlrobertson has quit [Quit: WeeChat 2.0]
<GitHub156> [artiq] sbourdeauducq opened issue #881: back up Github issues https://github.com/m-labs/artiq/issues/881
<GitHub38> [smoltcp] BurntPizza opened pull request #100: Add faster TCP checksum implementation for x86_64 (master...master) https://github.com/m-labs/smoltcp/pull/100
<GitHub156> [artiq] gkasprow commented on issue #854: @sbourdeauducq This is regular MII mode. The PHY is operating in 1Gbit mode and converting to 100Mbit mode. We use home-made sata-sfp cables for long time in CBM experiment. In which place your cable breaks? https://github.com/m-labs/artiq/issues/854#issuecomment-353717400
<GitHub189> [artiq] gkasprow commented on issue #854: Another option is simple PCB with AMC connector on one side and SFP on another side.... https://github.com/m-labs/artiq/issues/854#issuecomment-353717524
<GitHub126> [artiq] gkasprow commented on issue #854: Is the LINK LED on? On my AMC board it is.... https://github.com/m-labs/artiq/issues/854#issuecomment-353717822
<GitHub171> [artiq] gkasprow commented on issue #854: I cannot test it because University is closed and I'm 200km away. https://github.com/m-labs/artiq/issues/854#issuecomment-353717862
<GitHub30> [artiq] sbourdeauducq commented on issue #854: Again, the cable you gave me 1) had its solders inside the SFP broken 2) causes issues with at least one of my media converters due to missing EEPROM and/or link indicator signal. I had to make new cables using copper SFP-SFP cables cut in half and soldered to SATA connectors, but that's still fragile.... https://github.com/m-labs/artiq/issues/854#issuecomment-3537184
<GitHub148> [artiq] sbourdeauducq commented on issue #854: Again, the cable you gave me 1) had its solders inside the SFP broken 2) causes issues with at least one of my media converters due to missing EEPROM and/or link indicator signal. I had to make new cables using copper SFP-SFP cables cut in half and soldered to SATA connectors, but that's still fragile.... https://github.com/m-labs/artiq/issues/854#issuecomment-35371
<GitHub39> [artiq] sbourdeauducq commented on issue #854: Again, the cable you gave me 1) had its solders inside the SFP broken 2) causes issues with at least one of my media converters due to missing EEPROM and/or link indicator signal. I had to make new cables using copper SFP-SFP cables cut in half and soldered to SATA connectors, but that's still fragile.... https://github.com/m-labs/artiq/issues/854#issuecomment-3537184
<GitHub171> [artiq] gkasprow commented on issue #854: did you reboot the board after you flashed the firmware?... https://github.com/m-labs/artiq/issues/854#issuecomment-353719205
<GitHub93> [artiq] sbourdeauducq commented on issue #854: Yes, I power-cycled it. The FPGA power doesn't come back until the JTAG probe is unplugged anyway. https://github.com/m-labs/artiq/issues/854#issuecomment-353719299
<GitHub52> [artiq] sbourdeauducq commented on issue #854: Yes, I power-cycled it. The FPGA power doesn't come back until the JTAG probe is unplugged anyway, and sometimes it also needs some fiddling with the USB connector due to some other bugs. https://github.com/m-labs/artiq/issues/854#issuecomment-353719299
<GitHub195> [artiq] sbourdeauducq commented on issue #854: Can you get two media converters to work with the MII firmware, send us one (with the corresponding tested SATA/SFP cable), and keep the other for testing ARTIQ on your side? https://github.com/m-labs/artiq/issues/854#issuecomment-353719651
<GitHub67> [artiq] gkasprow commented on issue #854: Probably your programmer keeps reset low.... https://github.com/m-labs/artiq/issues/854#issuecomment-353720902
<GitHub150> [smoltcp] kpp commented on issue #100: Why not use https://github.com/AdamNiederer/faster ? @AdamNiederer seems like a good challenge for you! https://github.com/m-labs/smoltcp/pull/100#issuecomment-353721096
<GitHub74> [smoltcp] whitequark commented on issue #100: Sweet! Can you please add some testcases?... https://github.com/m-labs/smoltcp/pull/100#issuecomment-353721781
<GitHub41> [artiq] gkasprow commented on issue #854: @sbourdeauducq would you prefer AMC-SFP-RJ45 version or SATA-RJ45?... https://github.com/m-labs/artiq/issues/854#issuecomment-353722025
<GitHub42> [artiq] gkasprow commented on issue #854: Or maybe you would like AMC box with 6 SATAs ? I have a few pieces and one proto which can ship to you. https://github.com/m-labs/artiq/issues/854#issuecomment-353722079
<GitHub146> [smoltcp] whitequark pushed 1 new commit to master: https://github.com/m-labs/smoltcp/commit/275eb90785a26ed1bd942f087c2d81647dc58f84
<GitHub146> smoltcp/master 275eb90 whitequark: Unswitch the IP checksum loop for 30% improvement in performance.
<travis-ci> m-labs/smoltcp#516 (master - 275eb90 : whitequark): The build passed.
<GitHub22> [artiq] sbourdeauducq commented on issue #854: Thanks.... https://github.com/m-labs/artiq/issues/854#issuecomment-353723520
<GitHub136> [artiq] gkasprow commented on issue #854: AMC box has RTM, but acces to the bottom side is indeed hard.... https://github.com/m-labs/artiq/issues/854#issuecomment-353723833
<GitHub155> [artiq] whitequark commented on issue #881: I think we have many more important things to do... https://github.com/m-labs/artiq/issues/881#issuecomment-353724943
<GitHub26> [smoltcp] whitequark commented on pull request #98 50c5b77: > Would the public mock IpAddress be an IPv6 variant if proto-ipv6 was enabled and IPv4 if not?... https://github.com/m-labs/smoltcp/pull/98#discussion_r158582087
<sb0> whitequark, can you fix satman, i'd like to give drtio a quick test?
<GitHub92> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/00ed51f6f4941320c28318573e7d68bf075894ac
<GitHub92> artiq/master 00ed51f Sebastien Bourdeauducq: satman: use new alloc_list (#880)
<bb-m-labs> build #981 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/981
<sb0> what happens if the gth transceiver clock is not applied during the first initialization attempt? is there some miracle that makes it well-behaved and waits for the clock to be there? does it self-destruct like the altera trash does?
<GitHub197> [artiq] sbourdeauducq closed issue #880: satman compilation broken https://github.com/m-labs/artiq/issues/880
<bb-m-labs> build #643 of artiq-win64-test is complete: Warnings [warnings python_coverage] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/643 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #1855 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1855
<GitHub112> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/3b11e1e27246d7d64de223b819decef9e6be1267
<GitHub112> migen/master 3b11e1e Sebastien Bourdeauducq: sayma_amc: add SFP TX disable pins
<GitHub38> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/70b7f28ad35f58ccf83bc00542862c54f185e465
<GitHub38> artiq/master 70b7f28 Sebastien Bourdeauducq: drtio: drive SFP TX disable pins
<bb-m-labs> build #220 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/220
<bb-m-labs> build #982 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/982
<whitequark> sb0: okay
<sb0> whitequark, I fixed it
<whitequark> oh you already di
<sb0> and of course, you can guess the result of the drtio test on sayma, it's in line with about everything that has been going on with that board
<sb0> sigh
<whitequark> sayma seems like a disaster...
<bb-m-labs> build #644 of artiq-win64-test is complete: Warnings [warnings python_coverage] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/644 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<GitHub161> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/2e12e91315ed5161ef45cd472380cb084a45834f
<GitHub161> migen/master 2e12e91 Sebastien Bourdeauducq: sayma_amc: fix SFP TX disable I/O voltage
<bb-m-labs> build #1856 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1856
<bb-m-labs> build #221 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/221
<_florent_> sb0: what are you testing, between what and what?
<sb0> _florent_, sayma to sayma, connected via sfp, and the code in artiq master
<_florent_> sb0: with one sfp or 2? what's the behavious?
<_florent_> behaviour
<sb0> one SFP
<sb0> receiver does not detect link (board::csr::DRTIO[0].link_status_read stays at 0)
<sb0> I don't know if it transmits or not, nor if the CPLL is locking. note that with the ARTIQ DRTIO design, the transceiver clocks are not present when the FPGA is configured, since this needs si5324 setup
<sb0> for both master and satellite
<sb0> the GTX seemed fine with that, but maybe the GTH is not
<_florent_> sb0: from the test i did, i think it's also fine on GTH
<_florent_> sb0: when testing jesd, i remember having no clock on GTH refclk at startup, then was configuring the rtm clocking and GTH were operationals
<GitHub7> [artiq] sbourdeauducq commented on issue #860: @jbqubit What happens on your boards? https://github.com/m-labs/artiq/issues/860#issuecomment-353734884
<GitHub157> [artiq] sbourdeauducq commented on issue #860: @jbqubit What happens on your boards?... https://github.com/m-labs/artiq/issues/860#issuecomment-353734884
<GitHub190> [smoltcp] hjr3 commented on issue #81: I am working on this and should have a PR up in a few days. https://github.com/m-labs/smoltcp/issues/81#issuecomment-353736822
<GitHub162> [smoltcp] whitequark commented on issue #81: Cool! Thank you. https://github.com/m-labs/smoltcp/issues/81#issuecomment-353737294
<cr1901_modern> sb0: Are misoc wishbone peripherals still limited to 256MB of contiguous allocation? I seem to recall that this limitation was removed, but can't remember.
<GitHub114> [artiq] a-shafir commented on issue #860: There is a visible on a scope trailing (extra) short pulse on SCK. With a simple shift register as in CPLD it makes all received bits shifted etc. Probably not all SPI IC are sensitive to it because some of them have "de-glitching" filter. CPLD certainly need a very clean clock. HMC830 possible too. ... https://github.com/m-labs/artiq/issues/860#issuecomment-353738408
f4bug has joined #m-labs
<GitHub45> [smoltcp] liranringel commented on issue #82: @LuoZijun any progress?... https://github.com/m-labs/smoltcp/issues/82#issuecomment-353744194
<GitHub81> [smoltcp] AdamNiederer commented on issue #100: I don't think there's anything *preventing* it working with `no_std` - I'll see if I can hack something together. https://github.com/m-labs/smoltcp/pull/100#issuecomment-353744415
<GitHub88> [smoltcp] BurntPizza commented on issue #100: I've revised to hopefully improve further upon 275eb90785a26ed1bd942f087c2d81647dc58f84, which was apparently the one simple formulation which works that I didn't try last night. :\... https://github.com/m-labs/smoltcp/pull/100#issuecomment-353748942
<GitHub127> [smoltcp] whitequark commented on issue #100: > What kind of testcases are you looking for?... https://github.com/m-labs/smoltcp/pull/100#issuecomment-353750224
<GitHub129> [smoltcp] kpp commented on pull request #100 86235f8: I would like to see comments like:... https://github.com/m-labs/smoltcp/pull/100#discussion_r158589998
<GitHub15> [smoltcp] whitequark commented on pull request #100 582c5e5: Better? https://github.com/m-labs/smoltcp/pull/100#discussion_r158590041
<GitHub8> [smoltcp] whitequark created pr/100 (+5 new commits): https://github.com/m-labs/smoltcp/compare/ea5f9719d7e7^...582c5e574491
<GitHub8> smoltcp/pr/100 247852f BurntPizza: Merge branch 'master' of https://github.com/m-labs/smoltcp
<GitHub8> smoltcp/pr/100 ea5f971 BurntPizza: Add faster TCP checksum implementation for x86_64
<GitHub8> smoltcp/pr/100 3d5d27f BurntPizza: Merge/use Veedrac's basis for TCP checksum
<GitHub80> [smoltcp] whitequark deleted pr/100 at 582c5e5: https://github.com/m-labs/smoltcp/commit/582c5e5
<GitHub25> [smoltcp] whitequark created pr/100 (+5 new commits): https://github.com/m-labs/smoltcp/compare/ea5f9719d7e7^...582c5e574491
<GitHub25> smoltcp/pr/100 247852f BurntPizza: Merge branch 'master' of https://github.com/m-labs/smoltcp
<GitHub25> smoltcp/pr/100 3d5d27f BurntPizza: Merge/use Veedrac's basis for TCP checksum
<GitHub25> smoltcp/pr/100 ea5f971 BurntPizza: Add faster TCP checksum implementation for x86_64
_whitelogger has joined #m-labs
<travis-ci> m-labs/smoltcp#521 (pr/100 - 582c5e5 : whitequark): The build passed.
<travis-ci> Change view : https://github.com/m-labs/smoltcp/compare/ea5f9719d7e7^...582c5e574491
<travis-ci> m-labs/smoltcp#520 (pr/100 - 582c5e5 : whitequark): The build passed.
<travis-ci> Change view : https://github.com/m-labs/smoltcp/compare/ea5f9719d7e7^...582c5e574491
<GitHub47> [smoltcp] whitequark closed pull request #100: Add faster TCP checksum implementation for x86_64 (master...master) https://github.com/m-labs/smoltcp/pull/100
<GitHub157> [smoltcp] whitequark pushed 1 new commit to master: https://github.com/m-labs/smoltcp/commit/56ddb0c206bff68dbbd1e7e97bfadee7988f79b1
<GitHub157> smoltcp/master 56ddb0c Josh Gangloff: Make IP checksum loop use larger chunks to ease autovectorization.
<GitHub23> [smoltcp] whitequark deleted pr/100 at 582c5e5: https://github.com/m-labs/smoltcp/commit/582c5e5
<travis-ci> m-labs/smoltcp#522 (master - 56ddb0c : Josh Gangloff): The build passed.