<GitHub>
conda-recipes/master 922e9f7 whitequark: binutils-or1k-linux: use msys on windows instead of cygwin.
<GitHub58>
[artiq] jbqubit commented on issue #856: Yes, I'm flashing the RTM. I neglected to paste it -- now included below. Booting fails with ```Memory test failed``` or ```serwb bridge initialization failed.``` Once it advances to the point where the failure was "HMC830 lock timeout". ... https://github.com/m-labs/artiq/issues/856#issuecomment-369071921
<whitequark>
bb-m-labs: force build --props=package=binutils-or1k-linux conda-win64
<bb-m-labs>
build #206 forced
<bb-m-labs>
I'll give a shout when the build finishes
<GitHub151>
[artiq] philipkent opened issue #935: Artiq 2.4: Experiment fails to run on Windows because cygwin1.dll can't be found https://github.com/m-labs/artiq/issues/935
<GitHub>
conda-recipes/master 0a107bc whitequark: binutils-or1k-linux: give up and just install texinfo.
<whitequark>
bb-m-labs: force build --props=package=binutils-or1k-linux conda-win64
<bb-m-labs>
build #209 forced
<bb-m-labs>
I'll give a shout when the build finishes
futarisIRCcloud has joined #m-labs
<GitHub27>
[artiq] whitequark closed issue #935: Artiq 2.4: Experiment fails to run on Windows because cygwin1.dll can't be found https://github.com/m-labs/artiq/issues/935
<GitHub179>
[artiq] whitequark reopened issue #935: Artiq 2.4: Experiment fails to run on Windows because cygwin1.dll can't be found https://github.com/m-labs/artiq/issues/935
<whitequark>
bb-m-labs: force build --props=package=binutils-or1k-linux conda-win64
<bb-m-labs>
build #210 forced
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
whitequark: openocd builds were done by cr1901_modern IIRC.
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
<cjbe>
sb0: I only have two Kasli ATM, but am expecting a delivery of qty 3 of the next revision in a few days
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rjo>
whitequark: wouldn't it be better to move the bulk of the knowledge about building and testing artiq from the buildbot into the artiq repository/packages? that would also handle build divergence between branches.
<GitHub118>
[artiq] jordens commented on issue #856: @hartytp Reading undue rudeness into that question is thin-skinned IMHO. Especially in the light of past experience with negligent and careless treatment of advice and instructions and the frustration associated with it. You yourself are confirming that by suggesting that Joe personally may not have been careful. The "rudeness" seems to be already healed by the purely technic
<GitHub13>
[artiq] hartytp commented on issue #856: > @hartytp Reading undue rudeness into that question is thin-skinned IMHO. Especially in the light of past experience with negligent and careless treatment of advice and instructions and the frustration associated with it. You yourself are confirming that by suggesting that Joe personally may not have been careful. The "rudeness" seems to be already healed by the purely technic
<GitHub180>
[artiq] jordens commented on issue #856: @hartytp My points are, that it wasn't meant rude, that I don't consider it rude if I am asked that question by you, that "even" is not an insult (just search through your own usage of it on artiq or sinara), that I wouldn't recommend considering it rude for the etiquette rules you are writing, and that I claim on the basis of the general level of rudeness by Joe that even if
<rjo>
sb0: you have Urukul/v1.1?
<rjo>
the hardware or the cpld code?
<rjo>
whitequark, sb0: ok if i look into the active sayma rtm bistream loading?
<rjo>
... while whitequark works on the buildbot?
<rjo>
sb0: congrats to getting urukul v1.1 ;) i don't have that yet. so you'll need to test the cpld gateware and the hardware.
<marmelada_>
rjo: yes, kasli rc4 is v1.1
<marmelada_>
rjo: i'll release it now
<rjo>
sb0: on the strain relief, my procedure has been: the ones i had made with strain relief were of the non-staggered kind. removing one strain relief makes the staggered and makes them fit 4hp boards. i used the free strain reliefs to convert other cables that didn't have them from non-staggered to staggered.
<rjo>
marmelada_: thanks! pinout as well (can be csv/txt/xlsx as exported from altium)?
<marmelada_>
yup
<rjo>
marmelada_: on the fpga temperature. is it really the LVDS termination that is drawing so much current? the power simulations don't seem to indicate that and are only claiming 3W. or is there something else afoot?
<marmelada_>
it seems that even without termination fpga gets very hot with many channels set as output
<marmelada_>
on my bistreams that I use for tests I set direction using virtual i/o
<rjo>
marmelada_: right. and even without switching activity.
<rjo>
marmelada_: "virtual i/o"?
<marmelada_>
vio, xilinx ip core
<GitHub59>
[sinara] marmeladapk tagged Kasli/v1.1 at 36facd7: https://git.io/vAXm9
<marmelada_>
currently I have no idea why it's running that hot and is it normal
<marmelada_>
but it seems that it should be that way
<marmelada_>
but each channel consumes roughly 8*3,5 mA
<marmelada_>
*each channel consumes roughly 8*3,5 mA
<rjo>
marmelada_: ok. but since you are also seeing it with your gateware, that exludes a bunch of possible issues.
<rjo>
marmelada_: channel == IOBUFTDS?
<marmelada_>
and according to xilinx they have true current sources for lvds
<marmelada_>
channel = eem
<rjo>
then no EEM connected would mean no current. and also that current won't contribute much to the heatload since it is burned elsewhere.
<rjo>
on output.
<marmelada_>
and this power consumption made sense when I had diff_term on and direction set to output
<marmelada_>
however without termination this makes less sense
<rjo>
yes. i have disabled termination on outputs as well.
<marmelada_>
however they still have to set voltage bias to ~1,2V
<rjo>
marmelada_: ack
<marmelada_>
I'll talk about it with greg and one other prof. on wut, but greg didn't seem too surprised about this power consumtion
<marmelada_>
I don't know if we're doing that, but it could be helpful to have all eems be declared as inouts and switch them forcibly to inputs in idle kernel
<rjo>
marmelada_: yeah. i am no expert on that. happy to defer to you and greg.
<rjo>
marmelada_: on experiments, we can't idle outputs unless they are mode2 (failsafe) and the output state is the "correct" one dictated by the experiment.
<marmelada_>
right
hartytp has joined #m-labs
<rjo>
marmelada_: and also in well-run labs the idle kernel should not see much usage. there are always things to measure ;)
<hartytp>
where do the Si5324 satellited
<hartytp>
parameters come from?
<hartytp>
Am I misreading you, or are you running the first loop at 16kHz
<hartytp>
?
attie has quit [Ping timeout: 245 seconds]
attie has joined #m-labs
<marmelada_>
rjo, hartytp, did you have a look on bp adapter?
<hartytp>
did you post pdf?
<hartytp>
will do once I have a pdf
<hartytp>
(thanks again for doing that!)
<marmelada_>
pdf is on its way...
<rjo>
marmelada_: looks good.
<rjo>
marmelada_: thanks.
<rjo>
marmelada_: in case someone definitely wants to mount this as a backplane, would there be anyt difference?
<rjo>
marmelada_: just mounting holes to the rails?
<rjo>
marmelada_, hartytp: i don't want to delay it. just if it can be made backplane-able in let's say <1h work by adding a few more holes. otherwise, let's not bother.
<marmelada_>
right angled bp connector has mounting holes in a different place
<marmelada_>
than straight one
<hartytp>
lgtm
<hartytp>
looks great! Send it off
<marmelada_>
rjo: and I can't add holes for straight ones, they overlap
<rjo>
marmelada_: i don't think those holes are used to attach the connector to the board. at least the vme backplanes don't put screws in there.
<rjo>
marmelada_: ok. don't bother. send it.
<marmelada_>
ok
<rjo>
marmelada_: ... and it can't be made backplane-compatible without the Z-rails because it would be too tall for the non-backplane case.
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.5.0/20171114221957]]
<cjbe>
sb0: The recovered clock (rtio_rx0) on the satellite is well phaselocked to the master si clock output, so the problem must lie with the si somehow
marmelada_ has quit [Ping timeout: 260 seconds]
<cjbe>
touching the si crystal causes the satellite si output phase to sweep by ~100s of cycles in one direction as the crystal warms up, then similar in the other direction after stopping touching it
<rjo>
cjbe: in my measurements i have seen that level of phase noise at < 10 Hz for the si as well. independent of drtio.
marmelada has joined #m-labs
<rjo>
cjbe: i think that's intrinsic to to the design and the loop bw.
<rjo>
cjbe: ah. no. scratch that. the conditions were different.
<rjo>
cjbe: did you get a chance to check urukul again?
rohitksingh_work has quit [Read error: Connection reset by peer]
hartytp has quit [Quit: Page closed]
<cjbe>
rjo: Urukul now works for me - the placement option for the MMCX clock was not correct
<rjo>
cjbe: details? c189/c197?
<rjo>
*c194
hartytp has joined #m-labs
<hartytp>
hmmm I think we either need to turn the Si5324 BW right up
<cjbe>
rjo: someone had changed the placement option from int osc to mmcx, and placed one of those capacitors at 90 degrees off bridging to a neighbouring pad - i.e. very wrong
<hartytp>
or switch to a high-quality TCXO as WR does
<hartytp>
or, just scrap the Si5324 and copy wr
<hartytp>
marmelada which package did you use for the XTAL on Kasli?
<rjo>
cjbe: ack. but the default population is mmcx. there shouldn't be any changes necessary.
<cjbe>
rjo: agreed - I think this was something someone at Oxford did (or someone at WUT during testing)
<rjo>
whitequark: re slave_fpga loading. am i correct that there is only the firmware part and the flashing part missing? plus testing and debugging and documenting?
<cr1901_modern>
rjo: I don't recall doing any openocd builds for conda. That said, today on Windows it should compile "out of the box"
hartytp has quit [Quit: Page closed]
<rjo>
cjbe: ack. the one thing on urukul-ad9910 that wasn't tested yet iirc is the sync circuitry. just to minimize overlap, is that something you plan to do?
<rjo>
cr1901_modern: ok. someone else then.
<cr1901_modern>
Is it currently broken on conda?
FabM has joined #m-labs
<rjo>
cr1901_modern: whitequark mentioned there is something wrong with the build.
<bb-m-labs>
build #2129 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2129 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
rohitksingh has quit [Ping timeout: 252 seconds]
<rjo>
sb0, whitequark: what's better embed the rtm gateware into the firmware or put it into a fixed flash position?
rohitksingh has joined #m-labs
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
<_florent_>
rjo: i'm done with sayma1 & sayma3
hartytp has joined #m-labs
<rjo>
_florent_: thanks.
<hartytp>
Chris Weida and I looking at Si5324
<hartytp>
...
<hartytp>
So: 1. I see what you're doing with the 10k prescaler value
<hartytp>
but, I don't think that's a good solution in terms of phase stability
<hartytp>
we tried clocking Kasli from a 150MHz source and using and running the PFD at 2MHz
<hartytp>
big improvement in the phase stability of the output (measured by using Chris's calibrated finger to change the temperature of the XTAL)
<hartytp>
But, to be honest, this is a limitation of the Si5324 and simillar: it is achieves great flexability by having huge divider values
<hartytp>
that's not good for stability and probably not what we want
<rjo>
does the drtio recovery work with that bandwidth and a shaking fiber?
<hartytp>
well, with the current settings, we see TTL timings drifting by ns when Kasli in rack
<hartytp>
that's not okay for us
<hartytp>
(NB this is not BW, but PFD frequency)
<hartytp>
So, I think this is a genuine problem with the current design
<hartytp>
2. Si5324 only really works well at the highest BW settings, not sure what that means for jitter cleaning
<hartytp>
Some of this will probably be helped by adding a higher quality XO to Kasli to replace the cheap Xtal
<hartytp>
but, in the long run, I think that replacing the SI5324 with a proper PLL chip is the way to go
<hartytp>
have a PLL with TCX0 at 25MHz or something like WR does
sb0 has joined #m-labs
<hartytp>
(either use a PLL IC or the FPGA+DAC+PFD)
<hartytp>
either way, the current solution does not look great from timing stability POV
<sb0>
cjbe, thanks a lot for testing that! yes, let's try increasing the si5324 BW
<hartytp>
it's already at max
<hartytp>
need to increase the PFD frequency not the BW
<hartytp>
I want my TTLs on different Kaslis stable to <<<1ns over standard temperature range
<sb0>
also. in case it also starts doing things like non-deterministic skew, is it a crazy idea to put it into the feedback path of a FPGA MMCM?
<hartytp>
also, afaict, the dividers aren't reset properly so there is no control on the output phase at all
<hartytp>
"Input to output phase skew after an ICAL is not controlled and can assume any value"
<sb0>
yes, that's what I'm proposing to address with the MMCM
<hartytp>
so, seems broken unless I'm missing something
<sb0>
it does sound broken. but we didn't see this problem in practice with the initial testing...
<sb0>
I think the main risk with the MMCM is the slow response time of the Si5324 may make it unstable
<hartytp>
what's the advantage of the Si5324 over a standard PLL with a 25MHz TCXO?
<hartytp>
does the same job but with much better performance
<sb0>
basically: it is on FPGA devkits and can be tested easily. and for better performance people seemed to want a dedicated clock anyway
<hartytp>
sbo: well, we also want to use the recovered clock for things like TDCs, DDSs etc
<hartytp>
using a proper PLL gives good enough performance to do that
<hartytp>
the Si5324 does not seem to
<hartytp>
Well, you can test a PLL by plugging an eval board into Kasli and control it from an EEM
<hartytp>
these things aren't hard to develop
<hartytp>
and, I don't think anyone "wants" to use a dedicated clock
<hartytp>
they will do if they have to
<hartytp>
but, that means a lot more distributing signals over the lab, which was one thing I was keen to avoid with Sinara
<sb0>
yep. I like that PLL solution if that works.
<sb0>
dedicated clocks are also tricky to align, e.g. user-unfriendly
<hartytp>
looks like there was a reason the wr people didn't do this
<hartytp>
but, I do like the idea of a TCVCXO and PLL
<hartytp>
that should work and can be developed using current HW
<sb0>
I did ask a WR developer back then but couldn't get a conclusive answer as to why they rolled their own PLL. and the si5324 seemed to work well enough using the kc705 tests. but yes, this should be revisited.
<sb0>
WR also has a more relaxed timing target iirc (<1ns)
<hartytp>
spoke to jeff over the winter
<hartytp>
wr gives *much* better performance than sepcified
<hartytp>
they were limited by measurements
<hartytp>
it's really good
<sb0>
okay. well, maybe we can recycle their "softpll" design, then
<cjbe>
sb0: can you expand on your MMCM idea? Is it using the rtio_rx clock as MMCM reference, the si output as MMCM FB, and drive the si input from the MMCM output?
rohitksingh has joined #m-labs
balrog_ has joined #m-labs
jaeckel has quit [*.net *.split]
bb-m-labs has quit [*.net *.split]
balrog has quit [*.net *.split]
balrog_ is now known as balrog
jaeckel has joined #m-labs
hartytp has quit [Quit: Page closed]
bb-m-labs has joined #m-labs
<sb0>
cjbe, yes
<whitequark>
rjo: regarding RTM gateware, I don't think it should be embedded into the firmware
<whitequark>
I do not build any gateware typically, and that would break my workflow in a major way, apart from the slowdown caused by increasing the size of the firmware
<whitequark>
rjo: actually, I have some code saved locally that should, in theory, already load the RTM gateware
<whitequark>
it's not upstream because, last time I tried to get it to work, one sayma didn't have the right resistors and the other refused to work due to the 1V8 bug
<whitequark>
so there shouldn't be anything you need to do,as assuming I didn't mess it up
<whitequark>
rjo: I don't think knowledge about building ARTIQ should be moved into the ARTIQ repository.
<whitequark>
buildbot cannot load build steps from the repository (at least not without some horrifying hacks). this means that we will get severely limited in the kind of build steps that can be used
<whitequark>
it's probably more reasonable to duplicate buildsteps next time we do some major change.
<rjo>
whitequark: not loading steps from artiq, maybe just have one big proper build and test step that does it all. instead of having multiple steps in the buildbot.
<whitequark>
I don't think there is anything proper about it
<whitequark>
the logs are already large and annoying to navigate enough
<rjo>
whitequark: i already messed with the slave fpga loading stuff.
<rjo>
whitequark: but could you push your changes so that i can steal the rest?
<sb0>
whitequark, sayma-1 should be fine now, though I'm not sure about the resistors
<rjo>
whitequark: especially if you already have the flashing part.
<rjo>
sb0: resistors?
<whitequark>
sb0: I think sayma-1 is the one that didn't have resistors correct.
<bb-m-labs>
build #2131 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2131 blamelist: Robert Jordens <rj@m-labs.hk>, Robert Jordens <jordens@gmail.com>
<GitHub62>
[artiq] whitequark closed issue #935: Artiq 2.4: Experiment fails to run on Windows because cygwin1.dll can't be found https://github.com/m-labs/artiq/issues/935
mumptai has quit [Remote host closed the connection]