<GitHub-m-labs>
[artiq] sbourdeauducq closed issue #1081: RTIO sequence errors when setting multiple outputs and collecting inputs https://github.com/m-labs/artiq/issues/1081
<GitHub-m-labs>
[artiq] hartytp commented on issue #794: @sbourdeauducq What's the plan for testing this at the full 2.4GHz DAC clock? It seems worth checking that works reliably before we move onto Sayma v2.0 in case there are any changes we decide to make to the hw. https://github.com/m-labs/artiq/issues/794#issuecomment-401706657
<GitHub-m-labs>
[artiq] jordens commented on issue #1081: A possible extension to SED would be to also have a sorting network at the cpu side that would make smarter lane choices instead of just advancing, to achieve better packing. I.e. it could choose the lane that has the largest timestamp queued that still meets strict monotonicity. https://github.com/m-labs/artiq/issues/1081#issuecomment-401707659
<GitHub-m-labs>
[artiq] jordens commented on issue #1081: The submission-to-output latency maybe. Does that matter? But AFAICT the user-visible RTIO latency (from trigger to output or the `break_realtime()` value) is dominated by RTIO API and CPU, not by the gateware. https://github.com/m-labs/artiq/issues/1081#issuecomment-401710307
<rjo>
sb0: there is also the wikipedia figure. and iirc basler had some reasonably good info on it.
<sb0>
the wikipedia figure is copied from the website I linked
<rjo>
but it's older.
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1001: @enjoy-digital How does the low-speed PHY meet timing? Assume that with low bit rates and fast flip-flops, the chance of not meeting setup/hold is small? https://github.com/m-labs/artiq/issues/1001#issuecomment-401714900
<sb0>
the "fixed" version appeared more or less at the same time, I suspect Vswitchs is also the author of the website
<GitHub-m-labs>
[artiq] jordens commented on issue #1081: The gateware latency? As long as it's orders of magnitude less than the RTIO API and CPU latency then I'd happily get better lane utilization at the expense of a couple cycles of gateware latency. https://github.com/m-labs/artiq/issues/1081#issuecomment-401716017
<rjo>
sb0: there is another (the channel link) mapping.
<rjo>
sb0: from a quick check the compound (channel link plus camera link) mapping is the one from the web page. and the specification has only the camera link mapping.
<sb0>
ah, ok, thanks
<rjo>
looks like they tried to undo the channel link mapping in camera link but messed it up/couldn't decide on a desired pattern.
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1001: > Is it worth adding some termination resistors on to the boards so that we can use the high-speed phy again with a supported IO standard?... https://github.com/m-labs/artiq/issues/1001#issuecomment-401724084
<GitHub-m-labs>
[artiq] hartytp commented on issue #1001: > I don't think faster programming of the DAC/HMC SPI etc. is that important and worth the trouble of reworking all boards (since otherwise, the master gateware would only work with some).... https://github.com/m-labs/artiq/issues/1001#issuecomment-401735430
<GitHub-m-labs>
[artiq] hartytp commented on issue #1083: > Okay, I didn't realise that. Do you see any of the bad eye scans that I see? Here "Bad" = hysteresis between the eye scan and the value we measure at the "default phase" after the scan, or slips moving the transition by significantly more than 34 taps.... https://github.com/m-labs/artiq/issues/1083#issuecomment-401744568
rohitksingh_work has quit [Ping timeout: 256 seconds]
<GitHub-m-labs>
[artiq] hartytp commented on issue #1001: OK, I don't feel like doing that right now. If there isn't anything a bit easier to solder on to within an inch or so of the FPGA then let's not bother. https://github.com/m-labs/artiq/issues/1001#issuecomment-401755361
<omid>
rjo: I guess this message was missed from Friday: I can ping now. But when I run command $artiq_flash -f flash_storage.img proxy storage start it tells me Binaries directory kc705-nist_clock does not exist. How can I get it to use my binary directory named kc705-phaser ?
richardas_ has joined #m-labs
<sb0>
omid, -m phaser
<sb0>
hartytp, why DATA_RATE=DDR?
<hartytp>
copy paste
<hartytp>
have removed that
<sb0>
oh, you're trying to output the JESD clock?
<hartytp>
yes
<hartytp>
(when is that needed, I hadn't seen it before)
<omid>
Thanks sb0
<richardas_>
Hello, is i was wondering if there was any simple misoc example?
<larsc>
because you wouldn't know how to use them anyway!!!
<larsc>
for ultrascale they took the approach that the IO pins are first and foremost a DDR PHY, but which has a secondary mode where the pins can be used individually
<hartytp>
sb0: okay, have the JESD clock output on the SYSCLK output for the working config
<hartytp>
all looks good as expected
<hartytp>
will rebuild and look at non-working config tomorrow and see what we can see...
<richardas_>
when running this code(sorry I'm really new to this) https://pastebin.com/Tg23Ggi1 , I expected to see new addresses in generated/include/csr.h file but there is nothing. What I'm doing wrong? Could anyone help please?
<sb0>
richardas_, blinker should derive from autocsr + you should add "blinker" to self.csr_devices
<omid>
sj0: I also ran the led example on the website. The output error is the same. Connection refused. I also compiled the led.py file got this error: https://pastecode.xyz/view/89e6598e
<omid>
There is still no output on the terminal where I run flterm /dev/ttyUSB2
<sb0>
omid, you still have not told me if your startup kernel terminates.
<omid>
(I still need to press some key, any key, for it to output that error.)
<sb0>
are you sure it's the correct ttyUSB and not e.g. a JTAG port?
<sb0>
anyway if flterm craps out for some reason, you can use another serial terminal program
<omid>
sb0: I used the other ttyUSB. The result is the same
<omid>
Do you have a suggestion for a serial terminal program replacement?
<sb0>
gtkterm, putty
<sb0>
stty + cat
sb0 has quit [Quit: Leaving]
<richardas_>
thanks sb0
richardas_ has quit [Remote host closed the connection]
<omid>
sb0, rbj: I starting using gtkterm (instead of flterm) and ran the led.py script. The result is the same error output (https://pastecode.xyz/view/89e6598e). No output is generated on gtkterm when I run the script (I checked all the the ttyUSB's on gtkterm configuration).
<omid>
I can ping the device and I can flash it. All the steps prior to running an script works.
<GitHub-m-labs>
[artiq] philipkent commented on issue #1091: This also happens if you create an environment from the "main" channel with `conda create -n artiq-main artiq-kc705-nist_qc2` which installs version 3.6 as well. https://github.com/m-labs/artiq/issues/1091#issuecomment-401932298