00:13 <hartytp> zotino seems to work

00:14 <hartytp> well, assuming it doesn't spontaneously die again...

00:14 <hartytp> will leave on over the weekend

00:16 <hartytp> I'm planning to finish up my ARTIQ driver and submit a PR on Monday

00:17 <hartytp> A question first: would you prefer me to create a Zotino class that derives from AD5360? Or, shall I create a new Zotino class and copy-pase from AD5360?

00:18 <hartytp> I slightly prefer to create a new class, as there are some minor nits I have with the old class. (Names aren't consistent with other EEMs, timings are generally very conservative, they overall layout isn't ideal for Zotino etc)

00:18 <hartytp> but, am happy to take your steer

00:18 <hartytp> (I slightly prefer to create a new class and copy/pase rather than inheriting the old code)

00:27 <GitHub-m-labs> [artiq] hartytp opened pull request #963: Add Zotino and Sampler functions to Kasli. Add Zotino to Kasli EEM 7 … (master...kasli_zotino_sampler) https://github.com/m-labs/artiq/pull/963

01:15 <sb000> hartytp, the old class should be fixed. there is enough duplication/inconsistencies in artiq already (sawg vs. wavesynth, ad9914 vs. urukul). we need to clean those up, not introduce more similar issues

01:18 <sb000> if there is a zotino class, it should just be a thin wrapper for leds plus the ad driver

09:55 <Hartytp> sb0: I'm fine with that. Comments...

09:55 <Hartytp> 1. I want to rename a few functions which will break existing user cide

09:56 <Hartytp> Code

09:56 <Hartytp> I don't want to deal with the fallout

09:57 <Hartytp> 2. Zotino is a pcb with a single chip and well defined si properties. The ad5360 aims to support several chips and pcbs.

09:57 <Hartytp> 3. I want to tweak timings to go as fast as possible on Zotino (e.g. no 1us delay before ldac)

09:58 <Hartytp> That may break some setups with bad si

09:58 <Hartytp> 4. I want to add si functions. That's not possible with the ad5360 as the conversion is different for the different chips

09:59 <Hartytp> I can put the si into Zotino but then I need to track gain/offset settings over fund calls.

10:00 <Hartytp> Given all that and how simple the dac driver is, starting afresh with a Zotino class seems cleaner

10:01 <Hartytp> Well I can have the ad5360 store the gain and offset for each channel but not use that info

10:02 <Hartytp> And add the si funcs to Zotino.

10:02 <Hartytp> Anyway, your call. I want to wrap this up on Mon so let me know how you want it done

11:29 <GitHub-m-labs> [artiq] jordens commented on commit c4fa44b: EEM5, EEM4 https://github.com/m-labs/artiq/commit/c4fa44bc62bfe246f5a2270cf9840f547713d9b0#commitcomment-28144857

11:30 <GitHub-m-labs> [artiq] jordens commented on commit c4fa44b: Why that much ififo depth? https://github.com/m-labs/artiq/commit/c4fa44bc62bfe246f5a2270cf9840f547713d9b0#commitcomment-28144859

12:26 <sb0> 1. if it's just renaming functions, that's pretty easy for users to deal with. just add an entry in RELEASE_NOTES saying that X should be renamed to X in their code.

12:26 <sb0> *to Y

12:27 <sb0> 2. yes, so ad5360 should also aim to support zotino

12:27 <sb0> 3. is it hard to parameterize the relevant ad5360 timings?

12:27 <sb0> 4. I think those si functions would naturally fit into the wrapper class

12:28 <sb0> the ad5326 class shouldn't store anything, but the wrapper class (which may use inheritance) can

12:30 <sb0> I can write this if you want, but the zotino I have burned, so I cannot test

12:32 <Hartytp> sb0: if you want to write then go for it but I want this asap so happy to write myself if that's quicker

12:33 <Hartytp> Happy to test here either way

12:34 <Hartytp> Timings should be close to dac datasheet values to optimize t

12:34 <Hartytp> Throughput

12:35 <sb0> Hartytp, I'm not too sure about what you want (especially the renaming functions part) so maybe you can write a draft and I can complete/clean it up/integrate it

12:36 <Hartytp> Bot much just make it more like novo

12:36 <Hartytp> E.g. functions in mu should have suffix

12:37 <sb0> ah, yes

12:37 <sb0> yes, for this kind of fix this should just be done, with an entry in RELEASE_NOTES

12:38 <Hartytp> If you want delay params for boards with si issues I'm fine with that but the interface starts to get a bit cluttered for my liking

12:38 <sb0> the general policy for breaking changes is it's OK to introduce them between major releases (X.0 -> X+1.0) but they should be listed in RELEASE_NOTES

12:38 <Hartytp> Similarly if the wrapper has to overload all setters to store gains and offset then we have a lot of extra code

12:39 <Hartytp> The dac code is basically trivial so id personally prefer to replicate it if that

12:39 <Hartytp> Gives a cleaner outcome

12:40 <Hartytp> I don't feel strongly

12:40 <Hartytp> Will push an outline to my fork tomorrow

12:41 <Hartytp> rjo: thanks for review apologies for typos will check more carefully next time before pushing

12:41 <Hartytp> Ififo should be ofifo

12:42 <Hartytp> Don't care about the depth just copied from elsewhere feel free to change

12:42 <Hartytp> Will fix typos tomorrow

15:30 <Hartytp> sbo: let me write a first draft of Zotino driver; I think I know what I want and it won't take long. Once that's done you can make any changes you want to it while I'm testing the hw

15:31 <Hartytp> In the meantime can you give _florent_ a hand with the sdram? I still worry that with one person on this part time it has the potential to drag on

15:31 <Hartytp> And keep causing us all a headache