Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

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.

McBSP driving DAC8831 with 16 clk wide frame pulse

Other Parts Discussed in Thread: ADS8363, DAC8831

Hi,

I'm developing a system based on C6418 at 600Mhz.
The system processes 4 RX channels at 187500 16-bit samples per second each coming from one ADS8363 on McBsp0 driven at 15MHz clock (CPU clock / 8 / 5), each channel  sampling rate of 15M / 20 / 4 = 187500 sps.
The system also generate a single TX channel on McBSP1 through a DAC8831 and, for DSP code being homogeneous in TX and RX, I'd like to use exactly the same 187500 sps sampling rate.
The only way I can obtain this is to drive the 8831 at 3,750 Mhz (CPU clock / 8 / 5 / 4) and sending a sample every 20 clk.
Looking at DAC8831 specs I see that i could obtain this by generating a FS/CS sync active low, 16 clk width (FWID = 16 -1 = 15), 20 clk period (FPER = 20 - 1 = 19), and data delay 0.
The Mcbsp manual (chapter 4.4.1) suggest that FWID be programmed to a value less than XWDLEN (that is 16-bit).
Does this literally mean that if FWID = 15 < 16 this can be done (i.e. a frame sync pulse of the same width of the data word)?
Or is it be intended that the sync pulse width must be less than the word duration, and in this case this can't be done?
Thanks for any help.
Alberto
  • Hi Alberto,

    Figure 9 in the manual assumes your data will be from leading edge to leading edge of the Frame Sync.  If you set the port up with an active low FSx, with FWID set to 16 (0x0F) and FPER at 20 (0x13), with no data delay - the MSB to the DAC8831 will be available with the first clock after the falling edge of FSx.  The LSB will be present at the last clock just before the FS rising edge.  FS will be high for four clocks between transmissions.  Imagine the timing diagram of Figure 1 in the DAC8831 data sheet with four clock cycles under /CS high to get a better understand of what to expect.

  • Hi Tom, thanks for your interest.

    Only a little thing for my understanding. The FWID value you indicate (0x0F = 15) is ok, but the FPER value should be 19 (0x13) because the frame period should be FPER+1 (or I'm misunderstanding the specs?)

    Apart from the above, definitely using a 20 clk real period and a 16 clk wide active low sync, with data delay 0, 8831 should work fine for my need, I understand.

    But the other doubt I have (and pheraphs I'm overzealous) is whether is it possible for MCBSP to generate a 16 clk wide sync, due to the sync width limit written in the McBSP specs which say "FWID should be less than WDLEN", where in this case WDLEN = 16.

    So I wonder whether FPER = 15 satisfies this condition (because 15 < 16) or I misunderstand the McBSP specs which, insted, mean that the real sync width in clocks should be less than the word length in clocks.

    Excuse me if you already answered me about this point and I didn't  understand.

    Alberto

  • Hi Alberto,

    You are right, I forgot to 'subtract 1' so yes, 0x13 is correct for the FPER setting for 20 clock cycles.  I'm going from the C6000 McBSP Users Guide (SPRU580) and I don't see a restriction on the length of FWID with respect to WDLEN.  Can you point me to a specific page number?

  • Hi Tom,

    the document is the McBSP reference spru580g, dec 2005, chapter 4.4.1, page 23.

    "it is recommended that FWID be programmed to a value less than (R/X)WDLEN1/2"

  • Hi Alberto,

    Sorry for the delay in getting back to you.  I was looking at revision C of that document so I did not see that entry.  When running in standard McBSP mode, I don't think there is any issue but I'll try to get some clarification on that point from the C6000 applications guys. 

  • Thanks Tom for your help,

    I'll wait about that.

    Alberto

  • Hi Alberto,

    I'm still waiting for a definitive answer from my colleges - in the meantime though, have you considered using 'clock stop' mode on this project?