sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
hartytp_ has joined #m-labs
<hartytp_>
sb0: no 1V8 issues so far after a couple of days worth of work and quite a few restarts
<hartytp_>
The only difference I can see from your setup is that I haven't updated the MMC firmware (still using whatever Greg originally loaded onto my board).
<hartytp_>
AFAICT, none of Greg, Joe or I see this issue. So seems to be some issue with your setup or your boards (maybe Greg is right and they are damaged, but that seems a bit unlikely)
<hartytp_>
Ideally, it would be great if you could stick a scope on your supply rails
<hartytp_>
otherwise, it would be good if you could post photos of your setup and part numbers for PSUs etc, then post one of your boards back to Greg for further tests
<hartytp_>
I don't recall seeing any serwb issues, no
<hartytp_>
ack on the si5324, although I do remember you having some frustrations getting that up and running. In any case, it's still quite possible that we're doing something daft with the HMC830
<hartytp_>
As I said on GitHub I still have a few ideas for things to look at on that chip. Otherwise, I have an eval board on order, so will use that as a test setup to validate loop filter, register values, etc
<hartytp_>
Did you try altering the muxes to allow you to use an external clock?
<hartytp_>
Ideally, I'd like to work on the HMC830 on Monday (although, can't work on it all day, as have some other lab stuff to do) but if you have problems getting an external clock to work then I can prioritise looking at that instead
<hartytp_>
just let me know what would be most helpful
hartytp_ has quit [Ping timeout: 260 seconds]
rohitksingh has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
kmehall has quit [Remote host closed the connection]
kmehall has joined #m-labs
<whitequark>
rjo: sb0: wanted to say that I'm renaming the lockfiles and ttyUSB*s to be more consistent for sayma and kc705
<davidc__>
key2: I'd readback the flash after each test
<whitequark>
ohsix: thanks
<ohsix>
it seems to run the same sequence regardless of vendor so it's turning out as a good way to go
<ohsix>
i dunno what i was going to actually tell you to help, but i can talk about what i've done trying to figure it out later :D
futarisIRCcloud has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
mumptai has joined #m-labs
sb0 has quit [Remote host closed the connection]
sb0 has joined #m-labs
<sb0>
hartytp, yes I changed the switches. I'm unsure of my rf generator though (the synthnv firmware is buggy and I don't have something to measure 1.2GHz)
futarisIRCcloud has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<rjo>
whitequark: ack. good. the developer notes are still appLicable?
<sb0>
so... I wanted to compare the simulation results of the xilinx transceiver trash between my code and the wizard-generated one
<sb0>
but of course that could not go well either: the wizard breaks when you disable the 8b10b encoder
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sb0>
also the wizard has this funny option "Extend reset to 3ms" with this tooltip "Use in case of fast programming modes like BPI and PCAP"
<sb0>
i.e. the xilinx trash works differently depending on how fast you load the bistreams
<sb0>
I might be overly optimistic in assuming that the silicon works without bug with 8b10b disabled...
<sb0>
rjo, what happened to the kasli uart?
mumptai has quit [Remote host closed the connection]
<rjo>
sb0: oh. i tried something. let me fix that.
<rjo>
sb0: they are back
<larsc>
sb0: freenode has a bot that k-lines those spambots when it sees them, you can get the bot to join the channel by inviting it the bots name is Sigyn
<rjo>
larsc, sb0: thanks! that would be great.
hartytp_ has joined #m-labs
<hartytp_>
sb0: what happened with your signal generator?
<hartytp_>
so, to be clear, you do want me to look at using an external clock in my setup before doing more work on the HMC830?
<hartytp_>
So, I'll change the mux settings and rebuild the code
<hartytp_>
then inject a 1.2GHz clock into the SMP where the clock mezzanine is supposed to go (IIRC, the LTC chips don't go to 1GHz so I can't use the SMA)
<hartytp_>
I'll 50R terminate the other SMP port
<hartytp_>
__florent__ just to double check, please can you confirm the mux settings required to use the clock mezzanine DAC clock port?
<hartytp_>
then, I'll comment out the HMC830 init code, so that it all starts
<hartytp_>
I'll probe the board to ensure that a 1.2GHz DAC clock is present at the output of the HMC7043 and hence reaching the DACs
<hartytp_>
What will I see if it's working?
<hartytp_>
A message on the UART?
<hartytp_>
and, a ramp on the DAC output, right?
<hartytp_>
anything else I should do/look out for while doing that?
<hartytp_>
...
<hartytp_>
on another note, can you confirm how the clocking works atm?
<hartytp_>
The DACs are clocked from the 7043, a divided-down version is also sent to the FPGA.
<hartytp_>
Is the JSED core/SAWG/ramp generator clocked from this divided-down version of the DAC clock (from the 7043)?
<hartytp_>
i.e. I'm currently only supplying a single 100MHz clock (soon to be 1.2GHz) so want to check I understand how the FPGA clock ends up phase locked to this.