2
\$\begingroup\$

I have some Verilog code that simulates correctly. I decided to synthesize it, and I see these warnings that make me uneasy:

 Signal <> missing in the sensitivity list is added for synthesis purposes. HDL and post-synthesis simulations may differ as a result.

About 20 of the same type. I don't WANT those signals to be added to the sensitivity list, I really don't. All I want is it to do things on clock edges, not everytime a signal changes.

Giving it the benefit of the doubt, I changed my process from

 always @(posedge clk or negedge reset)

to:

 always @(*)

And of course none of my stuff worked anymore (in simulation). Probably because the non-blocking statements are now doing stuff every time something changes, rather than waiting for clock edges.

Is there a way to prevent Verilog from doing this? I take it that it thinks my code is combinational, rather than sequential.... But why? Is there a way to tell it that this is sequential and just to use the clk?

Thanks in advance!

Edit, Here is some code, I'm cutting out some of the functionality:

always @(*) begin
    // Some signals here that I apparently can't put in the other one
    // Something about double edges
end

always @(posedge clk or negedge reset) begin

case (!reset)
    0: begin
            // Assign 0 to things       
        end
    1: begin            
        p_spi_done <= spi_done;       // Wants these to be in sensitivity list
        case ((spi_done == 1) && (p_spi_done!=spi_done))
            0:  begin   
                    case (helper_reg)
                    5'b00000: begin
                            // Do something else
                        end
                    5'b00001: begin                     
                            ...
                        end                     
                    5'b00010: begin
                            ....
                        end                     
                    5'b00100: begin
                            i_wData <= i_rDataA[SPI_WIDTH-1:0];
                            i_temp_reg <= i_rDataA[BANK_DATA_WIDTH-1:SPI_WIDTH];
                            helper_reg[3] <= 0;
                        end
                    5'b01000: begin
                            ...
                        end
                    5'b10000: begin
                            ...
                        end
                    default:    begin
                            // Don't know what happened
                            helper_reg <= 0;
                        end
                    endcase                     
                end             
            1:  begin
                    case (cpu_state)
                    0: begin                                // SYNC HAS ARRIVED
                            if (spi_rx_data == SYNC_VALUE) begin
                                cpu_state           <= 1;
                            end
                        end
                    1: begin
                        OPCODE <= spi_rx_data;
                        // Instruction set begins here
                        case (spi_rx_data)
                            0:  begin                               
                                    ...
                                end
                            1:  begin   
                                   ...  
                                end
                            2:  begin
                                   ...
                                end
                            3:  begin                                   // Set maximum count value for watch unit
                                        if (SPI_WIDTH > MAX_COUNT_LENGTH) begin
                                            n_rx                    <= 1;
                                        end
                                        else begin
                                            n_rx                        <= (MAX_COUNT_LENGTH + SPI_WIDTH/2)
                                                                        /SPI_WIDTH;                                 // Compiler truncates
                                        end
                                        cpu_state               <= 2;
                                        helper_reg[5]           <= 1;
                                    end
                            4:      begin                   
                                    end
                            5:      begin
                                        cpu_state <= 2;
                                    end
                            default: begin
                                    end
                        endcase
                    end
                    2: begin                                        // DATA
                        case (OPCODE)
                            0: begin

                                end
                            1: begin

                                end
                            2: begin
                                    .... and it goes on in this fashion
\$\endgroup\$
  • \$\begingroup\$ 1. Does this block have outputs that are used by other parts of our design? If it does, it should not be trimmed in synthesis...If this is just a test, try hooking up the outputs to actual output pins and see if it still gets trimmed. \$\endgroup\$ – The Photon Aug 15 '14 at 18:27
  • 2
    \$\begingroup\$ Please share a some of your code, there might be something else going on. If you want clocking events then you need always @(posedge clk or negedge reset). The always @(*) is for combinational logic, not synchronous logic. \$\endgroup\$ – Greg Aug 15 '14 at 18:29
  • \$\begingroup\$ 2. What Greg said. \$\endgroup\$ – The Photon Aug 15 '14 at 18:30
  • \$\begingroup\$ My code is very long... I mean sure, I'll put some of it up, but I don't know how that will help. \$\endgroup\$ – Mewa Aug 15 '14 at 18:31
  • 1
    \$\begingroup\$ I don't think that's what causes your synthesis issue. But most Verilog I've seen uses if/else when there's only two choices, and most Verilog coders will have an easier time reading your code if you stick to conventional style. I didn't recognize that you were handling the reset with a case statement until after I'd commented. \$\endgroup\$ – The Photon Aug 15 '14 at 18:48
4
\$\begingroup\$
always @(posedge clk or negedge reset) begin

case (!reset)
    0: begin
            // Assign 0 to things       
        end
    1: begin   
            // Do stuff
        end
 endcase

Notice that you have the reset logic inverted.

You have sensitivity to negedge reset, implying you should reset when the reset signal goes low.

But then you actually set things to zero if !reset is low, meaning reset is high.

This basically means you are trying to create flip-flops with sensitivity to two different clock signals, which isn't synthesizable. The synthesis tool probably tried to create an equivalent function from combinatorial logic, which is why it suggested you to expand the sensitivity list.

I think this was the source of your problem.

The conventional way to create flip-flops with low-active syncronous reset is

always @(posedge clk or negedge reset) begin
    if(!reset) begin
        // set things to zero
    end
    else begin
        // do things 
    end
end
\$\endgroup\$
  • \$\begingroup\$ Actually the issue wasn't that. The syntax is just the remnants of me messing around with the posedge/negedge for reset. I used to have posedge before putting this post up. With posedge it simulated correctly, but gave synthesis warnings. Similarly with negedge (once I fixed it), it was suggesting I add more things to the sensitivity list. Once I changed it to if statements, the warnings went away. \$\endgroup\$ – Mewa Aug 15 '14 at 20:35
  • \$\begingroup\$ The thing about VHDL and Verilog is they were originally hardware description languages for simulation but later got re-purposed for synthisis. The result is tools look for specific structures in the code, if you don't follow the idioms (for example by using case instead of if) then they may not recognise what you are trying to do. \$\endgroup\$ – Peter Green Oct 9 '18 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.