Dual Clock FIFO with controlled stream: Verilog

beginner_EDA · Oct 26, 2015

ads-ee said:
Why didn't you run a simulation on the design before implementing it? Debugging a design with signal tap is what you do when the simulation doesn't show any problem, but the errors only occur when the design is implemented.

To be honest I have only little experience working with Modelsim. I got stuck writing testbench especially the part which drive input. Therefore I used signal tap

but as you say it's not a right approach.

As mentioned here:
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_fifo.pdf

"The DCFIFO IP core rdempty output may momentarily glitch when the aclr input is asserted. To
prevent an external register from capturing this glitch incorrectly, ensure that one of the following is true:
• The external register must use the same reset which is connected to the aclr input of the DCFIFO IP
core, or
• The reset connected to the aclr input of the DCFIFO IP core must be asserted synchronous to the
clock which drives the external register.
"
and also in page 17 of same document. Does It have something to do with aclr? In my real design I am also using aclr for Dualclock fifo mixed width.

- - - Updated - - -

or
it is the case in dual clock fifo mixed width, when input data written to FIFO is not exactly multiple/sub multiple of output data.
I mean lets say when Input width is 4 bit and output width is 8 bit and when you write only 20 bits of data which is not multiple of 8. Then only 16 bit data(which is multiple of 8) is read and remaining 4 bit is not read because for last 4 bit rdempty might become high.

ads-ee · Oct 26, 2015

The only full code posted shows you aren't even connecting the aclr, which means it either threw an error and you fixed it or it got hardwired to inactive when synthesized. The document is basically saying have the ACLR synchronous to the read clock on the FIFO if you want to avoid problems caused by the empty flag glitching.

I don't know about Altera (haven't used them for nearly a decade) but with Xilinx the dual clock mixed width FIFO the empty flag does not go inactive until both nibbles are written, if you write 3 nibbles then the empty flag will go inactive after the 2nd nibble and will stay inactive when the 3rd nibble is written. When the first byte is read (nibbles 1 & 2) the empty would go active (3rd nibble alone won't keep the empty inactive).

If Altera doesn't behave this way then you'll have to add the fullness count to the FIFO an monitor that yourself and generate empty when the count is < 2.

beginner_EDA · Oct 26, 2015

ads-ee said:
if you write 3 nibbles then the empty flag will go inactive after the 2nd nibble and will stay inactive when the 3rd nibble is written. When the first byte is read (nibbles 1 & 2) the empty would go active (3rd nibble alone won't keep the empty inactive).

what you mentioned here might be the reason. I write into dual clock mixed width fifo regardless whether it is multiple of output or not and read from it unless not empty. This problem is seen for me when I read the fifo, stop reading based on empty signal and then again start reading. Then I have mostly this trouble.

ads-ee said:
you'll have to add the fullness count to the FIFO an monitor that yourself and generate empty when the count is < 2.

Fullness count might be the solution but how to implement this?

Is this right approach ?

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
reg [1: 0] nibble_count ; 
always @ posedge (rd_clk)
begin
    nibble_count <= nibble_count + 1;
     if (fifo_empty) && (nibble_count < 2)
       begin
         custom_fifo_empty <= 1;
      end
end

ads-ee · Oct 26, 2015

No regenerate a new FIFO core, with the read count added.

beginner_EDA · Oct 30, 2015

Hi,
This dual clock fifo mixed width seems to work for me only when input is multiple/submultiple of output. otherwise I have to solve the riddle till I have no success.

So, I chose following way:

For another case where input 8 bit and output 32 bit, I used as:

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
//source component
input  Tx_fifo_write;
output Tx_fifo_full;
input Tx_fifo_wclk;
input [7:0] Tx_input_to_fifo;
 
reg [31:0] input_to_fifo;
 
reg [7:0] adc_value [0:3]; 
reg [1:0] idx = 0; 
 
always @ (posedge Tx_fifo_wclk)
 
 begin
  if ((Tx_fifo_full == 0) && (Tx_fifo_write == 1))
  idx <= idx + 1;
  adc_value[idx] <= Tx_input_to_fifo;
end
 
always @ (posedge Tx_fifo_wclk)
    begin
           if (idx == 0)
             begin  
                
                    if(Tx_fifo_full == 1)
                       begin
                            Tx_fifo_write_in <= 0;
                        end
                    else
                      begin 
                          Tx_fifo_write_in <= Tx_fifo_write;
                          input_to_fifo <= {adc_value[0], adc_value[1], adc_value[2], adc_value[3]};
                      end
            end
    end
 
 
 
 
dcfifo  
    #(
        .intended_device_family ("Cyclone IV"),
        .lpm_numwords(65536),
        .lpm_showahead("OFF"),
        .lpm_type("dcfifo"),
        .lpm_width(32),
        .lpm_widthu(16),
        .overflow_checking("ON"),
        .rdsync_delaypipe(4),
        .read_aclr_synch("ON"),
        .underflow_checking("ON"),
        .use_eab("ON"),
        .write_aclr_synch("ON"),
        .wrsync_delaypipe(4)
    )
    Inst_RxFIFO (
        .aclr(),
        .wrclk(Tx_fifo_wclk),
        .wrreq(Tx_fifo_write_in),
        .wrfull(Tx_fifo_full),
        .data(input_to_fifo),
        .rdclk(Tx_fifo_rclk),
        .rdreq((Tx_fifo_read) && (!Tx_fifo_empty)),
        .rdempty(Tx_fifo_empty),
        .q(Tx_output_from_fifo)
    );

Do you think this is a right approach and will work? I am choosing this because of rdempty glitch in mixed width fifo, which I was not able to solve.

Regards

ads-ee · Oct 30, 2015

That will work. I've done similar stuff in the past. Though you should have just run a simulation instead of asking.

vGoodtimes · Oct 31, 2015

@ads_ee
agree. Run a simulation. This thread is multiple days old, and a sim of this level takes a day at most.

@op
My observations are that you pre-write an invalid/zero as idx starts at zero and idx=0 is the write qualification. I don't think the question was about that. This part of the design might be pipelined, or handeled in a different manner. In some applications with ADC's, dropping samples is important to report. This is to the point that injecting invalid data may be preferable in an effort to maintain timing.

You're problems mostly stem from a lack of familiarity with latency+feedback, aka hazards. You also don't fully appreciate pipelined designs. The read "glitch" is not actually a glitch. It is an unfamiliarity with single-cycle feedback and a preference to single-cycle+register-output designs. Likewise, the 4:1 packer you have will write an invalid value at the start because you don't want to pipeline the input.

I personally dislike the proposed solution because I dislike misleading logic names. A "fifo_rd" or "fifo_wr" should either be correct, or should be (strongly) commented. Saying "fifo_rd" makes me think "fifo IS read" not "fifo maybe read if you want but if not it's ok we won't judge you". IMO, the only thing worse than random signal names is misleading signal names.

(that said, naming/commenting signals by sample+cycle delay can be useful)

Welcome to EDAboard.com

Dual Clock FIFO with controlled stream: Verilog

beginner_EDA

Full Member level 4

ads-ee

Super Moderator

beginner_EDA

beginner_EDA

Full Member level 4

ads-ee

Super Moderator

beginner_EDA

Full Member level 4

ads-ee

Super Moderator

vGoodtimes

Advanced Member level 4

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Connect with us

Online statistics

Forum statistics