Hi Tom,
The clock should trigger capture of the values on the data lines when they
are stable, so putting the clock edges out of phase with the data
transitions makes sense. Having said that, the controller HDL may or may
not mess with the relative phases of clock and data in the FPGA, so the
correct thing for the ADC chip to do isn't well defined unless you dig into
the interface code. If I remember correctly, the values Dale sent were
empirically determined -- we saw data capture glitches at high clock rates,
indicative of the clock sampling the data lines as they changed, so we
changed the clock phase and the glitches went away. The "correct" thing to
do is probably to have the interface carry out link-training on power up --
put the ADC in a test mode where it outputs a known pattern, and mess with
the clock vs data phases in the FPGA until data capture is reliable. Some
of the other ADCs do this in firmware or software.
Cheers
Jack
On Wed, 18 Apr 2018 at 17:45 Tom Kuiper <kui...@jpl.nasa.gov> wrote:
> This is probably aimed at Jack now but someone else may have an answer to
> the question below.
>
>
> On 04/18/2018 11:33 AM, Gary, Dale E. wrote:
>
> This sounds like the problem we had until Matt Dexter and Dave MacMahon
> determined that some KatADC registers need to be set for correct ADC
> operation. Below is the python code we use to set them:
>
> addr = [0x0000, 0x0001, 0x0002, 0x0003, 0x0009, 0x000A,
> 0x000B, 0x000E, 0x000F]
> val = [0x7FFF, 0xBAFF, 0x007F, 0x807F, 0x03FF, 0x007F,
> 0x807F, 0x00FF, 0x007F]
> #val = [0x7FFF, 0xB2FF, 0x007F, 0x807F, 0x03FF, 0x007F,
> 0x807F, 0x00FF, 0x007F] # 300 MHz
> #if interleaved: val[4] = 0x23FF # Uncomment this line for
> interleaved mode
> for i in range(len(addr)):
> print('Setting ADC register %04Xh to 0x%04X' % (addr[i],
> val[i]))
> # Program both ZDOKs (this could be made smarter if
> needed).
> corr.katadc.spi_write_register(self.fpga, 0, addr[i],
> val[i])
> corr.katadc.spi_write_register(self.fpga, 1, addr[i],
> val[i])
>
> Note that at higher clock speeds, the value of the second register is
> changed (commented third line), as determined by Jack Hickish. If you want
> more detailed information, you will have to consult these folks, but I am
> optimistic that this will help you. This uses the older corr python
> module, but some equivalent command to spi_write_register() must exist in
> the more up-to-date casperfpga module.
>
> So it turns out that these registers are write-only (as per the data sheet
> section 1.4) so I was reluctant to write to them without understanding what
> I was doing. Everything in your bit of code just re-asserts the power-on
> values, except for registers 0x0001 and possiby 0x0009.
> In register 0x0001, bit 11 is turned on which put the clock edges in the
> middle of the data bit cell (90 deg or Q phase). I think that a 1020 MHz
> clock qualifies as a higher clock speed. *So why is it good to put the
> clock edged in the middle of the data bit cell?*
>
> In 0x0009, setting bit 13 enables duel edge sampling which I guess makes
> sense for interleaving but is not relevant since I'm sampling at the clock
> speed.
>
> Thanks and best wishes
>
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>
--
You received this message because you are subscribed to the Google Groups
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.
