• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 20 subscribers
  • Views 4984 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LMK04828: SYSREF / SYNC topology for multiple JESD204B links

Michael Eggert
Prodigy 40 points
Part Number: LMK04828
Other Parts Discussed in Thread: DAC38J84, DAC37J84

Hi,

after reading several datasheet and app notes I still got a few questions about how to generate the right SYSREF and SYNC signals.

We'd like to use subclass 1 for deterministic delays between the ADCs and the DAC in our system:

(Nov. 20: edited image)


During the initialisation of the LMK, the internal dividers are synchronised by toggling the SYNC polarity register bit (SYNC_POL). Following, the divider synchronisation is disabled (SYNC_DISxx). Now, after the device clocks are stable, we initialise the ADCs, the JESD IP cores and the DAC.

By pulling the SYNCb line low, each JESD receiver can cause the corresponding JESD transmitter to send the synchronisation sequence -- but when and how should we request the LMK to generate the SYSREF pulse(s) before?

- For example, we could trigger a SYSREF pulse over SPI, the same way we did during the initialisation and internal synchronisation.
- We even could repeat this regularly and check the devices for re-synchronisation.
- Alternatively, we could also conjunct all SYNCb outputs (from DAC and JESD RX IP cores) into a common SYNCb (to ADCs, JESD TX IP core and LMK) for an automatic SYSREF generation on SYNC request. But in every diagram I've seen the SYSREF is over before SYNCb is pulled low, so maybe we'd need to delay the SYNCb to the ADCs and the JESD TX IP core.

So, is there some common or preferred method for triggering SYSREF generation?

Also, I found there are several modes of SYSREF generation (one pulse, multiple pulses) and acceptance (all pulses, first pulse, second puls, all pulses after the first,...) but I did not find any recommendation which one to use and why.

Best regards,
Michael.

  • 0
    TI__Genius 9920 points

    Hi Michael,
    I didn't think it is correct "But in every diagram I've seen the SYSREF is over before SYNCb is pulled low".

    Regards,

    Shawn

  • 0 in reply to Shawn Han
    Prodigy 40 points

    Hi Shawn,

    oh really, I must have misinterpreted this, thanks a lot!

    So is it a good idea to conjunct every receiver's SYNCb output to the LMK's SYNC input?

    Best regards,

    Michael.

  • 0 in reply to Michael Eggert
    TI__Genius 9920 points

    Hi Michael,
    No. They are different "SYNC" functions.

    1, In LMK04828, SYNC pin is for output clocks (device clocks or SYSREF) synchronization. FPGA or processor could control it. When this pin works as a SYNC request function, SYSREF clock would be output by the request. So SYSREF would get ready earlier for JESD024B link setup . SYREF clock would make RX or TX internal LMFC ready.
    In above block diagram, the net name "SYNCB" from FPGA to LMK04828 would confuse you. It is better to rename it.

    2, In JESD204B link, SYNCB signal is to maintain synchronous internal frame clock in TX and RX side. Your connections in above block diagram are correct.

    Regards,
    Shawn

  • 0 in reply to Shawn Han
    Prodigy 40 points
    Dear Shawn,

    thanks, I edited the image.

    I know there are three different SYNC functions to take place for subclass 1:
    a) synchronize the internal dividers of the clock generating device (LMK). This is done by toggling SYNC_POL during initialization.
    b) synchronize the clock dividers of the ADCs, DAC and JESD IP core by generating a SYSREF pulse.
    c) code group synchronization, triggered by the receiving device pulling SYNCb low.

    The idea was to also request a SYSREF pulse every time a receiver pulls SYNCb low.
    The result would be a SYSREF pulse while SYNCb is low, as shown in the image you posted.

    Best regards,
    Michael.
  • 0 in reply to Michael Eggert
    TI__Genius 9920 points
    Hi Michael,
    See DAC38J84 datasheet. SYSREF (for LMFC) should be ready earlier than SYNC~ for link re -initialization.

    "7.3.8 Multi-Device Synchronization
    In many applications, such as multi antenna systems where the various transmit channels information is
    correlated, it is required that the latency across the link is deterministic and multiple DAC devices are completely
    synchronized such that their outputs are phase aligned. DAC37J84/DAC38J84 achieves the deterministic latency
    using SYSREF (JESD204B Subclass 1).
    SYSREF is generated from the same clock domain as DACCLK, and is sampled at the rising edges of the device
    clock. It can be periodic, single-shot or “gapped” periodic. After having resynchronized its local multiframe clock
    (LMFC) to SYSREF, the DAC will request a link re-initialization via SYNC interface. Processing of the signal on
    the SYSREF input can be enabled and disabled via the SPI interface."

    JESD204B standard also shows "Annex F (informative) Example of device clock and SYSREF generation". FPGA design could refer to the "Logic Device" in the block diagram.

    Regards,
    Shawn
  • 0 in reply to Shawn Han
    Prodigy 40 points

    Hi Shawn,

    Shawn Han said:
    SYSREF (for LMFC) should be ready earlier than SYNC~ for link re -initialization.

    That's what I also thought before ("SYSREF is over before SYNCb is pulled low"). But in the image you showed SYSREF comes while SYNC~ is low, and anyway, SYSREF is usually ignored unless it actually causes a _re_synchronization of the dividers. That's why continuous SYSREF works (not recommended for other reasons).

    Shawn Han said:
    JESD204B standard also shows "Annex F (informative) Example of device clock and SYSREF generation". FPGA design could refer to the "Logic Device" in the block diagram.

    Thanks for the example! According to figure F.1, "JESD204 TX/RX Block" is the Xilinx IP Core here, which does not have any particular "active SYSREF request" output. Instead of that...

    "When SYSREF Required on Re-Sync is set to 1, a SYSREF event is required for the link to re-establish SYNC following a re-sync request.
    - An RX core waits for a SYSREF event to realign the LMFC counter, and only deasserts SYNC on the next LMFC boundary.
    - A TX core waits for a SYSREF event to realign the LMFC counter, and only then begins ILA transmission on an LMFC boundary after SYNC is deasserted."

    https://www.xilinx.com/support/documentation/ip_documentation/jesd204/v6_0/pg066-jesd204.pdf

    ...the Xilinx JESD204 IP core obviously expects SYSREF while or shortly after SYNC is asserted.

    Best regards,

    Michael.

  • 0 in reply to Michael Eggert
    TI__Genius 9920 points
    Hi Michael,
    SYSREF is to generate LMFC, so one pulse on SYSREF also could work. After LMFC had been aligned in chip, SYSREF is no useful. Now we will focus on SYNC~ de-assertion (LOW to HIGH), as you showed, all next actions would be triggered after SYNC~ de-asserted and next LMFC boundary.
    In subclass 1, JESD024B didn't highlight when SYNC~ should be asserted (High to Low).

    Regards,
    Shawn