sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
Gurty has quit [Ping timeout: 264 seconds]
Gurty has joined #m-labs
<GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/3e6f39a0ccca0b4c750e7515820d79c8dd17f4d4
<GitHub-m-labs> migen/master 3e6f39a msloniewski: build/platforms: add upduino_v1 board initial support
jason1_ has quit [Ping timeout: 256 seconds]
<bb-m-labs> build #367 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/367
_whitelogger has joined #m-labs
<sb0> rjo: the kc705 can do 100M, only the kasli and sayma require 1G
<bb-m-labs> build #1016 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/1016
<bb-m-labs> build #2879 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2879
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #m-labs
cedric has quit [Ping timeout: 272 seconds]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
kuldeep has quit [Quit: Its never too late!]
stekern has joined #m-labs
kuldeep has joined #m-labs
rohitksingh has joined #m-labs
<sb0> kcu105 still doesn't work after reprogramming the maxim pmbus stuff...
<sb0> it seems 3.3V is short-circuited to ground, i can hear the coil of the regulator attempting to restart, and the maxim software reports an overcurrent on that rail
proteusguy has quit [Remote host closed the connection]
rohitksingh_work has joined #m-labs
proteusguy has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh_ has joined #m-labs
rohitksingh_ has quit [Ping timeout: 240 seconds]
<sb0> _florent_: do you have any idea of what can cause the FPGA-DAC latency to vary between reboots by about half a SYSREF period, when SYSREF meets setup/hold at both?
<sb0> (period of the *current* SYSREF. decreasing the SYSREF frequency has no impact on the timing variation)
<sb0> to clarify: I'm getting two possible latency values, and they differ by half a SYSREF period
<_florent_> sb0: if in understand correctly, if you change the SYSREF frequency, the variation is always a half SYSREF period?
<sb0> _florent_: correct
<sb0> well I only tried 1/2 the original frequency
<_florent_> i don't know for now, but i'll think about it
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/ec8560911fb19de164710dea3abd01217741a103
<GitHub-m-labs> artiq/master ec85609 Sebastien Bourdeauducq: siphaser: bugfixes...
<bb-m-labs> build #2361 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2361
<bb-m-labs> build #2362 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2362
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<keesj> I modified the code to boot from bram and .. at least I now am getting something.. I really did not expect it to work at this point
proteusguy has quit [Ping timeout: 250 seconds]
proteusguy has joined #m-labs
<rohitksingh> keesj: modifying the uart terminal's settings to automatically add carriage-return with each new line should fix the weirdly indented output
<keesj> picocom -b 115200 /dev/ttyUSB1 --imap lfcrlf
<keesj> does the trick for me
<keesj> after flashing I need to really take the power off (the reset button does not work) but once booted I can press the reset button. the boot now looks like https://pastebin.ubuntu.com/p/D4cRmdn7YP/
<keesj> I imagine that If I want to save some memory blocks I need to move the "bios" to execute in place in spi flash?
<bb-m-labs> build #1017 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/1017
<bb-m-labs> build #2880 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2880
<keesj> I am doing this work in preparation of doing experiments with https://github.com/enjoy-digital/litedram on ddr3
<keesj> if possible I would like to keep the ddr3 memory free for experiments
<GitHub8> [smoltcp] pothos commented on issue #269: I think most times I looked at the smoltcp log message about the segment not being in the receive window, it was because it was a retransmitted packet which was not needed anymore and thus not in the window. Looking at my wireshark and the here posted wireshark labels I have doubts about the quality of the label names. E.g., the packet before the `ACKed unseen segment` label con
<GitHub-m-labs> [artiq] hartytp opened issue #1256: SUServo negative numbers https://github.com/m-labs/artiq/issues/1256
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: Also, unless I'm missing something, there seems to be an issue with `data[6]` (the lower bits of the ftw) always being 0. https://github.com/m-labs/artiq/issues/1256#issuecomment-458975551
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: Note to self: the current delay in `get_profile_mu` isn't large enough and pretty deterministically gives underflows. Increasing to `6us` fixes. https://github.com/m-labs/artiq/issues/1256#issuecomment-458978837
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: Okay, all these issues are related to not correctly masking off bits in the data written.... https://github.com/m-labs/artiq/issues/1256#issuecomment-459019771
<GitHub-m-labs> [artiq] hartytp commented on issue #1256: @jordens am I missing something, or does this issue appear multiple times in the SUServo code. e.g. https://github.com/m-labs/artiq/blob/450a035f9ef0dd9637325e04c6e708e97f7bfdb4/artiq/coredevice/suservo.py#L286 should be `ftw & 0xffff` right? Otherwise it overflows the data part of the register. https://github.com/m-labs/artiq/issues/1256#issuecomment-459023308
<GitHub27> [smoltcp] pothos commented on issue #269: Actually it's a known bug, see here: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10745... https://github.com/m-labs/smoltcp/issues/269#issuecomment-459034480
<rohitksingh> keesj: yup, using XIP spi flash to save block ram is an option. booting speed might be slower though
<GitHub-m-labs> [artiq] jbqubit opened issue #1257: reduce latency of check_pause() https://github.com/m-labs/artiq/issues/1257
rohitksingh has quit [Ping timeout: 250 seconds]
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
Gurty has joined #m-labs
massi_ has joined #m-labs
early has quit [Ping timeout: 244 seconds]
early has joined #m-labs
massi_ has quit [Remote host closed the connection]
ti_ has joined #m-labs
ti_ has quit [Quit: Page closed]