SystemVerilog FIFO implementation

[logari84]

Hi all.

I've been looking for a FIFO implementation in SystemVerilog and unfortunately I couldn't find anything. So I decided to make one and post it here just in case someone needs it in the future.

---

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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
/****************************************************************************************************************
 
    STAMATIS POULIOS, 28/07/2015
 
    File name: fifo.sv
    
    Description: Generalized fifo. Stores 'IN_BUS_WIDTH'-wide words. The depth of the fifo is defined by the value
                 of the 'FIFO_DEPTH' variable.
 
****************************************************************************************************************/
 
`ifndef FIFO__SV
`define FIFO__SV
 
//***************************************************************************************************************
// Defines section
//***************************************************************************************************************
`define FIFO_DEPTH      32
`define IN_BUS_WIDTH    5
`define FIFO_CNT_WIDTH  5
 
//***************************************************************************************************************
// Module declaration: fifo
//***************************************************************************************************************
module fifo
(
    input logic clk,
    input logic rst,
    input logic [`IN_BUS_WIDTH-1:0] data_in,
    input logic rd_en,
    input logic wr_en,
    output logic empty,
    output logic full,
    output logic [`IN_BUS_WIDTH-1:0] data_out
);
 
logic [`FIFO_DEPTH-1:0][`IN_BUS_WIDTH-1:0] buff_mem;
logic [`FIFO_CNT_WIDTH-1:0] rd_ptr, wr_ptr;
logic [`FIFO_DEPTH-1:0] status;
// The 'status' signal indicates the status of the Nth memory position. Value '1' indicates new data is stored
// in the Nth memory position, but not yet read. Value '0' indicates that the data from that memory position is
// read and the memory position is available for writing new data.
 
 
always@(data_out)
begin
    assign empty = (status == 0);
    assign full = (status == {(`FIFO_DEPTH){1'b1}});
end
 
always@(posedge clk or posedge rst)
begin
    if(rst)
    begin
        data_out <= 0;
        buff_mem <= 0;
        status <= 0;
        rd_ptr <= 0;
        wr_ptr <= 0;
    end
    else
    begin
        data_out <= data_out;
        buff_mem[wr_ptr] <= buff_mem[wr_ptr];
        rd_ptr <= rd_ptr;
        wr_ptr <= wr_ptr;
        if( rd_en && !empty )
        begin
            data_out <= buff_mem[rd_ptr][`IN_BUS_WIDTH-1:0];
            status[rd_ptr] <= 1'b0;
            rd_ptr <= rd_ptr + 1;
        end
        else if( wr_en && !full )
        begin
            buff_mem[wr_ptr] <= {data_in};
            status[wr_ptr] <= 1'b1;
            wr_ptr <= wr_ptr + 1;
        end
    end
end
 
 
endmodule
 
`endif

---

P.S. I want to upload the source code for the FIFO and for the testbench but I get an error about incompatible file... Is not .sv supported??

 

[dpaul]

I am sure someone will benefit from it sometime.
Did you try to upload your work as a Blog post? SV files types might be supported there.

 

[logari84]

I joined the forum quite recently and I don't know how things work. I just pushed the "attachments" button when I was composing the original post. Then a pop-up window appeared and I tried to upload files from there. I don't know if this is what you mean.

 

[dpaul]

No no, this is a normal Forum. There is a completely different Blogs section from edaboard. Look at the top of this webpage and you'll find it there. In my opinion, a Blog is a better place to share such things.
Else take the help of any of the Moderators in this Forum and they can advice you what to do.

 

[ads-ee]

The only thing I see that is SV is the use of logic. What's the point? Other than that everything else will compile as standard Verilog.

Also I have a issue with using defines for things like the following:

`define FIFO_DEPTH      32
`define IN_BUS_WIDTH    5
`define FIFO_CNT_WIDTH  5

What if I have 6 FIFOs, that are all different sizes?

Haven't you ever done any real design reuse code? These should all be parameters not defines, defines should never be used in synthesizable code unless it's used to select mutually exclusive options that change the design for say different product families or enable simulation only code. I also typically use them as the design's version/id code. Even then you still might want to avoid using them altogether as they are GLOBAL.

As most FPGA vendor tools now allow defining the top level parameters/generics in the compilation scripts/gui you can avoid using any kind of defines or such in your code even for the above mentioned uses. Though I typically use a script to generate a single version file that gets used during compilation, so that script normally gets automatically called each time the build process is run.

- - - Updated - - -

Oh, besides what I've already mentioned, I don't think your design can handle a simultaneous read and write. Only the read will occur and the write gets ignored.

 

[logari84]

Nice feedback 'ads-ee'. In my design I have all the parameters in a separate file. I use the defines just for the simulation. This is actually a sample code for the logic of the FIFO. I usually work with VHDL so whenever I want to use a component that is generic I just use a tool to produce it (e.g Altera megafunction wizard). In SV I don't know how things work, so when I searched for a FIFO implementation I found nothing. That's why I designed a FIFO (for the needs of my project. Not very generic). The simultaneous read/write operation is something I haven't considered since it was something I never need in my design. I can improve that though.

 

[vGoodtimes]

data_out <= data_out;
buff_mem[wr_ptr] <= buff_mem[wr_ptr];
rd_ptr <= rd_ptr;
wr_ptr <= wr_ptr;

These are actually implied and don't need to be added. This is the same in VHDL. The only one of concern is the buff_mem[wr_ptr] one, as it might infer something other than a RAM.

The buff_mem probably can't be reset either if you want to infer optimized structures for larger fifos. Both xilinx and altera have coding guidelines if you want to make use of these structures.

FIFO implementations typically use either a size counter, the read/write pointers, or the pointers plus a full/empty bit. There isn't a need to store a 'valid' bit for every location. After all, you won't ever have a state of "00010101010011", that would be invalid. You only have states like "0011111000000", which can be defined as the difference between the read address and write address. if they are the same, the fifo is either empty or full. thus a read that makes the pointers the same means empty, and a write that makes them the same means full.