• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 456 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMS320F28335: Clock requirements

TMS320F28335: Are TMS320F28335PTPS & TMS320F28335PTPQ are 150MHz devices?

DHAIVAT JANI
Prodigy 230 points
Part Number: TMS320F28335

Hi there,

Can you please confirm TMS320F28335PTPS & TMS320F28335PTPQ ARE BOTH 150MHz devices and would work with 150MHz cruystal oscillator.

Best regards,

Dhaivat

  • 0
    TI__Guru* 95315 points

    I presume this is a continuation of your previous post. 

    Yes, as clearly shown in table 3-1 of SPRS439O, both part #s you refer to are 150 MHz devices. 

    By "crystal oscillator", I presume you are referring to a "can" oscillator that is capable of outputting a single-ended clock. Yes, that would work. I presume you have done the cost-benefit analysis of using a 30 MHz crystal (with the on-chip PLL) as opposed to using 150 MHz oscillator, which is likely to be a more expensive solution.

    If you are planning on using the XCLKOUT pin as a clock to your FPGA chip, you may want to buffer the signal with a Schmitt buffer. Or you could implement a /2 divider using a D flip-flop completely bypassing the DSP.

  • 0 in reply to Hareesh Janakiraman
    Prodigy 230 points

    Hi Hareesh,

    Yes, but digikey are showing the PTPS & PTPQ parts as supporting different clocks. So I was just confirming with you. 

    My design is already out and waiting for the prototypes to arrive for testing. I am using XCLKOUT directly into an FPGA as we are planning to use external interface in synchronous mode and the clock becomes very critical. I don't have buffers on XCLKOUT. Do you think it may not work? Use of buffers created a delay of a few nano seconds which was either 1 clock cycle or half clock cycle depending on the frequency used.

    I am not worried about the cost of crystal as reliability is required in our product.

    You can certainly give a feedback to your chip architecture person that I don't like the way they have created XCLKOUT. Its horrible, particularly knowing that it is a DSC and not a DSP. Possibly this is the weakness in design.

  • 0 in reply to DHAIVAT JANI
    TI__Guru* 95315 points

    I don't have buffers on XCLKOUT. Do you think it may not work?

    Buffer will produce a cleaner clock, but some designs may be OK w/o one.

     

    You can certainly give a feedback to your chip architecture person that I don't like the way they have created XCLKOUT. It's horrible,

    Could you please be more specific?

  • 0 in reply to Hareesh Janakiraman
    Prodigy 230 points

    Hi Hareesh, 

    I would certainly give a feedback once I have thoroughly tested my board.

    The feeling I already get is, in the process of making this device cater to lot and provide backward compatibility a fair bit of ambiguity is added in the core design. Some may argue it is a flexibility. But a clock output has to be stable and not go through emotions at boot up. This could potentially lock up devices like FPGA which heavily rely on the clock for execution. I mean I could delay booting of the FPGA device based on a calculated time till XCLKOUT is ready. But that relies on the fact that there is a fixed time delay and not when the XCLKOUT has stabilised. You cant call this implementation truly synchronous.

    With most RAM ICs going out of fashion you can expect an implementation to be more like FPGA rather than old style SRAM ICs. The designer has clearly overlooked this fact.

    Best regards,

    Dhaivat

  • 0 in reply to DHAIVAT JANI
    TI__Guru* 95315 points

    OK. Thank you for the feedback. I will pass it to the concerned team.