AM2732-Q1: Using the McASP to talk to an ADC and DAC controller at 960kS/s

Hello Corey, 

Can you please share the ADC and DAC that you are using? 960kS/s is not a standard audio clock rate and so I would like to get more details.

Typically, the framesync frequency would be a multiple of 48kHz and would not exceed 192 kHz in most audio applications.

Can you share more details on the expected audio frame format?

• Is the audio frame TDM, I2S, or other format? If TDM, how many slots of audio are you expecting per frame?
  • You mention that you only need one slot, is this expected? it is atypical for audio applications to send only one slot of audio in a frame. 
• The audio bit clock and framesync frequencies will be a reflection of the expected frame format. What is the expected bit clock and frame sync frequencies in your system?

Regards

Erik

Thanks for the reply.

I'm not using this for audio, it's for a radio application for I/Q transmit and receive.  I need lock-step processors and a DSP and the AM2732 chip seemed ideal.  The McASP looked feasible, but as they say, the devil is in the details.

As far as clocking, I think I see what is going on.  I'd need a 15,360,000 bit clock, which won't divide down from 480MHz.  It looks like I'd have to use an external clock source or figure out a way to get an internal clock at the right rate.  960kS/s isn't a hard requirement, it could run at 937.5kS/s which evenly divides into 480MHz.  But sysconfig won't take that, even though it looks doable.  The fastest I could get was 375kS/s in systemconf.  Is there some other limit being hit?  I couldn't find it in the TRM.

Looking at the clock documentation in the TRM is really confusing.  In the clocking section, it lists 6 clocks for the McASP: RCSS_MCASP_REF<n>_CLK where <n> is 0-5.  I don't know how those are used for the McASP AUXCLK (which is also undocumented).  I'm guessing the REF clocks are the AUXCLKs for each receive and transmit section in the McASPs but that's a guess and I don't know the mapping.  Looking at the RCSS_MCASP_REF<n>_CLK values, there is a WUCPUCLOCK (undocumented), RCSS_ATL_CLKOUT<n> (sort of documented, but I don't know what drives it).  I'd like to avoid an external clock; it's one more thing to deal with, but it's doable.

I'm currently looking at one Analog AD4680 for the ADC (two ADCs in one package) and two AD5541's for the DAC, though that's not set in stone.  I need pipelined simultaneous sampling devices; I couldn't find anything from TI that looked suitable.  Everything there wasn't pipelined; you can't transfer data while a conversion is happening.  Or it was way overkill (too expensive).

The format for both devices is basically the same.  You have a bit clock and a clock sync (CS).  For the DAC, when the CS goes high to low, you shift data into a shift register, when that is done a low to high transition on CS transfers the shift register to the DAC register.  Then CS goes low again to transfer the next value into the shift register.  For the ADC, a high to low CS transition initiates a conversion.  Then CS going high transfers the conversion to a shift register and CS going low initiates a new conversion and start transferring the data out of the shift register.  Note that this is *exactly* what I want.

Since there are two devices both ways, I'm using two separate inputs and two separate outputs from the AM2732.  Each frame would transfer one sample.  It is possible to transfer two samples together over one line for the ADC, which would double the bit clock rate to 30,720,000.  I could probably do that on the transmit side, too, but I would need a new DAC part or some external logic.  If you have two serializers configured, does that count as two slots?  Or is it two slots on each serializer?  I could configure 8-bit slots, I suppose, and if I arranged things right two slots would come out as a single 16 bit value.

Hopefully that helps explain things.

-corey

I've been all over the TRM sections on McASP and clocking and I'm not getting any resolution.

I can see the limitation on 2 slots.  You say that "it is atypical for audio applications to send only one slot of audio in a frame" but there are applications in telecom that would do this.  Mono is a thing.  And limiting this chip to audio applications seems, well, limiting to the usefulness of the device.  I think it could easily apply to many areas beyond audio.  The chip is advertised as being able to talk to ADC and DAC devices, if you had two separate devices doing left and right in a stereo application, that would be a 1 slot configuration.

As far as the data rate, I will point out that TI makes audio codecs that support 384k and 768k sample rates.  I would use one of those, except that they seem to have a 96k filter on the front end and probably won't work down to DC, which I need for I/Q.

I cannot figure out where all the clocks come from and go on the AM2732.  Different names are used for the same clocks, it seems, all over the TRM and data sheet, and many of them seem undocumented or under documented.

I cannot see the limitation on the master clock being a 128/256/512/1024 multiple of the frame sync that sysconfig requires.  Well, there is a mention in the S/PDIF case of 128, but just there, and that kind of makes sense for that case.

I also cannot figure out how to set the clock source for the McASP in sysconfig.  I think it can have different internal clock sources, though as I said, it's confusing, but I don't see a way to set them.

Anyway, I'm in exploratory mode for an application.  I've picked some things and I'm diving down into the details to make sure they work.  The AM2732 solves a lot of problems and I would really like to use it.  We are using the TMS570 lockstep processor chips for other applications and they have served us well.  Now we are looking at using a DSP instead of external radio chips so we have more flexibility.

Thanks,

-corey

Corey, 

The McASP is intended for audio data transmission as defined by the standardized audio protocols such as TDM or I2S. 

The parts mentioned in your reply do not require the McASP for serial data transfer as they are not sending/receiving audio frames. 

The parts mentioned make use of standard SPI and the MIBSPI module(s) of the AM273x can be used for interfacing.

CS, in this case, is referring to chip select rather than clock sync and is an active low signal indicating that the SPI transaction is intended for that specified target.

For the specified application, McASP should not be considered for the application. Please let me know if you have any additional questions.

Regards,

Erik  

> The McASP is intended for audio data transmission as defined by the standardized audio protocols such as TDM or I2S. 

The TRM, section 11.5.1.1, says:

• Glueless connection to audio analog-to-digital converters (ADC), digital-to-analog converters (DAC), codec, digital audio interface receiver (DIR), and S/PDIF transmit physical layer components.
• Wide variety of I2S and similar bit-stream format.

Clearly it's intended for more than just I2S and TDM.  What ADC and DAC devices will it work with?

> The parts mentioned in your reply do not require the McASP for serial data transfer as they are not sending/receiving audio frames. 

> The parts mentioned make use of standard SPI and the MIBSPI module(s) of the AM273x can be used for interfacing.

I'm pretty sure it can't.  I need precisely timed frames from/to the ADC/DAC, like you would get with a frame sync.  I don't think the SPI interfaces can accomplish that.

> CS, in this case, is referring to chip select rather than clock sync and is an active low signal indicating that the SPI transaction is intended for that specified target.

I am aware of that, but on the ADC and DAC I mentioned, they perform more than just a chip select function.  They also synchronously drive the conversions and transfers to the serial registers.  I'm not expecting you to read the spec of those devices, but they perform the function of a frame sync even though they are called chip select and it says it's SPI.

> For the specified application, McASP should not be considered for the application. Please let me know if you have any additional questions.

That's a little disappointing.  Suppose I could use external logic to convert to an I2S interface, which I could do.  The AM2732 solves enough problems that it's probably worth it to put a small FPGA or something out there to get the data in.

First, can you suggest something else that would be suitable?

Second, if I can massage the data in to I2C or TDM format, I still have the following questions:

• I cannot see the limitation on the master clock (AHCLKX) being a 128/256/512/1024 multiple of the frame sync that sysconfig requires.  Is that really required?  I can't find it in the TRM.  Well, there is a mention in the S/PDIF case of 128, but just there, and that kind of makes sense for that case.
• I also cannot figure out how to set the clock source for the McASP in sysconfig.  I think it can have different internal clock sources, though as I said, it's confusing, but I don't see a way to set them in sysconfig, and most of the clock sources are mostly-undocumented and inconsistently named.  The clock sources in the TRM are really hard to understand.  I can use an external clock, though, but the previous question about AHCLKX still stands.

The documentation for the AM2732 doesn't seem to be up to TI's normal standards.  I've looked at other chips and the docs are much better.

Thanks,

-corey

Corey,

Corey Minyard said:

Glueless connection to audio analog-to-digital converters (ADC), digital-to-analog converters (DAC), codec, digital audio interface receiver (DIR), and S/PDIF transmit physical layer components.

All of the mentioned devices make use of Serial Audio Data Output Formats such as I2S, TDM, and Left-Justified. 

Corey Minyard said:

Clearly it's intended for more than just I2S and TDM.  What ADC and DAC devices will it work with?

The Multichannel audio serial port is intended to work with audio ADC and DAC devices such as PCM6240 or TAD5212. 

Corey Minyard said:

I'm pretty sure it can't.  I need precisely timed frames from/to the ADC/DAC, like you would get with a frame sync.  I don't think the SPI interfaces can accomplish that.

Can you please expand on what limitations of the SPI module make it so that it can't be used in this application? 

Corey Minyard said:

I cannot see the limitation on the master clock (AHCLKX) being a 128/256/512/1024 multiple of the frame sync that sysconfig requires.  Is that really required?  I can't find it in the TRM.  Well, there is a mention in the S/PDIF case of 128, but just there, and that kind of makes sense for that case.

This is a nuance of a standard audio frame format. FS is demarking the start of a frame and the bit clock is set in accordance of frame format. 

For example, I2S or TDM2, are two slot of audio data. If the data is 16 bit words and frame sync is 48kHz then the bit clock would be 48,000*2*16 = 1.536 MHz. The bit clock (ACLK) is derived from the AHCLK which is restrained to being multiples of frame sync as mentioned. There is no restriction on dividing AHCLK by a different value for a different ACLK. The driver sets all dividers based on the set framesync value and AHCLK value in accordance with slot size and word width. 

The McASP can make use of the AUXCLK to select different values for the root clock of AHCLK and subsequently ACLK/FS. For more information on all McASP topics, please refer to McASP Design Guide. 

Regards,

Erik

Thanks for the reply.

Corey Minyard said:

I'm pretty sure it can't.  I need precisely timed frames from/to the ADC/DAC, like you would get with a frame sync.  I don't think the SPI interfaces can accomplish that.

Can you please expand on what limitations of the SPI module make it so that it can't be used in this application?

I need precisely timed and synchronized input and output from two DACs and two ADCs.  For instance, on the ADC, I need two samples, each fro one of the ADCs, taken at exactly the same time.  The jitter between successive samples must be very low.  Both of those really need to be sub-nanosecond precision.  To use the SPI device, I'd have to general an external frame sync somehow and then somehow combine it with the frame sync from the McASP.  On those parts, the CS is part of the sample logic.  Well, on the DAC there is an option of an external sample pin, but it would still need to be coordinated with CS somehow.

I really need a one-bit frame sync.  Those ADC and DAC devices are designed to work that way.

Corey Minyard said:

I cannot see the limitation on the master clock (AHCLKX) being a 128/256/512/1024 multiple of the frame sync that sysconfig requires.  Is that really required?  I can't find it in the TRM.  Well, there is a mention in the S/PDIF case of 128, but just there, and that kind of makes sense for that case.

This is a nuance of a standard audio frame format. FS is demarking the start of a frame and the bit clock is set in accordance of frame format. 

For example, I2S or TDM2, are two slot of audio data. If the data is 16 bit words and frame sync is 48kHz then the bit clock would be 48,000*2*16 = 1.536 MHz. The bit clock (ACLK) is derived from the AHCLK which is restrained to being multiples of frame sync as mentioned. There is no restriction on dividing AHCLK by a different value for a different ACLK. The driver sets all dividers based on the set framesync value and AHCLK value in accordance with slot size and word width. 

Ah.  From the McASP Design Guide you mention below (which is very helpful) I see:

The master clock is typically required to run at a multiple of the sample rate, fs: 128fs, 256fs, or 512fs,
(the device-specific data manual for your audio device will tell you which one is expected).

So it's really more a function of the codec than it's a function of the McASP.  AFAICT, there is nothing in the McASP that uses the AHCLK for anything except to send it out on that pin and to generate ACLK.

The McASP can make use of the AUXCLK to select different values for the root clock of AHCLK and subsequently ACLK/FS.

Yes, the clocking inside the McASP is pretty clear.  The question is: Where does AUXCLK come from?  It's mentioned nowhere outside the McASP section in the AM2732 TRM.  And nothing there says where it comes from.

Looking in the clocking section of the TRM, there is Table 6-1680. Configuration Options and in that there is RCSS_MCASP_REF0_CLK through RCSS_MCASP_REF5_CLK.  I would assume those are the AUXCLKs, but I don't know how to correlate those with the various McASP units RECV and XMIT devices.  And the sources of those clocks: WUCPUCLK, RCSS_ATL_CLKOUT0, RCSS_ATL_CLKOUT1, RCSS_ATL_CLKOUT2, RCSS_ATL_CLKOUT3, RCCLK10M, XREF_CLK0, XREF_CLK1, are not well documented.

For more information on all McASP topics, please refer to McASP Design Guide.

Thank you, that is very helpful.

-corey

Corey, 

Can you please confirm the intended bit clock and frame sync frequencies for your application? 

Regards,

Erik

Erik Friedel said:

Can you please confirm the intended bit clock and frame sync frequencies for your application?

This is really more of an exploratory thing.  I'm looking to see what can be achieved within budget and space constraints, with parts that are extended industrial temperature (-40-105C or better).  I would like to have around 1 million samples a second, in that range.  960 was just a nice multiple of 48.  1MS/s with 16-bit samples would be a 1MHz frame sync and a 16MHz bit clock, with two individual channels in each direction.  Or with a channel in each direction (two channels multiplexed), a 32MHz bit clock.

We currently have an application that is using external FSK chips for communications,  We have 4 receivers and one transmitter.  We would like to move to more advanced modulation techniques, but that requires signal processing that you can't buy in a chip (and the chips we are using have gone out of production).  Thus a DSP or FPGA hooked to a radio front-end with a lockstep control processor.

The minimum requirements we could get by with are around 100kHz bandwidth.  I had originally started with a TAC5212 codec, which would easily interface to the AM2732.  You can get around 200kHz bandwidth from that with I/Q modulation, except that you get a hole in the middle of the spectrum between around -20Hz and 20Hz.  And more bandwidth would increase the flexibility of the system, allowing it to work for more things.

After studying the ADC and DAC for a bit, I think you are right about the ADC, that it won't work as is, though I am not 100% sure either way.  I think the DAC will work, but again, not 100% sure.  So it's likely some sort of front-end logic would have to be added to adapt whatever ADC and DAC were used.  But adding some sort of programmable logic device is yet more space, and I'm thinking it's going to be too much at this point.  More bandwidth may have to wait for a later project.

I guess to close this, I would really like to know:

Does the AHCLKx clock need to be 128, 256, or 512 (or 1024 per sysconfig) times the AFSx rate from the McASP's point of view?  The sysconfig tool enforces this, but the CODECs I'm looking at don't seem to require it.

Does the McASP use AHCLKx for anything internally?  If I provide an external clock, for ACLKx and AFSx, do I have to provide AHCLKx, too?

Thanks,

-corey

Actually, to answer my own question, from the McASP document, section 2.3 Clock Pins:

AHCLKX and AHCLKR – These are high-frequency clocks pins, sometimes referred to as master
clocks (often referred to on audio codecs as MCLK). McASP uses a master clock for one purpose: to
divide it down and generate a bit clock. There are several cases where a master clock is not required.

Is that correct?

Assuming that's correct, that multiple of AFSx in sysconfig is not valid.  It would be nice if sysconfig didn't have that restriction.

-corey

Ok, I think I have all the information I need here.  Well, the explanation of all the clocks on the AM2732 is not here, and undecipherable from the manual, but I can live with taking the defaults for everything.