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
balrog has quit [Ping timeout: 264 seconds]
balrog has joined #m-labs
balrog has quit [Ping timeout: 240 seconds]
balrog has joined #m-labs
rohitksingh_work has joined #m-labs
<GitHub-m-labs>
[artiq] jbqubit commented on issue #908: Built from master with SAWG. Loaded onto board that I've had for many months -- not the one that @marmeladapk mentioned is in the mail. ... https://github.com/m-labs/artiq/issues/908#issuecomment-375531041
<davidc__>
rjo: I don't have a ton of experience, I've mostly just used some Point Grey GIGE vision cameras with their own SDK
<davidc__>
rjo: but I had to debug some stuff, so spent a bit of time fiddling with the SDK
<davidc__>
* and looking at it in wireshark
sb0 has joined #m-labs
<sb0>
whitequark, i think the errors you're seeing with openocd are just jtag chain confusion with/without rtm.
<sb0>
/usr/local/share/openocd/scripts/board/sayma_amc.cfg doesn't work when the rtm *is* connected
<sb0>
artiq_flash doesn't work when the rtm *is not* connected
<sb0>
whitequark, additionally sayma-3 (florent's board) lacks a hardware rework to make the xadc work I think
<whitequark>
hm okay
<sb0>
whitequark, also you are the first one to try the DACs on sayma-1. like most things on sayma, whether it works or not depends heavily on the particular board (and the phase of the moon). what has been tested and confirmed to work (sometimes) is rtm-1 on sayma-3 (florent's)
<sb0>
though we fixed a number of things since that test; with luck it may work
<whitequark>
alright
<whitequark>
is there an overview of the architecture somewhere?
<whitequark>
or is it just undocumented migen code?
<sb0>
architecture of?
<whitequark>
DACs
<whitequark>
there's this thing called JESD and everything
<whitequark>
I'm not sure how it fits together
<whitequark>
well I guess overall architecture of sayma
<sb0>
there are JESD204 (google it) links between the AMC FPGA and the ADI DAC chips
<sb0>
those DACs also have a SPI interface, which is connected to the RTM FPGA, and is accessed by the AMC FPGA over the serwb bridge
<whitequark>
remind me, why do we have the AMC/RTM split in the first place?
<whitequark>
are there multiple RTM boards planned?
<sb0>
this is somewhat controversial and debatable, but 1) use of the desy clock backplane (which is now pretty much dead) 2) not enough space on one board 3) EMI and thermal considerations
<whitequark>
yes, I see why it's controversial
<whitequark>
ok, I think I understand what JESD204 is now
<whitequark>
12.5 Gbps, wow
<sb0>
yeah *8
<whitequark>
that explains why the FPGA costs a small fortune
<sb0>
not really; USB3 chips don't cost a small fortune but have similar technology inside
<sb0>
it's mostly xilinx market segmentation
<sb0>
also those transceivers would certainly be cheaper if they weren't designed in such a stupid way
<whitequark>
which stupid way?
<sb0>
pack them with buggy hardwired features that rather belong in the fabric
<whitequark>
ah
<sb0>
plus many other problems that likely don't impact cost on the xilinx side
<sb0>
at least the xilinx transceiver don't self-destruct when they are not clocked, unlike the altera ones
<sb0>
iirc you also need some transceiver clock source connected in some way to the fpga, otherwise the software workaround doesn't work
<sb0>
and it will of course not warn you if that clock source is malfunctioning
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #950: Reproducible on the SYSU target. An idle kernel does not appear to be necessary; I can make the error appear by interrupting one regular kernel with another regular kernel (e.g. running ``artiq_run`` while another instance was already running). https://github.com/m-labs/artiq/issues/950#issuecomment-375573467
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #950: I guess what happens is simple: there are events programmed far into the future by the first kernel (since the LED frequency is low). When the second kernel takes over, the value of ``now_mu`` given by ``break_realtime`` is the value of the RTIO counter plus some delta, which is less than the timestamp of some already programmed events.... https://github.com/m-
<GitHub-m-labs>
artiq/master 1553fc8 Robert Jordens: sed: reset `valid` in output sorter
<rjo>
hartytp: i meant that load could be controlled externally (by non rtio-gpio if needed or pulled low permanently). in init and it you have ldac, yes, you should set it high.
<rjo>
sb0: i have the feeling that the interrupt (EventManager) is typically involved in the timing paths for mor1kx in misoc on kasli. can we easily add some pipeline registers there?
<hartytp>
seems like the set function in the ad5360 is incorrect
<hartytp>
busy width varies depending on num channels updated
<hartytp>
cf data sheet fig 9
<hartytp>
fixing
<hartytp>
okay, fixed
<hartytp>
gtg now. will try to finish this eve
hartytp has quit [Quit: Page closed]
sb000 has joined #m-labs
<sb000>
hartytp, maybe by redefining/overloading methods?
<sb000>
rjo, does it pass timing when removed?
<sb000>
we don't actually need interrupts at all, I think
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #950: The commit part can be done by the gateware when one given 32-bit part of the 64-bit word is written. LLVM would have to know about this, though. https://github.com/m-labs/artiq/issues/950#issuecomment-375644063
<whitequark>
sb000: we need exceptions
<whitequark>
but no, we don't use interrupts at all; used to use them for UART but that's not the case with Rust code
<whitequark>
sb0: now it hangs trying to write to the second flash
<sb0>
does it hang or are you just flashing a large binary that takes time to write?
<whitequark>
it doesn't print anything for a long time
<sb0>
it's not printing anything when it writes
<sb0>
only when erasing
<whitequark>
oh
<whitequark>
that's stupid
<whitequark>
rjo: why did you disable slave FPGA bitstream loading?
<sb0>
whitequark, because it doesn't work for sayma reasons and blocks firmware startup
<whitequark>
sb0: can I get Allaki working without RTM bitstream?
<whitequark>
probably not
<sb0>
whitequark, load it with jtag
<sb0>
see /home/sb/load_rtm
<sb0>
minus the sayma intermittent bug, it recovers from AMC reloads, so you can (often) just leave it there
<sb0>
_florent_, any progress fixing serwb? jesd initialization? jesd sc1?
<whitequark>
got it all working. took me only a hour and a half...
<whitequark>
what a waste of time
<whitequark>
sb0: did you have scope probes somewhere?
<whitequark>
I can't find any
<whitequark>
only empty boxes
<sb0>
whitequark, I don't have many; they are around the tables. note that the 2kV probe you had is burned (I replaced it with a 4kV one) so don't use that one
<_florent_>
sb0: i'll work on that next week
<rjo>
_florent_: re serwb, copying the I/O SERDES/DELAY reset/vtc pattern from the ddr phy may or may not make a difference. also note that (IIRC) the reset i implemented for sayma is different from what you have in sayma_test (and maybe litex as well) currently.
<_florent_>
rjo: yes i have to look at what you did, it's probably better
<whitequark>
sb0: can I reduce the DAC frequency to something like 100 MHz?
<whitequark>
or does it have to run at 1.2 GHz?
<sb0>
why reduce it?
<whitequark>
the scope can't cope with 1.2 GHz...
<sb0>
but you're looking at the dac output, not the dac clock
<sb0>
the triangle wave test pattern is within the scope bandwidth
<whitequark>
I'm looking at the dac clock now
<sb0>
why?
<whitequark>
because there is no output from any of the DAC SMAs
<whitequark>
they are all just permanently high
<sb0>
whats on the log?
<whitequark>
nothing interesting
<sb0>
if the dac clock was wrong there would be an error
<whitequark>
define wrong
<sb0>
did it do the prbs tests?
<whitequark>
prbs tests?
<whitequark>
what's that?
<sb0>
see jesd204
<whitequark>
where in artiq is that?
<sb0>
there should be something in the log about it
<whitequark>
there is nothing in the log about prbs...