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