14 Replies Latest reply on Mar 19, 2015 11:54 PM by dakn_263916

    PSoC5LP ADC_SAR_seq at full 1MHz rate


      I am commencing a design that will require the SAR ADC to run almost full 1 Msample per sec while sequencing across 8 channels. Is this realistic as far as channel-to-channel crosstalk, settling time to 12 bit accuracy, etc?


      Anyone with experience doing this and verifying performance?





        • 1. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

          You might have to post a CASE on this as datasheet specs, analog globals,


          are referenced to DelSig input, and of course from one design to another


          route can be different. So no short answers in the docs.




          Assuming a 1V Vref settling to 1 LSB, calculator here (you could use


          ohmmeter tool to get route R and fudge the C)














          To create a technical or issue case at Cypress -








          “Technical Support”


          “Create a Case”




          You have to be registered on Cypress web site first.




          Regards, Dana.

          • 2. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

            Achieving 12 bit accuracy with 8 channel MUX with 1 MHz sequencing ADC is very unlikely. It all depends on the settling time, which even on 50 oHm load will be few usec. I didn't try it with PSoC, but can compare it with high-end NI-DAQ boards, where I see considerable cross-talk between channels at 1MHz. Here realistic combined speed becomes typically 200kHz with 100oHm loads and ~1% cross-talk between channels. 


                 To eliminate cross-talk it is typically recommended to MUX/interleave sampling channels with GND, so that each 2-nd ADC measurement is done on the GND, to short the remaining charge. Another way to improve cross-talk is to have all measured voltages to be of the same scale, otherwise 1% crosstalk from 1V channel will completely spoil 10mV measurement of next channel.



            • 3. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

              Here is an example (you can diddle the values yourself) to 13 bits is


              ~ 36 nS -








              From the ap note on the ADI tool settling time page -








              With respect to crosstalk, there is a spec in datasheet using DelSig as the load


              of > 100 db. You might, when you file your case, ask if that would be representative


              of the crosstalk in a SAR route.




              Regards, Dana.

              • 4. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                I see in the PSoC5LP data sheet (Table 11-31) that the switch and routing resistance is going to be around 1000 ohms, but the missing information is the input capacitance of the SAR ADC.


                Of the 18 clocks (56ns period) per conversion cycle, the signal must be stable for 4 clocks (acquisition window), leaving about 750ns for settling. If the SAR ADC input capacitance is 150 pf, then tau ~ 1K x 150pf = 150ns and I have about 5 time constants to settle. If the input capacitance is bigger than that, I could connect an op amp as a buffer (data sheet Table 11-19, input capacitance = 18pf) but that's no help if the routing resistance from op amp output to SAR ADC is still 1Kohm.


                I have a case open so I will see what they say.

                • 5. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                  If you use the ohmmeter tool you can get an idea of route R -








                  Insofar as SAR input C you might file a CASE on this, 150 pF seems incredibly high, would


                  take up a lot of die area. You might also point out the TIA R tolerances are - 25% to + 35%,


                  seems like muxes should track ? This is a guess on my part as mux Rdson is very dependent


                  on Vgson, maybe thats why the departure. Maybe they have better characterization data for


                  running part at a specific Vdd.








                  To create a technical case at Cypress -








                  “Technical Support”


                  “Create a Case”




                  You have to be registered on Cypress web site first.




                  Regards, Dana.

                  • 6. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                     The likely culpit will be not RC, but MUX switching time (about 1us) and ADC OPAMP slew rate(approx. 1V/us). Adding those values into ADC calculator gives about 500kHz sampling rate.




                    Anyway, it will be interesting to see actual performance. Please share your project when done.



                    • 7. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                      Interestingly enough the PSOC 4 Architecture TRM states -




                      CTBm output via sarbus0/1 (not fast enough to sam
                      ple at 1 Msps)






                       AMUXBUS_A/_B (not fast enough to sample at
                      1 Msps)










                      When you file CASE ask if the PSOC 4 is the same geometry/process as the 5LP family.






                      The SR of the OpAmp at high power, 200 pF load, is ~ 3 V/uS, too bad its not speced


                      with 15 pF or something more relevent.




                      You could always set up a mux test and measure it just to see if Cypress is


                      overly conservative.






                      Regards, Dana.

                      • 8. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                         Just to bring a bit of clarity to this discussion...


                        The SAR ADC is designed to permit hardware muxing with zero latency - meaning that you can use a hardware-driven mux on the front, and run the SAR at an aggregate 1 Msps, or 125 ksps per channel, without significant crosstalk issues.  The SAR issues a signal usually referred to as 'next' when it is done sampling the input signal.  This is typically used as the trigger to click the input mux onto the next channel and you have a generous ~0.75 us for the switching to happen.  This assumes of course that the mux is connected direct to the SAR.  It's not a good idea to put an amplifier between mux and SAR (unless it is super super fast); if you need any kind of conditioning, give each channel its own amplifier.


                        The effective input capacitance of the SAR is ~8 pF and it will charge to 12bit accuracy in enough time as long as the source resistance is 2.3k or less.  Now, quite a lot of that is consumed by the internal routing, so the best assumption is that the full-speed operation is only for low impedance sources of less than a few hundred ohms.  If you have high impedance sources, buffer them - with an amplifier that gives you a closed-loop bandwith of at least 6 MHz at the gain you want.  PSoC amplifiers will achieve this at unity gain, but you may need to use external parts if you want significantly greater gain.


                        I haven't found internal research work yet on the 8-channel configuration, but we studied the 2-channel configuration at 500 ksps per channel on PSoC 4A quite intensively, and showed clearly that there was no significant interchannel crosstalk with the default sampling settings and low impedance signals from generators.  We even checked the case where one channel was deliberately overdriven, and no unusual behaviour was seen.


                        Hope that helps a little!

                        • 9. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                          @kvcp Thanks for the clarifying answer. Does everything you say apply equally to PSoC5LP and PSoC4?


                          I was under the impression that PSoC4 has dedicated mux switching near the SAR ADC while PSoC5LP uses the GPIO-pin switches. That might suggest that PSoC5LP's mux bus routing capacitance is added to the raw ADC.


                          My application is going into a CY8C5868LTI-LP038.





                          • 10. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                            The PSoC 5LP SARs should have no problem running at 1 MSPS.  Assume that you external signal has a relatively low output impedance and you are not using the internal PGAs or opamps.  By default the SAR ADC clock will be at 18 MHz so it will take 18 clock for a full conversion.  The first four clocks (by default) is the acquisition time, or the time allowed to charge the input capacitor of the SAR ADC.  This input cap is about 8 or 10pF.  You can increase this acquisition time on the PSoC 5LP if you need a little more time to settle.  It isn't as flexible as the PSoC4 SAR acquisition time, but it is usable. 


                            The other half of the settling is from the pin to the input to the SAR.  This part of the circuit has almost 4 times more time to settle.  There If I remember correctly, one clock after the sampling is complete, this signal goes high letting the sequencing hardware switch the internal AMUX to the next channel.  this means that the input signal can settle all the way to the input switch of the SAR for almost a full conversion cycle or almost an entire us.  When the ADC starts to sample again, the input cap will be at the same voltage of the last channel, so it will have to charge/discharge the input cap with the new value. 


                            I know what you are thinking, once you start the acquisition phase again, the internal routing capacitance may not totally overwelm the input capacitor.  Correct, but at least it had a head start.  If the route plus your source resistance is too high, you can increase the acquisition time with the ADC_SAR_1_SAR_CSR2_REG register.  The values are kind of wierd 1 thru 7, then, 128, 256, 384, etc, but better than nothing.  The PSoC 4 SAR you can change this value from I think 2 to over 1000, in 1 clock steps.


                            Hope this helps,





                            • 11. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                              This additional info is very useful and I feel encouraged that this can work. We will have a CY8CKIT-050B dev kit soon and I will be doing some verification tests. If anyone wants to post or send me a PSoC Creator project for testing I'd be happy to run it.




                              As I understand it now there are TWO time constants here. First, the GPIO-AMUXBUS switches change state. The selected signal charges the distributed routing capacitance through a resistance consisting of (1) external source resistance -- in my case ~75 ohms; (2) the activated switch; (3) the AMUXBUS resistance. This total will nominally be ~500 ohms (ref Dana's probing; I haven't used that tool yet) and might be up to double that depending on temperature, supply voltage, etc. So say 1000 ohms worst case. I haven't heard what the AMUXBUS capacitance is likely to be, but as long as it's less than 80 pf or so 750 nsec will be plenty of time to settle within 1 LSB. Let's say it is 20pf.




                              The second time constant comes into play when the SAR ADC acquisition window, 250 ns long, opens. The charge on the AMUXBUS's 20pf will equalize with the SAR input capacitance (8pf) through a switch in the ADC. This time constant will be roughly 8pf times the switch path resistance (a few hundred ohms) and charge will equalize pretty quickly (maybe 15 ns to 1LSB). However this only gets the voltage (20/28) or 70% of the way to its final value. The remaining 30% of the charge has to transferred through the full routing resistance to the full routing capacitance (plus ADC input capacitance) in the remaining time. With my made-up numbers that time constant is 1000 ohms x 28pf = 28ns, and because I'm already 70% home I only need 7 time constants to settle to 1LSB, i.e. 200 nsec. Whew, I think I just made it! If not, I can tweak a control register and allow more time for the acquisition window; however if I do that I will have to derate from 1Ms/sec and I don't have much wiggle room there.







                              • 12. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                                I think it would be great if meh and kvcp pooled their knowledge into


                                an ap note, or a one page white paper at minimum. Quite valuable.


                                Include actual architecture of SAR front end discussion.




                                But then thats just my thought.




                                Regards, Dana.

                                • 13. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                                  FYI, some preliminary test results from a DC adjacent-channel crosstalk test using CY8CKIT-050B:




                                  17.82MHz ADC clock, 0-3.3V ADC range, 4 acquisition clocks (default), 100 ohm source resistance, 4 LSB crosstalk.


                                  17.82MHz ADC clock, 0-3.3V ADC range, 7 acquisition clocks, 100 ohm source resistance, 3 LSB crosstalk.


                                  17.82MHz ADC clock, 0-3.3V ADC range, 128 acquisition clocks, 100 ohm source resistance, 0 LSB crosstalk.


                                  Bench test conditions were not perfect so I do not consider these results definitive.





                                  • 14. Re: PSoC5LP ADC_SAR_seq at full 1MHz rate

                                    With 100 ohms source R I would have expected at most 2 LSBs, intrinsic


                                    +/-1 LSB conversion uncertainty. Maybe additional noise from processor


                                    not related to crosstalk of the input routes contributing.




                                    Results seem high to me, if you said these were at K range of source R


                                    then I would have thought OK, good.




                                    Maybe grounding unused inputs with mux might help.....?




                                    If you average readings this is a sign uncorrelated noise is being removed,


                                    note processsor noise generally highly correlated to internal processes,






                                    Maybe seg can comment on this.




                                    Regards, Dana.