NCO and FIR COmpiler Megafunction performance

Thanks FvM

u were rite, problem was with sampling rate, which by mistake was set to 1.0E7

after setting it to 1E8,

the O/P is good, though not smooth, but frequency wise its good.

thanks

see attachement.

--- Quote Start ---

the O/P is good, though not smooth, but frequency wise its good.

--- Quote End ---

Yes the overflow problem mentioned in my previous post isn't yet solved.

--- Quote Start ---

Yes the overflow problem mentioned in my previous post isn't yet solved.

--- Quote End ---

I don't see overflow problem since it is 18 bits + 18bits => 19 bits

--- Quote Start ---

I don't see overflow problem since it is 18 bits + 18bits => 19 bits

--- Quote End ---

I know that this is a popular misunderstanding of Verilog (and VHDL too) expression length evaluation.

First point, even without understanding the overflow cause in Verilog terms, the waveforms don't allow any doubt about it.

In the below assignment, both input variables are 18 bit and the variable receiving the sum is 19 bit.

mix <= fsin_o +fsin_o_2;

The mistake is in assuming that the assignment LHS would determine the expression length, but it doesn't. It's the maximum bit length of involved input terms, 18 bit in this case. Please refer to the detailed and instructive chapter 5.4 expression bit lengths in IEEE Std 1364.

To avoid overflows, you have to extend one of both input terms before the add operation to 19 bit (with sign extension). Or use the simple trick suggested in the Verilog specification, add an integer 0 which extends the intermediate result to 32 bit.

mix <= fsin_o +fsin_o_2 + 0;

Thanks FvM for the note. However in that case it is not really misunderstanding of verilog(or vhdl) by the designer but rather misunderstanding of designer by verilog or vhdl.

common sense tells me that if result is 19 bits and operands are 18 bits then why on earth would the result depend on input width and not output width.

Normally in vhdl adder inference - a far as I remember - it does not let input width be less than output forcing in effect avoidance of this scenario,

So in short, it is a ludicrous mistake in the standards to be that misleading.

In VHDL, the result length of an add operation is just the same, the length of the largest summand. There's however an important difference that helps you to avoid the observed overflow problem, VHDL doesn't allow to assign the 18 bit sum to a 19 bit variable:

Error (10344): VHDL expression error at unsigned_adder.vhd(27): expression has 18 elements, but must have 19 elements

In VHDL, an automatic length extension of add result would be unwanted, because an overflow within the same result width is often required, e.g. for counters.

In less strictly typed Verilog, an automatic extension would be an option, but obviously the language designers decided differently.

For understanding the effect of no. of bits of output, i wrote a simple code :

module testing (in1, in2, out,out1, out2);
input  in1;
input  in2;
output  out;
output  out1;
output  out2;
assign out = in1 + in2;
assign out1 = in1 + in2;
assign out2 = in1 + in2;
endmodule 

this design i simulated with unsigned decimals. in1 and in2 = 1 to 36;

the various outputs are as shown in attachment.

http://www.alteraforum.com/forum/attachment.php?attachmentid=6206&stc=1&d=1345964169

The same design i simulated for signed decimal input. and result is :

http://www.alteraforum.com/forum/attachment.php?attachmentid=6207&stc=1&d=1345964401

CLEARLY :

I believe, in verilog, if we assign a higher no. of bits to output, the result doesnt vary or affected by the nature of input viz. signed/unsigned etc.

what do u think ??

Thanks for example, I have to correct my previous statement. In the discussed assignment, the expression bit length is context determined. So kaz was right about correct evaluation to 19 bit.

mix <= fsin_o +fsin_o_2 + 0;

The waveforms seems to indicate an overflow, but it's actually the result of a wrong number display format, signed instead of unsigned. The same thing happens in your example.

You have to care however, that NCO output and FIR filter are using the same number representation. If they are different, the filter will get a distorted input signal. I guess this happens in your test. You can change from unsigned (offset binary) to signed representation by inverting the MSB.

I apologize for causing confusion.

Thank FvM.

So I believe even though the binary arithmetic performed may be right, but its not fully correct till its correct interpretation, and thats what the key feature of implementing signal processing on FPGAs : representation !!

:)