08:47 <hartytp> in the runtime, how do I print something to the log without an automatic new line?

08:48 <whitequark> hartytp: no

08:48 <whitequark> you could print something to console with print!

08:50 <hartytp> whitequark: tried that, but "error: cannot find macro `print!` in this scope"

08:51 <hartytp> do I need to import it from board::misoc::Console?

08:51 <whitequark> where are you using print! exactly?

08:51 <whitequark> which part of firmware?

08:51 <hartytp> libboard_artiq/jesd204sync.rs

08:52 <whitequark> hartytp: you need to add #[macro_use] to extern crate board_misoc;

08:52 <whitequark> and replace in Cargo.toml,

08:52 <whitequark> board_misoc = { path = "../libboard_misoc" }

08:52 <whitequark> with

08:52 <whitequark> board_misoc = { path = "../libboard_misoc", features = ["uart_console"] }

09:00 <hartytp> thanks

09:01 <hartytp> hmmm.still can't find print

09:01 <hartytp> so, libboard_artiq/lib.rs already has board_misoc as an extern crate under macro use

09:01 <hartytp> so no change needed there

09:02 <hartytp> I added the uart_console feature to the Cargo, but no help

09:22 <hartytp> whitequark: or, what's the best way of doing the rust equivalent of ",".join(array) where array = [u32; n]?

09:22 <hartytp> where I want to print the result to the UART log

09:24 <hartytp> sb0: success! ... I think...

09:24 <hartytp> ish anyway

09:24 <hartytp> so, using the one-shot mode as a phase detector seems not to work

09:24 <hartytp> but, what does seem to work, ish, is using the following sequence:

09:24 <hartytp> - set the delay line to a calibrated value

09:25 <hartytp> - enable one-shot then monitor mode and arm

09:25 <hartytp> - now, scan the delay of the phase shifter while looking at currerr = currerr_l + ((currerr_h&0x1)<<8)

09:26 <hartytp> here is a sample eye scan at 1.2GHz where I set the initial delay to 255

09:28 <hartytp> https://hastebin.com/udaresabaw.css (it looks ugly because I haven't figured out how to print that properly yet)

09:29 <hartytp> oops, truncated...sec

09:41 <whitequark> hartytp: you need to add #[macro_use] specifically before extern crate board_misoc;

09:41 <whitequark> #[macro_use] only works on the immediately following statement

09:41 <whitequark> like all attributes

09:42 <hartytp> aah, right, sorry I'd forgotten that part of rust syntax

09:42 <hartytp> thanks

09:48 <hartytp> sb0: it may be that with the one-shot mode we have to do something silly like disable the sync machine and reenable it each time to reset some logic

10:34 <hartytp> sb0: whoo! After a few resets of the device, I have got it synchronised at 2.4GHz

12:34 <sb0> hartytp: great!

12:34 <sb0> to RF generation?

12:36 <sb0> hartytp: so you can conclude that it's a problem inside the DAC and there is no point in me doing the test with the hmc7043 anymore?

12:43 <hartytp> sb0: building with sawg now

12:43 <hartytp> sb0: essentially, yes

12:44 <hartytp> I can conclude that the way JESD SC1 is currently handled does not seem to work at higher clock freuencies (although this is a quick test to perform, so I still think it would be worth you reconfirming this observation when you have time)

12:44 <sb0> so what did you change to make it work?

12:44 <hartytp> the way it's broken does not seem to be explainable in terms of SI etc, but is almost certainly some issue with the logic in the DAC (at least, I can't see how it could be anything else, but would welcome ideas)

12:44 <hartytp> https://github.com/sinara-hw/sinara/issues/583#issuecomment-425885954

12:45 <hartytp> afaict the issue comes with realigning the sysref machine

12:45 <sb0> yeah, the ad9154 itself hadn't caused horrid crazy bug so far, it had to happen

12:45 <hartytp> well, at least, operating in one-shot mode seems to give strange issues

12:45 <hartytp> so, I moved to the following process:

12:45 <hartytp> 1. Set the dac phase to a previously calibrated value

12:46 <hartytp> 2. Set the DAC to one-shot then monitor mode

12:46 <hartytp> 3. enable the sync machine

12:46 <hartytp> 4. arm it

12:46 <hartytp> 5. read the phase error registers

12:46 <hartytp> 6. if there is a phase error detected then sync didn't work, so disable the sync engine and repeat steps 3-5

12:47 <hartytp> 7. if that all okay then do positive and negative margins from the calibrated phases without rearming the sync machine

12:47 <hartytp> that seems to work most times

12:47 <hartytp> but sometimes even after 100 cycles of disable and re-enable the sync engine it's still broken

12:48 <hartytp> probably now it boots successfully about 9/10 times, and every time it doesn't the firmware produces a proper error message

12:48 <hartytp> in particular, once it's working, repeated eye scans always seem to give the same result

12:48 <hartytp> so...

12:48 <hartytp> I wouldn't say I have a proper solution yet, but I'm getting pretty close.

12:49 <sb0> what about resetting the whole DAC when it acts up?

12:49 <hartytp> I think you'll definitely need to budget some debugging time to looking into this and getting a proper solution

12:49 <sb0> oh yes, sayma 2.0 will require a huge debugging budget

12:49 <hartytp> repeating my measurements and talking to ADI would be a really good first step (should be relatively quick now I've done a lot of the leg work)

12:49 <hartytp> sb0: I'm pretty sure that would work

12:50 <hartytp> based on the fact that when it plays up `artiq_flash -t sayma start` fixes it

12:50 <sb0> maybe budget some very large amount then reallocates in the unlikely case that things go well

12:50 <hartytp> but, that's a pretty shit solution, isn't it. Do you want to get into multiple cycles of JESD init + PRBS + etc

12:50 <sb0> to e.g. speeding up artiq

12:50 <hartytp> sb0: ack

12:51 <hartytp> anyway, I can't think of anything else to do here. I would definitely talk to adi next, but it seems like this works well enough for me to have a go a looking at rf. If the DAC's not lying to me then it's synchronised

12:52 <hartytp> sb0: fyi, here is a trace showing the current reset working: https://hastebin.com/iserexufoj.sql

12:54 <hartytp> with sync code : https://hastebin.com/juhexeceyo.java

15:32 <hartytp> sb0: can you see anything obviously wrong with this method of generating my SYSREF? https://hastebin.com/uyewujevuh.pl

15:33 <hartytp> or with this experiment https://hastebin.com/ekeguluyiz.rb

15:33 <hartytp> my aim is to generate a SYSREF signal that's synchronised with the RTIO coarse TS, and also to generate a TTL that's synchronised with the coarse ts

15:34 <hartytp> currently, triggering a scope off that TS and looking at my (retimed) SYSREF, I see variations of many 150MHz clock cycles

15:37 <hartytp> in fact, even taking out the retiming, I have two FPGA outputs: one SYSREF and one the TTL from the Kernel. I expect the delay to be constant between resets, but it's not so I'm doing something daft...

15:38 <hartytp> (the delay varies between power cycles)

16:03 <GitHub-m-labs> [artiq] dhslichter commented on issue #1117: @whitequark @jordens @sbourdeauducq it would be very helpful if these sorts of distinctions (subtle issues that can dramatically impact efficiency of operation) could have some brief mentions in the compiler section of the manual. I feel like a number of ARTIQ adopters might get very frustrated by issues like this and #709 and #804, and if it's in the manual as "kno