Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Analog to Digital Converter (ADC)

Status
Not open for further replies.

simonmada

New Member
Hi everyone,

I'm undertaking a project involving Analog to Digital Converter (ADC). From what i know, one way to implement this ADC in Verilog is by using a DAC and comparator. The DAC output and an analog input will be the inputs of the Comparator. The output of the comparator will then be fed into the ADC. Basically this method is based on the Successive Approximation. The problem with this design is that it is slow as it requires many comparisons. Is there any ADC with parallel(flash) comparisons where we can speed up the design?

The application note is Xilinx app155. What I want to know is that is there any other methods to implement the ADC in Verilog? Any further info on the different types, block diagrams, and how they work for ADCs are very much appreciated.

I've tried the tracking ADC, which uses the up/down counter, but it seems to be slower.

Thank you in advance.
 
We need to know what your idea of fast/slow is.
How many bits?
What type of DAC are you using? PWM or PRM
What is the fastest clock in your design?
What comparator are you using?

There are many external ADC. Pick one!

The most simple method is the external analog comparator + resistor and capacitor.

For simple 6 bit ADC, I have used the “differential receiver” input cell found in some ASICs as a comparator. 3 pins + R+C A pulse rate modulator will allow a much smaller RC delay. There are several DAC design that produce “video rate” signals that could drive the comparator. Before I go on….How fast?
 
A true flash A/D requires (2^n)-1 comparators for an n-bit ADC. For a 10 bit ADC, that's 1023 comparators! Successive approximation only requires n comparisons on one comparator for an n-bit ADC.
There are pipelined versions of the flash ADC that require fewer comparators, but they require some DACs also, and they have higher latency than a true flash.
 
I would say 8/9 bits.

Let me explain based on this example. We consider this based on 9 bits. So the range would be from 0(0 0000 0000) to 511(1 1111 1111).The reference level will start from the middle which means 256(1 0000 0000). We consider the analog input to be a wave which rises all the way up to Vcc(which means all the way to 1 1111 1111). Lets say for a Successive Approximation(SAR) ADC, the reference level would start from 1 0000 0000(256)-->1 1000 0000(384)-->1 1100 0000(448)--> 1 1110 0000(480)-->1 1111 0000(496)-->1 1111 1000(504)-->1 1111 1100(508)-->1 1111 1110(510)-->
1 1111 1111(511)

This SAR ADC works based on the output of the comparator. If the output of the comparator is TRUE, then it will set the next bit one at a time until it reaches the LSB. What I meant by slow is that, in order to get the output of the ADC, this circuit needs to run/loop 9 times before finally resolving to 1 1111 1111. SAR functions by jumping by half(128-->64-->32-->16-->8-->4-->2-->1), so if the analog input changes frequently, the tracking ADC would be slower. I know that flash ADC are the fastest, but i cant use that in this project.

I'm looking for something which can reduce the number of loops before finally getting the output. Seriously need some help over here.
 
Roff said:
A true flash A/D requires (2^n)-1 comparators for an n-bit ADC. For a 10 bit ADC, that's 1023 comparators! Successive approximation only requires n comparisons on one comparator for an n-bit ADC.
There are pipelined versions of the flash ADC that require fewer comparators, but they require some DACs also, and they have higher latency than a true flash.

Yeah, I know that. What is my problem now is the n-comparisons needed. I need to do something to reduce the number of comparisons.
 
simonmada said:
Yeah, I know that. What is my problem now is the n-comparisons needed. I need to do something to reduce the number of comparisons.

The n comparisons is inherent in that architecture. Your real problem isn't n comparisons but rather it takes too long to do n comparisons right? Since you cant use other types of A/D's, the easiest thing to do may be just run your system faster.
 
The **broken link removed** might be faster. It still requires n comparisons, but I believe they are pipelined, and so can run much faster. I don't have any first-hand experience with these.
 
Optikon said:
The n comparisons is inherent in that architecture. Your real problem isn't n comparisons but rather it takes too long to do n comparisons right? Since you cant use other types of A/D's, the easiest thing to do may be just run your system faster.

Yeah, my concern is that it takes too long to do n comparisons, but if there is any ways whereby I can make less than n comparisons to get the output would be even better.

Roff said:
The **broken link removed** might be faster. It still requires n comparisons, but I believe they are pipelined, and so can run much faster. I don't have any first-hand experience with these.

I see. I'll have a look and give it a try to see if it works. If I face any problems, I'll have to come back for help. Thanks
 
Optikon said:
The n comparisons is inherent in that architecture. Your real problem isn't n comparisons but rather it takes too long to do n comparisons right? Since you cant use other types of A/D's, the easiest thing to do may be just run your system faster.

Yeah, my concern is that it takes too long to do n comparisons, but if there's a way to reduce the number of comparison that I need to make, it would be even better
 
Roff said:
The **broken link removed** might be faster. It still requires n comparisons, but I believe they are pipelined, and so can run much faster. I don't have any first-hand experience with these.

I see. I'll have a look and give it a try to see whether it works, if it doesn't I'll have to come back for help again. Thanks.
 
Roff said:
The **broken link removed** might be faster. It still requires n comparisons, but I believe they are pipelined, and so can run much faster. I don't have any first-hand experience with these.

Folding is something like a and unfortunately its slower compared to a SAR ADC. Still figuring out about this, anyone got any ideas?
 
Is this just a theoretical approach or do you intend to really use an ADC?
Are you trying to make an ADC yourself or do you want to use an existing one?

I mean, like ronsimpson already said, why not pick on from the many out there?

Analog has a 14 bit 150MSPS (150.000.000 samples per second) :eek:
Isn't that fast enough??
 
ADC in a digital world

Simonmada & Roff,

I still do not know what speed you want.

A Successive approximation ADC with a 100mhz clock will convert at 10mhz.
--------------------------------------------
People reading this thread will say “buy a ADC”. For the last hard ASIC I made there was a huge price advantage to not go mixed signal. (development cost) In a digital only ASIC we made ADCs using 3 pins and a RC. Ask you boss; Should I use a $5.00 ADC or a $0.01 R+C? Multiply by 100,000 unites per year.
--------------------------------------------
I have used an ADC much like the ramp ADC but faster.

Modify the ramp ADC to have a Up/Down counter. The output of the analog voltage comparator drives the U/D pin on the counter. The ramp heads up until it crosses the unknown analog voltage. Then the ramp heads down until it crosses again (one count). If the analog voltage is at a value of 200.3 then the output of the U/D counter will = 200, 201, 200, 200, 201, 200, 200, 201 etc. The bad news is it takes a while to find the voltage. The good news; when it is close there is an output every clock.

To speed things up I tried to combine the successive approximation idea with the UpDown idea. The DAC counts up by +32 until the voltages cross. Then it counts down by –8 until the voltages cross. Then counts up by +2, then counts Up/Down/Up/Down etc.

I struggle with logic to detect when the unknown voltage is many counts from the DAC output. If the unknown voltage moves up fast then the counter needs to up1, up1, up1, up2, up4, up8, up16, up32, (too high) down 16, up 8, down 4, up2, down, up down, up down, up etc.

This crazy method works when you want to over sample a signal. (OR) If you want to have very low delay to output. (Leave the UpDown ADC running all the time, read the output when you want the information.)

Simonmada; You are not alone. There are people get “free” analog functions out of a digital part. Keep working. Please post your results!
 
simonmada said:
Yeah, my concern is that it takes too long to do n comparisons, but if there's a way to reduce the number of comparison that I need to make, it would be even better

but "takes too long" is a relative statement. We still don't know how "fast" you want to go. Also, whats wrong with living with n comparisons and running your system faster? This is probably the path of least resistance to your solution.. otherwise, what you are hinting at is developing a whole new architecture that is probably very much outside the scope of your project.
 
mcs51mc
I'm trying to make an ADC myself by implementing it using Verilog.

Ronsimpson:

Erm, well I guess I might be a little misleading with what I'm asking here. I'll try to clarify it now.

Quoting from Ronsimpson:
The bad news is it takes a while to find the voltage. The good news; when it is close there is an output every clock.

Yes, this method takes a while to find the voltage, therefore, I would say it is "slow" in my definition. There is an output at every clock cycle but, the problem with this architecture is that the output voltage is unstable because like what you said "If the analog voltage is at a value of 200.3 then the output of the U/D counter will = 200, 201, 200, 200, 201, 200, 200, 201 etc", the output will keep varying.

Optikon:

I'll try to explain more clearly. Currently what I'm doing is, refer to one architecture, which is the SAR ADC and make improvement on it to make it work faster in any way, be it modifying the architecture or changing the algorithm or whatever it takes.

Lets consider the worst case for this SAR ADC. If the analog input is at 5V (1 1111 1111), the SAR ADC starts counting from 1 0000 0000 and takes a minimum of 8 comparisons before zooming in on the analog voltage. This 8 comparisons is what I meant by "slow". I tried to make this ADC jump faster, but it would reduce the accuracy, therefore it was not accepted.
 
Last edited:
In defense of a DAC where 200.3 looks like 200, 200, 201.
Take any DAC that can only see 200 or 201 and measure 200.3 many times. You may get the same answers. (200, 200, 201 etc)

It looks like the ‘how fast’ question is not going to get answered, except ‘too slow’. So, Good luck
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top