<GitHub103>
[artiq] jonaskeller commented on issue #902: Just out of curiosity: Does that still mean that it takes a corrupted packet to trigger it? And if so, have you been able to reproduce it with the latest capture / found a culprit?... https://github.com/m-labs/artiq/issues/902#issuecomment-366406186
jkeller has quit [Quit: Page closed]
<GitHub15>
[artiq] whitequark commented on issue #902: > Just out of curiosity: Does that still mean that it takes a corrupted packet to trigger it? And if so, have you been able to reproduce it with the latest capture / found a culprit?... https://github.com/m-labs/artiq/issues/902#issuecomment-366407452
<GitHub66>
[artiq] jonaskeller commented on issue #902: Yes, it's on windows (not my choice...). Looks to me like the win64 and linux64 packages for openocd are the same version in the conda repository, though.... https://github.com/m-labs/artiq/issues/902#issuecomment-366412665
<GitHub23>
artiq/master ccc279b hartytp: rewrite HMC7043 init code without using ADI GUI outputs, working analog/digital delay
<GitHub73>
[artiq] sbourdeauducq commented on issue #922: Also I think the delay adjustment code should be broken out into separate functions, so we can easily implement automatic scans (which will be used to determine the fixed values to put into the code). https://github.com/m-labs/artiq/pull/922#issuecomment-366414778
<sb0>
rjo, remind me, what is needed to do for dac sync is align sysref with the rtio clock (and the rtio counter, i.e. sysref edges should always come at the multiples of some value in the rtio counter)?
<sb0>
is it permitted to use the HMC7043 analog delay on the DAC clock or does that introduce excessive noise?
<sb0>
ah, no
<sb0>
<sb0>
Exposing this channe
<sb0>
on noise sensitive DCLK channels.
<sb0>
l causes phase noise degradation of up to 12 dB; therefore, do not use
<GitHub74>
[artiq] sbourdeauducq commented on issue #908: We do seem to have problem with IOSERDES clocking though, which produces the warning and the error in the timing report, and seems to be a plausible explanation for those symptoms. I don't understand why, though: CLK is sys4x and CLKDIV is sys, which are generated by the same PLL and without phase offset. Or am I missing something? https://github.com/m-labs/artiq/issu
<GitHub34>
[artiq] sbourdeauducq commented on issue #908: We do seem to have a problem with IOSERDES clocking though, which produces the warning and the error in the timing report, and seems to be a plausible explanation for those symptoms. I don't understand why, though: CLK is sys4x and CLKDIV is sys, which are generated by the same PLL and without phase offset. Or am I missing something? https://github.com/m-labs/artiq/is
<GitHub63>
[artiq] sbourdeauducq commented on issue #908: We do seem to have a problem with IOSERDES clocking though, which produces the warning and the error in the timing report, and is a plausible explanation for those symptoms. I don't understand why, though: CLK is sys4x and CLKDIV is sys, which are generated by the same PLL and without phase offset. Or am I missing something? https://github.com/m-labs/artiq/issues/908#
<GitHub108>
[artiq] sbourdeauducq commented on issue #908: I don't see how it can work without write leveling (unless only one or a few chips are used), there is definitely skew that needs to be compensated for.... https://github.com/m-labs/artiq/issues/908#issuecomment-366426750
rohitksingh has quit [Quit: Leaving.]
<sb0>
_florent_, what is cd_sys4x_dqs?
<_florent_>
sb0: it was use for dqs but i think i removed it no?
<GitHub86>
[artiq] enjoy-digital commented on issue #908: @sbourdeauducq: I think Vivado generates this warning since we are applying a constraint on clocks at the output of the PLL. Vivado is then no longer propagating constraints from the input of the PLL to the outputs (ie that sys4x and sys are generated from the same PLL) and generates this warning. https://github.com/m-labs/artiq/issues/908#issuecomment-366427466
<GitHub76>
[artiq] sbourdeauducq commented on issue #908: For what it's worth, SDRAM is now working on the HKG board with SAWG, using the current ARTIQ master (41adbef9) which includes the RTM loading core and the clock constraint fix in MiSoC. It used not to work with recent gateware when the SAWG and the loading core were both present. But since this is so random, we cannot conclude yet that the clock constraint fix solved it.
<GitHub87>
[artiq] sbourdeauducq commented on issue #908: And, on the other hand, serwb is now broken. Again this doesn't make any sense, since Vivado is deriving itself the constraints I removed:... https://github.com/m-labs/artiq/issues/908#issuecomment-366433877
<sb0>
it seems that people who designed the ultratrash ioserdes took some inspiration from the transceiver team
hartytp has joined #m-labs
<hartytp>
sb0: letting off steam aside, what's your take on the Ultrascale FPGAs?
<hartytp>
are you saying they have silicon bugs that the Kintex 7 dont
<sb0>
compilation is extremely slow, for one
<hartytp>
or just that the vivado support is still new and buggy (which one might hope could imrpove over time, unlike hardware bugs)
<hartytp>
right, but is that just the software being newer and not as good
<hartytp>
if it's *actually* a HW issue, is it worth considering moving to a regular K7 for v2.0?
<sb0>
that would require changing a *lot* of things on the board...
<hartytp>
okay, I didn't realise that
<hartytp>
but, in any case, I'm still curious, do you think this is just vivado being crap for the US FPGAs atm
<hartytp>
(I can't actually remember why we went for an US on Sayma in the first place, I didn't get involved in that conversation)
<sb0>
as for the bugs. there are those ioserdes (sdram/serwb) issues, the transceivers are junk but this is unfortunately the case for basically every FPGA on the market, broken behavior with simple designs such as forwarding a clock through the FPGA (the output never toggled)
<hartytp>
hmmm....so you think those are HW issues in these FPGAs?
<sb0>
except for the transceivers, vivado bugs can explain the issues. also, the impact of every problem (even simple ones, like being unable to bring up a MMCME3) is magnified by the super-slow compilation times.
<hartytp>
k
<hartytp>
well, let's hope that improves over time
<sb0>
Greg observed similar "broken behavior" on artix7 (output pins driving constant values having the wrong level), so some of this isn't actually ultrascale-specific. it's just much worse when it takes 2 hours to recompile.
<hartytp>
okay, so the main ultrascale-specific complain is just the compilation time (which, I agree, makes all debugging/development work harder).
<sb0>
yes. combined with the crappy but somewhat usual FPGA bugs, it becomes really difficult to get anything done.