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.

AM2434: Using OBSCLK0 or MCU_OBSCLK0 to generate FPGA clock

Part Number: AM2434

We are in the process of designing a automotive test tool using the AM2434 processor.  In a previous version of this product we had a TI 5409A DSP that generated a 12 MHz clock for the FPGA (on BCLKR0).  In the new design we would like to generate a similar clock from the AM2434 processor, but does not have to be exactly 12 MHz.  It looks like OBSCLK0 or MCU_OBSCL0 might be able to generate such a clock.  However, the Reference Manual states that these outputs are for observation purposes to be used for test and debug.  Is there any reason why we cannot used one of these to generate our FPGA clock during normal system operation?

 

  • Hello Yosuf,

    The OBSCLK0 and MCU_OBSCLK0 cannot be used for anything more than observation only- debugging and testing.

    Best Regards,
    Borislav Lazarkov

  • Thank you, Boislav, for your response.  However, we would like to know why these signals can only be used for debug and testing.  What are the limitations for using these signals?  What will happen if we use these signals during normal operation?  

    Thanks,

    Yosuf

  • Hello Yosuf,

    Please refer to the data sheet for the recommended use case for the observation clocks.

    Regards,

    Sreenivasa

  • Thanks, Sreenivasa, for your response. However, I still don't understand why the observation clocks can only be used for test and debug.  Is it because the processor must be placed in a special mode of operation in order to use these observation clocks?  If so, how is that mode enabled.  I spent a lot of time looking through the reference manual and have not been able to figure out the reason for this limitation.

    Thanks,

    Yosuf

  • Hello Yosuf,

    Please refer below:

    Clock Output Configuration

    The clock output is not a default state. The processor needs to be configured to output the clock. 

    You may have to add a pulldown near to the attached device to hold the clock in a known state.

    Clock Characterization:

    These outputs are defined as “observation only” because they were not designed to meet any specific clock performance.  Therefore, TI has no plans to define any performance parameters associated with these outputs.  A customer may find they provide a clock output that is good enough for their system design, but any effort of validating the outputs meet their requirements is their responsibility.  TI doesn’t plan to assist with any effort required to use these clock outputs in a customer’s system design.

    Clock Glitch

    There is a good chance these clock outputs will produce a short cycle when the clock signal function is initially selected via the AM243x pin multiplexing logic because the signal function selection is not synchronized with these clocks.  The AM243x signal functions change asynchronous to these clocks.  This could be a problem for any synchronous logic being clocked from these outputs.  They should consider holding any logic being sourced by these outputs in reset until the clock signal function is selecting and producing full cycles.  

    Can you please help confirm if you have provision to hold the FPGA in reset until the processor power-up, configures the clock and the processor outputs a few clock cycles

    PLL JItter

    We do not define jitter profile on any clock outputs because there are many system specific variables that can impact jitter. Your customer will need to measure clock output jitter of their specific system implementation across all operating conditions expected for the final product.
    The system designer needs to understand the clocking requirements of the attached device, measure the performance of the AM243x clock output in their actual system design while the AM243x device is operating its expected application software across the full range of expected operating conditions, and use this information to determine if the AM243x clock output is good enough for the intended application. There are too many unknowns in someone's system design for TI to be certain the clock has acceptable performance for an attached device.
    PLL N/M jitter is short-term frequency error introduced as the PLL attempts to stay locked to its reference clock, where the multiplication (N) and division (M) ratios directly shape both the magnitude and character of that jitter.
    The jitter profile will change significantly based on PLL configuration and the PLL post-divider (HSDIV) configuration.
    Any frequency multiplication in the PLL chain amplifies input jitter. If OBSCLK0 is sourced from a multiplied PLL output, jitter scales with the multiplication ratio

    Regards,

    Sreenivasa

  • Hello Sreenivasa,

    Thanks for the useful information you have provided.  Let me explain what we have in mind.

    We will have a 25 MHz system clock (MCU_HFOSC0_CLKOUT) driven by MCU_HFOSC0, as shown in Figure 5-491 on page 2745 of the Reference Manual.  This 25 MHz clock will be routed to OBSCLK0 by setting the following fields in CTRLMMR_OBSCLK0_CTRL register, as shown in Figure 5-489 on page 2743.

      Bits  3-0    CLK_SEL  =   8     (select MCU_HFOSCO_CLKOUT)
      Bits 15-8   CLK_DIV   =   0    (divide by 1)

    OBSCLK0 is an alternate function for Pin D17, which will be connected to the FPGA.  Thus, OBSCLK0 will provide a 25 MHz clock to the FPGA.  The FPGA will be held in reset until the processor is powered up and fully configured.  We understand that there may be some timing anomalies during system initialization, but we are hopeful that we can avoid problems by keeping the FPGA in reset until the processor is fully configured.  We would appreciate any suggestions about what we might look out for to catch any potential problems.

    Regards,

    Yosuf

  • Hello Yosuf,

    Thank you.

    I am not sure if you had a chance to review the PLL related information i added in the above thread.

    We would appreciate any suggestions about what we might look out for to catch any potential problems.

    The recommendation is to evaluate the performance on a system level on the suitability.

    As mentioned, before we do not characterize the clock or have any data to share.

    Assuming the connection is point-point, there may not be a need to add any buffer, but you could consider provisioning for a low jitter buffer as required.

    Regards,

    Sreenivasa

  • Hi Sreenivasa,

    I saw your added PLL info after I sent my previous response.  We will look into what you have said and get back to you if we have any further questions.  We appreciate your help in trying to resolve this issue.

    Regards,

    Yosuf

  • Hello Yosuf,

    Thank you.

    As mentioned before, given the challenges with clock output performance, the OBSCLK0 has been names as a clock output for debug or test.

    Looking forward to your analysis. We may not have much to add but will do our best to support.

    We include the specifications for the LVCMOS clock input as part of the data sheet.

    Not sure if the FPGA has clock input requirements specified.

    Regards,

    Sreenivasa

  • Hello Yosuf,

    Refer below an example of the LVCMOS clock specifications.

    Regards,

    Sreenivasa