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
evilspirit has joined #m-labs
evilspirit has quit [Read error: Connection reset by peer]
<GitHub111>
[artiq] jordens created testbench-controllers (+5 new commits): https://git.io/vzQoy
<GitHub111>
artiq/testbench-controllers cda4a07 Robert Jordens: artiq_ctlmgr: refactor into artiq.devices.ctlmgr
<GitHub111>
artiq/testbench-controllers ccac852 Robert Jordens: lda: test tweaks
<GitHub111>
artiq/testbench-controllers f78eecb Robert Jordens: hardware_testbench: run controllers
fengling has joined #m-labs
rohitksingh has joined #m-labs
fengling has quit [Ping timeout: 272 seconds]
fengling has joined #m-labs
FabM has joined #m-labs
fengling has quit [Ping timeout: 272 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 272 seconds]
fengling has joined #m-labs
jaeckel has quit [Ping timeout: 240 seconds]
jaeckel has joined #m-labs
sb0__ has joined #m-labs
sb0__ has quit [Quit: Page closed]
<mithro>
rjo: I'm trying to use openocd and your spi flash proxy with my Atlys board, but I'm getting the spi flash returning "Unknown flash device (ID 0x00ffffff)" which sounds like something is broken
<mithro>
rjo: Programing the FPGA works fine with OpenOCD, as does reading the DNA
sb0__ has joined #m-labs
<sb0__>
rjo: can you send me your pdq2 slides shortly plz?
ylamarre has joined #m-labs
<sb0__>
mithro: do you have a logo to put on the slides related to numato/hdmi2usb?
<sb0__>
you have so many names :) hdmi2usb, timvideos, numato opsis...
<mithro>
sb0__: true
<sb0__>
so: timvideos is your 'company' that does video streaming, hdmi2usb is the firmware/gateware/software project, numato is your manufacturer in India, and opsis is the in-house/endorsed hardware for hdmi2usb?
<mithro>
s/company/hobby FOSS project that takes up too much of my time :)/
<sb0__>
yeah, hence the quotes :)
<mithro>
sb0__: btw did you write the HDMI/DVI sampler code in misoc?
<sb0__>
yes
<sb0__>
is that what you are using now?
<mithro>
sb0__: yes, when you are less busy I'd like to pick your brains to understand it better
<mithro>
sb0__: I'm slowly understanding how it works
<mithro>
sb0__: and adding documentation to it :)
<mithro>
sb0__: we are getting a low number of WER on the Opsis board inputs with some devices, it seems to be a signal level problem - but I want to rule out any sampling alignment issues first
<sb0__>
clock/data alignment?
<sb0__>
does this happen all the time on a problematic board, or is it intermittent (develops over time, only happens with certain cables/sources)?
<mithro>
sb0__: I think we have 1 bad board were is occurs much worse then the others, but mostly it only happens with certain cables/sources
<sb0__>
and yeah, the spartan6 idelay has many problems - you cannot know where it settles, it can max out arbitrarily, the taps are uncalibrated, it craps out if the delay is larger than the bit time
<sb0__>
they fixed many of those issues in 7-series, but removed the phase detector which was actually very useful
<mithro>
sb0__: yeah, I've heard you complain about them before :)
<sb0__>
AFAICT this halves the max data rate that can be received if you don't know the clock/data phase relationship in advance
<sb0__>
maybe they want to sell their expensive transceivers
<mithro>
sb0__: I did notice you aren't using any of the bitslip functionality, just the IDELAY stuff?
<sb0__>
bitslip is done in fabric because I had enough of the bugs and problems of the hardblock
<sb0__>
also, it doesn't make sense to have a hardblock for that anyway
<mithro>
sb0__: okay, I haven't discovered / understood that code yet
<mithro>
sb0__: it looks like most of the delay stuff is all passed up to software to handle?
<sb0__>
yes, that's one main difference with the xilinx design where this is implemented using (horrid) FSMs
<sb0__>
I'm actually amazed they got that thing to work with the FSMs
<sb0__>
surely they spent a lot of time with their chipscope thing...
<mithro>
sb0__: it also looks like you use that to work around the delays not giving any information on state by driving them in one direction until they stop?
<sb0__>
there is no workaround for that
<sb0__>
the only thing you can attempt is if the WER is too high, you reset the link and run the automatic phase detector centering again
<sb0__>
this will make you lose some of the video
<sb0__>
the current firmware does not do that
<sb0__>
I hope no one is using the IDELAY in any hi-rel application...
<sb0__>
note that the IDELAY might even stop where the delay is higher than the bit time, at which point it will start outputting complete garbage
<sb0__>
for 100 times: run 1000 small delay adjustments using the phase detector info, and check that the idelay stays within +/- 4 taps of what it was
<sb0__>
it's just a check function to verify that the idelay/phase detector are operating correctly, the code should run fine without it
<sb0__>
by 'correctly' I mean 'as correctly as it could', of course. the design of this thing is fundamentally flawed.
<sb0__>
if that function passes and the WER is high immediately after (doesn't develop over time, and the taps stay stable) it's probably a hardware problem
<sb0__>
high random jitter can cause the delay adjustments to average out over time, and cause WER
ylamarre has quit [Ping timeout: 245 seconds]
ylamarre has joined #m-labs
sb0__ has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined #m-labs
ylamarre has quit [Quit: ylamarre]
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
ylamarre has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
ylamarre has quit [Quit: ylamarre]
<GitHub119>
[artiq] jordens pushed 2 new commits to testbench-controllers: https://git.io/vzFsd
<GitHub119>
artiq/testbench-controllers 982fbb0 Robert Jordens: hardware_testbench: use plain subprocess to start controllers
<GitHub119>
artiq/testbench-controllers ab5e8fd Robert Jordens: hardware_testbench: fix timeout handling