Verilog – How to Create a Nested For-Loop in Verilog

crclfsrverilog

I try to create a CRC module on Verilog.

The CRC calculating use an LFSR and can be fully-sequential (with two cycles), semi-sequential (with one cycle) or parallel. I have already made sequential module. And I try to create a fully-parallel. There is some code-generators for fixed methods (like "CRC-16 modbus" or "CRC-32 Ethernet"). But I want to create an universal parametrizade parallel module.

With for-loop expression I create a prametrized LFSR.

module main 
#(
parameter LFSR_SIZE     = 16,
parameter START_VALUE   = 'hFFFF,
parameter POLYNOME      = 'h8005)
(
input           clk,    
input           n_reset,    
output reg  [LFSR_SIZE-1:0]lfsr);

integer lfsr_index;

always @(posedge clk) begin
    if(n_reset) begin       
        lfsr[0] <= lfsr[LFSR_SIZE - 1];             
        for(lfsr_index = 1; lfsr_index < LFSR_SIZE; lfsr_index = lfsr_index + 1) begin
            if( ((1 << lfsr_index) & POLYNOME) == 0) begin
                lfsr[lfsr_index] <= lfsr[lfsr_index - 1];                   
            end
            else begin
                lfsr[lfsr_index] <= lfsr[lfsr_index - 1] ^ lfsr[LFSR_SIZE - 1];
            end
        end     
    end
    else begin
        lfsr <= START_VALUE;                
    end
end
endmodule

Is it possible to generate number of shifts of the LFSR with a nested loop (two loops, one inside other)?
If answer is "no" does the nested loop usefull expression in some case?

Best Answer

The essential thing of a for-loop in HDL is the nonblocking assignment. With nonblocking assignments you can direct some wires through the loop and direct other wires around the loop.

data_internal = data_in; 
crc_shift = crc_internal ^ (data_internal << (CRC_SIZE - DATA_SIZE));           
for(int data_index = 0; data_index < DATA_SIZE; data_index++) begin
    msb = crc_shift[CRC_SIZE-1];
    crc_lfsr = (crc_shift << 1);                    
    for(int crc_index = 1; crc_index < CRC_SIZE; crc_index++) begin
        if(((1 << crc_index) & POLYNOME) != 0) begin
            crc_lfsr[crc_index] = crc_lfsr[crc_index] ^ msb;
        end
    end
    crc_lfsr[0] = msb;                  
    crc_shift = crc_lfsr;
end         
crc_internal = crc_shift;
crc_out = crc_shift;

But in you case there is no need to use two cycles. You can replace the inner cycle with the following expression:

crc_lfsr = crc_lfsr ^ ({CRC_SIZE{msb}} & POLYNOME);

Completely it will look like this:

module main 
#(      
parameter IS_CRC_REVERSED   = 1,
parameter IS_DATA_REVERSED  = 1,
parameter DATA_SIZE         = 8,    
parameter CRC_SIZE          = 16,
parameter START_VALUE       = 'hFFFF,
parameter POLYNOME          = 'h8005)
(
input       clk,    
input       n_reset,    
input       [DATA_SIZE-1:0]data_in,
output reg  [CRC_SIZE-1 :0]crc_out);    

reg [CRC_SIZE-1 :0]crc_internal;
reg [DATA_SIZE-1:0]data_internal;
reg msb;
reg [CRC_SIZE-1 :0]crc_shift;
reg [CRC_SIZE-1 :0]crc_lfsr;    

always @(posedge clk) begin
    if(n_reset) begin
        // data reverse
        if(IS_DATA_REVERSED) begin
            for(int i = 0; i < DATA_SIZE; i++) begin
                data_internal[i] = data_in[DATA_SIZE - 1 - i];
            end
        end
        else begin
            data_internal = data_in; 
        end     
        // CRC calculating
        crc_shift = crc_internal ^ (data_internal << (CRC_SIZE - DATA_SIZE));           
        for(int data_index = 0; data_index < DATA_SIZE; data_index++) begin
            msb = crc_shift[CRC_SIZE-1];
            crc_lfsr = (crc_shift << 1);                    
            crc_lfsr = crc_lfsr ^ ({CRC_SIZE{msb}} & POLYNOME);
            crc_lfsr[0] = msb;                  
            crc_shift = crc_lfsr;
        end         
        crc_internal = crc_shift;
        // CRC reverse
        if(IS_CRC_REVERSED) begin
            for(int i = 0; i < CRC_SIZE; i++) begin
                crc_out[i] = crc_shift[CRC_SIZE - 1 - i];
            end
        end
        else begin
            crc_out = crc_shift; 
        end
    end
    else begin
        crc_internal =  START_VALUE;
    end
end
endmodule

Related Solutions

Electronic – Implementing parallel CRC in verilog

This is a good example of mismatch in results between simulation and synthesis.

If you will synthesize this code and run a test on FPGA - it will work (at least you'll not see constant hash value). However, in simulation it behaves differently:

always @(*) construct means "evaluate the following block of code any time any of the signals used on the right hand side of the assignment change". In your code these signals are: data_in, poly and hashValue.
If none of the above signals change (which is the case you're describing, right?) - the block will not be evaluated by simulator and the assignments won't be made.

Once again - synthesis tool will produce the correct logic for this code, therefore these kind of bugs are very dangerous.

There correct way to handle this is to define a clock signal and use a sequential always @(posedge clk) construct.

Furthermore, it seems that you have at least two combinatorial loops in your code. Even if they are intended - this is very bad practice. You want to avoid using any synthesizable comb loop.

However, by inspection of your code, it seems that circular reference here is just for convenience - maybe it will not synthesize into comb loop. In this case you have two options:

Find an equivalent form which does not use circular reference
Use Verilog function construct.

The first approach is the correct one - Verilog is not a programming language, and the statements you are using to describe logic must be maximally similar to the inferred logic. However, this approach may be tricky, since many algorithms are written in software forms. Therefore you might use the second approach, in which case the code will look like this (not tested):

always @(posedge clk)
begin
  hashValue[15:0] <= calcNewHashValue(hashValue[15:0], poly[15:0], data_in[3:0]);
end

Where calcNewHashValue is the function encapsulating the for loop from your code.

Once again: if synthesis tool warns you about comb loops you mustn't use this design. In this case either think of other algorithmic implementation, or spread the calculation on several clock cycles.

You may also want to read this paper in order to get a deeper understanding of Verilog simulators behavior.

Except for that, your coding style is very bug-prone. As a guideline, I suggest you will define a separate always block for each signal. In other words - just one signal is assigned over in always block. Make exceptions only where you can't handle it other way, and think carefully before each such decision.

Electrical – Verilog loop for multiple always blocks

I learned […] every reg needs to have his own always block…

I think you've got this backwards. Each register should only be assigned to by one always block. However, this doesn't mean you need a separate always block for each register! It's perfectly safe (and, in fact, quite normal) to have a single always block for all the synchronous logic in a module, e.g.

always @(posedge clk) begin
    if (reset) begin
        A <= 4'b0;
        B <= 4'b0;
        …etc…
    end else begin
        …etc…
    end
end

What if I have a loop, lets say something like this:

You can't do that in a loop.

Verilog loops are for generating multiple copies of repeated logic. They are not a substitute for clocked logic -- if you need to perform multiple actions, you will probably need to make them happen on separate clocks, and implement them in a state machine.

Depending on what you need to happen, there might be some way to "unroll" the loop and make several iterations happen in a single clock. However, you will need to be very careful about how you implement this. Making multiple levels of branching logic run in a single clock cycle is generally inadvisable; data dependencies will severely limit the clock rate of such a design.

Best Answer

Related Solutions

Electronic – Implementing parallel CRC in verilog

Electrical – Verilog loop for multiple always blocks

Related Topic