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.
Part Number: ADC3244
Hi, I have 5 ADC3244s in my system. They all get synchronize sample clocks and are operated in 2-wire mode. The problem is the Frame Clock is 2 samples wide for the data output and since they are set up individually, they don't all start converting at the same time. This leads to some with frame clocks 180 degrees out of phase with the others. What is the best way to accommodate this? Can I disable the input clocks while each chip is set up then start the the input clocks simultaneously? I'm not using the internal divider, but could SYSREF help in this instance?Thanks,
You might be able to get away with starting the sampling clocks at the same time, but I don't think that this is a reliable approach, so I would use SYSREF.
By default, the clock buffer is bypassed, so you will need to enable the clock buffer to divide by 1. Write 0x27 0x01 (address, data).
After doing this, you will be able to synchronize the clock buffers of each ADC by using SYSREF.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to dBrock:
OK, I think I understand the SYSREF solution. I have a design in hardware and I haven't connected SYSREF because the documentation was pretty sketchy and seemed to indicate it was only for dividing the clock, but I'll look into that. In the meantime, regarding turning on the clocks together - is there any issue resetting and setting registers in the ADCs while the clock is stopped. And, for that matter, as long as I can enable the clock during the low time so we don't get any glitches or runt pulses, is there another reason it would be unreliable?Thanks again,
In reply to Ryan Miller1:
There should not be any problem configuring the ADC registers when the clock is not applied.
Intuitively, I believe that, as long as all of the sample clock sources are length matched (cables/routing/etc), and are derived from the same source(frequency/phase locked), there should be no issue. In reality, there may be some difference in the aperture delay inside of the different ADCs (just from process variation during fabrication of the IC), but I do not know if this is enough to cause the fclk phase issues that you had initially reported.
Are you able to experiment, and see if starting the clocks simultaneously works as expected?
Yes, I'll be starting that next week. I've been working with one channel verifying the interface and I'm adding code in the FPGA to support multiples. I can control the clocks as I've described and the design does incorporate matched lengths and a single clock source. I do have access to the sysref pins on my board but they don't connect directly to the FPGA - although I could add a patch to connect them, but that's not my first choice. I appreciate your help. How come the sysref info hasn't made it into the ADC3244 data sheet yet?
My first try with turning the clock off, doing the setup, then clock on did not work. I still have some probing to do to make sure everything is working the way I think, but it looks like I'll be trying sysref. Is there a way to drive it with a single ended 3.3V signal? And can I connect the same signal to all 5 adc inputs?Thanks again,
I'm also exploring other options for driving SYSREF. One is to use my single-ended, 1.8V reset control. Can the ADC be reset using only the serial interface command or is the hardware reset pulse required? If I need a new signal to drive SYSREF, I'll have to use a 3.3V output from my FPGA. From the data sheet the absolute max is 1.8V. Also the signal is internally biased. We've AC coupled the SYSREF inputs (P and N), but the ADC is on a daughter board, so I brought the pins to the FPGA board, but terminated them at the connector with pull-down resistors to ground as I didn't think I needed the signal. I could use a pull-up to 1.8V and drive with the 3.3V signal using tri-state for high, maybe. Any advice is appreciated.
In the datasheet, it states that the ADC requires a hardware reset (pg 54).
Can you explain a little further as to what happened in the previous test of turning on the clock source to all ADCs? Was the data not aligned, or did something else happen?
Are you able to share the schematic? Driving the SYSREF is a little inconvenient if not accounted for initially since the common mode is not all that common. Maybe you could use the reset output as a monoshot SYSREF pulse, but I don't know what provisions are available on your board.
Yes, I read that about the reset, but then it says basically the same thing about the serial command reset, so I was just wondering if it might be possible to skip the hardware reset. Regardless, the problem was as I suspected, some of the ADC Frame clocks were 180 degrees out of phase with others and it didn't seem to be predictable. My startup sequence is: Clock off, reset pulse to all ADCs simultaneously, set-up each ADC via serial commands sequentially, then clock on to all ADCs simultaneously. I can't really see what else I can do and I don't really understand why some are essentially 1 sample off. Some sort of start thing or maybe how the clock gets into the chip? I'll try to attach a pic of the ADC hookup. I'm driving each of the ADCs with a matched length LVDS clock that are produced by the FPGA from a single internal clock. Clock and SYSREF interfaces are shown at the bottom of the page. AC-coupled, 100 ohm terminator for both. As I said, the clock is driven by LVDS. The P and N for SYSREF are brought out of this board through the connector to the FPGA board, but just terminated with pulldowns. We can wire it to the FPGA, although an LVDS output would be difficult. I could use 2 complementary 3.3V outputs, also. And of course, the pullup to 1.8V with the 3.3V outputs tri-stated when high. The datasheet seems to indicate the sysref inputs can be driven from 0 to 1.8V. The big problem here, of course, is that the sysref interface is not very well documented. In fact, in the 3244 datasheet there's almost nothing. The docs indicate it's for divided clocks which I'm not using so I discounted the interface entirely.
One more question - I'm assuming when this out of sync condition occurs that the sampling across multiple ADCs is still really in sync, it's just that some are a sample behind others. I guess I'd have to check that by putting in a step or something, but I'm making the assumption that for one ADC it's delivering samples S0,S1 S2,S3 S4,S5 on successive frame clocks while one of the offset ones is delivering S1,S2 S3,S4 S5,S6 on successive frame clocks. Does that make sense?
Yes, this is the correct way to think about it. The ADCs are still sampling the same data (after the initial sampling instance), but they are just offset.
For some reason, the attachment that was shared did not come through. Could you please add the image in a zip file?
One thing you might try, to get around using the SYSREF, is the following:
- Provide clocks
- Reset ADC
- Program ADC registers
While it's not stated in the datasheet, I believe this approach might work.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.