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.

On building a multi-channel DAC system with DAC8568 or AMC7812EVM

Other Parts Discussed in Thread: TMS320F2812, DAC8568EVM, DAC8568, AMC7812EVM-PDK, AMC7812

Dear All,

I am relatively inexperienced with hardware building, but have some theoretical understanding of electronics. I am trying to build a multi-channel DAC system with the following requirements:

No. DAC Channels: >=8
DAC Resolution: 12-16 bits
Settling time: 5us or less

Also, I need to play out DAC patterns for at least 200ms. i.e., assuming 16 bits resolution for DACs, I would need data memory of at least 16x8x(200ms/4us)=16x8x50k bits=800kBytes, say 1MB.

With this in mind, here is what I was hoping to do. Use a DAC8568 evm (http://www.ti.com/tool/dac8568evm) in conjunction with a TMS320F2812 eZdsp Start Kit (DSK) (http://www.ti.com/tool/tmdsezd2812). These two boards are supposed to go together through the HPA-MCU Interface Board. In the specifications of Starters kit (TMS320F2812), it is mentioned that it can address up to 1.0Mword Total external memory. I hope this can be used for the data patterns that I wish to play out on the DACs and use the onboard RAM in TMS320F2812 to store the instructions to control the DACs. Here are a few queries in this regard.

1. First, I request experienced users here to point to any pitfalls in my thinking, before I procure these components, especially on the memory front.
2. Next, would it be possible to swap a AMC7812EVM (http://www.ti.com/tool/amc7812evm-pdk) instead of DAC8568 (given their better settling times). The documentation of AMC7812EVM mentions that the board "can be connected to any modular EVM system interface card". Hence the question.
3. I would like to know of other microcontroller boards that can interface to the above DACs in a similar manner, but allow larger data storage for my DAC patterns (say from an external SD card).

I look forward to your inputs.

Regards,
Umesh Rudrapatna

  • Suryanarayana Umesh Rudrapatna said:
    Also, I need to play out DAC patterns for at least 200ms. i.e., assuming 16 bits resolution for DACs, I would need data memory of at least 16x8x(200ms/4us)=16x8x50k bits=800kBytes, say 1MB.

    The DAC8568 has 8 channels and is a 16bit DAC. The digital input word is 32bit wide to accommodate for control bits.

    If you are planning on communicating transparently and only writing to the device you will need store 16 data bits plus 3 channel bits in order to select each of the 8 channels. So you will have 19 dynamic bits and 13 static bits. (The static bits can stored once and not changed.)

    Similarly the AMC7812 has 12 channels and 12bit DACs. But you will only use 8 channels. The word width for this device is 24bits. You will have 15 dynamic bits and 9 static bits.

    If you plan to communicate with the device every 4us for 200ms at a time, then you will need (200ms/4us) = 50k codes. This means that you need to store:

    • DAC8568: 50k * 19bits = 950kbits = 119kB
    • AMC7812: 50k * 15bits = 225kbits = 29kB

    This means that the total storage memory required would be around 150kB. Keep in mind that this is only for the SPI sequence codes, the programming code will still require some space.

    Suryanarayana Umesh Rudrapatna said:
    2. Next, would it be possible to swap a AMC7812EVM (http://www.ti.com/tool/amc7812evm-pdk) instead of DAC8568 (given their better settling times). The documentation of AMC7812EVM mentions that the board "can be connected to any modular EVM system interface card". Hence the question.

    Yes, you could swap the DAC8568 for an AMC7812 and interface them with a microcontroller, IF you are okay with the lower resolution DACs of the AMC7812.

    Since you are planning on using the EVMs for a single project and are planning on using any other features from the AMC7812, I would suggest using the DAC8568EVM since it has a price tag of $49.00, compared t the AMC7812EVM-PDK with a price tag of $499.00.

    Suryanarayana Umesh Rudrapatna said:
    3. I would like to know of other microcontroller boards that can interface to the above DACs in a similar manner, but allow larger data storage for my DAC patterns (say from an external SD card).

    I am moving this post to the MCU forum for more assistance, since they will be more familiar with the device. They should be able to suggest an approach.

  • Hi Eugenio,

    Thanks a lot for your reply. That clarifies quite a bit. However, I still have a question regarding the memory usage. I was hoping to use the DAC boards to play out different analog patterns on different DAC channels. I realize that it would require more clock cycles to select a DAC at a time and load the relevant code to its register. But that is fine with me. I guess DAC8568 allows that. In that case, I hope you agree that I need 8x119kB of data memory. With the clock speed of 150MHz (TMS320F2812), I hope I can still squeeze in this 8x data loading steps and still achieve the desired 5us conversion rate. Any opinion on that?


    bye,

    Umesh

  • Umesh,

    The DAC8568 allows for a maximum update rate of about 1.56MHz with a 50MHz CLK. This means that you can write a new DAC code every 0.64us, regardless of which channel you are writing to. If you are writing to each channel sequentially you can write to each channel every 5.12us which is not within your specification of 5us.

    If you are still interested in the number of bits required, then here is the calculation:

    200ms/0.64us = 312.5k codes

    312.5k * 19bits = 5.94Mbits = 742kB

    if you are only trying to achieve less than 16bit performance you can also make make some of the dynamic LSBs static. This will NOT improve your update rate, but it will reduce storage space.

  • I forgot to ask you a question.

    What kind of waveforms are you trying to generate?

    Typically it is a square, triangle or saw-tooth waveform, you can get reduce storage size by defining a function that generates these values within the MCU without having to store every code as a look-up table.

  • Hi Eugenio,

    Thanks for giving me a clear answer regarding the timing issues. About the waveforms, they are going to be complex and varied. I initially had thoughts of going to a C6xxx processor in order to generate the shapes from my data, but I decided to take the easier route. I plan to generate the shapes using Matlab and dump the discrete data into the microcontroller ram through RS232. And finally I plan to drive the digital data through McBSP to the DACs.


    That brings up more questions. Sorry to bother you again. When you talked about the timing, you discounted the McBSP (or other) transfer times to the DACs, right?, or can they go on in parallel somehow? I guess I need to add a minimum of about 6.67ns x bits (at 150MHz) for McBSP transfer to each DAC register. That is still quite small assuming say 16 bits (12 data + 3 control + 1 dymmy) and comes to 16*6.67ns=0.1us. Thus the true update rate would be somewhere around 5.12us + 8x0.1us ~ 6us. Am I right in my thinking? This is still fine with me, but am wondering if I have correctly accounted for the additional overhead for the communication between the microcontroller board and the DAC board. In my case, the bandwidth limitations will be in the amplifiers that will follow the DACs and hence I am not too bothered by additional 1us for conversion.

    Finally, I hope you can comment on whether the use of RS232 (UART) to dump all the patterns and control bits on the microcontroller RAM is a common practice. That part is hazy to me. If you foresee any other potential pitfall in my thinking, I request you to point them out.

    Jumping ahead, in view of possible further expansions, I am wondering if two such microcontroller boards along with their 8-channel DAC boards can be synchronized to create a 16-channel DAC. If the prototype works, I may be asked to scale up the operation to 16-channels and hence this question. Except that the data transfer will get a bit messy, my gut feeling says that synchronized operation should be possible with a common clock source. Any comment on that?

    Regards,

    Umesh

  • Suryanarayana Umesh Rudrapatna said:
    When you talked about the timing, you discounted the McBSP (or other) transfer times to the DACs, right?

    Yes, I was only speaking of the limitations of the DAC itself. And your calculation of overhead is correct.

    Suryanarayana Umesh Rudrapatna said:
    or can they go on in parallel somehow?

    The channels could be updated in parallel if you wanted, but the serial interface would still limit you to the same overall update rate.

    Suryanarayana Umesh Rudrapatna said:
    Finally, I hope you can comment on whether the use of RS232 (UART) to dump all the patterns and control bits on the microcontroller RAM is a common practice.

    I am not sure if this is common practice, this may be a question for the MCU team but as far as I'm concerned the max standard baud rate of RS232 is 115,200 bits per second, which would mean that loading the RAM would take some time.

    Suryanarayana Umesh Rudrapatna said:
    Jumping ahead, in view of possible further expansions, I am wondering if two such microcontroller boards along with their 8-channel DAC boards can be synchronized to create a 16-channel DAC. If the prototype works, I may be asked to scale up the operation to 16-channels and hence this question. Except that the data transfer will get a bit messy, my gut feeling says that synchronized operation should be possible with a common clock source. Any comment on that?

    It should be possible. Depends on how much work you want to employ. You could use separate /CS to distinguish between devices, but your channel update rate would double. You could instead, use two separate DINs from the MCU (one for each chip) and update a channel on each chip with different data values, while maintaining the same 6us channel update rate.

  • Thanks for all the inputs Eugenio. I feel far more comfortable now with the whole stuff thanks to your inputs. I hope to get going with the prototype soon.

    Regards,

    Umesh