sb0 changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs :: Due to spam bots, only registered users can talk. See: https://freenode.net/kb/answer/registration
pdx has joined #m-labs
pdx has quit [Read error: Connection reset by peer]
hiredman5 has joined #m-labs
hiredman5 has quit [Remote host closed the connection]
Kottizen10 has joined #m-labs
Kottizen10 has quit [Remote host closed the connection]
nrs_3 has joined #m-labs
nrs_3 has quit [Remote host closed the connection]
justaguy13 has joined #m-labs
justaguy13 has quit [Remote host closed the connection]
fitzsim has quit [Remote host closed the connection]
freddy has joined #m-labs
freddy has quit [Remote host closed the connection]
rohitksingh_work has joined #m-labs
th3voic329 has joined #m-labs
th3voic329 has quit [Remote host closed the connection]
pasasap23 has joined #m-labs
pasasap23 has quit [Remote host closed the connection]
doodadjs has joined #m-labs
doodadjs has quit [Remote host closed the connection]
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined #m-labs
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
PoueT18 has joined #m-labs
patriciadomin0 has joined #m-labs
patriciadomin0 has quit [Remote host closed the connection]
PoueT18 has quit [Ping timeout: 260 seconds]
mauz555 has joined #m-labs
badgerops20 has joined #m-labs
mauz555 has quit [Remote host closed the connection]
badgerops20 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
BillSmith4lyfe has joined #m-labs
BillSmith4lyfe has quit [Remote host closed the connection]
<hartytp> in the runtime, how do I print something to the log without an automatic new line?
<whitequark> hartytp: no
<whitequark> you could print something to console with print!
<hartytp> whitequark: tried that, but "error: cannot find macro `print!` in this scope"
<hartytp> do I need to import it from board::misoc::Console?
<whitequark> where are you using print! exactly?
<whitequark> which part of firmware?
<hartytp> libboard_artiq/jesd204sync.rs
<whitequark> hartytp: you need to add #[macro_use] to extern crate board_misoc;
<whitequark> and replace in Cargo.toml,
<whitequark> board_misoc = { path = "../libboard_misoc" }
<whitequark> with
<whitequark> board_misoc = { path = "../libboard_misoc", features = ["uart_console"] }
mauz555_ has joined #m-labs
<hartytp> thanks
<hartytp> hmmm.still can't find print
<hartytp> so, libboard_artiq/lib.rs already has board_misoc as an extern crate under macro use
<hartytp> so no change needed there
<hartytp> I added the uart_console feature to the Cargo, but no help
noodleTR has joined #m-labs
mauz555 has quit [Ping timeout: 250 seconds]
noodleTR has quit [Remote host closed the connection]
<hartytp> whitequark: or, what's the best way of doing the rust equivalent of ",".join(array) where array = [u32; n]?
<hartytp> where I want to print the result to the UART log
<hartytp> sb0: success! ... I think...
<hartytp> ish anyway
<hartytp> so, using the one-shot mode as a phase detector seems not to work
<hartytp> but, what does seem to work, ish, is using the following sequence:
<hartytp> - set the delay line to a calibrated value
<hartytp> - enable one-shot then monitor mode and arm
<hartytp> - now, scan the delay of the phase shifter while looking at currerr = currerr_l + ((currerr_h&0x1)<<8)
<hartytp> here is a sample eye scan at 1.2GHz where I set the initial delay to 255
<hartytp> https://hastebin.com/udaresabaw.css (it looks ugly because I haven't figured out how to print that properly yet)
<hartytp> oops, truncated...sec
mumptai has joined #m-labs
<whitequark> hartytp: you need to add #[macro_use] specifically before extern crate board_misoc;
<whitequark> #[macro_use] only works on the immediately following statement
<whitequark> like all attributes
<hartytp> aah, right, sorry I'd forgotten that part of rust syntax
<hartytp> thanks
<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
Teppich has joined #m-labs
Teppich has quit [Remote host closed the connection]
<hartytp> sb0: whoo! After a few resets of the device, I have got it synchronised at 2.4GHz
mauz555_ has quit [Remote host closed the connection]
kudowins_IM has joined #m-labs
kudowins_IM has quit [Ping timeout: 268 seconds]
ekiIn has joined #m-labs
zacmpsHf has joined #m-labs
zacmpsHf has quit [Remote host closed the connection]
ekiIn has quit [Remote host closed the connection]
mauz555 has joined #m-labs
MrHydean has joined #m-labs
cr1901_modern has quit [Ping timeout: 252 seconds]
MrHydean has quit [Remote host closed the connection]
<sb0> hartytp: great!
<sb0> to RF generation?
rohitksingh_work has quit [Read error: Connection reset by peer]
<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?
cr1901_modern has joined #m-labs
<hartytp> sb0: building with sawg now
<hartytp> sb0: essentially, yes
<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)
<sb0> so what did you change to make it work?
<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)
<hartytp> afaict the issue comes with realigning the sysref machine
<sb0> yeah, the ad9154 itself hadn't caused horrid crazy bug so far, it had to happen
<hartytp> well, at least, operating in one-shot mode seems to give strange issues
<hartytp> so, I moved to the following process:
<hartytp> 1. Set the dac phase to a previously calibrated value
<hartytp> 2. Set the DAC to one-shot then monitor mode
<hartytp> 3. enable the sync machine
<hartytp> 4. arm it
<hartytp> 5. read the phase error registers
<hartytp> 6. if there is a phase error detected then sync didn't work, so disable the sync engine and repeat steps 3-5
<hartytp> 7. if that all okay then do positive and negative margins from the calibrated phases without rearming the sync machine
<hartytp> that seems to work most times
<hartytp> but sometimes even after 100 cycles of disable and re-enable the sync engine it's still broken
<hartytp> probably now it boots successfully about 9/10 times, and every time it doesn't the firmware produces a proper error message
<hartytp> in particular, once it's working, repeated eye scans always seem to give the same result
<hartytp> so...
<hartytp> I wouldn't say I have a proper solution yet, but I'm getting pretty close.
<sb0> what about resetting the whole DAC when it acts up?
<hartytp> I think you'll definitely need to budget some debugging time to looking into this and getting a proper solution
<sb0> oh yes, sayma 2.0 will require a huge debugging budget
<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)
<hartytp> sb0: I'm pretty sure that would work
<hartytp> based on the fact that when it plays up `artiq_flash -t sayma start` fixes it
<sb0> maybe budget some very large amount then reallocates in the unlikely case that things go well
<hartytp> but, that's a pretty shit solution, isn't it. Do you want to get into multiple cycles of JESD init + PRBS + etc
<sb0> to e.g. speeding up artiq
<hartytp> sb0: ack
<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
<hartytp> sb0: fyi, here is a trace showing the current reset working: https://hastebin.com/iserexufoj.sql
<hartytp> with sync code : https://hastebin.com/juhexeceyo.java
mauz555 has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
mauz555 has joined #m-labs
mauz555 has quit []
mauz555 has joined #m-labs
mauz555 has quit [Read error: Connection reset by peer]
rohitksingh has quit [Quit: Leaving.]
m4ssi has joined #m-labs
upbmP has joined #m-labs
upbmP has quit [Remote host closed the connection]
mumptai has quit [Quit: Verlassend]
hartytp has quit [Ping timeout: 256 seconds]
maze has joined #m-labs
maze has quit [Remote host closed the connection]
hartytp has joined #m-labs
<hartytp> sb0: can you see anything obviously wrong with this method of generating my SYSREF? https://hastebin.com/uyewujevuh.pl
<hartytp> or with this experiment https://hastebin.com/ekeguluyiz.rb
<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
<hartytp> currently, triggering a scope off that TS and looking at my (retimed) SYSREF, I see variations of many 150MHz clock cycles
<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...
<hartytp> (the delay varies between power cycles)
joutyyd has joined #m-labs
joutyyd has quit [K-Lined]
movedx_ has joined #m-labs
rohitksingh has joined #m-labs
<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
movedx_ has quit [Ping timeout: 268 seconds]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
csviu_ has joined #m-labs
csviu_ has quit [Ping timeout: 252 seconds]
tyteen4a03rD has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
tyteen4a03rD has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
m4ssi has quit [Ping timeout: 252 seconds]
ScallyJV has joined #m-labs
ScallyJV has quit [Remote host closed the connection]
lazy_bumFU has joined #m-labs
lazy_bumFU has quit [Ping timeout: 252 seconds]
svth_ has joined #m-labs
svth_ has quit [Read error: Connection reset by peer]
jennis_ has joined #m-labs
jennis_ has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit []
mauz555 has joined #m-labs
mauz555 has quit [Read error: Connection reset by peer]
mauz555 has joined #m-labs
mauz555 has quit []
rnd_gen has joined #m-labs
berglh has joined #m-labs
rnd_gen has quit [Remote host closed the connection]
berglh has quit [Remote host closed the connection]
azwieg103 has joined #m-labs
azwieg103 has quit [Remote host closed the connection]
n9nesum has joined #m-labs
n9nesum has quit [Remote host closed the connection]
MajiirOB has joined #m-labs
MajiirOB has quit [Remote host closed the connection]
chriscpO has joined #m-labs
chriscpO has quit [K-Lined]
dl9pfwv has joined #m-labs
dl9pfwv has quit [Remote host closed the connection]
fo0jg has joined #m-labs
fo0jg has quit [K-Lined]