Reply by rickman December 27, 20142014-12-27
On 12/27/2014 11:33 AM, Eric Jacobsen wrote:
> On Sat, 27 Dec 2014 01:35:55 -0500, rickman <gnuarm@gmail.com> wrote: > >> On 12/26/2014 1:15 PM, Eric Jacobsen wrote: >>> On Fri, 26 Dec 2014 12:05:24 -0500, rickman <gnuarm@gmail.com> wrote: >>> >>>> On 12/26/2014 11:45 AM, Eric Jacobsen wrote: >>>>> On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote: >>>>> >>>>>> On 12/25/2014 4:32 PM, Eric Jacobsen wrote: >>>>>>> On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>> >>>>>>>> On 12/25/2014 3:56 PM, Eric Jacobsen wrote: >>>>>>>>> On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> On 12/25/2014 10:52 AM, Eric Jacobsen wrote: >>>>>>>>>>> On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 12/23/2014 4:48 PM, Eric Jacobsen wrote: >>>>>>>>>>>>> On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 12/23/2014 10:35 AM, Eric Jacobsen wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Many applications don't need separate LUTs to get the required >>>>>>>>>>>>>>> performance, and even then, or even in the case of complex output, it >>>>>>>>>>>>>>> can be done without multipliers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Care to elaborate on this? I'm not at all clear on how you make a LUT >>>>>>>>>>>>>> based NCO without LUTs and unless you are using a very coarse >>>>>>>>>>>>>> approximation, without multipliers. >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure what you're asking. You a need a LUT, but just one in many >>>>>>>>>>>>> cases. Having a dual-ported single LUT is easy in an FPGA and >>>>>>>>>>>>> usually in silicon as well. >>>>>>>>>>>>> >>>>>>>>>>>>> What makes a multiplier necessary? I've never found the need, but my >>>>>>>>>>>>> apps are limited to comm. >>>>>>>>>>>> >>>>>>>>>>>> Maybe we aren't on the same page. The multiplier is there for the fine >>>>>>>>>>>> adjustment. If you are happy with some -60 or -80 dB spurs one LUT is >>>>>>>>>>>> fine. But if you want better performance the single LUT approach >>>>>>>>>>>> requires *very* large tables. >>>>>>>>>>> >>>>>>>>>>> There are a lot of tricks that can be used to keep the table size >>>>>>>>>>> down. I've mentioned one already. >>>>>>>>>> >>>>>>>>>> And what was that? You have made some 20 or more posts in this thread, >>>>>>>>>> I don't feel like weeding through all of them to find this. Reading >>>>>>>>>> back through this thread it seems like your posts are intended to be >>>>>>>>>> mysterious rather than informative. Every one leaves enough unsaid that >>>>>>>>>> more questions are needed. >>>>>>>>> >>>>>>>>> I can't divulge trade secrets or proprietary information that doesn't >>>>>>>>> belong to me. I can, however, hint in directions of benefit. Take >>>>>>>>> it or leave it. >>>>>>>> >>>>>>>> I have no idea what you are talking about. If you don't have anything >>>>>>>> to say, why are you bothering to post? >>>>>>> >>>>>>> Why do you care whether I post or not? Feel free to put me in your >>>>>>> kill file if you don't like my posts. >>>>>> >>>>>> If you aren't interested in having a conversation, why do you bother to >>>>>> type? Above you said you had already mentioned "one" method already. >>>>>> Clearly that one is not a trade secret. Care to explain what method you >>>>>> are referring to? >>>>> >>>>> I did later in the same post. >>>> >>>> What same post would that be? I'm not sure what "same" means since the >>>> context is not clear. >>> >>> The same one you were responding to at the time. >> >> At this point it is pretty clear you are just playing with me and have >> nothing to say. > > No, seriously, it was in the same post. I found it ironic that you > were asking me to explain the method I was referring to, and I had > explained in the post you were responding to at the time.
I have no idea which post you are referring to. Context is long lost and you keep saying the "same post".
>>>>>>>> I don't even recall the hints. >>>>>>>> Or are you forbidden from pointing out what those are? >>>>>>> >>>>>>> No, but it seems to me like unnecessary duplication. There are lots >>>>>>> of hints from multiple people scattered throughout the thread, as well >>>>>>> as in some of the literature mentioned previously. >>>>>> >>>>>> Exactly, scattered in some 50 or so messages. If you have something to >>>>>> say, why no say it instead of being so vague? Just tell me which >>>>>> message you are referring to. >>>>> >>>>> So you want me to go back and search through the thread for you? Are >>>>> you not capable of doing that? I'm not at all clear why you think >>>>> that I should do the search if you're the one that wants the >>>>> information. >>>> >>>> I'm assuming that you might have more recollection of having made a >>>> post than I do of reading it. I did a scan and I never saw any useful >>>> comments on table reduction. Everything you posted seems to allude to >>>> things but always shies away from actually giving any info. >>> >>> I mentioned the quarter-wave reduction specifically multiple times. >>> Sorry you weren't able to glean anything. Not everybody does. >> >> I just never read your post in this thread where you mentioned that. >> That's why I pointed it out to someone who spoke of using the full wave. >> >>>>>>>> You said you had already mentioned a way to reduce table size. What was >>>>>>>> that? >>>>>>> >>>>>>> One way is to store a quarter wave instead of a full cycle. I think >>>>>>> that was mentioned more than once, but here it is again just for you. >>>>>> >>>>>> Thank you for the response. >>>>>> >>>>>> Yes, that is table reduction 101. Anyone other than a newbie is aware >>>>>> of that. I believe *I* was the one who in this thread pointed it out to >>>>>> someone who said memory is cheap not fully appreciating that memory is >>>>>> order 2^N is size. Even so it is just a factor of four and does nothing >>>>>> to change the fact that memory is anything but cheap if you are looking >>>>>> for high resolution and low distortion. Using MBs of memory to store a >>>>>> LUT is usually not a good trade off. >>>>>> >>>>>> What was the technique *you* mentioned as you indicate above? >>>>> >>>>> That was one of them. I mentioned it more than once. In my >>>>> experience a 4x reduction in memory can be significant, and the >>>>> quarter-wave trick isn't obvious to some people so I didn't make the >>>>> assumption that it was. >>>>> >>>>> You're welcome. >>>> >>>> Yes, a four fold reduction in size can be useful, but like I said, this >>>> is sine table 101. >>>> >>>> Was there anything else of value you have to offer on the topic? >>> >>> You can go back and see what's valuable to you, and I can't anticipate >>> what will or won't be. You seem to resent having the quarter-wave >>> trick pointed out to you, so I'm not going to try to guess what you >>> might or might not find obvious. One of the nice things about usenet >>> is that the posts a pretty sticky, so you can go back and review if >>> you want to and take or leave things as you see fit. >> >> I have read your posts here and I didn't see you mention the quarter >> wave table or anything else specific. Rather you gave thin references >> to the fact that "significant" reductions are possible. That's why I >> asked and so far you have not been able to explain what you meant or >> point to a post. You just keep repeating that you have already said >> things. Ok, nuff said. > > I've mentioned several techniques for improving DDS performance > specifically. I didn't go into a lot of detail, but I mentioned a > number of things pretty unambiguously, both before and after the > thread started cross-posting. Maybe you just didn't see them. > > I use Forte newsreader, and there's not a simple way to go back and > search which posts in a thread contained what, even if I posted it. > I'm not inclined to do that for you. Sorry. It's there if you, or > anybody, want to look, though.
Yes, it's there... on the Internet. Anyone can find that! -- Rick
Reply by Eric Jacobsen December 27, 20142014-12-27
On Sat, 27 Dec 2014 01:35:55 -0500, rickman <gnuarm@gmail.com> wrote:

>On 12/26/2014 1:15 PM, Eric Jacobsen wrote: >> On Fri, 26 Dec 2014 12:05:24 -0500, rickman <gnuarm@gmail.com> wrote: >> >>> On 12/26/2014 11:45 AM, Eric Jacobsen wrote: >>>> On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote: >>>> >>>>> On 12/25/2014 4:32 PM, Eric Jacobsen wrote: >>>>>> On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>> >>>>>>> On 12/25/2014 3:56 PM, Eric Jacobsen wrote: >>>>>>>> On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>> >>>>>>>>> On 12/25/2014 10:52 AM, Eric Jacobsen wrote: >>>>>>>>>> On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> On 12/23/2014 4:48 PM, Eric Jacobsen wrote: >>>>>>>>>>>> On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 12/23/2014 10:35 AM, Eric Jacobsen wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Many applications don't need separate LUTs to get the required >>>>>>>>>>>>>> performance, and even then, or even in the case of complex output, it >>>>>>>>>>>>>> can be done without multipliers. >>>>>>>>>>>>> >>>>>>>>>>>>> Care to elaborate on this? I'm not at all clear on how you make a LUT >>>>>>>>>>>>> based NCO without LUTs and unless you are using a very coarse >>>>>>>>>>>>> approximation, without multipliers. >>>>>>>>>>>> >>>>>>>>>>>> Not sure what you're asking. You a need a LUT, but just one in many >>>>>>>>>>>> cases. Having a dual-ported single LUT is easy in an FPGA and >>>>>>>>>>>> usually in silicon as well. >>>>>>>>>>>> >>>>>>>>>>>> What makes a multiplier necessary? I've never found the need, but my >>>>>>>>>>>> apps are limited to comm. >>>>>>>>>>> >>>>>>>>>>> Maybe we aren't on the same page. The multiplier is there for the fine >>>>>>>>>>> adjustment. If you are happy with some -60 or -80 dB spurs one LUT is >>>>>>>>>>> fine. But if you want better performance the single LUT approach >>>>>>>>>>> requires *very* large tables. >>>>>>>>>> >>>>>>>>>> There are a lot of tricks that can be used to keep the table size >>>>>>>>>> down. I've mentioned one already. >>>>>>>>> >>>>>>>>> And what was that? You have made some 20 or more posts in this thread, >>>>>>>>> I don't feel like weeding through all of them to find this. Reading >>>>>>>>> back through this thread it seems like your posts are intended to be >>>>>>>>> mysterious rather than informative. Every one leaves enough unsaid that >>>>>>>>> more questions are needed. >>>>>>>> >>>>>>>> I can't divulge trade secrets or proprietary information that doesn't >>>>>>>> belong to me. I can, however, hint in directions of benefit. Take >>>>>>>> it or leave it. >>>>>>> >>>>>>> I have no idea what you are talking about. If you don't have anything >>>>>>> to say, why are you bothering to post? >>>>>> >>>>>> Why do you care whether I post or not? Feel free to put me in your >>>>>> kill file if you don't like my posts. >>>>> >>>>> If you aren't interested in having a conversation, why do you bother to >>>>> type? Above you said you had already mentioned "one" method already. >>>>> Clearly that one is not a trade secret. Care to explain what method you >>>>> are referring to? >>>> >>>> I did later in the same post. >>> >>> What same post would that be? I'm not sure what "same" means since the >>> context is not clear. >> >> The same one you were responding to at the time. > >At this point it is pretty clear you are just playing with me and have >nothing to say.
No, seriously, it was in the same post. I found it ironic that you were asking me to explain the method I was referring to, and I had explained in the post you were responding to at the time.
>>>>>>> I don't even recall the hints. >>>>>>> Or are you forbidden from pointing out what those are? >>>>>> >>>>>> No, but it seems to me like unnecessary duplication. There are lots >>>>>> of hints from multiple people scattered throughout the thread, as well >>>>>> as in some of the literature mentioned previously. >>>>> >>>>> Exactly, scattered in some 50 or so messages. If you have something to >>>>> say, why no say it instead of being so vague? Just tell me which >>>>> message you are referring to. >>>> >>>> So you want me to go back and search through the thread for you? Are >>>> you not capable of doing that? I'm not at all clear why you think >>>> that I should do the search if you're the one that wants the >>>> information. >>> >>> I'm assuming that you might have more recollection of having made a >>> post than I do of reading it. I did a scan and I never saw any useful >>> comments on table reduction. Everything you posted seems to allude to >>> things but always shies away from actually giving any info. >> >> I mentioned the quarter-wave reduction specifically multiple times. >> Sorry you weren't able to glean anything. Not everybody does. > >I just never read your post in this thread where you mentioned that. >That's why I pointed it out to someone who spoke of using the full wave. > >>>>>>> You said you had already mentioned a way to reduce table size. What was >>>>>>> that? >>>>>> >>>>>> One way is to store a quarter wave instead of a full cycle. I think >>>>>> that was mentioned more than once, but here it is again just for you. >>>>> >>>>> Thank you for the response. >>>>> >>>>> Yes, that is table reduction 101. Anyone other than a newbie is aware >>>>> of that. I believe *I* was the one who in this thread pointed it out to >>>>> someone who said memory is cheap not fully appreciating that memory is >>>>> order 2^N is size. Even so it is just a factor of four and does nothing >>>>> to change the fact that memory is anything but cheap if you are looking >>>>> for high resolution and low distortion. Using MBs of memory to store a >>>>> LUT is usually not a good trade off. >>>>> >>>>> What was the technique *you* mentioned as you indicate above? >>>> >>>> That was one of them. I mentioned it more than once. In my >>>> experience a 4x reduction in memory can be significant, and the >>>> quarter-wave trick isn't obvious to some people so I didn't make the >>>> assumption that it was. >>>> >>>> You're welcome. >>> >>> Yes, a four fold reduction in size can be useful, but like I said, this >>> is sine table 101. >>> >>> Was there anything else of value you have to offer on the topic? >> >> You can go back and see what's valuable to you, and I can't anticipate >> what will or won't be. You seem to resent having the quarter-wave >> trick pointed out to you, so I'm not going to try to guess what you >> might or might not find obvious. One of the nice things about usenet >> is that the posts a pretty sticky, so you can go back and review if >> you want to and take or leave things as you see fit. > >I have read your posts here and I didn't see you mention the quarter >wave table or anything else specific. Rather you gave thin references >to the fact that "significant" reductions are possible. That's why I >asked and so far you have not been able to explain what you meant or >point to a post. You just keep repeating that you have already said >things. Ok, nuff said.
I've mentioned several techniques for improving DDS performance specifically. I didn't go into a lot of detail, but I mentioned a number of things pretty unambiguously, both before and after the thread started cross-posting. Maybe you just didn't see them. I use Forte newsreader, and there's not a simple way to go back and search which posts in a thread contained what, even if I posted it. I'm not inclined to do that for you. Sorry. It's there if you, or anybody, want to look, though. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by rickman December 27, 20142014-12-27
On 12/26/2014 1:15 PM, Eric Jacobsen wrote:
> On Fri, 26 Dec 2014 12:05:24 -0500, rickman <gnuarm@gmail.com> wrote: > >> On 12/26/2014 11:45 AM, Eric Jacobsen wrote: >>> On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote: >>> >>>> On 12/25/2014 4:32 PM, Eric Jacobsen wrote: >>>>> On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote: >>>>> >>>>>> On 12/25/2014 3:56 PM, Eric Jacobsen wrote: >>>>>>> On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>> >>>>>>>> On 12/25/2014 10:52 AM, Eric Jacobsen wrote: >>>>>>>>> On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> On 12/23/2014 4:48 PM, Eric Jacobsen wrote: >>>>>>>>>>> On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 12/23/2014 10:35 AM, Eric Jacobsen wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Many applications don't need separate LUTs to get the required >>>>>>>>>>>>> performance, and even then, or even in the case of complex output, it >>>>>>>>>>>>> can be done without multipliers. >>>>>>>>>>>> >>>>>>>>>>>> Care to elaborate on this? I'm not at all clear on how you make a LUT >>>>>>>>>>>> based NCO without LUTs and unless you are using a very coarse >>>>>>>>>>>> approximation, without multipliers. >>>>>>>>>>> >>>>>>>>>>> Not sure what you're asking. You a need a LUT, but just one in many >>>>>>>>>>> cases. Having a dual-ported single LUT is easy in an FPGA and >>>>>>>>>>> usually in silicon as well. >>>>>>>>>>> >>>>>>>>>>> What makes a multiplier necessary? I've never found the need, but my >>>>>>>>>>> apps are limited to comm. >>>>>>>>>> >>>>>>>>>> Maybe we aren't on the same page. The multiplier is there for the fine >>>>>>>>>> adjustment. If you are happy with some -60 or -80 dB spurs one LUT is >>>>>>>>>> fine. But if you want better performance the single LUT approach >>>>>>>>>> requires *very* large tables. >>>>>>>>> >>>>>>>>> There are a lot of tricks that can be used to keep the table size >>>>>>>>> down. I've mentioned one already. >>>>>>>> >>>>>>>> And what was that? You have made some 20 or more posts in this thread, >>>>>>>> I don't feel like weeding through all of them to find this. Reading >>>>>>>> back through this thread it seems like your posts are intended to be >>>>>>>> mysterious rather than informative. Every one leaves enough unsaid that >>>>>>>> more questions are needed. >>>>>>> >>>>>>> I can't divulge trade secrets or proprietary information that doesn't >>>>>>> belong to me. I can, however, hint in directions of benefit. Take >>>>>>> it or leave it. >>>>>> >>>>>> I have no idea what you are talking about. If you don't have anything >>>>>> to say, why are you bothering to post? >>>>> >>>>> Why do you care whether I post or not? Feel free to put me in your >>>>> kill file if you don't like my posts. >>>> >>>> If you aren't interested in having a conversation, why do you bother to >>>> type? Above you said you had already mentioned "one" method already. >>>> Clearly that one is not a trade secret. Care to explain what method you >>>> are referring to? >>> >>> I did later in the same post. >> >> What same post would that be? I'm not sure what "same" means since the >> context is not clear. > > The same one you were responding to at the time.
At this point it is pretty clear you are just playing with me and have nothing to say.
>>>>>> I don't even recall the hints. >>>>>> Or are you forbidden from pointing out what those are? >>>>> >>>>> No, but it seems to me like unnecessary duplication. There are lots >>>>> of hints from multiple people scattered throughout the thread, as well >>>>> as in some of the literature mentioned previously. >>>> >>>> Exactly, scattered in some 50 or so messages. If you have something to >>>> say, why no say it instead of being so vague? Just tell me which >>>> message you are referring to. >>> >>> So you want me to go back and search through the thread for you? Are >>> you not capable of doing that? I'm not at all clear why you think >>> that I should do the search if you're the one that wants the >>> information. >> >> I'm assuming that you might have more recollection of having made a >> post than I do of reading it. I did a scan and I never saw any useful >> comments on table reduction. Everything you posted seems to allude to >> things but always shies away from actually giving any info. > > I mentioned the quarter-wave reduction specifically multiple times. > Sorry you weren't able to glean anything. Not everybody does.
I just never read your post in this thread where you mentioned that. That's why I pointed it out to someone who spoke of using the full wave.
>>>>>> You said you had already mentioned a way to reduce table size. What was >>>>>> that? >>>>> >>>>> One way is to store a quarter wave instead of a full cycle. I think >>>>> that was mentioned more than once, but here it is again just for you. >>>> >>>> Thank you for the response. >>>> >>>> Yes, that is table reduction 101. Anyone other than a newbie is aware >>>> of that. I believe *I* was the one who in this thread pointed it out to >>>> someone who said memory is cheap not fully appreciating that memory is >>>> order 2^N is size. Even so it is just a factor of four and does nothing >>>> to change the fact that memory is anything but cheap if you are looking >>>> for high resolution and low distortion. Using MBs of memory to store a >>>> LUT is usually not a good trade off. >>>> >>>> What was the technique *you* mentioned as you indicate above? >>> >>> That was one of them. I mentioned it more than once. In my >>> experience a 4x reduction in memory can be significant, and the >>> quarter-wave trick isn't obvious to some people so I didn't make the >>> assumption that it was. >>> >>> You're welcome. >> >> Yes, a four fold reduction in size can be useful, but like I said, this >> is sine table 101. >> >> Was there anything else of value you have to offer on the topic? > > You can go back and see what's valuable to you, and I can't anticipate > what will or won't be. You seem to resent having the quarter-wave > trick pointed out to you, so I'm not going to try to guess what you > might or might not find obvious. One of the nice things about usenet > is that the posts a pretty sticky, so you can go back and review if > you want to and take or leave things as you see fit.
I have read your posts here and I didn't see you mention the quarter wave table or anything else specific. Rather you gave thin references to the fact that "significant" reductions are possible. That's why I asked and so far you have not been able to explain what you meant or point to a post. You just keep repeating that you have already said things. Ok, nuff said. -- Rick
Reply by Eric Jacobsen December 26, 20142014-12-26
On Fri, 26 Dec 2014 12:05:24 -0500, rickman <gnuarm@gmail.com> wrote:

>On 12/26/2014 11:45 AM, Eric Jacobsen wrote: >> On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote: >> >>> On 12/25/2014 4:32 PM, Eric Jacobsen wrote: >>>> On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote: >>>> >>>>> On 12/25/2014 3:56 PM, Eric Jacobsen wrote: >>>>>> On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>> >>>>>>> On 12/25/2014 10:52 AM, Eric Jacobsen wrote: >>>>>>>> On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>> >>>>>>>>> On 12/23/2014 4:48 PM, Eric Jacobsen wrote: >>>>>>>>>> On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> On 12/23/2014 10:35 AM, Eric Jacobsen wrote: >>>>>>>>>>>> >>>>>>>>>>>> Many applications don't need separate LUTs to get the required >>>>>>>>>>>> performance, and even then, or even in the case of complex output, it >>>>>>>>>>>> can be done without multipliers. >>>>>>>>>>> >>>>>>>>>>> Care to elaborate on this? I'm not at all clear on how you make a LUT >>>>>>>>>>> based NCO without LUTs and unless you are using a very coarse >>>>>>>>>>> approximation, without multipliers. >>>>>>>>>> >>>>>>>>>> Not sure what you're asking. You a need a LUT, but just one in many >>>>>>>>>> cases. Having a dual-ported single LUT is easy in an FPGA and >>>>>>>>>> usually in silicon as well. >>>>>>>>>> >>>>>>>>>> What makes a multiplier necessary? I've never found the need, but my >>>>>>>>>> apps are limited to comm. >>>>>>>>> >>>>>>>>> Maybe we aren't on the same page. The multiplier is there for the fine >>>>>>>>> adjustment. If you are happy with some -60 or -80 dB spurs one LUT is >>>>>>>>> fine. But if you want better performance the single LUT approach >>>>>>>>> requires *very* large tables. >>>>>>>> >>>>>>>> There are a lot of tricks that can be used to keep the table size >>>>>>>> down. I've mentioned one already. >>>>>>> >>>>>>> And what was that? You have made some 20 or more posts in this thread, >>>>>>> I don't feel like weeding through all of them to find this. Reading >>>>>>> back through this thread it seems like your posts are intended to be >>>>>>> mysterious rather than informative. Every one leaves enough unsaid that >>>>>>> more questions are needed. >>>>>> >>>>>> I can't divulge trade secrets or proprietary information that doesn't >>>>>> belong to me. I can, however, hint in directions of benefit. Take >>>>>> it or leave it. >>>>> >>>>> I have no idea what you are talking about. If you don't have anything >>>>> to say, why are you bothering to post? >>>> >>>> Why do you care whether I post or not? Feel free to put me in your >>>> kill file if you don't like my posts. >>> >>> If you aren't interested in having a conversation, why do you bother to >>> type? Above you said you had already mentioned "one" method already. >>> Clearly that one is not a trade secret. Care to explain what method you >>> are referring to? >> >> I did later in the same post. > >What same post would that be? I'm not sure what "same" means since the >context is not clear.
The same one you were responding to at the time.
>>>>> I don't even recall the hints. >>>>> Or are you forbidden from pointing out what those are? >>>> >>>> No, but it seems to me like unnecessary duplication. There are lots >>>> of hints from multiple people scattered throughout the thread, as well >>>> as in some of the literature mentioned previously. >>> >>> Exactly, scattered in some 50 or so messages. If you have something to >>> say, why no say it instead of being so vague? Just tell me which >>> message you are referring to. >> >> So you want me to go back and search through the thread for you? Are >> you not capable of doing that? I'm not at all clear why you think >> that I should do the search if you're the one that wants the >> information. > >I'm assuming that you might have more recollection of having made a >post than I do of reading it. I did a scan and I never saw any useful >comments on table reduction. Everything you posted seems to allude to >things but always shies away from actually giving any info.
I mentioned the quarter-wave reduction specifically multiple times. Sorry you weren't able to glean anything. Not everybody does.
>>>>> You said you had already mentioned a way to reduce table size. What was >>>>> that? >>>> >>>> One way is to store a quarter wave instead of a full cycle. I think >>>> that was mentioned more than once, but here it is again just for you. >>> >>> Thank you for the response. >>> >>> Yes, that is table reduction 101. Anyone other than a newbie is aware >>> of that. I believe *I* was the one who in this thread pointed it out to >>> someone who said memory is cheap not fully appreciating that memory is >>> order 2^N is size. Even so it is just a factor of four and does nothing >>> to change the fact that memory is anything but cheap if you are looking >>> for high resolution and low distortion. Using MBs of memory to store a >>> LUT is usually not a good trade off. >>> >>> What was the technique *you* mentioned as you indicate above? >> >> That was one of them. I mentioned it more than once. In my >> experience a 4x reduction in memory can be significant, and the >> quarter-wave trick isn't obvious to some people so I didn't make the >> assumption that it was. >> >> You're welcome. > >Yes, a four fold reduction in size can be useful, but like I said, this >is sine table 101. > >Was there anything else of value you have to offer on the topic?
You can go back and see what's valuable to you, and I can't anticipate what will or won't be. You seem to resent having the quarter-wave trick pointed out to you, so I'm not going to try to guess what you might or might not find obvious. One of the nice things about usenet is that the posts a pretty sticky, so you can go back and review if you want to and take or leave things as you see fit. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by rickman December 26, 20142014-12-26
On 12/26/2014 11:45 AM, Eric Jacobsen wrote:
> On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote: > >> On 12/25/2014 4:32 PM, Eric Jacobsen wrote: >>> On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote: >>> >>>> On 12/25/2014 3:56 PM, Eric Jacobsen wrote: >>>>> On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote: >>>>> >>>>>> On 12/25/2014 10:52 AM, Eric Jacobsen wrote: >>>>>>> On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>> >>>>>>>> On 12/23/2014 4:48 PM, Eric Jacobsen wrote: >>>>>>>>> On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> On 12/23/2014 10:35 AM, Eric Jacobsen wrote: >>>>>>>>>>> >>>>>>>>>>> Many applications don't need separate LUTs to get the required >>>>>>>>>>> performance, and even then, or even in the case of complex output, it >>>>>>>>>>> can be done without multipliers. >>>>>>>>>> >>>>>>>>>> Care to elaborate on this? I'm not at all clear on how you make a LUT >>>>>>>>>> based NCO without LUTs and unless you are using a very coarse >>>>>>>>>> approximation, without multipliers. >>>>>>>>> >>>>>>>>> Not sure what you're asking. You a need a LUT, but just one in many >>>>>>>>> cases. Having a dual-ported single LUT is easy in an FPGA and >>>>>>>>> usually in silicon as well. >>>>>>>>> >>>>>>>>> What makes a multiplier necessary? I've never found the need, but my >>>>>>>>> apps are limited to comm. >>>>>>>> >>>>>>>> Maybe we aren't on the same page. The multiplier is there for the fine >>>>>>>> adjustment. If you are happy with some -60 or -80 dB spurs one LUT is >>>>>>>> fine. But if you want better performance the single LUT approach >>>>>>>> requires *very* large tables. >>>>>>> >>>>>>> There are a lot of tricks that can be used to keep the table size >>>>>>> down. I've mentioned one already. >>>>>> >>>>>> And what was that? You have made some 20 or more posts in this thread, >>>>>> I don't feel like weeding through all of them to find this. Reading >>>>>> back through this thread it seems like your posts are intended to be >>>>>> mysterious rather than informative. Every one leaves enough unsaid that >>>>>> more questions are needed. >>>>> >>>>> I can't divulge trade secrets or proprietary information that doesn't >>>>> belong to me. I can, however, hint in directions of benefit. Take >>>>> it or leave it. >>>> >>>> I have no idea what you are talking about. If you don't have anything >>>> to say, why are you bothering to post? >>> >>> Why do you care whether I post or not? Feel free to put me in your >>> kill file if you don't like my posts. >> >> If you aren't interested in having a conversation, why do you bother to >> type? Above you said you had already mentioned "one" method already. >> Clearly that one is not a trade secret. Care to explain what method you >> are referring to? > > I did later in the same post.
What same post would that be? I'm not sure what "same" means since the context is not clear.
>>>> I don't even recall the hints. >>>> Or are you forbidden from pointing out what those are? >>> >>> No, but it seems to me like unnecessary duplication. There are lots >>> of hints from multiple people scattered throughout the thread, as well >>> as in some of the literature mentioned previously. >> >> Exactly, scattered in some 50 or so messages. If you have something to >> say, why no say it instead of being so vague? Just tell me which >> message you are referring to. > > So you want me to go back and search through the thread for you? Are > you not capable of doing that? I'm not at all clear why you think > that I should do the search if you're the one that wants the > information.
I'm assuming that you might have more recollection of having made a post than I do of reading it. I did a scan and I never saw any useful comments on table reduction. Everything you posted seems to allude to things but always shies away from actually giving any info.
>>>> You said you had already mentioned a way to reduce table size. What was >>>> that? >>> >>> One way is to store a quarter wave instead of a full cycle. I think >>> that was mentioned more than once, but here it is again just for you. >> >> Thank you for the response. >> >> Yes, that is table reduction 101. Anyone other than a newbie is aware >> of that. I believe *I* was the one who in this thread pointed it out to >> someone who said memory is cheap not fully appreciating that memory is >> order 2^N is size. Even so it is just a factor of four and does nothing >> to change the fact that memory is anything but cheap if you are looking >> for high resolution and low distortion. Using MBs of memory to store a >> LUT is usually not a good trade off. >> >> What was the technique *you* mentioned as you indicate above? > > That was one of them. I mentioned it more than once. In my > experience a 4x reduction in memory can be significant, and the > quarter-wave trick isn't obvious to some people so I didn't make the > assumption that it was. > > You're welcome.
Yes, a four fold reduction in size can be useful, but like I said, this is sine table 101. Was there anything else of value you have to offer on the topic? -- Rick
Reply by Eric Jacobsen December 26, 20142014-12-26
On Thu, 25 Dec 2014 18:08:54 -0500, rickman <gnuarm@gmail.com> wrote:

>On 12/25/2014 4:32 PM, Eric Jacobsen wrote: >> On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote: >> >>> On 12/25/2014 3:56 PM, Eric Jacobsen wrote: >>>> On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote: >>>> >>>>> On 12/25/2014 10:52 AM, Eric Jacobsen wrote: >>>>>> On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>> >>>>>>> On 12/23/2014 4:48 PM, Eric Jacobsen wrote: >>>>>>>> On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>>> >>>>>>>>> On 12/23/2014 10:35 AM, Eric Jacobsen wrote: >>>>>>>>>> >>>>>>>>>> Many applications don't need separate LUTs to get the required >>>>>>>>>> performance, and even then, or even in the case of complex output, it >>>>>>>>>> can be done without multipliers. >>>>>>>>> >>>>>>>>> Care to elaborate on this? I'm not at all clear on how you make a LUT >>>>>>>>> based NCO without LUTs and unless you are using a very coarse >>>>>>>>> approximation, without multipliers. >>>>>>>> >>>>>>>> Not sure what you're asking. You a need a LUT, but just one in many >>>>>>>> cases. Having a dual-ported single LUT is easy in an FPGA and >>>>>>>> usually in silicon as well. >>>>>>>> >>>>>>>> What makes a multiplier necessary? I've never found the need, but my >>>>>>>> apps are limited to comm. >>>>>>> >>>>>>> Maybe we aren't on the same page. The multiplier is there for the fine >>>>>>> adjustment. If you are happy with some -60 or -80 dB spurs one LUT is >>>>>>> fine. But if you want better performance the single LUT approach >>>>>>> requires *very* large tables. >>>>>> >>>>>> There are a lot of tricks that can be used to keep the table size >>>>>> down. I've mentioned one already. >>>>> >>>>> And what was that? You have made some 20 or more posts in this thread, >>>>> I don't feel like weeding through all of them to find this. Reading >>>>> back through this thread it seems like your posts are intended to be >>>>> mysterious rather than informative. Every one leaves enough unsaid that >>>>> more questions are needed. >>>> >>>> I can't divulge trade secrets or proprietary information that doesn't >>>> belong to me. I can, however, hint in directions of benefit. Take >>>> it or leave it. >>> >>> I have no idea what you are talking about. If you don't have anything >>> to say, why are you bothering to post? >> >> Why do you care whether I post or not? Feel free to put me in your >> kill file if you don't like my posts. > >If you aren't interested in having a conversation, why do you bother to >type? Above you said you had already mentioned "one" method already. >Clearly that one is not a trade secret. Care to explain what method you >are referring to?
I did later in the same post.
>>> I don't even recall the hints. >>> Or are you forbidden from pointing out what those are? >> >> No, but it seems to me like unnecessary duplication. There are lots >> of hints from multiple people scattered throughout the thread, as well >> as in some of the literature mentioned previously. > >Exactly, scattered in some 50 or so messages. If you have something to >say, why no say it instead of being so vague? Just tell me which >message you are referring to.
So you want me to go back and search through the thread for you? Are you not capable of doing that? I'm not at all clear why you think that I should do the search if you're the one that wants the information.
>>> You said you had already mentioned a way to reduce table size. What was >>> that? >> >> One way is to store a quarter wave instead of a full cycle. I think >> that was mentioned more than once, but here it is again just for you. > >Thank you for the response. > >Yes, that is table reduction 101. Anyone other than a newbie is aware >of that. I believe *I* was the one who in this thread pointed it out to >someone who said memory is cheap not fully appreciating that memory is >order 2^N is size. Even so it is just a factor of four and does nothing >to change the fact that memory is anything but cheap if you are looking >for high resolution and low distortion. Using MBs of memory to store a >LUT is usually not a good trade off. > >What was the technique *you* mentioned as you indicate above?
That was one of them. I mentioned it more than once. In my experience a 4x reduction in memory can be significant, and the quarter-wave trick isn't obvious to some people so I didn't make the assumption that it was. You're welcome. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by rickman December 25, 20142014-12-25
On 12/25/2014 4:32 PM, Eric Jacobsen wrote:
> On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote: > >> On 12/25/2014 3:56 PM, Eric Jacobsen wrote: >>> On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote: >>> >>>> On 12/25/2014 10:52 AM, Eric Jacobsen wrote: >>>>> On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote: >>>>> >>>>>> On 12/23/2014 4:48 PM, Eric Jacobsen wrote: >>>>>>> On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>>> >>>>>>>> On 12/23/2014 10:35 AM, Eric Jacobsen wrote: >>>>>>>>> >>>>>>>>> Many applications don't need separate LUTs to get the required >>>>>>>>> performance, and even then, or even in the case of complex output, it >>>>>>>>> can be done without multipliers. >>>>>>>> >>>>>>>> Care to elaborate on this? I'm not at all clear on how you make a LUT >>>>>>>> based NCO without LUTs and unless you are using a very coarse >>>>>>>> approximation, without multipliers. >>>>>>> >>>>>>> Not sure what you're asking. You a need a LUT, but just one in many >>>>>>> cases. Having a dual-ported single LUT is easy in an FPGA and >>>>>>> usually in silicon as well. >>>>>>> >>>>>>> What makes a multiplier necessary? I've never found the need, but my >>>>>>> apps are limited to comm. >>>>>> >>>>>> Maybe we aren't on the same page. The multiplier is there for the fine >>>>>> adjustment. If you are happy with some -60 or -80 dB spurs one LUT is >>>>>> fine. But if you want better performance the single LUT approach >>>>>> requires *very* large tables. >>>>> >>>>> There are a lot of tricks that can be used to keep the table size >>>>> down. I've mentioned one already. >>>> >>>> And what was that? You have made some 20 or more posts in this thread, >>>> I don't feel like weeding through all of them to find this. Reading >>>> back through this thread it seems like your posts are intended to be >>>> mysterious rather than informative. Every one leaves enough unsaid that >>>> more questions are needed. >>> >>> I can't divulge trade secrets or proprietary information that doesn't >>> belong to me. I can, however, hint in directions of benefit. Take >>> it or leave it. >> >> I have no idea what you are talking about. If you don't have anything >> to say, why are you bothering to post? > > Why do you care whether I post or not? Feel free to put me in your > kill file if you don't like my posts.
If you aren't interested in having a conversation, why do you bother to type? Above you said you had already mentioned "one" method already. Clearly that one is not a trade secret. Care to explain what method you are referring to?
>> I don't even recall the hints. >> Or are you forbidden from pointing out what those are? > > No, but it seems to me like unnecessary duplication. There are lots > of hints from multiple people scattered throughout the thread, as well > as in some of the literature mentioned previously.
Exactly, scattered in some 50 or so messages. If you have something to say, why no say it instead of being so vague? Just tell me which message you are referring to.
>> You said you had already mentioned a way to reduce table size. What was >> that? > > One way is to store a quarter wave instead of a full cycle. I think > that was mentioned more than once, but here it is again just for you.
Thank you for the response. Yes, that is table reduction 101. Anyone other than a newbie is aware of that. I believe *I* was the one who in this thread pointed it out to someone who said memory is cheap not fully appreciating that memory is order 2^N is size. Even so it is just a factor of four and does nothing to change the fact that memory is anything but cheap if you are looking for high resolution and low distortion. Using MBs of memory to store a LUT is usually not a good trade off. What was the technique *you* mentioned as you indicate above? -- Rick
Reply by Eric Jacobsen December 25, 20142014-12-25
On Thu, 25 Dec 2014 16:13:15 -0500, rickman <gnuarm@gmail.com> wrote:

>On 12/25/2014 4:01 PM, Eric Jacobsen wrote: >> On Thu, 25 Dec 2014 12:02:57 -0500, rickman <gnuarm@gmail.com> wrote: >> >>> On 12/25/2014 10:55 AM, Eric Jacobsen wrote: >>>> On Wed, 24 Dec 2014 01:24:42 -0700, Rob Doyle <radioengr@gmail.com> >>>> wrote: >>>> >>>>> I agree that the CORDIC has the same complexity as a multiply. I agree >>>>> that table-based algorithms using multipliers use less FPGA fabric. >>>>> >>>>> I was simply pointing out that there might be places where a CORDIC has >>>>> advantages over LUT-based NCOs. >>>>> >>>>> Especially if have ROM or multiplier limitations. >>>>> >>>>> I also wanted to point out that if you need to do a 20-bit (using your >>>>> 120dB example) complex downconversion for example, the CORDIC still >>>>> requires zero multipliers. >>>>> >>>>> If you want to do a 20-bit complex downconversion using a table-based >>>>> NCO followed by a complex mixer, you might need a *lot* of multipliers. >>>>> If you only have an 18-bit multiplier, each multiplication requires >>>>> (maybe up to) 4 multiplier blocks and you need 8 multiplications. >>>>> >>>>> I also /suspect/ that for any given device technology the CORDIC will >>>>> execute at higher speeds. >>>>> >>>>> Thats all... >>>> >>>> That's been my experience; that if multipliers are scarce or too >>>> expensive, or memory is scarce or too expensive, then a CORDIC is a >>>> nice back-up option. These days multipliers and memory are both >>>> plentiful in most platforms, so CORDICs just aren't as useful as they >>>> used to be. >>> >>> I think the distinction between a multiply and the CORDIC technique is >>> bogus. CORDIC is an iterative process including all the operations that >>> make up a multiply. The only difference is that in many cases there is >>> hardware available that facilitates execution of generic multiplies >>> while the CORDIC must be implemented in detail in every case. >> >> In the past (some of it long ago) when we did tradeoffs on using a >> CORDIC or an NCO, or a CORDIC or a complex mix implemented with >> multipliers, it comes down to resource availability. If multipliers >> are available (either in FPGA fabric or as a module in silicon), then >> a mixer is generally much more efficient with multipliers. If the >> memory is available, then a LUT with a phase accumulator is hard to >> beat for a numeric oscillator. The latency may also tilt the >> tradeoff further away from the CORDIC. >> >> They certainly have their place, but those places have gotten more >> limited as silicon resources get cheaper. > >Let's assume there is no multiplier blocks and no LUTs. Now how is the >CORDIC better than using a multiplies? Just like the CORDIC the >multiplies can be done iteratively using virtually the same logic. >Speed, in most cases, will be determined by the carry chain in the adder >so speed should be about the same.
It could be there isn't much difference, which means if you have a CORDIC laying around, there may not be a reason to not use it.
>>>> The latency is sometimes an issue as well. >>>> >>>> There are still some places where they make sense, though. >>> >>> Care to explain? > >So where are the places where the CORDIC makes sense? > >-- > >Rick
Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by Eric Jacobsen December 25, 20142014-12-25
On Thu, 25 Dec 2014 16:08:45 -0500, rickman <gnuarm@gmail.com> wrote:

>On 12/25/2014 3:56 PM, Eric Jacobsen wrote: >> On Thu, 25 Dec 2014 11:56:15 -0500, rickman <gnuarm@gmail.com> wrote: >> >>> On 12/25/2014 10:52 AM, Eric Jacobsen wrote: >>>> On Tue, 23 Dec 2014 18:10:43 -0500, rickman <gnuarm@gmail.com> wrote: >>>> >>>>> On 12/23/2014 4:48 PM, Eric Jacobsen wrote: >>>>>> On Tue, 23 Dec 2014 11:06:39 -0500, rickman <gnuarm@gmail.com> wrote: >>>>>> >>>>>>> On 12/23/2014 10:35 AM, Eric Jacobsen wrote: >>>>>>>> >>>>>>>> Many applications don't need separate LUTs to get the required >>>>>>>> performance, and even then, or even in the case of complex output, it >>>>>>>> can be done without multipliers. >>>>>>> >>>>>>> Care to elaborate on this? I'm not at all clear on how you make a LUT >>>>>>> based NCO without LUTs and unless you are using a very coarse >>>>>>> approximation, without multipliers. >>>>>> >>>>>> Not sure what you're asking. You a need a LUT, but just one in many >>>>>> cases. Having a dual-ported single LUT is easy in an FPGA and >>>>>> usually in silicon as well. >>>>>> >>>>>> What makes a multiplier necessary? I've never found the need, but my >>>>>> apps are limited to comm. >>>>> >>>>> Maybe we aren't on the same page. The multiplier is there for the fine >>>>> adjustment. If you are happy with some -60 or -80 dB spurs one LUT is >>>>> fine. But if you want better performance the single LUT approach >>>>> requires *very* large tables. >>>> >>>> There are a lot of tricks that can be used to keep the table size >>>> down. I've mentioned one already. >>> >>> And what was that? You have made some 20 or more posts in this thread, >>> I don't feel like weeding through all of them to find this. Reading >>> back through this thread it seems like your posts are intended to be >>> mysterious rather than informative. Every one leaves enough unsaid that >>> more questions are needed. >> >> I can't divulge trade secrets or proprietary information that doesn't >> belong to me. I can, however, hint in directions of benefit. Take >> it or leave it. > >I have no idea what you are talking about. If you don't have anything >to say, why are you bothering to post?
Why do you care whether I post or not? Feel free to put me in your kill file if you don't like my posts.
> I don't even recall the hints. >Or are you forbidden from pointing out what those are?
No, but it seems to me like unnecessary duplication. There are lots of hints from multiple people scattered throughout the thread, as well as in some of the literature mentioned previously.
>You said you had already mentioned a way to reduce table size. What was >that?
One way is to store a quarter wave instead of a full cycle. I think that was mentioned more than once, but here it is again just for you.
>-- > >Rick
Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by rickman December 25, 20142014-12-25
On 12/25/2014 4:01 PM, Eric Jacobsen wrote:
> On Thu, 25 Dec 2014 12:02:57 -0500, rickman <gnuarm@gmail.com> wrote: > >> On 12/25/2014 10:55 AM, Eric Jacobsen wrote: >>> On Wed, 24 Dec 2014 01:24:42 -0700, Rob Doyle <radioengr@gmail.com> >>> wrote: >>> >>>> I agree that the CORDIC has the same complexity as a multiply. I agree >>>> that table-based algorithms using multipliers use less FPGA fabric. >>>> >>>> I was simply pointing out that there might be places where a CORDIC has >>>> advantages over LUT-based NCOs. >>>> >>>> Especially if have ROM or multiplier limitations. >>>> >>>> I also wanted to point out that if you need to do a 20-bit (using your >>>> 120dB example) complex downconversion for example, the CORDIC still >>>> requires zero multipliers. >>>> >>>> If you want to do a 20-bit complex downconversion using a table-based >>>> NCO followed by a complex mixer, you might need a *lot* of multipliers. >>>> If you only have an 18-bit multiplier, each multiplication requires >>>> (maybe up to) 4 multiplier blocks and you need 8 multiplications. >>>> >>>> I also /suspect/ that for any given device technology the CORDIC will >>>> execute at higher speeds. >>>> >>>> Thats all... >>> >>> That's been my experience; that if multipliers are scarce or too >>> expensive, or memory is scarce or too expensive, then a CORDIC is a >>> nice back-up option. These days multipliers and memory are both >>> plentiful in most platforms, so CORDICs just aren't as useful as they >>> used to be. >> >> I think the distinction between a multiply and the CORDIC technique is >> bogus. CORDIC is an iterative process including all the operations that >> make up a multiply. The only difference is that in many cases there is >> hardware available that facilitates execution of generic multiplies >> while the CORDIC must be implemented in detail in every case. > > In the past (some of it long ago) when we did tradeoffs on using a > CORDIC or an NCO, or a CORDIC or a complex mix implemented with > multipliers, it comes down to resource availability. If multipliers > are available (either in FPGA fabric or as a module in silicon), then > a mixer is generally much more efficient with multipliers. If the > memory is available, then a LUT with a phase accumulator is hard to > beat for a numeric oscillator. The latency may also tilt the > tradeoff further away from the CORDIC. > > They certainly have their place, but those places have gotten more > limited as silicon resources get cheaper.
Let's assume there is no multiplier blocks and no LUTs. Now how is the CORDIC better than using a multiplies? Just like the CORDIC the multiplies can be done iteratively using virtually the same logic. Speed, in most cases, will be determined by the carry chain in the adder so speed should be about the same.
>>> The latency is sometimes an issue as well. >>> >>> There are still some places where they make sense, though. >> >> Care to explain?
So where are the places where the CORDIC makes sense? -- Rick