<sb0>
whitequark, how's the coredevice slowdown issue?
<sb0>
is there some sort of holiday in Poland? seems I cannot reach anyone at technosystem since last week
sb0 has quit [Quit: Leaving]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 255 seconds]
sb0 has joined #m-labs
<rjo>
sb0: you were comaplaining about the camera link cables a while back. any other progress with the grabber gateware?
<sb0>
no, mostly been doing shitty admin involving insufferable banksters, lab tours and sales, and ad9914 tests
<sb0>
I think I can start looking into this in a some days; maybe the best solution is to connect that camera at the quartiq office and I'll debug remotely
<sb0>
since everything cameralink is expensive as hell
<_florent_>
sb0: i'll do others JESD204 SC1 tests. Last time i investigated, i was not able to notice the effects of the HMC7043 delays at the AD9154 side so that was blocking me...
<sb0>
_florent_, yes. but since the tests Tom did, it became clear that the hmc7043 phase shifts are working, so the problem is likely to be some obscure bit that is not set in the ad9154 configuration somewhere
<sb0>
larsc, maybe you have some ideas?
<_florent_>
sb0: yes but i have to find this obscure bit...
<_florent_>
sb0: what i'm doing: configure the AD9154 in "One-Shot Then Monitor Sync Mode", then play with the HMC7043 delays and look at the SYNC_CURRERR_L/SYNC_CURRERR_H registers that should reflects the HMC7043 delays
<sb0>
_florent_, how do you get into that one-shot mode? maybe something additional needs to be done to trigger the shot?
<_florent_>
sb0: no, i know that the shot is triggering with a bit i'm setting before and that is cleared
<_florent_>
triggering/triggered
<sb0>
okay, then maybe the "monitor sync" part is broken?
<sb0>
what about trying another approach? wasn't there some "continous sync" mode that would still tell you when it resync'd outside of some window, which you could set to 0?
<_florent_>
sb0: yes i can try another approach
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has quit [Ping timeout: 260 seconds]
<larsc>
_florent_: do you use the analog or digital delays?
<_florent_>
larsc: IIRC i tried with both
<sb0>
larsc, Tom tested the hmc7043 and the phase shifts worked with the latest code
<sb0>
_florent_, have you actually tried it carefully with the new 7043 code?
<_florent_>
sb0: yes i tested it with new hms7043 code, but i'll redo the test
<larsc>
the digital delay is basically the reset value for the output divider counters, so those only take effect when a sync is done
hartytp has joined #m-labs
<hartytp>
_florent_ what code are you using for the ad9154 sync?
<larsc>
the analog is only 23ps per step (iirc)
<larsc>
so depending on your dac clock frequency that may or may not be enough to move the sysref by a full clock cycle
<hartytp>
larsc: hmm
<hartytp>
maybe I'm misreading your statement about the digital phase shift
<hartytp>
but my reading of what you're saying doesn't match my experience
<hartytp>
I wrote some code that cycled through values of the digital delay
<hartytp>
and looked at the outputs on a scope
<_florent_>
hartytp: i'll redo the test and will share core
<hartytp>
and saw the phases move
<_florent_>
core/code
<hartytp>
thanks _florent_
<hartytp>
I'm sure you're doign everything correctly, but I'm curious and happy to have a skim over the code
<larsc>
hartytp: maybe I'm mixing this up with some other clockchip
<larsc>
let me check
<_florent_>
hartytp: yes sure, any review/help is welcome
<sb0>
hartytp, didn't you test the analog delay as well?
<hartytp>
yes, I used both
jfng has joined #m-labs
<hartytp>
one thing I think we should do is to add a function that sets the analog and digital delays
<hartytp>
that way, I can verify that that function works
<hartytp>
the tests I did were using some code that I hacked into the init function which has since been deleted
<hartytp>
so, I haven't actually tested any code that is still present, so it's possible that bugs have crept in
<larsc>
hartytp: sorry, I mxied things up, on the HMC7043 you can adjust at runtime
<hartytp>
larsc: np
<larsc>
_florent_: The way I read the SYNC_CURRERR register description it would only change in continuous sync mode
<larsc>
ah, no, Ic an't read
<larsc>
and write
<larsc>
I have a AD9152 here, let me see if I can get SYNC_CURRERR != 0
<rjo>
sb0: please stop the whining. for grabber i think it is much easier and faster to write a simple pattern generator for camera link. your complaints about everything related to the camera would be worse.
<sb0>
rjo, why? the camera cannot be set up to output a continuous stream of data and then left untouched?
<rjo>
sb0: it's amusing how you praise HK for its superior taxes, simple admin but can't handle your bank.
<_florent_>
larsc: from what i understand, SYNC_CURRERR will be 0 just after the only one adjustment in "One-Shot Then Monitor Sync Mode" and should then be updated if we change sysref phase
<sb0>
and I'm certainly not the only one complaining, you can find many other articles mentioning this
<_florent_>
larsc: thanks for looking at that
<larsc>
need to build a bitstream first, so this will take a few minutes
<sb0>
rjo, also about "handling" the bank, they likely will require you to come here
<sb0>
to check your passport in person. how nice is that
<rjo>
sb0: sure. you can do that. but i think you are underestimating the complexity of the camera, the driver, the overhead involved in shipping it around, setting it up. have you had a look at the camera's manual and the sdk?
<hartytp>
oh, btw, the TI DCXO arrived
<_florent_>
larsc: ok, np, i'm also setting up things here
<hartytp>
Weida is having a play at doing a digital lock with it on the KC705 using a DDMTD
<hartytp>
but, the open-loop phase noise is per-datasheet, which is nice
<sb0>
rjo, well eventually there needs to be a setup somewhere with that camera and kasli, right?
<sb0>
rjo, can't the development be done on that setup?
<rjo>
sb0: you'll want to look at signals. if you need me to service that development setup, i might as well do the development of the SERDES interface. with a fixed pattern generator you have so much more flexibility and decouple debugging from all kinds of issues.
<sb0>
I don't think I'll have to look at the signals at the electrical level. ethernet dev went quite well even though it is more complex than cameralink
<sb0>
as long as the camera behaves and keeps generating data, which it needs to do anyway, then I should be fine
rohitksingh_work has quit [Ping timeout: 276 seconds]
<sb0>
worst case I can set up a free-running ISERDES at ~1Gbps and sample its output with microscope, which is actually better than hooking up an oscilloscope to the signals
<sb0>
even if I had physical access to the hardware I'd still prefer it over the oscilloscope
<rjo>
the way i see it is that greg did all the measurement for you.
<sb0>
well, you were asking for a cameralink core, not characterizing the board
rohitksingh_work has joined #m-labs
jfng has quit [Ping timeout: 246 seconds]
<larsc>
_florent_: I can trigger it
<larsc>
write 0x89 to 0x3a, then 0xc9 to 0x3a, check 0x3b that bit 0 is set and then change the phase
<_florent_>
larsc: ok thanks, i'm going to check with what i'm doing
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
<_florent_>
sb0: is the 1.2GHz clock generator connected to sayma-3?
<sb0>
_florent_, it was last time I checked, whitequark ?
<sb0>
rjo, hartytp, isn't sampler 8HP contrary to what the wiki says?
<hartytp>
it's 8HP
<hartytp>
yes
<hartytp>
wiki is prob out of date
<sb0>
ok fixing
<hartytp>
ta
<hartytp>
that thing needs a *lot* of work
<_florent_>
larsc: btw, which chip are you using to generate the phase shift, ad9516?
<_florent_>
sb0: i get JESD ready timeout, i'll retry later when i have confirmation that clocking is fine
<_florent_>
sb0: i'm going to re-do some tests with my kcu105 + ad9154 fmc
<sb0>
_florent_, no clock normally results in "SERDES PLL lock timeout". but yes, sayma has many bugs
X-Scale has joined #m-labs
<sb0>
if I flash OpenMMC, can I expect the boards to work in the µTCA chassis and without JTAG or additional Ethernet breakage?
<_florent_>
sb0: from what i remember, we were able to get jesd working without too much problems
<sb0>
_florent_, not really. when I wanted to test sync I had a script that power-cycled the boards many times, and that turned up many JESD failures (though they might have been serwb data corruption)
<larsc>
_florent_: ad9528
jfng has joined #m-labs
<larsc>
this one only has fine delay, but I can move the offset by up to 2 clock DAC cycles and I can see that in the CURRERR register