Don't care output about dblclockfft HOT 7 CLOSED

Which version are you running? 'x propagation should've been fixed at the end of March in this commit. Are you getting issues with the current version?

Dan

from dblclockfft.

Also, if you would like me to debug your issue, I will need the test script you used to produce the issue above so that I can reproduce it here and narrow down the issue.

Alternatively, feel free to dig into the various FFT stages of the resulting FFT to find out which one is the source of the 'x value, and then produce a trace showing me which internal value is causing it.

In case you aren't familiar with it, the FFT is composed of a number of FFT stages, down from your FFT size down to the qtrstage (FFT size of 4) down to the laststage (FFT size of 2). Chances are the bug is in one of these stages. Each stage passes a data register and sync to the next stage, etc. If you look at the output of the first stage in the chain and you are still seeing 'x propagation, then that's where to look further.

Thanks!

Dan

from dblclockfft.

Hi!

First, thank you the quick reply!

I use the newest verison.

I attach my vivado test bench code.
If you have time, to check my code i would be really aprrieciate.

Máté

`timescale 1ns / 1ns
//////////////////////////////////////////////////////////////////////////////////
// Company:
// Engineer:
//
// Create Date: 16.04.2021 13:39:07
// Design Name:
// Module Name: sim
// Project Name:
// Target Devices:
// Tool Versions:
// Description:
//
// Dependencies:
//
// Revision:
// Revision 0.01 - File Created
// Additional Comments:
//
//////////////////////////////////////////////////////////////////////////////////

module test(

);

reg [4:0] Arr [15:0] = {5'b00000, 5'b00011, 5'b00100, 5'b00011, 
                           5'b00000, 5'b11101, 5'b11100, 5'b11101, 
                           5'b00000, 5'b00011, 5'b00100, 5'b00011, 
                           5'b00000, 5'b11101, 5'b11100, 5'b11101};
//Inputs

reg clk = 0;
reg fsine = 0;
reg rst = 0;
reg i_ce = 0;
wire [9:0] i_sample;
//Outputs
wire [9:0] o_result;
wire o_sync;

//Test

fftmain uut (

.i_clk(clk),
.i_reset(rst),
.i_ce(i_ce),
.i_sample(i_sample),
//Outputs
.o_result(o_result),
.o_sync(o_sync)
);

reg [4:0] adc_reg;
reg [3:0] i = 0;

always @(negedge clk) begin
    if (rst) begin
        adc_reg <= 5'b0;
        i <= 0;
    end
    else begin
        adc_reg <= Arr[i];
        i <= i+1;
    end
end
assign i_sample = {adc_reg,5'b00000};

initial begin
clk = 0;
#1 rst = 1;
#2 rst = 0;
#3 i_ce = 1;
end

always #1 clk = ~clk;

endmodule

from dblclockfft.

Sorry, but I could not duplicate your problem here. Using your test bench, I did not have any issues. All output values were fully defined.

I will notice, however, that your test bench has a potential for delta cycle issues in how you are setting rst and i_ce.

Dan

from dblclockfft.

I think the problem is reading from the cmem hexa file. Maybe this problem is come from that is use a different program, and i use windows, not linux. Anyway, thank you for the reply.

from dblclockfft.

Here's what I have after cleaning up your test bench a touch. I used Icarus Verilog for simulation. Key differences:

1. Everything should transition on the positive edge of the clock. If you are using 1ns clock timing, w/ 1ns precision, there's no time associated with a negative edge. There are no other times available to you other than the positive edge. In hind sight, I'd recommend going back and adjusting your clock timing to 100MHz rather than 1GHz. You are likely to have less problems with the simulator.
2. Your always block now transitions on a positive edge
3. i_rst and i_ce are now set on the positive edge of the clock.
4. I needed to copy the cmem*.hex files into the local directory
5. I also made a small change to the FFT stage to get rid of Icarus Verilog's warnings about setting 14 or 18'bit values with a 32'bit value (i.e. a 32-bit zero!) Expect this change to be pushed soon. It won't affect performance at all, but might get rid of a couple of warnings.

Chances are these will fix your problem.

Dan

from dblclockfft.

I found the solution. In Vivado need to add cmem.hex file as a source file. (In simulation) Now working fine. Thank you again, the help!

from dblclockfft.