Iota22 has quit [Remote host closed the connection]
vespaper has joined #m-labs
vespaper has quit [Remote host closed the connection]
em has joined #m-labs
em has quit [Killed (Sigyn (Spam is off topic on freenode.))]
mort18 has joined #m-labs
mort18 has quit [Remote host closed the connection]
<sb0>
those hmc7043 problems are even more frustrating as we don't need a hmc7043 at all
<sb0>
connect the 830 output to the DACs with a non-programmable fanout buffer, connect SYSREF to the FPGA, and voila
<sb0>
much simpler, less bugs (though we're still stuck with the ultratrash odelay, 7series would have been better), and not worse from a sync standpoint
<sb0>
connecting the 7043 rfsyncin to the FPGA isn't good, as the 7043 (of course) doesn't have a way to check if s/h is met on this signal
<sb0>
a hmc7044 is perhaps better from a sync standpoint as it potentially doesn't have the huge PVT variations and not-so-good jitter that ultrascale would have on SYSREF, but P can be calibrated out and I'm not sure if VT are a real issue. but it most likely has hmc-bugs.
Steinsplitter20 has joined #m-labs
Steinsplitter20 has quit [Remote host closed the connection]
VM_ has joined #m-labs
VM_ has quit [K-Lined]
was has joined #m-labs
was has quit [Ping timeout: 272 seconds]
Jacob843 has joined #m-labs
Jacob843 has quit [Remote host closed the connection]
rogue2 has joined #m-labs
rogue2 has quit [Remote host closed the connection]
SleePy0 has joined #m-labs
SleePy0 has quit [Ping timeout: 256 seconds]
_whitelogger has joined #m-labs
alphor9 has joined #m-labs
alphor9 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
sb0 has quit [Quit: Leaving]
Numline127 has joined #m-labs
Numline127 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
YuGiOhJCJ25 has joined #m-labs
YuGiOhJCJ25 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
<d_n|a>
bb-m-labs: force build --branch=pull/1136/merge artiq
<bb-m-labs>
build forced [ETA 54m13s]
<bb-m-labs>
I'll give a shout when the build finishes
<d_n|a>
rjo: Regarding #1137, I'm convinced that the current behaviour isn't self-consistent under any reasonable definition. If the model was one where the FPGA acts like one big synchronous system clocked off the RTIO clock and the reference plane is the edge of the FPGA (up the exact < 8 ns S/H timings), that'd fine by me, and in fact what I expected. Unfortunately, that's not what happens.
pokk3 has joined #m-labs
pokk3 has quit [Remote host closed the connection]
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1137: Does replacing ``rtio_input_timestamp(self.i_previous_timestamp, self.channel)`` in ``count()`` with ``rtio_input_timestamp(self.i_previous_timestamp+500, self.channel)`` make the problems disappear? https://github.com/m-labs/artiq/issues/1137#issuecomment-414123382
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1137: As for doing latency compensation everywhere, it conflicts with performance. The SAWG has a lot more latency than TTLs, so the TTLs would become slower if compensated.... https://github.com/m-labs/artiq/issues/1137#issuecomment-414123527
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1137: As for doing latency compensation everywhere, it conflicts with performance. The SAWG has a lot more latency than TTLs, so the TTLs would become slower if compensated.... https://github.com/m-labs/artiq/issues/1137#issuecomment-414123527
<GitHub-m-labs>
[artiq] sbourdeauducq commented on pull request #1136 7435cac: There may be leftover events because of the very bug you are testing against (due to the gateware latency in the timestamp counter to gate path, the timeout - referenced to the timestamp counter - is too small and the kernel thinks the gateware has closed the gate when it has not). Use ``core.reset()`` instead. https://github.com/m-labs/arti
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1137: I suspect that the bug is: due to the gateware latency in the timestamp counter to gate path, the timeout - referenced to the timestamp counter - is too small and the kernel thinks the gateware has closed the gate when it has not.... https://github.com/m-labs/artiq/issues/1137#issuecomment-414125085
jcline13 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
<GitHub-m-labs>
[artiq] klickverbot commented on issue #1137: Potentially yes. I'm not sure how that would selectively cause part of the arrival time histogram to disappear, but since that also goes away with the extra delay, the issues are probably related.... https://github.com/m-labs/artiq/issues/1137#issuecomment-414127242
<GitHub63>
[smoltcp] whitequark commented on issue #253: > I plan to seeing how much sACK improves it first because I presume 4 was picked for a reason, e.g. memory consumption. If that is not the case, then increasing the number of holes would indeed solve the issue as far as I can tell.... https://github.com/m-labs/smoltcp/pull/253#issuecomment-414162809
Maven_ has joined #m-labs
Maven_ has quit [Ping timeout: 265 seconds]
acuzio18 has joined #m-labs
acuzio18 has quit [Remote host closed the connection]