<whitequark>
rjo: RFout of windfreak connected to J1 of ad9154-fmc-ebz now
<whitequark>
LOL
<whitequark>
how do you think windfreak enumerates on USB?
<whitequark>
[11120175.862902] usb 1-10: Manufacturer: Teensyduino
<whitequark>
and that costs $500?
kuldeep has quit [Ping timeout: 264 seconds]
<sb0>
yes, the firmware is also pretty buggy
kuldeep has joined #m-labs
<sb0>
rjo, I can easily get two HackRF, which are single channel but can be externally clocked, I suppose that works?
<sb0>
hm, there's a lo/mixer inside the rf chip...
<sb0>
and only 8-bit 20Msps
<sb0>
well I can maybe disable the RF front-end with just a bit of soldering and get a pure ADC.
<sb0>
and IQ ADC, so two channels on one board
kuldeep has quit [Ping timeout: 244 seconds]
kuldeep has joined #m-labs
kuldeep_ has joined #m-labs
kuldeep has quit [Ping timeout: 272 seconds]
<sb0>
rjo, why did you mention AD9528? the FMC card uses AD9516
<sb0>
larsc, what's the advantage of 9528?
<sb0>
I would stick to what is proven on the FMC card as much as possible. proprietary chips acting up are not fun.
<sb0>
the 9528 cannot produce 2.4GHz anyway
<sb0>
VCO from 3.4GHz to 4GHz and no direct VCO mode
<sb0>
instead of reshuffling samples, what about reprogramming the phase inside the clock chip to align SYSREF with the RTIO clock? this keeps more of the system consistent across reboots
<sb0>
and it's easier to get the sample reshuffling wrong
<larsc>
sb0: compared to ad9516? two plls for jitter cleanup
<sb0>
rjo, "the channel dividers allow a coarse phase offset or delay to be set. Depending on the division selected, the output can be delayed by up to 31 input clock cycles"
<sb0>
larsc, but its max frequency is too low, so this resolves the question
<sb0>
rjo, that's AD9516-1
<larsc>
I think input is vcxo frequncy in that case
<sb0>
what's the sysref frequency?
<larsc>
like the input to the divider, not the input to the clockchip
<larsc>
4 of the outputs also have a delay line for fine delay
<sb0>
yes, but that still gives us 12ns of range
<sb0>
since the RTIO clock is <= 8ns, we should always be able to align
<larsc>
sysref can be anything that is an integer multiple of the lmfc
<sb0>
including 1?
<sb0>
seems so...
<larsc>
according to the spec yes, but I think some of the ADI converters only work with 2
<sb0>
now what is the lmfc frequency?
<larsc>
lmfc is linerate / 160
<larsc>
or 320
<larsc>
320 probably
<sb0>
so ~37MHz
<sb0>
I guess we'd need a combination of first resetting the divider to get SYSREF within a some ns of what we want, then measuring its fine phase, and adjusting the phase delay registers to get it within ~400ps of what we want
<larsc>
and when I said sysref is a integer multiple I meant the period, not the frequency, sorry
<larsc>
it is a subharmonic
<sb0>
there's the SYNC pin for doing this divider reset
<larsc>
if it is not synchronous you'll get +- 1 VCO cycle uncertainty
<sb0>
yes, and then we measure the output precisely with a IDELAY scan on the FPGA, and rewrite the phase offset register to compensate
<sb0>
it seems the AD9516-1 will do what it should, and is on the FMC card for prototyping
<sb0>
it doesn't have the fancier SYSREF generator though, that we could try using if the first plan fails
<larsc>
to be honest the sysref generator is not that useful in my opinion
<larsc>
unless you want oneshot sysref
<larsc>
rather than periodic
<sb0>
ok. we definitely want periodic sysref, as we can do a idelay scan instead of a much more complex TDC
<larsc>
one of the issues with the sysref genertor is that it runs of the downdivided PLL feedback clock, rather than the VCO like the othe dividers, so you are much more limited in the available frequencies
<sb0>
now a 200MHz RTIO clock will be nice, as the DAC clock will be an integer multiple of it
<sb0>
but the Xilinx transceivers only let you set the line rate to 20x or 40x their reference clock... pff
<sb0>
so we could have 4Gbps DRTIO
<sb0>
instead of 5
<sb0>
or 8, if the backplane allows it
<larsc>
sysref is not the reference clock
<larsc>
oh, you mean the reference clock for the CDR?
<sb0>
yes
<sb0>
or the transmitter
kuldeep_ has quit [Ping timeout: 272 seconds]
kuldeep_ has joined #m-labs
kuldeep_ has quit [Max SendQ exceeded]
kuldeep_ has joined #m-labs
<sb0>
HMC7043 is just a buffer/divider/sysref generator (no PLL) so this leaves HMC7044 vs. AD9516-1
<sb0>
the HMC7044 coarse delays do not have enough range to cover one full RTIO clock cycle
<sb0>
rjo, we are out of clock outputs. we can trust that DRTIO clock recovery will work, or add another buffer
sandeepkr_ has joined #m-labs
sandeepkr__ has joined #m-labs
sandeepkr has quit [Read error: No route to host]
sandeepkr_ has quit [Ping timeout: 264 seconds]
bentley` has quit [Ping timeout: 276 seconds]
sandeepkr_ has joined #m-labs
sandeepkr__ has quit [Read error: No route to host]
sandeepkr__ has joined #m-labs
sandeepkr_ has quit [Ping timeout: 272 seconds]
<rjo>
whitequark: thanks. that manufacturer thing might just be a reuse bei either windfreak or arduino..
<rjo>
sb0: what do you want to align to what and how do you want to measure it?
<rjo>
sb0: i don't think the noise specs of the ad9516 are particularly impressive. ant it doesn't have enough outputs.
<rjo>
sb0: ... as you just discovered as well.
<rjo>
sb0: what do you want to do with the hackrf?
<sb0>
phase noise measurements
<rjo>
have you read the paper?
<sb0>
not in detail. been busy looking into jesd clock sync and clock chips.
sandeepkr_ has joined #m-labs
sandeepkr_ has quit [Max SendQ exceeded]
sandeepkr_ has joined #m-labs
sandeepkr_ has quit [Max SendQ exceeded]
<rjo>
sb0: ok. then let's talks about measuring phase noise when you have read the paper.
<rjo>
sb0: new insights about the clocking?
sandeepkr__ has quit [Ping timeout: 272 seconds]
kuldeep__ has quit [Ping timeout: 272 seconds]
sandeepkr has joined #m-labs
<sb0>
yes
<sb0>
writing an email rn
sandeepkr has quit [Max SendQ exceeded]
sandeepkr has joined #m-labs
kuldeep__ has joined #m-labs
kuldeep__ has quit [Max SendQ exceeded]
kuldeep__ has joined #m-labs
<sb0>
email sent
<sb0>
oh, actually the hmc has a third mechanism to adjust output phase
<sb0>
so scratch my comment about range. there is no reason to not use the hmc.
<rjo>
ack. adjusting phases is a good alternative to sample slip. but it also needs to be done for the fpga deviceclock.
<rjo>
what makes you think you can generate that SYNC to within a dac clock cycle?
<rjo>
sb0: ^
<sb0>
you don't
<sb0>
SYNC gives you a rough alignment, then you measure what you got by IDELAY scanning, and apply a correction by programming the various delays of the clock chip
<sb0>
actually, with the HMC, we don't need SYNC at all, since the slip mode has infinite range
<rjo>
quoting you: "The FPGA first roughly aligns SYSREF within one cycle before a desired RTIO clock edge by asserting the synchronization signal of the clock chip, which resets its dividers. This alignment has an uncertainty of one DAC clock cycle."
<rjo>
and as i said, you also need to phase shift the deviceclocks of the fpga and the adcs. not jut sysref.
<sb0>
yes, you get +/- 1 DAC clock cycle, 800ps of precision sounds reasonable even if it were a CMOS signal
<rjo>
but it's not at all one (or one of two) specific clock cycles.
<sb0>
wrt the RTIO clock it is
<sb0>
the purpose of this SYNC is to get the low frequency (dozens MHz) SYSREF roughly where you want it, that's all
<rjo>
so you want to get the coincident phase of all devicecllocks and sysrefs "as close as possible" to rtio first.
<sb0>
and always before where you eventually want it, then you apply delays
<sb0>
close to within the delay range, yes
<rjo>
ok.
<rjo>
yeah. that's fine. that gets rid of the sample shuffling.
<sb0>
yes, and of carrying state from one boot to the next
<sb0>
the HMC chip has 25ps fine delay resolution, the IDELAY may be a bit more problematic, taps are rated "2.5 to 15 ps", will have to dig into that
<rjo>
yeah. we can even replace the idelay scan by a hmc fine delay scan.
<rjo>
as a fallback.
<sb0>
looking at the DAC's s/h violation monitor?
<rjo>
no. for measuring the sysref fine phase w.r.t. rtio. tiwddling idelay and delaying the signal in the hmc are equivalent.
<sb0>
right, we can do that with the HMC
<sb0>
I was still thinking of the AD, which has a limited number of fine delay blocks, so we'd have to send a clock without fine delay to the FPGA
<rjo>
ack.
_rht has joined #m-labs
<rjo>
right now the most pressing thing seemed to be to figure out what the oxford pll black box looks like.
<rjo>
but i think it will just be a 100 MHz -> 2.4 GHz or 2 GHz PLL. all the other clocking cases are covered with dividing that clock.
<rjo>
but i would like to insist that also the dacs are clocked through the hmc chip and not directly from the pll.
<rjo>
that's the only way to use trace length matching for sysref-to-deviceclock_dac. it's going to be a mess otherwise.
<rjo>
oh. and please connect the 100 MHz to one of the additional hmc inputs. that would allow for a couple more measurements of that phase.
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 264 seconds]
<sb0>
the Ben eyes-only thingy?
<rjo>
i think the eyes-only thing was the kbb stuff. afaict the pll will be open.
<rjo>
but anyway. i think it's just a module with a 100 MHz input and an 2/2.4 GHz output and power supplies.
mumptai has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
bentley` has joined #m-labs
sandeepkr has quit [Ping timeout: 264 seconds]
sandeepkr has joined #m-labs
kuldeep__ has quit [Remote host closed the connection]
kuldeep has joined #m-labs
kuldeep has quit [Ping timeout: 244 seconds]
sandeepkr has quit [Ping timeout: 244 seconds]
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 45.3.0/20160802213348]]
sandeepkr has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
kuldeep has joined #m-labs
kuldeep has quit [Max SendQ exceeded]
sandeepkr has quit [Read error: No route to host]
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
fengling has joined #m-labs
kyak has quit [Ping timeout: 272 seconds]
fengling has quit [Ping timeout: 268 seconds]
rohitksingh has quit [Quit: Leaving.]
kyak has joined #m-labs
<whitequark>
what
<whitequark>
why does or1k's l.lhz require an aligned address
<whitequark>
what is even the point of having it in the first place?!!
<whitequark>
I guess loading u16 members from non-packed structs and such...
<whitequark>
I'm pretty sure this is wrong as a) it should have been zextload (or have a corresponding sextload pattern) b) it doesn't check that the load has alignment of at least 4
<whitequark>
ah, no, scratch a), extload means *any* extension
<whitequark>
the alignment problem stands though...