<GitHub24>
[smoltcp] dlrobertson commented on pull request #219 ced197f: Is there a reason to not use an `Option` here? Then you don't have to run `lookup` if the user hasn't configured a buffer for routes. https://github.com/m-labs/smoltcp/pull/219#discussion_r191093361
<GitHub49>
[smoltcp] dlrobertson opened pull request #220: Remove v4 from udp/tcp of ChecksumCapabilities (master...fix_cksum_caps) https://github.com/m-labs/smoltcp/pull/220
<rjo>
sb0: manual tweaking with trial and error? and that is stable across PVT?
<sb0>
the tolerances there are higher than for some other parts of the fpga design
<rjo>
what tolerances?
<sb0>
on the timing
<rjo>
what other parts?
<sb0>
internal combinatorial paths, for example
<rjo>
could you elaborate?
<rjo>
are you saying your approach won't work because of the higher tolerances?
<sb0>
PVT effects are on things like the routing network. all circuits in the FPGA are similarly affected, and many have timing windows smaller than cameralink's
<sb0>
still, it works with just static timing
<sb0>
no I am saying a simple timing calibration will work
<rjo>
sb0: an off-line calibration?
<sb0>
maybe with a simple mmcm phase scan in software to make debugging easier
<sb0>
could be offline, but it's riskier and harder to debug if things go wrong
<rjo>
sb0: do you have timing constraints that guarantee it will work?
<rjo>
so instead of bitslip you want to shift the mmcm phase? with the same iserdes logic on the clock? why not just bitsplip then?
<sb0>
bitslip won't fix s/h violations
<sb0>
changing the mmcm phase will
<sb0>
as for timing constraints, LOCing the MMCM should be enough
<rjo>
bitsplit and idelay will place you right in the middle of the window. you won't get any better than that.
<rjo>
i don't get your reluctance to just implement the app note.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0>
it's more complicated, especially as the idelay is 2.5ns maximum and 1 UI can be up to 3.6ns
<rjo>
sb0: there is a note about that case in the app note.
<bb-m-labs>
build #2394 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2394 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<sb0>
yea, but another corner case = another thing that can go wrong
<sb0>
and what if the input signal happens to have no transitions during the scan? the data is not 8b10b encoded ...
<rjo>
you are scanning the clock.
<sb0>
then it's doing the same as I am doing, only more complicated and harder to debug
<rjo>
LOCing something is the most likely thing that can go wrong with your approach.
<sb0>
there is little visibility into the iodelay, whereas you can observe the clock pattern directly with my approach
<sb0>
if the firmware scans the phase and calibrates, there is no need for LOC
<rjo>
honestly, this looks like another NIH and a complaint-fest.
<sb0>
?
<rjo>
now you want to add firmware to the problem.
<sb0>
changing the phase of the clock instead of using idelay is NIH?
<rjo>
if you are certain that's the only difference, fine. but silently relying on a pile of additional tooling that's not written yet and expecting less issues with it is.
<sb0>
what pile of additional tooling?
<rjo>
firmware support for phase scans. just think about managing multiple grabbers, different hardware.
<sb0>
the tools are there; there is the CSR device group support already
<sb0>
and this phase+firmware calibration is not only simpler than the iodelay and its corner cases, it also brings more visibility into the process
<rjo>
can we please first try just idelay and bitslip and only if that doesn't work escalate?
<rjo>
it is literally just porting the app note code.
<sb0>
the only thing it cannot do it per-lane deskew
<sb0>
*is
<sb0>
how about doing the other way, if the phase shift doens't work then look at the app note?
<sb0>
I don't see a problem with rtio phys needing firmware; even with drtio, we have satman
<rjo>
because just porting known-working code is faster than implementing, debugging, and maintaining new concepts.
<sb0>
I don't think so
<sb0>
anyway
<sb0>
(well, in this particular case I don't think so)
<sb0>
how do you want to report things like the detected video resolution to the rest of the system (kernel?)
<rjo>
no. it's agnostic to that.
<rjo>
s/no/not at all/
<sb0>
shouldn't the kernel be able to check that it is currently receiving video with the expected parameters?
<sb0>
I think a good check for a valid video signal is "you have received a frame recently which had the correct dimensions"
<rjo>
"have received a frame" is enough. that's already implemented. the other interface has that and more information anyway.
<sb0>
how many rtio channels will this interface use?
<sb0>
rjo, for sawg you don't have to use rtio.Channel.from_phy()
<sb0>
the from_phy() is just a convenient method for simple PHYs. sawg is no such simple PHY...
<sb0>
I suggest creating rtio.Channel directly in sawg, since there is no input FIFO to configure
hartytp has joined #m-labs
<hartytp>
rjo: is it worth a note somewhere (either a note in the docs, or a comment in kasli.py) to remind users to set DIP switch 2 on Urukul (they're not 0-indexed in the HW) to "on"
<hartytp>
?
<rjo>
hartytp: yes. could you file an issue?
<hartytp>
will do
<rjo>
hartytp: btw. do you have a backplane adapter? do you remember who got one and whether there are more available?
<hartytp>
I don't have one
<hartytp>
Paweł was going to send me one, but I don't think he got round to it
<hartytp>
I suspect that if you email Wojciech then he has some he can sell you
<hartytp>
but, Paweł is the guy to ask about all of that
<hartytp>
(I haven't chased since I don't have enough HW atm to need one, but soon I will)
<rjo>
that's what i thought as well.
<sb0>
what is that backplane adapter? to add another 2 EEMs to kasli?
<kaolpr>
hmm, I thought it's possible to have multiple core devices in devices_db and in arguments to a particular device point to appropriate one, but it apparently doesn't work...
<sb0>
no, that should work actually
<sb0>
but the core devices won't be synchronized
<sb0>
there is no example because no one has tried it.
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.8.0/20180509233012]]
rohitksingh has joined #m-labs
hartytp has quit [Quit: Page closed]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
cjbe has joined #m-labs
<cjbe>
whitequark: after around Artiq commit 56a29b91 I no longer get any console log from satman (output: https://hastebin.com/lubisotido.rb). The runtime still works as normal, so it is just a logging issue. Do I have to change the log level somewhere?
<bb-m-labs>
build #2397 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2397 blamelist: Chris Ballance <chris.ballance@physics.ox.ac.uk>