Closed sbourdeauducq closed 6 years ago
It would be interesting to look at the output of the HMC7043 to be sure the clocks are clean. (from the first tests i remember it was not the case, so this could maybe explain the intermittents JESD failures).
The lock is not reliable. @enjoy-digital Do you see it on your board too? @gkasprow Can you do thorough tests of the HMC830 including running the ARTIQ code? Can you have a look at our code and see if you spot anything suspicious? https://github.com/m-labs/artiq/blob/master/artiq/firmware/libboard/hmc830_7043.rs
@jordens iirc @a-shafir found some SPI core bugs. Could that be the source of the problem?
Could be. Try the workaround in his tree with slow clock.
@jbqubit What happens on your boards? @jordens Can you get the bug fixed into MiSoC?
There is a visible on a scope trailing (extra) short pulse on SCK. With a simple shift register as in CPLD it makes all received bits shifted etc. Probably not all SPI IC are sensitive to it because some of them have "de-glitching" filter. CPLD certainly need a very clean clock. HMC830 possible too.
The combinatoric logic is not part of MiSoC but in artic/gateware/spi.py The proper fix needs latches on all SPI signals that will make the spi transaction 1 sysclk longer. In this case will need to adjust the read phase as well or use higher dividers. It can be done more efficient way: generate the "internal CS" one clock in advance so the latch will not delay the SCK. For this the changes in MiSoC the must.
m-labs/misoc#65 is fixed
Did this fix the HMC830 problem?
If not, @sbourdeauducq did you check the obvious things with a scope? e.g.
Note to self, cf https://github.com/m-labs/sinara/issues/216#issuecomment-314706532
Not sure it could be related, but the day i was testing hmc803/hmc7043 i also did this: https://github.com/enjoy-digital/litex/commit/c02de1632b9cbe269aeb76ef248f2a1869bcb7f9 I remember having an issue with Vivado that was not generating the last bit correctly (observed with litescope), issue that was solved by the way i reorganized part of the code.
A scope trace showing the SPI lines would allow us to eliminate this kind of thing very quickly.
@gkasprow I don't have PDFs of the layout. What is the best place to probe the SPI lines for the HMC830?
@sbourdeauducq Remind me, what reference frequency are you using for the HMC830? Is it still 100MHz?
Yes.
What is this for? AFAICT, we're running in HMC mode, so the address register is write only, right?
Why divide the 100MHz reference? The PFD is fully specified to run up to 100MHz.
What is this for? AFAICT, we're running in HMC mode, so the address register is write only, right?
Ignore that comment, mis-read the datasheet.
But, I'm still not sure this is correct. @enjoy-digital AFAICT, this sets the soft-reset to 1. The data sheet says that it must be set to 0 for correct operation, but I don't see where you do that. Am I missing something?
@hartytp: i'm reusing an initialization sequence from the vendor that is adapted for our case. But yes we can try to set it to 0.
@enjoy-digital Good to know. Where exactly did you get the initialisation sequence from? Copied from eval software?
Weida is double checking the loop filter, charge pump settings etc.
@hartytp: yes from the evaluation software (but don't have the software with me). Review of the settings is welcome!
I see. Did that spit the SPI transactions out into a text file? Do you have a copy of the original (don't have access to a windows PC atm to do this myself).
@sbourdeauducq @enjoy-digital Have you verified that transitions high before SCLK on startup (must not be any glitches during turn on)? This is needed for proper SPI operation?
I know @gkasprow checked this using the gateware he was using, but did anyone check for glitches on the gateware you're using?
@hartytp: what happens on startup should be fine since we are able to communicate with it then. But that would be good yes to do a capture of a spi transaction. (to see if we have the same issue i had with vivado). The spi transactions generated by the gui are described in a text file, but i don't have access to it now.
hmm...these chips are just full of undocumented test features. Note in register 6 how you program all the default values, but the data sheet instructs one to program values different to the default in, without any explanation.
CP should be 1.6mA with this loop filter not 2.54mA. Probably not enough to prevent it from locking, but won't help.
I'll create a PR later this eve with some slight modifications to the HMC830 regs.
If that doesn't lock, the next step would be looking on a scope. If you guys can't do that, can you send @gkasprow a binary so that he can, please?
If you guys can't do that, can you send @gkasprow a binary so that he can, please?
This is all packaged on conda with the usual infrastructure.
Why divide the 100MHz reference? The PFD is fully specified to run up to 100MHz.
CP should be 1.6mA with this loop filter not 2.54mA. Probably not enough to prevent it from locking, but won't help.
Then why does the ADI software suggest different values? Is the software buggy, was it used with incorrect input, is the documentation inaccurate, does the software contain workarounds for silicon bugs?
Not sure. PFD has a lower rating if used in frac-N mode IIRC (we're not doing that, but the eval software may be making it easy for us to try).
Anyway, if you change the PFD frequency you change the loop gain, which will cause problems. Did it lock with my PR?
I wouldn't take those recommendations too seriously. They're just giving you something that should work all other things being equal (e.g. loop filter etc). Not a guarantee that it's the best option for you case.
Note also that halving the reference frequency also degrades the phase noise, so we don't want to do it unless forced to.
Made a total of 4 tests (those tests are quite tedious due to slow bitstream loading times, 1V8 bugs, and serwb bugs). Failed twice with your patch, worked twice without.
:(
Well, not so surprising given how ambiguous some parts of that data sheet are. Anyway, the next step is definitely to verify the inputs with a scope. Once that's done we can have a more systematic look at the register values.
The other thing that would be extremely helpful is a scope trace at one of the loop filter components. This would tell us if the PLL has railed (implying an incorrect register setting) or if it's oscillating (something up wit the loop filter).
@gkasprow @jbqubit Can you install ARTIQ, try this on your boards, report whether your HMC830 works well, and do some oscilloscope testing of the kind @hartytp is suggesting? In case of problems with the ARTIQ installation itself, please use the mailing list or open other issues for support, do not post non-HMC830 content here.
I delivered 100MHz to HMC, loaded
0 $0 $20 spi_hmc830 .
0 $1 $2 spi_hmc830 . \ chip enable by SPI
0 $2 $2 spi_hmc830 . \ divider = 2
0 $6 $303CA spi_hmc830 .
0 $5 $1628 spi_hmc830 .
0 $5 $60A0 spi_hmc830 .
0 $5 $E090 spi_hmc830 .
0 $5 $2818 spi_hmc830 .
0 $5 $F88 spi_hmc830 . \ magic word enables PLL out
0 $5 $0 spi_hmc830 .
0 $7 $14d spi_hmc830 .
0 $8 $c1beff spi_hmc830 .
0 $a $2046 spi_hmc830 .
0 $b $7c061 spi_hmc830 .
0 $f $81 spi_hmc830 .
and I get 2.9726GHz at the output The loop voltage is 0.16V
then I load 0 $3 38 spi_hmc830 . 0 $4 3851ec spi_hmc830 . and I get 2.8000 Ghz and the voltage is 2.95V
when I read 0x12H I get
>1 $12 0 spi_hmc830 .
3 ok
which means the PLL is locked.
Yes, sometimes it works here, too. Have you tried with artiq?
not yet
@gkasprow how many bits are you transferring for each of those writes?
I use 32 bits - this is bit-bang SPI but the code is executed really fast. I get a few MHz SPI clock
: spi_hmc830 ( a b c )
rot 31 lshift rot 25 lshift rot 1 lshift or or
1 OUT0_SET_REG io! \ SCK hi
1 2 lshift OUT0_SET_REG io! \ deactivate hmc7043
1 16 lshift OUT0_SET_REG io! \ OE buff active
1 8 lshift OUT0_SET_REG io! \ SEN high
32 0 do
dup
1 31 lshift and
if
1 1 lshift OUT0_SET_REG io!
else
1 1 lshift OUT0_CLR_REG io!
then
1 OUT0_CLR_REG io! \ SCK low
2*
INP0_REG io@ 4 rshift 1 and +
1 OUT0_SET_REG io! \ SCK hi
loop
1 8 lshift OUT0_CLR_REG io! \ SEN low
$ffffff and \ return only valid bits
;
@sbourdeauducq @hartytp What's next step on this? It's one of the last bits to nail down before moving on to next revision of Sayma.
@jbqubit I'll look at it again after Easter.
Next step is to run Greg's code on my board and see if it works.
I ordered the HMC chip long time ago but still didn't get it to my hands. WIll probably get it next week and do a try.
@hartytp As I understand, this is blocked by you not having a board currently? @enjoy-digital do you still need it?
@sbourdeauducq: i already sent the board back to @hartytp 4 days ago, it should arrive soon.
@sbourdeauducq atm there are a few things blocking this from my end:
@hartytp I got the HMC chip on Friday. I will solder it tomorrow and let you know what is going on.
@gkasprow Any update?
It was due to incorrect settings of my 100MHz source. The HMC830 locks fine and then both AD9154 DACs usually work, including JESD lane startup (but intermittenly I get a "bad SYNC" error).