<GitHub57>
[artiq] whitequark commented on issue #898: @jbqubit RTM FPGA bitstream is not loaded from flash anyway right now, you have to invoke openocd manually. This will be fixed when the bitstream load is implemented. https://github.com/m-labs/artiq/issues/898#issuecomment-359137251
<GitHub140>
artiq/master 8fe463d Florent Kermarrec: sayma_rtm: add UART loopback to easily know if rtm fpga is alive
<GitHub140>
artiq/master 74ce731 Florent Kermarrec: sayma: reduce serwb linerate to 625Mbps (make it work on saymas with 1.8v issue, related?)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0>
_florent_, what sayma with 1.8v issue, sayma1?
sb0 has quit [Quit: Leaving]
<_florent_>
sb0: yes
<GitHub73>
[artiq] enjoy-digital commented on issue #856: By reducing serwb linerate from 1.25Gbps to 625Mbps, it seems to be reliable on at least a board that has the 1.8v issue. (it's difficult to say if it's related or not). Let's use 625Mbps for now.... https://github.com/m-labs/artiq/issues/856#issuecomment-359146463
<_florent_>
sb0: also, on sayma1, when reloading amc with artiq_flash (...) start, rtm fpga is no longer alive
<sb0>
whitequark, for fast JTAG speeds, the FPGA IOs will limit you...
<sb0>
(re. your idea of replacing FTDI with FPGA)
<sb0>
USB uses this strange serial data format instead of something like 8b10b, which requires very fast CDR locking speeds that need to be done digitally with 4x oversampling
<sb0>
so for 480Mbps USB 2.0 you need 1920Mbps IO. you could do it using the transceivers and some analog hacks for bidirectional IO, but it will be messy. or use a ULPI chip.
<whitequark>
nah, none of the above
<whitequark>
CY7C68013A converting 480Mbps USB 2.0 into a 8-bit bus, some iCE40 FPGA driving JTAG from that
<whitequark>
my calculations show that this can saturate USB
<whitequark>
and it's extremely cheap too
<sb0>
how do you program the 8051? sdcc?
<whitequark>
anything. at the level of complexity it needs to be even assembly works
<whitequark>
it has to set up two pipes to forward to UARTs and then one more to switch its FIFO between read and write
<whitequark>
the entire system firmware can live in its EEPROM, too
<whitequark>
what's neat is how once the 8051 is programmed, you never touch that crap again. you can wire any sort of custom logic in the FPGA.
<whitequark>
and if we use an iCE40LP1K, then the LED drive pins can be used to get higher slew rates on JTAG :)
<whitequark>
the MPSSE is actually trivial, I think I can prototype it in a few hours
<GitHub25>
artiq/master 94592c7 whitequark: artiq_flash: unify flash handling in XC7 and Sayma programmers.
<GitHub25>
artiq/master 1ffabac whitequark: artiq_flash: use atexit for tempfile cleanup.
<GitHub25>
artiq/master ab9eb56 whitequark: setup.py: migen now works on Python 3.6, relax version check.
<GitHub113>
[artiq] whitequark commented on issue #898: @jbqubit I've fixed artiq_flash for RTM FPGA, but only for --srcbuild for now, since I'm working on that code. You can use this as a stopgap.... https://github.com/m-labs/artiq/issues/898#issuecomment-359152386
<GitHub10>
[artiq] sbourdeauducq commented on issue #854: Now there is *some* dependence of the packet loss rate (from ping) on the phase of the TX clock, but packet losses stay over 70%. And some packets still get through (80% packet loss) with the TX clock grounded by the FPGA. I don't understand... https://github.com/m-labs/artiq/issues/854#issuecomment-359163121
<GitHub189>
[artiq] sbourdeauducq commented on issue #854: Now there is *some* dependence of the packet loss rate (from ping) on the phase of the TX clock, but packet losses (ICMP ping) stay over 70%. And some packets still get through (80% packet loss) with the TX clock grounded by the FPGA. I don't understand... https://github.com/m-labs/artiq/issues/854#issuecomment-359163121
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
<GitHub184>
[artiq] gkasprow commented on issue #854: Tx has its own PLL that produces valid clock from 25MHz reference. But without TXCLK you should be not able to write anything to the PHY data register. I have a setup at the university where we can run artiq. In this way I can have a look what the clock signal really looks like. https://github.com/m-labs/artiq/issues/854#issuecomment-359170066
<GitHub16>
[artiq] gkasprow commented on issue #854: Another issue could be with lock stability. In PHY devices the reference clock and TX clock frequency cannot differ more than 100ppm. In case of mis-configured PLL in the FPGA this would cause similar effect. Can you drive your TX engine with RX clock just to check if this helps? https://github.com/m-labs/artiq/issues/854#issuecomment-359170242
Gurty has joined #m-labs
rohitksingh-demo has quit [Quit: Leaving.]
rohitksingh-demo has joined #m-labs
<GitHub109>
[artiq] sbourdeauducq commented on issue #854: That clock tolerance is due to the elastic buffer, and depends on the packet size and IPG. Here I am only sending short ICMP replies with 64 bytes of payload, so the tolerance is higher than this 100ppm which is designed for 9000-byte jumbo frames. Also, this would not explain why I'm able to send packets at all when I'm grounding the TX clock. https://github.com/m-
<GitHub64>
[artiq] sbourdeauducq commented on issue #854: That clock tolerance is due to the elastic buffer, and depends on the elastic buffer size, packet size and IPG. Here I am only sending short ICMP replies with 64 bytes of payload, so the tolerance is higher than this 100ppm which is designed for 9000-byte jumbo frames. Also, this would not explain why I'm able to send packets at all when I'm grounding the TX clock. ht
<GitHub7>
[artiq] sbourdeauducq commented on issue #854: My best guess is that with your new MMC firmware, the PHY is not driving the clock pin anymore, but it is not taking it into account either. This doesn't explain well why there is an impact on the packet loss rate, maybe crosstalk (injection pulling) into the oscillator that produces the actual clock, and that crosstalk was not present before as there was contention on the
<GitHub149>
[artiq] sbourdeauducq commented on issue #854: My best guess is that with your new MMC firmware, the PHY is not driving the clock pin anymore, but it is not taking it into account either. This doesn't explain well why the TX clock phase has an impact on the packet loss rate, maybe crosstalk (injection pulling) into the oscillator that produces the actual clock, and that crosstalk was not present before as there was