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
<GitHub95>
[artiq] sbourdeauducq commented on issue #40: > I am assuming from this that the offset for a given channel is added to the timestamp sent from the kernel, in other words if you send a timestamp of 0 and the offset is 25, then it goes into the FIFO to be emitted at timestamp 25. Is this correct?... https://github.com/m-labs/artiq/issues/40#issuecomment-330411662
<_florent_>
sb0: I implemented the hardware fix for jesd, but that's not better. I added more controls for greg.
<rjo>
_florent_: both fixes?
<_florent_>
sb0: I'll probably test ethernet soon (I have my media converter)
<_florent_>
rjo: just the regulator fix
<rjo>
_florent_: what's with the other?
<_florent_>
rjo: I should order 201 / 100 ohm resistors for the clock fix
<_florent_>
or take one from another board...
<_florent_>
rjo: but if some lanes are working (and if with 4 lanes working fine), I don't think that's related to the clock input of the DAC...
<_florent_>
rjo: I tried all possible settings on the HMC7043 outputs in case
<_florent_>
rjo: no changes.
<rjo>
_florent_: is your SERDES PLL now locking reliably?
<_florent_>
on DAC1 yes (was always the case)
<_florent_>
on DAC0 no (and maybe adding termination resistor can help there)
<rjo>
_florent_: my feeling is that with a clock as bad as greg described it there is little chance of getting reliable results (positive or negative).
<rjo>
_florent_: but i'll naturally leave it to you. it's just that we are running out of time.
<sb0>
_florent_, is the xilinx reference design any useful?
<_florent_>
sb0: I'd like greg to look at the square wave signals on the lanes first, since the prbs errors are at very low level and: we are using the same defaults parameters as the Xilinx core and everythinq is working fine on KCU105
<_florent_>
sb0: also we see that some lanes are working, others not
<sb0>
well, better do things in parallel, as rjo pointed out, time is short
<_florent_>
ok I'm going to test prbs with the xilinx core, now after that if I have the same results I have the our core, not sure what I can do more
<sb0>
then we are sure it's a hardware problem and not the xilinx transceivers being awful as usual
<sb0>
thanks!
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined #m-labs
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo>
_florent_: great. thanks a lot for narrowing that down
rohitksingh1 has quit [Quit: Leaving.]
<GitHub176>
[artiq] dhslichter commented on issue #40: @sbourdeauducq adding on times to output timestamps is not particularly useful IMHO. As I pointed out above, the useful case is to put events on in the past. I understand that this is problematic from many standpoints with RTIO. The solution is to have everything default to a certain amount of positive offset, and then you reduce the positive offset for the higher-latency channels. This ends up just
<GitHub83>
[artiq] dhslichter commented on issue #40: @sbourdeauducq adding on times to output timestamps is not particularly useful IMHO. As I pointed out above, the useful case is to put events on in the past. I understand that this is problematic from many standpoints with RTIO. The solution is to have everything default to a certain amount of positive offset, and then you reduce the positive offset for the higher-latency channels. This ends up just in