<GitHub-m-labs>
[artiq] dhslichter commented on issue #1167: The ZC706 eval board comes with a XC7Z045FFG900–2; these are much more expensive as individual chips than the '030 size mentioned above, but then there is the advantage (for hardware testing/prototyping, anyway) that one can just get going with an existing eval board. For us at NIST, those eval boards look like they would be drop-in replacements for the KC705 with
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1167: The ZC706 eval board comes with a XC7Z045FFG900–2; these are much more expensive as individual chips than the '030 size mentioned above, but then there is the advantage (for hardware testing/prototyping, anyway) that one can just get going with an existing eval board. For us at NIST, those eval boards look like they would be drop-in replacements for the KC705 with
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1167: The ZC706 eval board comes with a XC7Z045FFG900–2; these are much more expensive as individual chips than the '030 size mentioned above, but then there is the advantage (for hardware testing/prototyping, anyway) that one can just get going with an existing eval board. For us at NIST, those eval boards look like they would be drop-in replacements for the KC705 with
JekotialY has joined #m-labs
JekotialY has quit [Remote host closed the connection]
Pengis has joined #m-labs
<GitHub92>
[sinara] dtcallcock pushed 1 new commit to master: https://git.io/fxYi9
<GitHub92>
sinara/master 5dab26f David Allcock: Made depreciation of this repository clear in the readme.
<GitHub122>
[sinara] dtcallcock pushed 1 new commit to master: https://git.io/fxYi5
<GitHub122>
sinara/master ba969e2 David Allcock: added sinara-hw link
Pengis has quit [Remote host closed the connection]
Chipm0nk has joined #m-labs
Chipm0nk has quit [Killed (Sigyn (Spam is off topic on freenode.))]
ryanakcaFt has joined #m-labs
ryanakcaFt has quit [K-Lined]
talyzmc has joined #m-labs
talyzmc has quit [Remote host closed the connection]
rohitksingh_work has joined #m-labs
balrog has quit [*.net *.split]
Jakey has joined #m-labs
ishFq has joined #m-labs
balrog has joined #m-labs
ishFq has quit [K-Lined]
Jakey has quit [Remote host closed the connection]
Guest48937 has joined #m-labs
Guest48937 has quit [Remote host closed the connection]
m4ssi has joined #m-labs
starz0rlz has joined #m-labs
starz0rlz has quit [K-Lined]
<GitHub-m-labs>
[artiq] hartytp commented on issue #1167: > The complex timing issue that Vivado has on Artix-7 with mor1kx (note that lm32 and vexriscv do not seem affected) can strike any part of the gateware and not only a soft CPU.... https://github.com/m-labs/artiq/issues/1167#issuecomment-427294078
<GitHub-m-labs>
[artiq] whitequark commented on issue #1167: > Another point is that the difference between `set()` and `set_mu()` has disappeared, and I think this is not to be overlooked -- especially for newer users of ARTIQ, the large performance difference between these can be confusing and lead to RTIOUnderflow errors (and frustration, and then deciding not to bother with ARTIQ because it's "slow").... https://github
<GitHub-m-labs>
[artiq] hartytp commented on issue #1167: > The ZC706 eval board comes with a XC7Z045FFG900–2; these are much more expensive as individual chips than the '030 size mentioned above, but then there is the advantage (for hardware testing/prototyping, anyway) that one can just get going with an existing eval board. For us at NIST, those eval boards look like they would be drop-in replacements for the KC705
<GitHub-m-labs>
[artiq] hartytp commented on issue #1167: > In principle, this could be fixed by enabling (and validating) mor1kx's FPU, which @sbourdeauducq has been quite pessimistic about so far, but which could be easier than migrating to Zynq...... https://github.com/m-labs/artiq/issues/1167#issuecomment-427297691
<GitHub-m-labs>
[artiq] hartytp commented on issue #1167: > What would a typical payload look like, with a typical mix of RTIO operations and computations? I guess you are not using it to compute Mandelbrot sets.... https://github.com/m-labs/artiq/issues/1167#issuecomment-427298543
<GitHub-m-labs>
[artiq] hartytp commented on issue #1167: > In terms of the speedups, my sentiment is that really fast/high-throughput RTIO event outputs are best done via DMA anyway (although the extra factor of 2-3 here is certainly nice). ... https://github.com/m-labs/artiq/issues/1167#issuecomment-427300674
<hartytp>
I'm looking at the link delay setup in the AD9154 p42 - p44 of the datasheet
<hartytp>
I'm not an expert on these things, but it looks like those link delays need to have non-zero values
<hartytp>
and I can't see anywhere in the code where they're set to anything non-zero
<larsc>
the LMFC delay is just how much the internal LMFC is delayed compared to the SYSREF edge
<larsc>
0 shoul dbe OK
<larsc>
You can decrease the overall link delay though if you fine tune this setting
<larsc>
basically you want to tune things so that the LMFC edge occurs just before the first data can arrive
<hartytp>
okay, thanks
<hartytp>
so putting that to a non-zero value just removes a constant latency from the system, it doesn't affect synchronisation directly
foobar_ has joined #m-labs
<larsc>
as long as the lane arrival time is still inside the window, if you move delay so that the lanes don't arrive in the same lmfc cycle things break
<hartytp>
*quickly reads up a bit on jesd*
<hartytp>
I see. So if our lane-lane timing variation is small and the overall delay puts us in the middle of the LMFC then there won't be an issue
<hartytp>
but, if the delays work out such that we're close to a LMFC edge then we could get all kinds of issues
<hartytp>
right?
<hartytp>
well, no, not all kinds of issues. The only issue this would cause would be non-deterministic latency at the level of +-1LMFC period
<larsc>
I think the DAC might actually reset the link of that happens
<larsc>
so if you see your DAC going through cycles of SYNC asserted, SYNC deasserted than that's probably the issue
<larsc>
In practice I've only ever seen that when SYSREF was not aligned
<hartytp>
okay, thanks
foobar_ has left #m-labs [#m-labs]
highwaychile has joined #m-labs
<highwaychile>
hi! I'm trying to connect to Artiq using the dashboard, but after the message "connected to ..." the dashboard shows "lost connection to core device moninj" and "moninj aborted: unknown packet 0x3". I tried to artiq_flash, but this did not help. Do you have an idea what causes this? (I'm on 4.0.dev+1408.gd0ee2c29)
<whitequark>
highwaychile: do the gateware, firmware and software versions match?
<highwaychile>
whitequark: how can I find this out? I suspected that artifq_flash updates the hardware version to the software version?
rohitksingh_work has quit [Read error: Connection reset by peer]
<whitequark>
that should happen, but it's possible that you're running the wrong dashboard for some reason
<whitequark>
there shoud be a warning in the log
<highwaychile>
no, there's no such warning in the command line output (or is there a dedicated logfile I have to check?): https://pastebin.com/DJgiHfhu
<whitequark>
ok, that's odd then
<whitequark>
can you capture a packet trace?
<highwaychile>
is there an internal artiq tool for this? Or using wireshark?
idmtrJe has quit [Remote host closed the connection]
mulkWc has joined #m-labs
mulkWc has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
<GitHub-m-labs>
[artiq] dtcallcock commented on issue #1167: Did anyone consider using Intel FPGAs here? One concern I have is that the 7000 Zynqs are pretty long in the tooth and if Ultrascale Zynq is a no-go we don't have a path to getting really high performance silicon. Also, naively it looks like Intel are less interested in putting everything plus the kitchen sink into their SoCs, which seems to be one of the problems
springermacvk has joined #m-labs
<GitHub-m-labs>
[artiq] dtcallcock commented on issue #1167: Did anyone consider using Intel FPGAs here? One concern I have is that the 7000 Zynqs are pretty long in the tooth and if Ultrascale Zynq is a no-go we don't have a path to getting really high performance silicon. Also, naively it looks like Intel are less interested in putting everything plus the kitchen sink into their SoC FPGAs, which seems to be one of the prob
springermacvk has quit [Remote host closed the connection]
<highwaychile>
whitequark: should I create an issue for the problem?
<whitequark>
highwaychile: go ahead
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1167: > I assume this is contention on the DRAM, and I hope the better branch prediction / prefetching of the Cortex-A9 would help with this.... https://github.com/m-labs/artiq/issues/1167#issuecomment-427382555
hartytp has quit [Quit: Page closed]
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1166: Using @hartytp build I also see problems with the sawtooth pattern. When errors occur they don't occur with the same period as the sawtooth so I've done a single-trigger capture. sawg0...sawg7... https://github.com/m-labs/artiq/issues/1166#issuecomment-427388926
dlechrg has quit [Remote host closed the connection]
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1167: > DMA is great to have as a backup for anything that requires large numbers of really short pulses, but being able to do things on the fly gives one so much flexibility. Currently, we're forced to use DMA for even relatively simple things like sideband cooling which is annoying.... https://github.com/m-labs/artiq/issues/1167#issuecomment-427416220
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1167: > DMA is great to have as a backup for anything that requires large numbers of really short pulses, but being able to do things on the fly gives one so much flexibility. Currently, we're forced to use DMA for even relatively simple things like sideband cooling which is annoying.... https://github.com/m-labs/artiq/issues/1167#issuecomment-427416220
m4ssi has quit [Remote host closed the connection]
<GitHub-m-labs>
[artiq] gkasprow commented on issue #1167: With ZynQ you can setup multiprocessing (SMP). One core can be responsible for low latency simple tasks and run from BRAM while other work from SDRAM and do remaining tasks.... https://github.com/m-labs/artiq/issues/1167#issuecomment-427432547
mumptai has joined #m-labs
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1167: I think for these applications, we are not enormously price sensitive if it means a substantial difference in performance. In other words, we don't need to spend huge amounts of money to get the very best performance, but if substantial performance enhancement can be had with a chip that is not much more expensive, I would go that way every time. https://githu
<GitHub-m-labs>
[artiq] gkasprow commented on issue #1167: With ZynQ you can setup multiprocessing (SMP). One core can be responsible for low latency simple tasks and run from BRAM while other work from SDRAM and do remaining tasks.... https://github.com/m-labs/artiq/issues/1167#issuecomment-427432547
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
webframplG has joined #m-labs
webframplG has quit [Remote host closed the connection]