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
rohitksingh has joined #m-labs
mumptai has quit [Quit: Verlassend]
futarisIRCcloud has joined #m-labs
<sb0>
hartytp, ah yes, the ltc chip only goes to 300MHz. I guess that's why it didn't work ...
<sb0>
hartytp, yes, there will be UART messages about the JESD initialization etc.
<sb0>
and ramps at the DAC outputs
<sb0>
and yes, everything should be clocked from the 7043
sb0 has left #m-labs ["Leaving"]
sb0 has joined #m-labs
<sb0>
freenode staff response is basically "go set up your own bot". bah.
attie has quit [Ping timeout: 240 seconds]
<cr1901_modern>
I'd thought about doing that myself, tbh
<cr1901_modern>
search for > $THRESHOLD names in 128 chars, kick the user
<sb0>
the problem with kicking is they keep messaging from outside the channel. this needs a +n mode to prevent that, but it blocks github notifications, unless we set up github so their bots are joining the channel
attie has joined #m-labs
attie has quit [Remote host closed the connection]
attie has joined #m-labs
<whitequark>
sb0: did you do /invite Sigyn ?
<sb0>
yes
<sb0>
<Sigyn> The invitation to #m-labs will be reviewed by staff
<sb0>
then asked in their channel...
<cr1901_modern>
"unless we set up github so their bots are joining the channel" <-- what's wrong with this? (I forgot about Sigyn)
<cr1901_modern>
oh wait
<cr1901_modern>
Github has like 100 bots
<whitequark>
no
<whitequark>
there's an option
<whitequark>
but it has to be set on every of our repos, and it produces a join/quit message every time a notification happens
<whitequark>
hartytp: being able to speak from my own experience now, sayma *is* a trash fire.
<whitequark>
this board can't even be programmed reliably. everything else is secondary.
<whitequark>
whose genius idea was it to use those FTDI chips full of bugs to program it?
<sb0>
whitequark, do you know a good alternative to those ftdi chips?
<sb0>
I'd certainly would love this board not to use anything from FTDI, Xilinx or Intel ...
<whitequark>
sb0: fx2lp plus a shift register?
<sb0>
does this give 3 uart channels + 1 fast (>=5MHz) jtag channel?
<whitequark>
hm, not sure about 3 uarts
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0>
and don't those fx chips require some volatile firmware upload from the PC which typically tends to fail?
<sb0>
it's a good idea on paper but in practice results in udev issues on linux and driver problems on windows
<sb0>
and somebody has to write that firmware + openocd drivers
<sb0>
do those chips still use a 8051? last time I checked, you had to use sdcc to compile firmware for those, which is ridden with bugs
<sb0>
but that was 10 years ago, things may have changed...
<sb0>
so yeah, ftdi is bad, but afaik it's the least bad solution
<davidc__>
the fx firmware upload is pretty reliable, and you can also have em load directly from an attached spi flash
<davidc__>
but most people don't because that costs extra :0
<davidc__>
FWIW, the FTDI chips have been quite reliable in my applications
<davidc__>
if you need help troubleshooting let me know, I've spent too much quality time with using the FTDI chips as JTAG/GPIO, including for loading FPGAs/direct SPI programming
<sb0>
rjo, finally got the xilinx transceiver junk to behave. ethernet link is up on kasli.
<sb0>
but let me check how reproducible that is...
<sb0>
IF-MIB::ifOperStatus.9 = INTEGER: up(1)
<sb0>
and kasli side says the same
<sb0>
it was slightly less annoying than expected, maybe we can do sfp ethernet on sayma if the mmc & co continue to be a pain...
<sb0>
that would be problematic with drtio though (only 1 link=
<sb0>
this, of course, would be a non-issue if xilinx had made all their transceiver compatible, instead of the current clusterfuck of GTP/GTX/GTY/GTZ and god-knows-what, each with their own quirks and bugs
<davidc__>
sb0: think of the poor xilinx fpga consultants, how would they earn a living if things just worked?
<sb0>
davidc__, idk if anyone benefits from that or if it's just groupthink/stupidity...
<sb0>
rjo, is there a bios/bootloader in the kasli flash?
<sb0>
I think that for GbE the best FPGA solution is IOSERDES + external CDR chip
<rjo>
sb0: nice! yes. there is the misoc bootloader at the usual address.
<sb0>
for sayma one would need a 125M GTP clock though...
<sb0>
since routing transceiver clocks from the fabric is a useful feature (at low data rates), xilinx did not implement it
<rjo>
whitequark: just to set the record straight: 1) the whining needs to stop. 2) when you talk about sayma, i hope you are aware that from the users' and my perspective smoltcp was a proper year-long trash fire, in its effect much worse than sayma.
<rjo>
sb0: good that we added that to kasli in the last minute.
<sb0>
oh actually, they did... GTGREFCLK but "not recommended"
<rjo>
sb0: and the upper networking layers are working as well?
<sb0>
compiling ...
<sb0>
but those are relatively deterministic and non-obscure
<rjo>
excellent. then maybe i can move all that hardware to PTB next week. i'll have another set of kasli/urukul from greg soon. and i should get remote access to PTB as well.
<rjo>
oh. the 255 argument limitation. why doesn't verilog have such a "feature"? ;)
<sb0>
board doesn't ping. would have been too easy...
<sb0>
rjo, is the default IP address 192.168.1.50 routed by your network?
<rjo>
no.
<rjo>
for the proper data see last monday or thereabouts.
rqou has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
<sb0>
okay, so far kasli is looking good :)
<sb0>
rjo, do we still have a spare kasli? we might want to migrate the current kc705 unittests onto it at some point
<sb0>
TCP also works fine... not that there's any reason it shouldn't
<rjo>
we never had a spare kasli so far. but we'll get one with the pending batch and iirc even in the current round there will be one.
<rjo>
yes. we should heavily involve kasli in CI.
<rjo>
sb0: awesome. do you want to spread the news? mailinglist and github issues. joe will not be amused.
<sb0>
rjo, will do
<rjo>
sb0: in summary do you consider this approach unlikely to be workable for Sayma (different transciever, no 125 MHz gtp clock, bad news for drtio)?
<sb0>
I think it's likely to work, but it'll be hassle, also the development cycles on sayma are much longer than on kasli due to 1.8v bug, jtag bugs, bootloader bug, and ultrascale vivado bloat
<rjo>
what's the bootloader bug?
<rjo>
the jtag bug is weird on sayma. kasli is the same chip and wired the same afaict. but it doesn't seem to have that issue.
<sb0>
mithro, no idea. haven't looked into either.
<rjo>
sb0: can't you disable the flow control lines with stty or something? flterm should do that as well.
<rjo>
sb0: we
<rjo>
... we'll have what on kasli as well?
<sb0>
probably can. or just not touch the MMC UART. but it seems that other things e.g. USB re-enumeration can put the board into dysfunctional modes that power-cycling does not resolve.
<sb0>
rjo, any bugs in the artiq bootloader.
<rjo>
sb0: yes. my suspicion for those weird state would also be interaction between the mmc and ftdi/uart/usb.
<rjo>
sb0: ack
<sb0>
rjo, _florent_ is arriving in HK tomorrow. any requests for the agenda or do you leave it to me?
<sb0>
we'll have a look into the sayma 1.8V and serwb bugs using his boards
sb0 has quit [Quit: Leaving]
Sigyn has joined #m-labs
<_florent_>
sb0: do you still need edif and mist modes in migen?:
<_florent_>
sb0: context: we are trying with mithro to get litex/migen/misoc closer and this is something i removed from litex since it seems to be obsolete, just want to see if i remove that from migen too or if i reimport that in litex
<mithro>
_florent_: I would like edif mode for reasons.....
<mithro>
_florent_: Didn't realize you had removed it -- I thought sb0 had added it :-P
<mithro>
Oh - sb0 isn't here :-P
<_florent_>
mithro: i'll discuss that with sb0 directly, let's remove that from the pull request for now if you want to pull request to be merged soon
<mithro>
_florent_: I haven't finished testing yet
sb0 has joined #m-labs
<sb0>
_florent_, i think mist can be removed
<_florent_>
mithro: ok for testing, i'm just looking looking at your pull request and trying to see what we can easily merge (lets do that for the first pull request) and what need special care.
<_florent_>
sb0: ok thanks, do you know the state of the edif support, was it already usable?
<sb0>
_florent_, yes worked fine afaict
<sb0>
edif isn't exactly complicated...
<mithro>
_florent_: My goal is to reduce the delta between migen+misoc and litex -- then I plan to figure out how to get stuff in litex either merged upstream or refactored in a way which doesn't need migen/misoc changes and can be provided as an extension
<sb0>
whitequark, sayma boards are back
<_florent_>
mithro: i added some comments to your pull request but that seems fine.
<mithro>
Great, let me look :-)
<mithro>
_florent_: Hrm - did you forget to press "send comments" I think?
<_florent_>
mithro: yes, done sorry
<mithro>
_florent_: I've done that way too many times myself before :-P
<rjo>
sb0: no particular request for the agenda other than focusing on pragmatic work on sayma. i'll try to shift my schedule a bit earlier to maximize overlap with you guys.
<rjo>
mithro: thanks for the consolidation work!
<sb0>
there's also kasli drtio... testing it on sayma is somewhat problematic
<sb0>
having drtio on kasli would 1) make it easier for Oxford to test it 2) make it easier to fix any bug in the generic drtio code and give it more thorough testing, since sayma bugs and vivado bloat no longer get in the way...
<sb0>
(or should I say, "ultrascaled bloat"?)
<rjo>
sb0: i'll play with kasli for a bit.
<_florent_>
sb0: i'll have an artix7 board with me that has sfp, if you want to look at drtio together, we could probably use it (i got drtio working between this board and a kc705 when linerate was 1.25gbps, haven't tested at 3gbps)
<sb0>
rjo, ok
<sb0>
_florent_, we don't have kaslis in HKG yet...
<sb0>
we can use the sayma rtm though
<sb0>
with SATA
<hartytp>
__florent__ can you confirm mux settings you gave me are to use the SMP DAC clock output from the clock mezzanine?
<sb0>
hartytp, iirc they are not, they were for the clock input, which doesn't work due to the LTC frequency limitation.
<sb0>
(SMA clock input on front panel)
<hartytp>
can someone remind me what I need to do then?
<sb0>
hartytp, so there is this GPIO core on the RTM
<sb0>
if you notice errors or think that those signals should be better named, PRs welcome
<hartytp>
how were you using the SMA anyway?
<hartytp>
That doesn't bypass the HMC830
<sb0>
no, I had a different code. the current code in the artiq repos uses the hmc830
<hartytp>
right, but IIRC you said you were putting 1.2GHz into the LTC chip from the SMA. That connector doesn't have any direct path to the HMC7043; it only goes via the HMC830
<_florent_>
sb0: what i was suggesting was to use an artix 7 board that we can connect to sayma drtio to get drtio working on artix7 and then on kasli, we'll see that.
<sb0>
_florent_, okay, we can try that
<rjo>
just fyi: dac_clk_src_sel=0 (600 MHz into dac_clk) is what i played with back in september and that got me a useful clock after the 7043
<rjo>
hartytp: ^^
<sb0>
hartytp, I was using _florent_'s code. might have misunderstood something, it didn't work, and then hmc830 worked (at the beginning) and I focused on that
<sb0>
_florent_, when bypassing the hmc830, where did you connect the input clock?
<hartytp>
rjo ack. What clock source did you use, and where did you connect it?
<_florent_>
sb0: i'm looking at that
<hartytp>
hmmm...this VCO subsystem on the 830 is a bit nasty -- separate SPI bus (different clock) with no register reads
<_florent_>
sb0: to dac_clk_p and dac_clk_n
<sb0>
_florent_, SMP connectors?
<sb0>
for the clock mezzanine?
<hartytp>
_florent_ good
<hartytp>
thanks for confirming
<hartytp>
sb0 do you want to try that on your board?
<_florent_>
sb0; yes probably (don't have the board with me), but i created 2 sma to smp cables for that.
<rjo>
hartytp: that was some random frequency generator in joe's lab. i soldered a sma pigtail to the clock "test" mezzanine. iirc that port was labeled "dac_clk". let me see whether i have photos.
<hartytp>
rjo: that's fine
<hartytp>
that's basically what I plan to do
<hartytp>
thanks
<hartytp>
that's all I need for now
<sb0>
those SMP connectors are hard to find, and expensive
<hartytp>
yes, but the tab sticking out of them is pretty easy to solder a coax pig tail to
<sb0>
yes, but this is generally a bit messy. I wonder if we should revisit alternative for sayma2...
<sb0>
I couldn't even find a single chinese vendor that had SMP. they have all sorts of RF connectors and cables, of pretty good quality and at very good prices, but not SMP...
<rjo>
sb0: buildbot is building misoc 0.8 (no .dev). what is the magic there again?
<sb0>
rjo, there's no magic, just tagging the next commit 0.8.dev
<sb0>
but I find those tags rather inelegant
<rjo>
ah. no. 0.9.dev
<sb0>
er, 0.9.dev yes
<sb0>
but can't we just say that py_!=0 is not a release?
<rjo>
sb0: yes. we can do that. and as long as we don't upload to the main channel that's fine imho.
<rjo>
then we agree to continue without 0.9.dev?
<sb0>
yes
<sb0>
maybe delete the old .dev tags, too
<rjo>
sb0: you have to synchronize that with everyone involved.
<rjo>
sb0: are you sure about sfp.rate_select=1? i don't think it matters for these modules but i'd have thought that 1.25 Gb/s is slow.
<rjo>
sb0: it handles hot-plugging the fiber nicely. don't know about the module itself though.
<sb0>
rjo, not sure
<sb0>
let me check...
<sb0>
rjo, yes it should be 0
<rjo>
sb0: i'll fix it.
<hartytp>
what can cause the spi core to crash during reads?
<hartytp>
I've seen that a few times now on Sayma when playing with the 830
<rjo>
hartytp: what is "crash"?
<hartytp>
not totally sure. hmc830::read not returning
<rjo>
hartytp: could be serwb, could be the spi core, could be the firmware.
<rjo>
hartytp: but certainly it's a bug somewhere.
<rjo>
my hunch would be 1 or 3.
<whitequark>
sb0: sayma is up but still cannot be flashed
<whitequark>
sayma_1
<whitequark>
same for sayma_2 and sayma_3.
rqou has joined #m-labs
<rjo>
bb-m-labs: force build --props=package=openocd conda-all
<bb-m-labs>
build #93 forced
bb-m-labs has quit [Killed (Sigyn (Spam is off topic on freenode.))]
sb0 has quit [K-Lined]
<rjo>
was that self-inflicted?
rqou has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
rqou has joined #m-labs
mquin has joined #m-labs
Sigyn has left #m-labs ["Highly illogical"]
bb-m-labs has joined #m-labs
<whitequark>
what was?
sb0 has joined #m-labs
<sb0>
the k-line
<whitequark>
k-line?
<whitequark>
my client must not have shown it
<sb0>
bb-m-labs was k-lined
<whitequark>
oh
<whitequark>
fuckers
<sb0>
whitequark, are you able to jtag sayma now?
<sb0>
whitequark, bah it's just a simple mistake. and they unbanned it quickly after I contacted them.
<whitequark>
well yes, they're better at it no
<whitequark>
*now
<whitequark>
but they used to ban _whitelogger way too much
<sb0>
if it still fails you can reload the RTM FPGA only a few times. with that workaround serwb eventually works ~half of the time if it failed the first time.
<sb0>
create a file sayma_new.cfg then run the first openocd command in the comments at the top
<bb-m-labs>
I'll give a shout when the build finishes
<bb-m-labs>
build #1930 of artiq is complete: Exception [exception board_lock] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1930 blamelist: whitequark <whitequark@whitequark.org>, Robert Jordens <jordens@gmail.com>
<hartytp>
clock doesn't look great before the HMC7043. Lots of SMPS spurs at multiples of 125kHz. But, -50dBc so probably not enough to cause it to fail to meet timing, I'd guess...
<rjo>
if you want to use the connectors, you can rejigger it to gtp_clk_in2 (dac_refclk 1)
<rjo>
maybe it's better to do that anyway since the connector stub is pretty long.
<rjo>
marmelada: Sébastien is sb0, Florent is _florent_, Tom is hartytp.
<marmelada>
thanks
<rjo>
hartytp: yes. loosing lock does not produce an error iirc. nor does it attempt to relock (yet) iirc.
<hartytp>
marmelada: hi
<marmelada>
hartytp: hey
<marmelada>
did you receive login details to our network? I got an e-mail that your account should be set today
<rjo>
fancy!
<marmelada>
although it's probably not necessary now
<hartytp>
me?
<hartytp>
not yet
<hartytp>
okay...with the external clock via SMPs, all looks fine.
<hartytp>
We do get a ramp, it just dies after some hundreds of ms.
<hartytp>
no idea why
<hartytp>
I'm going to stop looking at Sayma for now unless there is anything else important you want me to do?
<hartytp>
(will pick it back up once Greg's had a look at the 830 on his RTM)
<rjo>
hartytp: i'll browse around in the jesd/clocking code (again) to see whether there is something obviously wrong that might make it loose lock.
<hartytp>
thanks. I assume this is a gateware/firmware issue now: the PRBN tests show that the JESD links are fine from a SI perspective; and, my tests show that the clock is okay.
<rjo>
well. could still be power supply or synchronization issues. and the 830 does not play ball and ergo there is no clock "usually".
<hartytp>
I can scope the supply if that would help?
<sb0>
what PRBS tests?
<hartytp>
waht synchronization issues are you thinking of?
<sb0>
have they been done thoroughly?
<hartytp>
Didn't Greg verify the JESD links using a Xilinx core?
<sb0>
we're still waiting on support for that in the artiq runtime
<hartytp>
I thought he did that before?
<hartytp>
anyway, I don't think there is much that I can usefully do right now. but let me know if that changes
<sb0>
hmm greg's testing of sayma does not seem very deep, e.g. hmc830 not locking
<sb0>
so I'd double-check that
<rjo>
hartytp: imho a quick check of the supplies around the few 100 ms where it works would be useful.
<hartytp>
will do that now
<rjo>
sb0: could you and _florent_ also poke at the PRBS integration if i don't get to it today?
<rjo>
hartytp: on the synchronization i remember seeing some options where it re-asserted sync when the sysref/deviceclock had drifted. i hope we are not being too strict on that right now.
<sb0>
"When such condition occurs, please plug and unplug the OCD header. This will disable and enable the SCANSTA chip. Are you able to talk to the MMC in such state?"
<sb0>
though in my case power-cycling resolved it
<sb0>
MMC is on the last FTDI UART channel, 115200 bps
<rjo>
cjbe: the bidi are nice because it is only one fiber, which is useful for drtio synchronization (see the whiterabbit stuff). they are slightly more expensive than than the plain old two-fiber sfps and they are obviously asymmetric. https://www.ohwr.org/projects/white-rabbit/wiki/SFP
<rjo>
i don't know about the gbic. specifically i don't know whether it is dumb enough. but it would be nice to test one.
<rjo>
also so far i have only played with the "generic" ones. those don't seem to have anything on the i2c port which is a bit annoying. i don't know whether the "branded" ones have something useful on the i2c port (a EUI-48 or link strength data would be nice, you can debug them over i2c, https://github.com/quartiq/kasli-i2c).
mumptai has joined #m-labs
<rjo>
if the branded ones are only different by the existence of a i2c eeprom that says "Cisco" that would be meaningless as well...
<rjo>
in short: the bidi ones work well. i might test a direct attach copper tomorrow and i might buy some cisco branded sfps next time to check their i2c port. i'd also expect the ones with duplex fiber to be fine.
<cjbe>
rjo: thanks. Do you have a switch with an SFP, or do you use a converter? If so, which one?
<cjbe>
rjo: also, do you see any reason the RJ45 SFP would not work? If so I will buy one to try along with the fibre SFPs
<cjbe>
rjo: sorry - I only just saw your later messages. I will buy the same fibre SFPs as you, and buy an RJ45-SFP to test
<rjo>
cjbe: netgear gs110tp
<rjo>
cjbe: i already bought two gbics (rj45 sfp) to test. i'll let you know. they are more expensive than the fiber ones. fs.com has that warehouse in munich now. that's nice.
<rjo>
cjbe: it would be a nice gadget to try one of the SFPs with DOM (direct optical monitoring). i don't know whether the cisco-branded ones have them. let's see.
<bb-m-labs>
build #1935 of artiq is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1935 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<ohsix>
whitequark: did you find out what any eeprom part number might be?
<whitequark>
ohsix: how am I supposed to do that, break my display?
<whitequark>
24C32 is what the model .ini file says, anyway
<whitequark>
but it doesn't work like a 24c32.
Gurty has quit [Ping timeout: 255 seconds]
mumptai has quit [Quit: Verlassend]
Gurty has joined #m-labs
<ohsix>
i thought you may have seen so meone else take it apart or something, 24c32 is specific enough