<rjo>
by unreliable power connector you mean the connection actually opening up so that it doesn't get any power anymore?
<GitHub196>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vaXhb
<GitHub196>
artiq/master 1c9b8a1 Sebastien Bourdeauducq: test/coredevice/portability/pulses: compute time differences in MU
<sb0>
no idea why it didn't boot this time. i reset the fpga, jtag was fine, and everything worked again
<rjo>
reset by button or by jtag?
<sb0>
by jtag
<GitHub149>
[artiq] sbourdeauducq merged master into release-1: https://git.io/vaXhx
<sb0>
note that I had open a TCP connection to it that was abruptly interrupted when flashing started, so it is possible that the linux network stack got confused or something
<rjo>
sb0: i would have said drop the release-1 branch of we were not minutes (hopefully) away from tagging that 1.0rc1
<rjo>
let's do it anyway. with moore there will be other things to fix as well.
<rjo>
i tested the spi programming rate and that seemed sensible (a few µs). that excludes rt2wb pretty much.
<rjo>
my wild guess would be lots of floating point ops in the dds runtime or the artiq-python layer.
<rjo>
but that's probably what you thought as well.
<sb0>
yes, whitequark have you looked into it?
<sb0>
the runtime doesn't do FP
<rjo>
accidental printfs/core_log/print() etc.
<rjo>
maybe
<rjo>
priority inversion when doing the analyzer pushes and the cpu stuff are unlikely?
<sb0>
what do you mean?
<rjo>
analyzer generating a dram traffic burst and that colliding with the cuncurrent cpu traffic.
<rjo>
but i guess the analyzer would just drop stuff then.
<sb0>
bb-m-labs, force build artiq-kc705-nist_qc1
<bb-m-labs>
build #173 forced
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
bb-m-labs, force build artiq-kc705-nist_qc2
<bb-m-labs>
build #162 forced
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
bb-m-labs, force build artiq-pipistrello-nist_qc1
<bb-m-labs>
build #187 forced
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
rjo, the CPU shouln't do much DRAM traffic when programming the DDS
<sb0>
unless there's some pathological cache behavior
<rjo>
and it would not be prio inversion anyway because the cpu never has to wait for the analyzer, right?
<sb0>
there are two DRAM masters, they are arbitered in a round robin fashion per 512-bit transaction, and there is a lot of bandwidth compared to what the CPU or the analyzer can push
<sb0>
so it shouldn't be that
<sb0>
is there a good document that describes the sizes of CF flanges, including their names (CF35, CF65 etc.)?
<rjo>
aren't the icache and dcache even separate masters?
<rjo>
sb0 not really. especially if you venture into the chinese market territory.
sandeepkr__ has joined #m-labs
<rjo>
i would concentrate on the "standard" dimensions from lesker, vat, etc.
<sb0>
this particular seller (and others) has standard stuff AFAICT. didn't have any problem mixing KF25 flanges from three chinese vendors, MDC, and what I found in the ETH dumpster
<rjo>
i think there is a table of "commonly used cf dimensions" in one of the vacuum bibles.
<rjo>
ime, kf is more standardized by convention than cf
<sb0>
all the CPU masters go to L2, which itself it another DRAM master alongside the analyzer
<sb0>
*is
<sb0>
in fact, if the caches works well, there should be a negligible amount of DRAM traffic from the CPU when the DDS rate test is running
<rjo>
ah. the artiq build of release-1 triggered just the clock build in _master_
<rjo>
hmm. no. it computed the wrong version.
<rjo>
whitequark: i can't figure out why that triggere clock buildl (217) did not see the 1.0rc1 tag and built a package that the artiq unittests could not install because of the version number.
<rjo>
the nist_qc2 package jumped from 959 kB to 1.3 MB...
<rjo>
looks like that's just the second dds bus.
<rjo>
sb0: could you try copying the 1.0rc1 packages over to the main label?
key2 has joined #m-labs
rohitksingh has joined #m-labs
<sb0>
rjo, so timing is met and all?
<rjo>
sb0: pipistrello has been intermittently failing timing for a good year now. i don't take that as critical.
<sb0>
but shouldn't releases meet timing?
<sb0>
I copied the packages
<rjo>
sb0: ack.
<rjo>
sb0: i have tried a bunch of things to make it meet timing but was always limited by the non-reproducibility of the builds with ISE. a fix works ten times and then attempts 11-16 all fail timing. with the same code and the same options.
<rjo>
it always meets timing on vivado.
<rjo>
and we can consider pipistrello a bit of an optional target. feel free to invest time into pipistrello. to me this is good enough.
<rjo>
and overriding the libc rng does not help.
<whitequark>
rjo: re no replacement: ack. i will look into it.
<sb0>
well if it doesn't work, we shouldn't put it in the main channel
<sb0>
and timing wasn't met on this last build
<whitequark>
sb0: re CF35 USB feedthrough: I've asked about it before. apparently they are useful for space. the USB device is inside the temperature controlled and pressurized enclosure, so the usual role of the flange is inverted.
<whitequark>
sb0: rjo: re self.dds0.set being huge: probably that LLVM optimization pipeline problem I talked about.
<sb0>
are USB connectors space-qualified? I thought only rugged stuff that would not fall off with the vibrations/acceleration was acceptable...
<whitequark>
rjo: re triggers: perhaps it did not do git fetch --tags. i can fix that.
_whitelogger has joined #m-labs
<rjo>
sb0: ok. delete it. that's fine. the build before met timing and there were zero changes to the gateware.
<rjo>
if you pressurize a conflat you also _have_ to turn it around.
<whitequark>
you do?
<whitequark>
with KF, I can see that, yes. not with CF
<rjo>
cf windows break, and the gaskets are not flexible enough in cf. every bowing into the wrong direction will open them.
<whitequark>
interesting
<rjo>
maybe you can retighten them but it is not much fun. usually easier to turn it around then.
<rjo>
whitequark: i didn't see where it did the actual git fetch. but the other builders figured it out correctly. also that one on the second try (which was triggered manually).
<whitequark>
hm. odd.
mindrunner has quit [Quit: quit]
mindrunner has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
mindrunner has quit [Quit: quit]
mindrunner has joined #m-labs
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]