Spectral Purity Measurement

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.

-- 

Rick

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.


> The latency is sometimes an issue as well.
>
> There are still some places where they make sense, though.

Care to explain?

-- 

Rick

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.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

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.

>
>> The latency is sometimes an issue as well.
>>
>> There are still some places where they make sense, though.
>
>Care to explain?
>
>-- 
>
>Rick

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

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?  I don't even recall the hints. 
Or are you forbidden from pointing out what those are?

You said you had already mentioned a way to reduce table size.  What was 
that?

-- 

Rick

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

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

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

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

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