rohitksingh_work has quit [Ping timeout: 250 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Client Quit]
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
_whitelogger_ has joined #m-labs
_whitelogger has quit [Ping timeout: 250 seconds]
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 250 seconds]
m4ssi has joined #m-labs
m4ssi has quit [Quit: Leaving]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 240 seconds]
m4ssi has joined #m-labs
<rjo>
hartytp: i haven't looked at it in enough detail. we have a bunch of ADF4350 in opticlock but i didn't write the init sequence, just the "change" sequence. and there is a lot of reference code on that one.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 246 seconds]
rohitksingh_work has quit [Ping timeout: 246 seconds]
mauz555 has joined #m-labs
rohitksingh_work has joined #m-labs
mauz555 has quit [Ping timeout: 268 seconds]
<sb0>
of course, changing the system frequency by a tiny bit breaks the sdram...
<rjo>
BTW, someone should check whether the the requirement for the R divider when using 150 MHz f_rtio is a problem for phase determinism.
mauz555 has quit [Ping timeout: 272 seconds]
<rjo>
i have no idea and no evidence regarding the relative bugginess and usability of the adf[45]35[56] vs other plls.
<hartytp>
rjo: thanks. I wasn't aware of those drivers
<hartytp>
which R div requirement do you mean?
<rjo>
ADI has a show case where they phase 4 ADF535* to get 6 dB lower phase noise. might be a nice showcase for Mirny as well.
<hartytp>
rjo: also, in the current design we have the output bias inductors
<rjo>
hartytp: max PFD freq is 125 MHz. with 150 ref input, you'll need divide-by-two or the R divider. that introduces a non deterministic phase. and my understanding is that that phase can't be handled by the "resync" thingy.
<hartytp>
afaict those provide a narrow-band match, improving the output power by 1dB at certain frequencies, but significantly degrading the rf power at lower frequencies
<hartytp>
the internal 50R bias resistor provides better broadband performance. I'd dnp them by default
<rjo>
ack
<hartytp>
rjo: phase always gives me a headache
<hartytp>
however, I think that the R div is fine in this particular case, since the phase indeterminism it introduces is an integer multiple of ref clk cycles
<hartytp>
so, dividing by two and then multiplying by two, one can't tell the difference
<hartytp>
quite different to the VCO output divider case
<hartytp>
but, yes, I plan to check that and a few other things, starting this afternoon
<hartytp>
rjo: hmmm...I still don't see a driver for the adf[45]356
<hartytp>
there is an adf5355 driver
<rjo>
yes. N needs to be even.
<hartytp>
which looks sensible
<hartytp>
but, then, that chip has a different and more sensible init sequence in the data sheet
<rjo>
hartytp: i don't think the 5-6 difference is that big. apart from the noise I didn't see anything.
<rjo>
really?
<hartytp>
that init sequence I understand! So, either there is something odd in the x356 series, or it's just a confusing data sheet
<hartytp>
not a huge diff
<hartytp>
adf4356 recommends: 13, 12, 11, 10, 4, 9, ... , 1, "Ensure that >16 ADC_CLK cycles have elapsed between the write of Register 10 and Register 0."
<sb0>
okay luckily it works with 21 instead of 19...
<hartytp>
"ensure that >16 adc_clk cycles have elapsed between 10 and 0" only makes sense to me if the conversion happens only after reg 10 is written to. but for that to work, I'd expect the reference dividers to have to be configured first, which they aren't
<hartytp>
"yes. N needs to be even." yes. Which is fine for 150MHz since we keep R_div=1 and enable the div/2 prescaler
<GitHub-m-labs>
[artiq] jordens commented on issue #1166: Ack. The difference could still be due to the reduced amount of 125 MHz logic (kernel cpu and associated logic). But this is definitely at the beat. If this is PI, one might naively expect a significant "intermodulation" product on the power supplies at 25 MHz. If it is SI, then we should look at how the 125 MHz clock is getting into the 150 MHz/JESD domain. Could also
mauz555 has joined #m-labs
hartytp has quit [Ping timeout: 256 seconds]
<sb0>
amazingly, the GTH is not acting up with the external BUFG_GT divider
<sb0>
the vivado timing analyzer does, on the other hand
<sb0>
sigh
<lkcl>
whitequark: that's a massive and deeply impressive number of unit tests for nmigen.
<whitequark>
lkcl: not enough.
<whitequark>
rtlil is basically untested
<lkcl>
whitequark: what's needed?
<whitequark>
well the idea was to do cycle by cycle test of rtlil output vs nmigen sim output on real designs
<whitequark>
this would exercise both the converter and verify its correctness
<whitequark>
without having to e.g. match rtlil
<whitequark>
but i've yet to write any vpi stuff
<lkcl>
ok
<lkcl>
rtlil being part of yosys
<whitequark>
rtlil is yosys ir
<lkcl>
cool. ok.
<lkcl>
so... important to verify!
<whitequark>
yeah
<whitequark>
definitely
<whitequark>
well, right now we verify on real designs
<whitequark>
so it's not as bad
<whitequark>
but there have definitely been regressions and omissions because of coverage not being measured for that file
<lkcl>
hmmm hmmmm... what about using cocotb?
<lkcl>
nmigen->rtlil->yosys->verilog->cocotb
<lkcl>
vs
<lkcl>
nmigen->simulation
<whitequark>
what is cocotb
<lkcl>
it's a python wrapper around verilog c-compiled simulations
<whitequark>
ooooh interesting
<whitequark>
thanks
<whitequark>
i will investigate it
<lkcl>
basically, where nmigen has a single-step cycle-accurate simulation mode
<lkcl>
cocotb provides *exactly* the same python-level interface...
<lkcl>
... for *ANY* iverilog-compiled .v file.
<whitequark>
well not exactly the same
<whitequark>
but
<lkcl>
ok ok :)
<whitequark>
nmigen could very easily provide a wrapper
<whitequark>
yeah this looks great
<whitequark>
good thing i haven't tried to write vpi stuff yet.
<lkcl>
the example that got me really deeply impressed was a jpeg implementation of verilog being unit-test compared against the output of python-pil.
m4ssi has quit [Quit: Leaving]
<lkcl>
sorry.. a verilog implementation of a jpeg converter being compared...
<whitequark>
nice
<lkcl>
btw looks like we'll go with nmigen.
<whitequark>
sweet.
<lkcl>
it'll be a biiig frickin core...
<whitequark>
what core?
<lkcl>
128 64-bit FP and 128 64-bit INT registers
<lkcl>
a hybrid CPU, GPU and VPU
<lkcl>
RISC-V, with variable-length vectorisation
<whitequark>
wow
<lkcl>
that can break the register files down into 32-bit, 16-bit and 8-bit elements
<lkcl>
it's taken me 6 weeks to do the architectural review
<lkcl>
the reason for migen is because there's no frickin WAY i'm doing something that complicated in native verilog.
<lkcl>
hilariously, it'll be based on the 55-year-old Cray CDC 6600 :)
<key2>
lkcl: what us the purpose of this design ?
<lkcl>
key2: make a shed-load of money and solve some of the serious ethical issues associated with proprietary processors.
<key2>
doig it for a company ?
<lkcl>
intel management engine, proprietary GPUs, etc.
<lkcl>
key2, as a crowd-funded campaign, entirely libre-licensed
<lkcl>
i maaaay have to compromise on the DDR3/4 PHY
<key2>
yeah but what is it ? an open source project ? a company backed project ?
<lkcl>
libre rather than open. and i'm not a big fan of corporations (see documentary "The Corporation")
<key2>
you understand that even with nmigen such a project is something like 2 years of work
<lkcl>
key2: yes i do. in it for the long haul, for sure.
<hartytp>
rjo: having read more data sheets in this family and looked at how other people program them, I think it's just a mistake in the data sheet
<hartytp>
for the adf4356/5356
<hartytp>
1. The odd requirement to write to reg 4 near the beginning of the init isn't present in the adf5356, so it's either something odd in the adf4356 or more likely a typo
<hartytp>
2. the delays given in the other similar PLL data sheet makes more sense (configure everything, wait, update reg 0). i.e. AFAIC the ADC samples continuously and we just need to wait for one valid sample after writing to all regs
hartytp has quit [Client Quit]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 268 seconds]
<rjo>
hartytp: but writing reg 4 twice (after 10 and again after 5) as per the datasheet will probaby not hurt.
<rjo>
that sequence is in the DS since Rev.0
_whitelogger has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
mauz555 has quit [Remote host closed the connection]
mumptai has joined #m-labs
<acathla>
Is it normal to spend at least 30 min to build xc3sprog (finding the many missing libraries of that old program)?
<acathla>
is there an alternative?
hartytp has joined #m-labs
<hartytp>
rjo: sure, adding that extra register write and leaving a bit of extra padding should ensure it works reliably
<hartytp>
it's just that if there isn't a typo in the data sheet then I can't make sense of what the init sequence is supposed to be doing and that concerns me. Small errors in init sequences can waste huge amounts of time, so I like to feel like I've understood what I'm supposed to be doing as far as possible
<hartytp>
anyway, time to start playing with the hw and see