<GitHub41>
[artiq] whitequark commented on issue #624: Test case: this should result in read of `t` being hoisted out of the inner loop:... https://git.io/vXNOd
<GitHub91>
[artiq] whitequark commented on issue #624: Test case: this should result in read of `t` being hoisted out of the inner loop:... https://git.io/vXNOd
<whitequark>
sb0: where do I put a @deprecated decorator?
<sb0>
what is that for?
<whitequark>
seconds_to_mu
<sb0>
just remove it
<whitequark>
ok
<sb0>
this is what we have major/minor version numbers for
<GitHub178>
[artiq] sbourdeauducq pushed 1 new commit to release-2: https://git.io/vXN3F
patricia has quit [Remote host closed the connection]
<whitequark>
ok, I'm going to implement some sort of locking, because this is aggravating
<sb0>
did that fail because of your flterm?
<whitequark>
as usual...
<sb0>
you can also run your tests on kc705aux
<whitequark>
which ttyUSB is it on?
<sb0>
I don't know, it changed again
<whitequark>
sigh
<sb0>
I tried to flash the serial converters to differentiate them, but the open source tool is crap and one needs windows and the official software for that
<whitequark>
actually, there's another problem with kc705aux, I have to flash...
<whitequark>
sb0: you can differentiate them by path
<sb0>
yes, but that's fragile
<whitequark>
indeed
<sb0>
as for flashing kc705aux, that's not a big issue, you can identify it by serial number
<whitequark>
no, I mean kc705 is almost always flashed with master, so I can just boot and test
<sb0>
it already contains the misoc bios actually, so you may not even need to flash it at all yourself
<whitequark>
doesn't it have the phaser gateware or something?
<sb0>
Robert runs the phaser on it
<sb0>
it does
<sb0>
so you'd be conflicting with Robert's tests, but not the buildbot
<whitequark>
aren't the CSR definitions incompatible with master?
<sb0>
and I use both kc705s when testing drtio.
<sb0>
as far as the bios is concerned, it's fine
<whitequark>
yes, but my software (from master) won't run on gateware (from phaser)
<whitequark>
I think I already hit that earlier
<sb0>
ah. you can just load the master gateware into SRAM
<sb0>
no flashing
<sb0>
that's actually what I do for testing the drtio gateware
<whitequark>
that still requires me to build it
<whitequark>
or to pull it with conda
<whitequark>
this is very annoying.
<whitequark>
hence, my suggestion about locking
<whitequark>
that could be integrated into artiq_devtool, so we could all use that
<sb0>
let's keep things simple.
<sb0>
later there will be kcu105, sayma, etc.
<sb0>
various use cases
<whitequark>
well I don't find your suggestion simple
<sb0>
how is the DDS rewrite going?
<whitequark>
it's not. I'm still wasting time with this bullshit trying to test the seconds_to_mu patch
<whitequark>
amazing
<whitequark>
Assertion "tcp_slowtmr: TIME-WAIT pcb->state == TIME-WAIT" failed at line 1130 in /home/whitequark/Work/artiq-dev/artiq/artiq/runtime/liblwip/../lwip/src/core/tcp.c
<whitequark>
I just crashed lwip
<sb0>
loading master gateware into kc705aux is just wget, tar, and openocd -f board/kc705.cfg -c "ftdi_serial 123456789012; init; pld load 0 bitstream.bit; exit;"
<sb0>
which you can put into a shell script.
<whitequark>
wget from where?
<whitequark>
anaconda.org?
<sb0>
yes
<whitequark>
I can't put that into shell script because I have no way to tell it to give me the latest one
<sb0>
changes that break gateware compatibility are rare, you can keep using the same .bit for a while
<whitequark>
I need to know the build number
<whitequark>
this workflow is already fragile enough to make it more fragile with this gateware version mess
<whitequark>
anyway, I'll try to figure something out
<GitHub135>
[artiq] whitequark pushed 3 new commits to master: https://git.io/vXNl1
<GitHub135>
artiq/master 06ea763 whitequark: artiq_devtool: don't crash on invalid utf-8.
<GitHub135>
artiq/master b562b0f whitequark: artiq_devtool: detect a race condition during connect.
<GitHub135>
artiq/master 009d396 whitequark: Move mu_to_seconds, seconds_to_mu to Core.
<GitHub73>
[artiq] whitequark closed issue #622: seconds_to_mu should take the same in prepare and on the core device https://git.io/vXNlp
<sb0>
mu refers to a mutiplied rtio clock which is used for the high-speed serdes-based ttls
<whitequark>
hm
<whitequark>
we don't have that factor in device_db do we?
<whitequark>
oh we do, core_dds.sysclk
<whitequark>
oh, no, that's another clock
<whitequark>
OK to add another ref_period to core_dds in ddb? or should I do something else?
<sb0>
the DDS device driver can get the core device object and then obtain ref_period from there
<whitequark>
yes, but wouldn't I need also CONFIG_RTIO_FINE_TS_WIDTH?
<whitequark>
I thought 1 mu = 1 core.ref_period
FabM has joined #m-labs
<sb0>
the RTIO clock frequency is DDS sysclk divided by 24 on the 9914
<sb0>
(in device_db: core_dds -> refclk)
<sb0>
this should give you all the info you need
<whitequark>
hm, ok
<sb0>
and I don't think anything else uses CONFIG_RTIO_FINE_TS_WIDTH so that config option can be ditched
<whitequark>
yes, I noticed
kuldeep has joined #m-labs
<whitequark>
sb0: can there ever be different DDSes on the same core device?
<sb0>
no. and we only support one type of DDS now, the ad9914
<whitequark>
then I would like to fold the DDS support functions into "CoreDDS" object
<whitequark>
since the batch manager doesn't and cannot have references to individual channel objects anyway
<whitequark>
we could maybe have different CoreDDS kinds depending on exact type of DDS
<sb0>
mixing DDSes is kinda problematic due to clock synchronization issues, and there's no hardware that does that
<sb0>
ideally those DDS systems should use Sayma cards anyway
<sb0>
but note that we must support systems with two AD9914 buses
<whitequark>
that's not an issue
attie has quit [Quit: leaving]
attie has joined #m-labs
mithro has quit [Ping timeout: 240 seconds]
mithro has joined #m-labs
<whitequark>
sb0: what about CONFIG_RTIO_DDS_CLK_RATIO?
<sb0>
that't the ratio between sysclk and rtio clock. 24/8=3 for 9914.
kuldeep has quit [Ping timeout: 260 seconds]
<sb0>
rjo, what's the phaser2 rtio address width? why do you need the auto reset?
kuldeep has joined #m-labs
<whitequark>
sb0: how do I test DDS functionality?
<sb0>
whitequark, there is no easy way. we have the hardware, but assembling it is painful (plug a card on the backplane, connect 4 different supply voltages, connect and configure the synthnv synthesizer to multiply the fpga reference clock and connect to dds, connect oscilloscope)
<whitequark>
four?!
<sb0>
yes iirc
<whitequark>
who designed this thing?
<sb0>
or 3
<sb0>
but I'm sure there is at least 1.8V, 3.3V and 12V
<whitequark>
also doesn't the FMC already have some voltages?
<sb0>
physicists designed it.
<whitequark>
what does it even need 12V for?
<sb0>
oh and if you plug the DDS card backwards, it will likely smoke from the 12V being applied where it should not
<sb0>
RF output amplifier
<sb0>
you can run it without, but needs a bit of soldering
<whitequark>
amazing
<whitequark>
hrm, I suppose I could compare analyzer traces?
<sb0>
did I tell you I disliked those DDS systems? :)
<whitequark>
I don't recall, but I do see it now
<sb0>
the AD9914 also has a number of silicon bugs
<whitequark>
oh yes, I do remember you hating on the AD IC
<whitequark>
I think that's basically how every conversation about that one went
<whitequark>
why does AD9858 have a charge pump?
<sb0>
the previous DDS system (QC1) used a 9858 which has no silicon bugs as far as I can tell, but the hardware had horrible signal integrity and poor contacts in the connectors
<sb0>
those various problems are part of the reasons for the new artiq hardware we are designing right now...
<sb0>
no idea about the charge pump
<sb0>
if you want to drive a VCO apparently
<sb0>
whitequark, oh and yes, the FMC already has some voltages. and by default the KC705 has 2.5V IOs that need to be brought to 3.3V by reprogramming its power chip if you want to read back the DDS registers safely.
<sb0>
whitequark, so yes, i'd do the testing comparing the rtio analyzer traces.
<rjo>
sb0: 0 for the spline channels, 4 for the configuration channel.
<rjo>
sb0: is that not explained well enough in the commit message?
<sb0>
ah, github only showed me the first line (and no "...") where I was looking
<GitHub100>
[artiq] jordens pushed 3 new commits to phaser2: https://git.io/vXN5R
<GitHub100>
artiq/phaser2 b226dbd Robert Jordens: sawg: unittest data format
<GitHub100>
artiq/phaser2 2f838e3 Robert Jordens: rtio: fix i_data/o_data csr endianess
<GitHub100>
artiq/phaser2 174c4be Robert Jordens: phaser: false paths sys<->{jesd,phy.tx}
<sb0>
rjo, it doesn't say why the address is cleared. writing the address should be fast as it is < 32-bit
<sb0>
where are you saving the address write?
<rjo>
sure. address clearing is not necessary.
<rjo>
sb0: saving?
<sb0>
I mean, the address clearing is saving CPU time as it does not need to rewrite the address under certain conditions
<sb0>
I'm designing some sort of common RTIO interface to be used by the CPU, DMA, RTIO and DRTIO cores
<sb0>
OK to design it without address auto-clear?
<rjo>
sb0: that's not used anywhere. but it seemed correct to me to clear it.
<rjo>
sb0: yes
<rjo>
and we should look very hard into merging address and data.
<rjo>
the only reason we need them split is the replacement thing
<sb0>
yes. are physicists using the replacement functionality?
<rjo>
sb0: i was using it.
<rjo>
sb0: but the physicists might not be aware.
<rjo>
sb0: we do it on the input side of the fifo currently, right?
<rjo>
sb0: can't we do it on the output side with a "replacable" bitmask?
<sb0>
it's done at the input side, in a register that is pushed only when necessary into the async fifo
<sb0>
as replacements in an async fifo are difficult/impossible to do without bugs
<rjo>
sb0: but why did we not do it on the output side with the exact same logic?
<sb0>
because the guard time system is shared with underflow detection
<rjo>
i.e. have a "staging" event replace it with a fifo event if there is one that is allowed to replace it. needs a guard time of exactly 1 cycle afaict.
<sb0>
also how many replacements are supported?
<sb0>
you need to look ahead into the FIFO...
<rjo>
replace as long as there are valid replacement events.
<rjo>
just one entry.
<sb0>
it's not that simple
<rjo>
ah. right.
<rjo>
that could only replace once.
<sb0>
if the timestamp of the event is reached, and there are still replace events, that should be an underflow
<sb0>
but you cannot emit it
<rjo>
let's ask on the mailing list whether there is strong opposition to dropping the replacement feature.
<rjo>
i am ok with removing it.
<sb0>
I wonder if people are using it without knowing it
<rjo>
sb0: nice. one of the fundig projects was ranked first out of 22.
<rjo>
*funding
<sb0>
cool, which one?
<rjo>
the clock. don't know about the other one yet.
<whitequark>
sb0: oh I see, the C implementation doesn't even advance the timeline
<whitequark>
so thats why you need the delay...
<sb0>
whitequark, how do you want it to advance the timeline? you set the frequency "at" at certain point in time
<sb0>
that the register writes take time is an implementation problem (which is solved with the new artiq hardware)
<sb0>
rjo, so the plan for wide-data is a large (1024?) bit CSR and reset-to-zero?
<sb0>
I guess we can disable misoc accessor function generation for CSRs above 64 bits - it would instead just generate a definition for the base address and user code deals with the access manually
<rjo>
sb0: that's what i came up with for the kernel API. yes.
<rjo>
sb0: it does that.
<sb0>
1024 bits?
<sb0>
or less?
<rjo>
i need 160 right now. and for the sample-based channel 8x16 would be enough for now. but i can see dacs that would want 32*16=512
rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo>
512 for maximum data length seems a good value for now. where do we use that value other than in the CSR interface?
<GitHub78>
[artiq] r-srinivas commented on issue #623: @sbourdeauducq any idea why the timing fails? https://git.io/vXA5y
rohitksingh has joined #m-labs
<rjo>
whitequark: can we remove the note about the attributes-not written to (or demote it to debugging level)? it's too sensitive.
laclay has joined #m-labs
<rjo>
whitequark: it nags you until add stuff to kernel_invariants. even if you don't want to because it is verbose and not critical. or because you have one class that you use both sometimes in read, sometimes in write kernels as a non-attribute or as a global.
<whitequark>
rjo: yeah, I was going to add some option to enable it but got distracted
<GitHub162>
[artiq] whitequark pushed 1 new commit to master: https://git.io/vXAFz
<GitHub59>
[artiq] dleibrandt commented on issue #623: @sbourdeauducq, the sideband cooling pulse sequence is up to 1000 pulses. The pulse durations change during the sequence, but the majority are roughly 1 us. Each pulse consists of turning a ttl on and off and setting a dds frequency and amplitude twice (once at the start and once at the end of the pulse; we do this so that we can keep the AOM on but detune the light from the atomic resonance, thus keepi
<cr1901_modern>
ysionneau: https://twitter.com/yannsionneau/status/800709784899096576 I haven't taken a very close look yet, but what I'm guessing happens is that when the cache clr instruction is executed, the 4th NOP is going to be fetch and registered into the A stage at the same time the cache is invalidated.
<cr1901_modern>
I thought it would've been 3 NOPs since 3 pipeline stages between beginning to execute (Adr, Fetch, Decode), but that was an off-by-one error on my part :P