sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
mauz555 has joined #m-labs
<GitHub128> [smoltcp] kevinis opened issue #269: httpclient_example: segment not in receive window https://github.com/m-labs/smoltcp/issues/269
<GitHub142> [smoltcp] whitequark commented on issue #269: That's interesting. Could you try again with 556672f79811a1015c98afb329b8e47242fe3f29? https://github.com/m-labs/smoltcp/issues/269#issuecomment-451036050
<GitHub117> [smoltcp] kevinis commented on issue #269: Just tried 556672f79811a1015c98afb329b8e47242fe3f29 and v0.5.0. Still the same errors. https://github.com/m-labs/smoltcp/issues/269#issuecomment-451038653
<GitHub30> [smoltcp] whitequark commented on issue #269: Interesting. "ACKed unseen segment" looks like a bug, definitely. https://github.com/m-labs/smoltcp/issues/269#issuecomment-451039473
rohitksingh_work has joined #m-labs
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...
hartytp has joined #m-labs
<hartytp> rjo: ack, thanbks
<hartytp> from a quick look at the data sheet, the adf4350 seems to be a much simpler pll
<hartytp> less than half the number of registers for one thing
<hartytp> init/freq update sequence does not depend on the pfd frequency
<hartytp> and it doesn't have the temperature calibration ADC -- it just looses lock if the temperature drops below 0 for some VCO frequencies
<hartytp> also, doesn't have the phase coherent logic, etc
<hartytp> so, the interesting question will be whether the more complex PLLs are actually better or just buggier
mauz555 has joined #m-labs
<hartytp> also, re mirny/sayma: it looks like it's best to drive the ADF[45]356 reference single-ended rather than differential
<rjo> hartytp: a good starting point is probably the linux kernel driver. https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/frequency/adf5355.c
<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> adf5355 recommends: 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 "Wait >16 ADC clock cycles. "
<hartytp> "wait > 16 ADC clock cycles" I understand if the ADC is continually converting
<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] sbourdeauducq commented on issue #1166: Changed the system clock frequency using a patch similar to https://hastebin.com/nepilataje.rb, but with 21 instead of 19 (19 tickles a SDRAM bug), which yields 131.25MHz.... https://github.com/m-labs/artiq/issues/1166#issuecomment-451119051
<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.
<lkcl> simulator's done - spike-sv. took... mmm.... 6 weeks i think.
<lkcl> i forget :)
<key2> mmu ?
<lkcl> applied for a trust/security-related EU Grant of EUR $50k. i'll know by end-february if that comes through
<lkcl> it's to run standard GNU/Linux OSes, so yes, MMU.
<lkcl> SMP cache-coherent, L1/L2, the works.
<lkcl> might cheat there and plumb in to rocketchip tilelink... have to see
<key2> mmh
<lkcl> tilelink's a bitch, so am kiinda reluctant to commit to that
<key2> what fpga you are targetting ?
<lkcl> i have a ZC706, we've been offered a high-end (350 LUT) microsemi FPGA as well
<lkcl> Monsters, basically :)
<lkcl> the target's 800mhz dual-issue for 64-bit ops and quad-issue for 32-bit ops.
<key2> k
<lkcl> not in the FPGA obviously :)
<lkcl> so, whitequark: there *will* be a big design to test nmigen with :)
<key2> I think if nmigen gets tested with a simple 32bit risc-v processor, it'd be already good enough :p
<lkcl> well, we'll have to tackle that along the way, as we absolutely have to pass the riscv-isa-tests.
<lkcl> if that happens, it will have massively increased the confidence that nmigen is good
<whitequark> ahem.
mauz555 has quit [Ping timeout: 245 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub-m-labs> [artiq] sbourdeauducq pushed 7 new commits to master: https://github.com/m-labs/artiq/compare/77126ce5b384...62d7c89c4841
<GitHub-m-labs> artiq/master 175f8b8 Sebastien Bourdeauducq: drtio/gth_ultrascale: generate multiplied RTIO clock from BUFG_GT (#792)
<GitHub-m-labs> artiq/master 4af8fd6 Sebastien Bourdeauducq: ttl_serdes_ultrascale: fix Input
<GitHub-m-labs> artiq/master d6a3172 Sebastien Bourdeauducq: update copyright year
<key2> :p
<key2> lkcl: ok, so let's hope that we'd see soon a riscv with nmigen that passes the isa test :)
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 246 seconds]
<bb-m-labs> build #2173 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2173
<bb-m-labs> build #2174 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2174
<bb-m-labs> build #2780 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2780 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
rohitksingh has joined #m-labs
m4ssi has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 268 seconds]
<GitHub-m-labs> [artiq] drewrisinger opened issue #1225: Docs: Compiling & rounding numpy floats https://github.com/m-labs/artiq/issues/1225
X-Scale has quit [Ping timeout: 244 seconds]
X-Scale has joined #m-labs
m4ssi has quit [Quit: Leaving]
hartytp has joined #m-labs
<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
futarisIRCcloud has joined #m-labs
hartytp has quit [Ping timeout: 256 seconds]
mauz555 has joined #m-labs