• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 381 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.

TMS320C6748: C6748 McASP - stop ACLK and AFS between data transmissions

Robert Wolfe
Mastermind 7860 points
Part Number: TMS320C6748

Hello,

I have a design which pairs a C6748 DSP with a FPGA, where the FPGA will shift data to/from the DSP.  The design presently plans for the ACLKR, ACLKX, AFSR, and AFSX to go active only when the data is shifted between them, i.e. stop at the end of a data transfer, and start again the beginning of a new transfer.  Will this strategy work without issues, or could there be frame sync or other errors?

Regards,

Robert

  • 0
    TI__Guru 50170 points

    Hi, Robert,

    Please expect slow response during the holiday season.

    Rex

  • 0
    TI__Guru** 116170 points

    Robert,

    Please indicate in this setup who is supposed to be the clock master that supplies clock to this setup the FPGA or the DSP. With MCASP the clocks need to be present at all times ones the TDM McASP transfers have been initialized. If McASP is master which drives the clocks, it will continue to drive the bit clock and frame sync. 

    McASP integration with Xilunx FPGA is explained in the IEEE paper here:

    https://ieeexplore.ieee.org/abstract/document/4658948

    The same applies to MCBSP and FPGA based designs as well as you can see from the description provided here:

    https://ieeexplore.ieee.org/document/6986220

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Mastermind 7860 points

    Thanks for the reply.  The FPGA will be the master, and will stop the serial clock at the end of each data transfer, and start it again at the beginning of a new transfer.  Can you confirm that this will work, without getting frame sync or other errors?

    Regards,

    Robert

    P.S.  I do not have access to IEEE at this time.  Is it possible to reproduce the relevant design text here?

  • 0 in reply to Robert Wolfe
    TI__Guru** 116170 points

    Robert,

    You can refer to the material from PDF version of the document here

    PDF reference removed as TI can`t post/host IEEE resources in public forum for reference.

    Please note in some of our DSP devices McBSP has a clock stop feature and McBSP in SPI mode can be used for this kind of functionality. If you plan to use McASP then as far as I know the the bit clock need to be present to prevent the McASP to go into error state when no frame sync and clock is received from external source. 

    Regards,

    Rahul 

  • 0 in reply to Rahul Prabhu
    Mastermind 7860 points

    Thanks for the PDF, will review.  However, we are using McASP, McBSP is not available for this design (needed for other purpose)

    Rahul Prabhu said:

    If you plan to use McASP then as far as I know the the bit clock need to be present to prevent the McASP to go into error state when no frame sync and clock is received from external source. 

    Can you be more clear on this please?  Even if FPGA completely stops the frame sync and clock at the end of one data transmission, then restarts them cleanly for the next one, the McASP will go into an error state?  Which error state?  And how is this different than the very first transmission that occurs between the FPGA and DSP, when the clock and frame sync first arrive at the DSP?  I would think it is the same - the DSP had no clock and frame sync before this first transmission, then they come to the DSP from the FPGA for the first one - just like each new transmission in our case, after startup.  

    Robert

  • 0 in reply to Robert Wolfe
    Mastermind 7860 points

    Any further follow-up for this?

    Regards,

    Robert

  • 0 in reply to Robert Wolfe
    TI__Mastermind 27355 points

    Robert,

    I'm sorry for the delay, Rahul is currently out of office. I checked with a McASP design expert on this and this is what they had to say:

    If the bit clock and frame sync are externally generated, this should be fine. There is a bad clock detection capability in the McASP to check for a clock going out of range using an internal clock as a reference. This would be the only ‘error’ flagged and it’s an optional check...not applicable in this use case.

    If:

    a) They were to capture a waveform of the bit clock, frame sync, and data that they feed to McASP

    b) ‘Process’ the waveform by scaling all these signals within each bit clock interval, so that all bit clock intervals are the same duration after scaling

    c) Then…as long as this scaled waveform matches one of the options (formats) in the McASP guide, they will be fine as long as they ignore/disable the bad clock detection.


    Hope this helps. Please let me know if you have any questions.

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    Mastermind 7860 points

    Thanks Sahin, that helped much.  Looks pretty much like we're in the clear on this one.

    Robert