01:06 <sb0> rjo, so the same frame number potentially selects a different waveform at each PDQ and each DAC?

01:52 <rjo> sb0: yes. we usually think of the dacs as a single multi-channel bank.

02:17 <sb0> and is there any sort of clock synchronization between the DDS and the PDQ to avoid jitter due to the asynchronous trigger, or do we just live with the jitter?

02:20 <rjo> sb0: in this case live with the jitter. lets say its 2 cycles, 20ns, the analog lowpasses after the dacs are usually >1µs

02:23 <sb0> ok. and are there going to be frame numbers that are NOPs for some DACs (i.e. keep the previous waveform), or does every pulse on frame select a new waveform for every DAC?

02:25 <sb0> of course the new waveform could be programmed to be the same as the old one. but then we have to worry about keeping the phase continuous...

02:26 <rjo> frame selects the frame that is to be played next.

02:26 <rjo> phase?

02:27 <sb0> let's say you have a DAC generating the same low-frequency waveform in frame #1 and #2. when you switch, you may not want that waveform to be disturbed.

02:27 <rjo> sb0: changes in frame do not abort the current waveform.

02:29 <rjo> sb0: frame is only used as the index into the jump table when the current frame is done.

02:30 <sb0> oh, ok. so the frame change resolution is actually pretty low.

02:31 <rjo> sb0: in practice yes. technically it is "one line" which can be as short as a handful of cycles.

02:31 <rjo> but in practice it is tens of µs.

02:31 <rjo> at least

02:32 <rjo> in the old version changes in frame (aka "branch" back then) would abort a waveform. but that is pretty much never the right thing to do.

02:33 <sb0> so, I imagine an API where you register frames as complete sets of waveforms for each DAC

02:33 <sb0> the API gives you a number, which you store, and use in kernel

02:34 <rjo> sb0: a "handle". yes.

02:35 <sb0> we can directly use the frame number...

02:35 <sb0> (that is output on the TTL lines)

02:35 <rjo> sb0: yes

02:38 <rjo> in practice we sometimes have just a single frame (the frame signals always pulled low) and do need the ability to switch between frames. in any case an .append()-like method for frames would be useful that adds a synchronisation pulse and then appends another part of the waveform to the current frame.

02:39 <sb0> "do need the ability to switch between frames"?

02:40 <rjo> s/do/do not/

02:41 <sb0> ok. and what do you mean by append another part of the waveform to the frame?

02:41 <sb0> the API should support building the frame one DAC waveform at a time?

02:42 <rjo> sb0: building the waveform programmatically. like:

02:42 <sb0> eg. x = register_frame(); x.add_waveform("electrode1", ...); x.add_waveform("electrode2", ...);

02:43 <rjo> sb0: bd.pulse(1*us); electrodes.play(waveform_a); bd.pulse(1*us); electrodes.play(waveform_b)

02:43 <rjo> yes

02:43 <sb0> but waveform_a and waveform_b are two different frames, right?

02:43 <rjo> with "electrodes = pdq.get_frame()" or your "register_frame()"

02:44 <rjo> sb0: no. they are different parts of the same waveform: like transport from A to B and then transport from B to C)

02:45 <rjo> sb0: transport = electrodes.get_frame(index=None); bd.pulse(1*us); transport.play(waveform_a); bd.pulse(1*us); transport.play(waveform_b)

02:46 <sb0> so the bd.pulse delays should be automatically added to the waveform?

02:47 <rjo> get_frame() is your register_frame() in this case auto-selects an unused index, emits setting of the frame lines to said index at the right time. pulses trigger line at the beginning of play(waveform_a) and at the beginning of play(waveform_b).

02:47 <sb0> and how does the PDQ know which waveform to play?

02:47 <sb0> since you said it's one frame, and the frame selection lines are always pulled low.

02:47 <rjo> sb0: does not matter in this case. the play() just appends to the frame and inserts a pulse(trigger, 0.1*us) at the right time on the core rtio

02:49 <rjo> sb0: in the case where we did not wire the frame select to the rtio, allow only frame 0, else get an unused frame, set the frame lines to the index and pulse trigger when the waveform should start.

02:50 <sb0> but there are two waveforms: waveform_a and waveform_b

02:50 <sb0> I'd put each in a separate frame

02:51 <rjo> sb0: if we are lazy or ran out of ttl lines, we only have one frame available. then we want the two waveforms end up in the same frame.

02:52 <sb0> and when the trigger line is pulsed, how does the PDQ know which of waveform_a and waveform_b to play then?

02:52 <rjo> sb0: lets define for this discussion a frame to be composed of several waveforms, each waveform to be composed of several lines.

02:52 <rjo> sb0: depends on which line it is currently waiting for a trigger.

02:54 <rjo> sb0: a line is header+data. header has flags to wait for trigger high before and/or after this line.

02:54 <sb0> this line stuff looks rather complicated, more than having N TTL lines for 2**N frames ...

02:54 <rjo> https://github.com/nist-ionstorage/pdq2/blob/master/gateware/dac.py#L16 and L22

02:55 <rjo> sb0: line could also have been called "spline knot".

02:58 <rjo> sb0: each frame needs to consist of multiple smaller things. call them "lines" or "knots". knots is a bit misleading since they can also contain more or less than the spline knot data.

02:59 <sb0> if the frame selection signals are tied low, how do you tell the PDQ to go back to the start of the frame?

02:59 <rjo> sb0: it does so by itself if it sees a line with "end" in its header.

03:00 <rjo> sb0: then it jumps into the jump table.

03:00 <sb0> and this never goes out of sync?

03:01 <sb0> this looks a bit fragile. any glitch on trigger, and the PDQs silently fail until they are reprogrammed.

03:01 <rjo> sb0: it is by as much as the waveform length times how much the crystals have different frequencies relative to our maser.

03:02 <rjo> sb0: it also jumps back to the jump table on ~arm.

03:03 <rjo> well. if a trigger glitches, anything attached to it will do what it is supposed to do on trigger. that is nothing special.

03:03 <sb0> I don't see this arm signal in your platform file

03:03 <rjo> and not specific to the pdqs.

03:04 <sb0> btw, I think it's easier to understand if you split the "comm" IO block into USB and TTL parts

03:04 <rjo> https://github.com/nist-ionstorage/pdq2/blob/master/gateware/comm.py#L157

03:04 <rjo> yep. i wanted to split dac.py as well. but never got around.

03:04 <sb0> ah, so this comes from USB

03:04 <rjo> ye.s

03:05 <rjo> sb0: use DISARM before starting to write to the memories. the old version did not even prevent those kind of collisions.

03:05 <sb0> and how often do we have to touch this "arm" signal?

03:06 <rjo> sb0: as a barrier around changing the memory (uploading the frames).

03:06 <sb0> ok. do you ever change the memory during an experiment?

03:07 <sb0> or do you intend to?

03:08 <rjo> sb0: depends on the definition of "experiment". in https://github.com/m-labs/artiq/blob/master/examples/photon_histogram.py#L28 it would be only ever outside the self.nrepeats loop.

03:09 <rjo> like for transport_destination in range(3, 10): setup_transport_waveforms(); for n in range(self.nrepeats)

03:09 <rjo> ...

03:10 <sb0> ok. and we can either have to core device RPC the setup_transport_waveforms(), or run the outer loop on the host and break out " for n in range(self.nrepeats)...." into a kernel

03:10 <rjo> it might be best if i hack together an example experiment.

03:10 <rjo> exactly.

03:13 <rjo> sb0: i'll put together an example experiment tomorrow.

03:14 <sb0> ok, thanks :)

03:36 <rjo> sb0: you said your office is is downtown. is it also "occupied"?

03:36 <rjo> ;)

03:37 <rjo> s/is is/is/

03:38 <sb0> no, the protests didn't spread out west that much

03:38 <sb0> but it's close

03:39 <rjo> sb0: and the protests are not yet over, are they?

03:40 <sb0> no. still going strong. I checked them out yesterday evening, still roughly the same amount of people, with more tents and banners

03:44 <rjo> hmm. this may (or may not) become a historic moment. i wonder whether it was obvious during the "monday demonstrations" 1989/1990 in germany that they were historic...

03:54 <sb0> most hongkongers seem to call them highly unusual, if not historic

03:56 <sb0> what exactly is the "wait for low trigger after" feature? isn't it equivalent to waiting for the next trigger pulse?

03:57 <sb0> or is the PDQ trigger level sensitive, not edge sensitive?

06:06 <sb0> http://publiclab.org/notes/flatCat/08-29-2014/ramanpi-the-3d-printable-raspberry-pi-raman-spectrometer

13:33 <sb0> this python asyncio stuff is rather messy. eg try unpickling an object from a StreamReader ...

16:58 <stekern> sb0: do you have project where you tested to build the riscv core on s6 to share?

18:26 <rjo> sb0: the "trigger low" comment is outdated. "wait" and "trigger" both wait for the trigger signal high. level sensitive.

18:28 <rjo> sb0: the different meanings (wait before and wait after) become useful if you want to wait before jumping back into the jump table (set frame then trigger, ...) or if you want to have a part of the waveform started on a trigger without having to modify whatever preceded that part.

18:29 <rjo> sb0: i would be interested in having a decent resolution wideband spectrograph with a multimode fiber input. no need for the raman excitation stuff.

18:30 <rjo> sb0: as with most asynchronous frameworks, seeing through and digesting the design philosophy is tedious. what is the difficulty with getting pickles from a streamreader? buffering issues?