00:01 <mtrbot-ml> [mattermost] <astro> *sigh* @sb10q with a few brief tests I have managed to get the 2nd zc706 into a state in which it is no longer recognized by vivado hw_manager but still by openocd, though it behaves erratically. is it possible to power the board through the power-cycler?

06:55 <mtrbot-ml> [mattermost] <sb10q> @astro I've put both ZC706 on the same power cycler channel now

06:56 <mtrbot-ml> [mattermost] <sb10q> we should probably make a sinara power cycler/network relay, the current solution is a stm32 devkit with SSRs

07:27 <mtrbot-ml> [mattermost] <hartytp> @astro is the expectation here that after some basic optimization we should be able to get towards gigabit speeds?

07:29 <mtrbot-ml> [mattermost] <sb10q> @hartytp my expectation is that after painful reverse engineering of whatever the linux driver does on that shitty hardware, we might be able to get speeds comparable what I have seen on the red pitaya

07:29 <mtrbot-ml> [mattermost] <sb10q> @hartytp my expectation is that after painful reverse engineering of whatever the linux driver does on that shitty hardware, we might be able to get speeds comparable to what I have seen on the red pitaya

08:21 <mtrbot-ml> [mattermost] <hartytp> okay, that's quite a low expectation.

08:25 <mtrbot-ml> [mattermost] <sb10q> why should it be faster? is there a fundamental difference between rp and zc706?

08:26 <mtrbot-ml> [mattermost] <hartytp> Is there a fundamental reason we can't saturate the gigabit link?

08:26 <mtrbot-ml> [mattermost] <sb10q> yes. zynq is garbage hardware and anything that has not been done before does not work

08:27 <mtrbot-ml> [mattermost] <sb10q> and something that has been done before barely works

08:29 <mtrbot-ml> [mattermost] <hartytp> that's what I would call low expectations. IIRC someone (@cjbe ?) mentioned having used a Zed board with LWIP and getting gigabit ethernet speeds some time ago.

08:29 <mtrbot-ml> [mattermost] <hartytp> anyway, I don't have well-calibrated expectations here so just curious

08:31 <mtrbot-ml> [mattermost] <sb10q> even the JTAG programmer doesn't work reliably on this thing

08:31 <mtrbot-ml> [mattermost] <sb10q> the vivado hardware server crashes every 10 minutes when connected to the zc706, in addition to the bug astro mentioned

08:32 <mtrbot-ml> [mattermost] <sb10q> openocd (with an external jtag probe) seems somewhat more reliable

11:53 <airwoodix> rjo: sb10q: what's the general policy for argument processors in view of artiq#1434? There's indeed no check in NumberValue.__init__ so it fails late. Same for StringValue (probably safe), BoolValue (probably does unexpected things), and PYONValue (fails on process). EnumerationValue as an assertion, which is also not very nice for the GUI.

11:53 <airwoodix> Checking and throwing ValueError sounds like the most reasonable thing to do to me.

11:55 <rjo> airwoodix: I agree. They should cast early.

12:02 <airwoodix> rjo: ok, I'll prepare a PR if that's fine for you

12:10 <rjo> airwoodix: appreciated!

12:47 <mtrbot-ml> [mattermost] <rolf> rolf joined the team.

13:04 <mtrbot-ml> [mattermost] <astro> @sb10q great, thank you

13:05 <mtrbot-ml> [mattermost] <astro> I've read that the linux driver can get near gigabit speed

15:07 <mtrbot-ml> [mattermost] <sb10q> @rjo is synchronization supposed to work on urukul 1.4? I'm getting "no IO_UPDATE-SYNC_CLK alignment edge found"

15:07 <mtrbot-ml> [mattermost] <sb10q> cpld v1.4.0

15:07 <rjo> works fine last i checked.

15:08 <mtrbot-ml> [mattermost] <sb10q> how did you check?

15:21 <mtrbot-ml> [mattermost] <sb10q> ok it works with some Urukul PLL settings but of course not with those that we need for sayma

15:22 <mtrbot-ml> [mattermost] <sb10q> @rjo are we going to move to 125MHz RTIO clock on sayma?

15:23 <mtrbot-ml> [mattermost] <sb10q> @rjo https://git.m-labs.hk/M-Labs/sinara-systems/src/branch/master/saymamaster.json those are the settings that cause "no IO_UPDATE-SYNC_CLK alignment edge found" during calibration, do you know what is going on?

16:25 <rjo> what dds clock do you expect with that?

16:28 <rjo> if the 600 MHz use case can be abandoned, then sure we can switch to 125 MHz.

17:01 <mtrbot-ml> [mattermost] <hartytp> FWIW we're only interested in 125MHz