DSPRelated.com
Forums

Continuous-time DSP with no sampling

Started by Yannis November 2, 2005
robert bristow-johnson wrote:
> in article 1131399617.730331.219850@f14g2000cwb.googlegroups.com, Yannis at > ytctdsp@yahoo.com wrote on 11/07/2005 16:40: > > > Robert, > > > > You are beating the wrong horse. > > i'm sure he deserves it for some other reason i'm not aware of yet.
No, I meant that your comments in your previous message, which could have some validity in some cases, are targeting the wrong person (me). You even gave a URL in which somebody is ranting about academics in general, making some blanket statements like "they pretend to teach", etc. This is an insult to me. See http://www.ieee.org/organizations/pubs/newsletters/sscs/oct04/tsividis.html
> > I would have assumed that my messages of Nov. 3 and Nov. 4 in this thread > > would have convinved you, beyond doubt, that our group has a track record of > > research that leads to important industrial applications. > > i'm only commenting on the content of the article that you brought up. > whether or not your "group has a track record of research that leads to > important industrial applications" is immaterial to that. > > > As to your question, "how can you *ever* beat the glitches?", let me say this: > > If, in 1974, someone asked me "how can you *ever* make an op amp out of MOS > > trasistors", my answer would have been "I don't know *yet*"; > > i understand that this is the argument you've been making, but it's not > persuasive. you're talking about an issue with the natural variance of > delay times through *different* delay elements hooked up to different bits. > considering the MSB, you have to get that down to the pico- or femto-second > to prevent those glitches from being a problem.
This is how it may look, based on the paper you saw, which emphasized only the principle. This is how research often starts. Once problems such as the one you are talking about are identified, people work at correcting them. And, very importantly, some times the original principle rings a bell when opportunity knocks, and leads to a somewhat different idea that does not have these problems. Actually, we believe we already may have a solution to what you are talking about. We will talk about it in due course.
> > > if I had let myself be convinced by several people back then that what I was > > trying to do was impossible, I would not have tried. > > then build us a faster than light transportation device, because this is > sorta similar.
No, there is a better way. It just sounds impossible to you, based on the picture you have in mind. The paper you read is two years old. We haven't quite sitting since then.
> > > Fortunately, I did not take their advice, and in the end I was proven right. > > I hope history will repeat itself with this work. > > > > Being relevant in university research does not mean you do not jump > > into difficult territory. > > it should also have promise. and the promise of something better than what > is existing technology. that's where i also remain skeptical.
Yes, but you are missing an important point. Sometimes, the promise is not evident before solutions are found. And, solutions cannot be found unless one tries. Thus, if one needs to be 100% sure that something works before starting to work on it, they would not even begin. Again, this was the case with my work with the first fully-integrated MOS op amp in the early seventies. So, the best one can do is follow one's intuition. For me, CT DSP has the following promise: no aliasing; no quantization noise at non-harmonic frequencies (for a sine test signal; for more general inputs, better spectral properties for the quantization error than classical techniques); and power dissipation that goes down when the input activity is slow or low. This is enough promise for me; the fact that there are significant problems to be solved before this promise can be fulfilled is a *necessary* condition for me to be willing to do research.
> > -- > > r b-j rbj@audioimagination.com > > "Imagination is more important than knowledge."
Enough said for now... I do not plan to continue this discussion. But I will get back when we have a chip, which may take a year or two. Yannis
Jerry Avins wrote:
> Yannis Tsividis wrote: > > In principle, sampling is not necessary in order to do filtering > > digitally. This is discussed in the following paper: > > > > Y. Tsividis, "Digital signal processing in continuous time: a > > possibility for avoiding aliasing and reducing quantization error", > > Proc. 2004 IEEE Int. Conf. on Acoustics, Speech, and Signal Processing, > > vol. II, pp. 589-592, Montreal, May 2004. > > (If you are interested but cannot obtain this paper, please let me > > know.) > > > > In the above paper, I discuss a method to do DSP in continuous time, > > without sampling, resulting in a system with no aliasing. The system > > has no quantization error at non-harmonic frequencies, and exhibits > > 10-15 dB lower total quantization error than classical DSP, for a given > > number of bits. Power dissipation decreases when the input frequency is > > low, or in general when there is little activity. However, although > > breadboard measurements and simulations show that the idea works, there > > is a lot of work to be done before one can know whether all this is > > practically feasible. This work is at the early research stage, and no > > commercial feasibility is claimed at this point. > > > > I would be very interested in the opinion of DSP experts on this idea. > > We are currently looking for an appropriate application in order to > > demonstrate the concept. I welcome any comments! > > Yannis, > > I read through the paper quickly. I will need to go over it again to > understand how the quantization noise disappears, but although it hasn't > been focused on here, it is one of the more interesting results. (In > comparison, the absence of aliasing is trivial since the process can be > modeled as having an infinite sample rate.) > > The most obvious problem is glitching, as has been noted. I don't agree > that Gray codes can't help there, even if they aren't the entire > solution. For the moment, let's optimistically assume that glitching is > solved and touch on another issue. > > Consider one of Zeno's paradoxes and its resolution. > > *Paradox: Motion is Impossible* > Before one can move to some new location, one must go > halfway. To reach the half-way point, one must pass the > quarter point. Before that, 1/8th, then 1/16, then .... > There is no end to the enumeration, so the goal can't > be reached in finite time. > > *Resolution* > The enumeration of way points /in that way/ can't be > accomplished, but there is no link between the motion > itself and the enumeration. The supposed paradox > is simply bad logic. > > Digitizing amounts to an enumeration of (typically) voltages. The usual > way using uniform time steps is conceptually simple and mathematically > tractable. Another way, made possible by quantizing, is an enumeration > of the time required for the voltage to change from one step to the > next, and indicating of the direction of the change. We don't do that > because it's too hard. One difficulty is that before the voltage take a > new value, it must go half way -- shades of Zeno.
Jerry, there is no relation to Zeno's paradox. Think of it this way: When you go up some stairs in a building, before you reach the next step your foot has to go half way. Does this prevent you from going up the stairs? It's the same with the voltage going up the steps of the quantizer. To see this in proper context, one has to momentarily abandon the framework of working with discrete-time, countable sets, and think directly in terms of continuous time. This brings me to the discussion as to whether the technique I propose is really continuous-time or not, which has also been discussed under this topic (not by you). It is *precisely* continuous-time. The term "continuous time signals" has been defined for decades - it is not very wise to try to revise it. All signals in my technique are defined over real t, as opposed to being defined over a countable set of discrete time instants. The different time-widths of the steps in it are an integral part of the description, and play an important role in the output. The fact that there are steps, or that there could be glitches, does not change this. For example, a signal defined by: y=3D0, for t<5 y=3D1, for t>=3D5 is a continuous-time signal; it is continuous along the *time* axis. If there is a glitch g(t), the signal becomes: y'(t)=3Dy(t)+g(t) i=2Ee., the corrupted signal is composed of an ideal continuous-time signal plus a continuous-time error g(t). This sum is *still* defined over continuous time, although of course the continuous-time error in it, will make it worthless over the time that g(t) has a significant value. Finally, if you delay the input of such a system by an *arbtrarily small* amount Delta-t, all waveforms within the processor and at the output are delayed by *the same* amount Delta-t, simply because there is no clock and only the input determines when things will happen. (Again, all this is not addressed to you - I just found a good opportunity to mention it here.)
> We are exempted from > making the enumeration infinite only by accepting its truncation. Still, > small step size (read "allowed truncation error") implies very high data > rates and very fast converters. I don't know what the future may bring, > but one can reduce quantization noise and aliasing greatly right now by > using those same resources on more conventional ways. > > Many will know me as a habitual wet blanket. My reaction to most novel > ideas and authoritative pronouncements is a search for counterexamples. > The aim is not to attack the originator of the idea -- my own ideas get > the most scrutiny -- but to probe the idea itself for weakness. I think > that what you've shown is very interesting. I'm not sure how useful it > will be, but time will tell.
Sure, I take your comments in good faith. I have enjoyed this discussion.
> > Jerry > -- > Never ascribe to malice what might be be ignorance, stupidity, or sloth.
Yannis
> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF
Yannis wrote:
> Jerry Avins wrote:
...
>>Yannis, >> >>I read through the paper quickly.
...
>>Consider one of Zeno's paradoxes and its resolution. >> >> *Paradox: Motion is Impossible* >> Before one can move to some new location, one must go >> halfway. To reach the half-way point, one must pass the >> quarter point. Before that, 1/8th, then 1/16, then .... >> There is no end to the enumeration, so the goal can't >> be reached in finite time. >> >> *Resolution* >> The enumeration of way points /in that way/ can't be >> accomplished, but there is no link between the motion >> itself and the enumeration. The supposed paradox >> is simply bad logic. >> >>Digitizing amounts to an enumeration of (typically) voltages. The usual >>way using uniform time steps is conceptually simple and mathematically >>tractable. Another way, made possible by quantizing, is an enumeration >>of the time required for the voltage to change from one step to the >>next, and indicating of the direction of the change. We don't do that >>because it's too hard. One difficulty is that before the voltage take a >>new value, it must go half way -- shades of Zeno. > > > Jerry, there is no relation to Zeno's paradox. Think of it this way: > When you go up some stairs in a building, before you reach the next > step your foot has to go half way. Does this prevent you from going up > the stairs? It's the same with the voltage going up the steps of the > quantizer. To see this in proper context, one has to momentarily > abandon the framework of working with discrete-time, countable sets, > and think directly in terms of continuous time.
Of course we can actually climb the steps. What we can't do is enumerate all the powers of 1/2 remaining to be completed even for one step. With finite precision, the enumeration becomes finite but remains large. That makes it possible but hard. Discrete-time digital processing allows gaps between successive numbers out of the ADC, while continuous-time processing requires the ADC to put our each code in sequence at a rate determined by the signal's slope. In effect this is an enumeration; while finite, small quantization deltas make it large. In turn, that implies very high ADC speeds relative to the signal bandwidth. It seems to me that, for the present at least, the benefits of CT processing can be had by making use of that speed in more traditional ways.
> This brings me to the discussion as to whether the technique I propose > is really continuous-time or not, which has also been discussed under > this topic (not by you). It is *precisely* continuous-time. The term > "continuous time signals" has been defined for decades - it is not very > wise to try to revise it. All signals in my technique are defined over > real t, as opposed to being defined over a countable set of discrete > time instants. The different time-widths of the steps in it are an > integral part of the description, and play an important role in the > output. The fact that there are steps, or that there could be glitches, > does not change this. For example, a signal defined by: > > y=0, for t<5 > y=1, for t>=5 > > is a continuous-time signal; it is continuous along the *time* axis. If > there is a glitch g(t), the signal becomes: > > y'(t)=y(t)+g(t) > > i.e., the corrupted signal is composed of an ideal continuous-time > signal plus a continuous-time error g(t). This sum is *still* defined > over continuous time, although of course the continuous-time error in > it, will make it worthless over the time that g(t) has a significant > value. Finally, if you delay the input of such a system by an > *arbtrarily small* amount Delta-t, all waveforms within the processor > and at the output are delayed by *the same* amount Delta-t, simply > because there is no clock and only the input determines when things > will happen. (Again, all this is not addressed to you - I just found a > good opportunity to mention it here.)
Well, know that I agree. Don't take too much joy from that agreement; it carries little weight. (There may be only a finite number of finite discontinuities, but I'd not like the job of enumerating them all.) ... Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
in article 1131463050.523957.145500@z14g2000cwz.googlegroups.com, Yannis at
ytctdsp@yahoo.com wrote on 11/08/2005 10:17:

> > robert bristow-johnson wrote: >> in article 1131399617.730331.219850@f14g2000cwb.googlegroups.com, Yannis at >> ytctdsp@yahoo.com wrote on 11/07/2005 16:40: >> >>> Robert, >>> >>> You are beating the wrong horse. >> >> i'm sure he deserves it for some other reason i'm not aware of yet.
that was typed tongue-in-cheek.
> No, I meant that your comments in your previous message, which could > have some validity in some cases, are targeting the wrong person (me). > You even gave a URL in which somebody is ranting about academics in > general, making some blanket statements like "they pretend to teach", > etc. This is an insult to me.
if you're not in that group, the criticism (or "insult") is not directed toward you.
> See > http://www.ieee.org/organizations/pubs/newsletters/sscs/oct04/tsividis.html
i'm glad to read that you're a good teacher. i probably hadn't emphasized the other salient complaint of Anderson: "They represent their research and writing as important and relevant when much of it is not." i understand that you sincerely believe this CT DSP to be important and relevant research, but i can believe that only if there is some reasonable hope that it will be feasible someday. i do not. ...
>> >>> if I had let myself be convinced by several people back then that what I was >>> trying to do was impossible, I would not have tried. >> >> then build us a faster-than-light transportation device, because this is >> sorta similar. > > No, there is a better way. It just sounds impossible to you, based on > the picture you have in mind. The paper you read is two years old. We > haven't quite sitting since then.
i admire your optimism. but i don't share it.
>>> Fortunately, I did not take their advice, and in the end I was proven right. >>> I hope history will repeat itself with this work. >>> >>> Being relevant in university research does not mean you do not jump >>> into difficult territory. >> >> it should also have promise. and the promise of something better than what >> is existing technology. that's where i also remain skeptical. > > Yes, but you are missing an important point. Sometimes, the promise is > not evident before solutions are found. And, solutions cannot be found > unless one tries.
and sometimes the "solution" is hopelessly unfeasible. i doubt, with sampling rates as high as they are getting, that a CT DSP system as you describe will ever be preferable, in terms of price/performance, to sampled-data (at those high frequencies). the noise, due to glitches will be broadbanded, or in the high frequencies, and if you limit your application of CT DSP to lower frequency signals, you'll have trouble making it more feasible than sampled-data. if the unlimited "sampling-rate" is the selling point for higher frequencies, then the glitches will kill you. it's unavoidable.
> Thus, if one needs to be 100% sure that something > works before starting to work on it, they would not even begin.
that is what we call a "strawman argument". i'm not requiring 100% certainty, only something better than 0%. (and that's where the kernel of the disagreement is.)
> Again, this was the case with my work with the first fully-integrated MOS op > amp in the early seventies. So, the best one can do is follow one's intuition.
well, someone's paying for your intuition. the question is whether or not that's a good investment in this particular case of CT DSP.
> For me, CT DSP has the following promise: no aliasing;
neither does sampled-data for finite BW signals (if the sample rate is high enough, often that is quite feasible). what infinite BW signals are you planning to use this technology on (if it were to work).
> no quantization noise at non-harmonic frequencies (for a sine test signal; > for more general inputs, better spectral properties for the > quantization error than classical techniques);
certainly, even in the perfect circumstances, you get broadbanded quantization noise, because you do not have infinite bits.
> and power dissipation that goes down when the input activity is slow or low.
given the same application, say a simple digital filter, i cannot imagine the power requirement of this CT DSP to be competitive with sampled-data.
> This is enough promise for me; the fact that there are significant problems > to be solved before this promise can be fulfilled is a *necessary* condition > for me to be willing to do research.
good, knock yourself out!
> Enough said for now... I do not plan to continue this discussion. But I > will get back when we have a chip, which may take a year or two.
we'll be waiting with bated breath. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Yannis wrote:
> In principle, sampling is not necessary in order to do filtering > digitally. This is discussed in the following paper:
Finally read at least some of the paper. Look at Stark and Tutuer's , Modern Electrical Communications Systems, Prentice Hall 1979, in section 4.3 entitled, "Practical Aspects of Sampling." They assert that actual samplers have in effect some integration time. In your discussion on in-band quantization aliasing it looks like you use an ideal sampler. If the sampler has some integration associated with it, I believe that the harmonics will be a bit more attenuated, and thus less energy will fold in. I think your presentation about harmonics aliasing is kind of a worse case argument.
> > Y. Tsividis, "Digital signal processing in continuous time: a > possibility for avoiding aliasing and reducing quantization error", > Proc. 2004 IEEE Int. Conf. on Acoustics, Speech, and Signal Processing, > vol. II, pp. 589-592, Montreal, May 2004. > (If you are interested but cannot obtain this paper, please let me > know.) > > In the above paper, I discuss a method to do DSP in continuous time, > without sampling, resulting in a system with no aliasing. The system > has no quantization error at non-harmonic frequencies, and exhibits > 10-15 dB lower total quantization error than classical DSP, for a given > number of bits. Power dissipation decreases when the input frequency is > low, or in general when there is little activity. However, although > breadboard measurements and simulations show that the idea works, there > is a lot of work to be done before one can know whether all this is > practically feasible. This work is at the early research stage, and no > commercial feasibility is claimed at this point. > > I would be very interested in the opinion of DSP experts on this idea. > We are currently looking for an appropriate application in order to > demonstrate the concept. I welcome any comments! > > Yannis Tsividis > Columbia University >
Now that this discussion seems to have run its course, I would like to
thank all who participated in it, as well as those who wrote to me
directly. I appreciate all comments you have made. As a token of
appreciation, I would like to refer you to my short account of the
fascinating story of Edwin Armstrong, the inventor of FM radio:
http://www.ee.columbia.edu/history/armstrong/Armstrong.html.

We will now proceed with chip design. We have reasons to be optimistic,
but only measurements will tell if the idea works for sure. Once we
have such measurements, I may notify those of you who have indicated
they are interested. I also hope to add a link to my Web site,
http://www.ee.columbia.edu/index.php?dir=people&page=yannis_tsividis
dealing specifically with continuous-time DSP, hopefully soon.

I will no longer be monitoring this site (in which I have used a
temporary e-mail address to avoid getting spam in my regular address; I
will be de-activating the temporary address soon). If anyone would like
to write to me, please use my regular e-mail address, which is my last
name below at ee.columbia.edu.

Again, thanks a lot to everyone. 

Yannis Tsividis

Now that this discussion seems to have run its course, I would like to
thank all who participated in it, as well as those who wrote to me
directly. I appreciate all comments you have made.

We will now proceed with chip design, using a *variant* of the original
idea, which gets around some of the problems discussed here. We have
reasons to be optimistic, but only measurements will tell if the idea
works for sure. Once we have such measurements, I may notify those of
you who have indicated they are interested. I also hope to add a link
to my Web site,
http://www.ee.columbia.edu/index.php?dir=people&page=yannis_tsividis
dealing specifically with continuous-time DSP, hopefully soon.

Although not related to this topic, I would like to take this
opportunity to refer you to the fascinating story of Edwin Armstrong:
http://www.ee.columbia.edu/history/armstrong/Armstrong.html.

I will no longer be monitoring this site (in which I have used a
temporary e-mail address to avoid getting spam in my regular address; I
will be de-activating the temporary address soon). If anyone would like
to write to me, please use my regular e-mail address, which is my last
name below at ee.columbia.edu.

Again, thanks a lot. 

Yannis Tsividis

Jerry Avins wrote:
(snip)

> Digitizing amounts to an enumeration of (typically) voltages. The usual > way using uniform time steps is conceptually simple and mathematically > tractable. Another way, made possible by quantizing, is an enumeration > of the time required for the voltage to change from one step to the > next, and indicating of the direction of the change. We don't do that > because it's too hard. One difficulty is that before the voltage take a > new value, it must go half way -- shades of Zeno. We are exempted from > making the enumeration infinite only by accepting its truncation. Still, > small step size (read "allowed truncation error") implies very high data > rates and very fast converters. I don't know what the future may bring, > but one can reduce quantization noise and aliasing greatly right now by > using those same resources on more conventional ways.
OK, not disagreeing at all, but say you have a perfect flash A/D converter with gray code output, (I haven't tried to design one, but I think it might work) and also a perfect clockless D/A converter with gray code input. Given that, is there logic that can be put in between that will implement a digital filter of some kind? Considering that, it seems to me that skew could be a problem, if the transition order isn't maintained through the filtering, the results might not come out right. As an academic problem, though, it doesn't seem so bad. -- glen
Steve Underwood wrote:

(snip regarding continuous time A/D conversion)

> An analogue amp shows a continuous progressive output change as it > settles. The A/D converter shows no change for a while, then a burst of > glitching, then a new value. There is nothing continuous about that at > all. Its analagous to the self-clocked asychronous logic that people > have been trying to drive into the mainstream for years, except there > may not strictly be a clock in this case. It shares that "do it as fast > as you can, but don't do it in a continuous progressive manner" quality.
Can you put just enough feedback on the comparators to reduce the glitches for real signals? That is, the output transitions won't happen more often than, say, twice that required for the highest transition rate? In that case, the sampling rate probability distribution function would be zero above some frequency, rising continuously below that frequency. -- glen
glen herrmannsfeldt wrote:

> ... say you have a perfect flash A/D > converter with gray code output, (I haven't tried to design one, > but I think it might work) and also a perfect clockless D/A converter > with gray code input. Given that, is there logic that can be put > in between that will implement a digital filter of some kind? > > Considering that, it seems to me that skew could be a problem, if the > transition order isn't maintained through the filtering, the results > might not come out right. > > As an academic problem, though, it doesn't seem so bad.
I agree, provided I'm not the one who has to make it work. As for the filter, a shift register, with multipliers at the taps (fast Gray-code multiplier?) summing (fast Gray-code adder) to form the output can make an FIR. (A bucket-brigade or L-C delay line and analog multipliers can also do it..) Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;