I have a verilog module that contains an FSM.

I have extracted parts of it for this post below.

ISE XST issues warning that all the FF associated with the reg variables shown are removed and I don't understand why.

Any insights please

One of the warnings: Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . This FF/Latch will be trimmed during the optimization process.

If you look below - bit 3 of RedRam_Data3 is clearly set.

    reg [7:0] RedRam_Data1, RedRam_Data1_next, RedRam_Data2, RedRam_Data2_next, 
             RedRam_Data3, RedRam_Data3_next, RedRam_Data4, RedRam_Data4_next;  
    reg [5:0] Stream1_Counter, Stream2_Counter, Stream3_Counter, Stream4_Counter;
    reg [6:0] Stream1_Counter_next, Stream2_Counter_next, Stream3_Counter_next, 

    localparam Bit_1_Compare_Value = 6'd14;

    always @(posedge clk)

        RedRam_Data1 <= RedRam_Data1_next;
        RedRam_Data2 <= RedRam_Data2_next;
        RedRam_Data3 <= RedRam_Data3_next;
        RedRam_Data4 <= RedRam_Data4_next;  

        Stream1_Counter <= Stream1_Counter_next[5:0];
        Stream2_Counter <= Stream2_Counter_next[5:0];
        Stream3_Counter <= Stream3_Counter_next[5:0];
        Stream4_Counter <= Stream4_Counter_next[5:0];


    always @*
        Stream1_Counter_next = Stream1_Counter;
        Stream2_Counter_next = Stream2_Counter;
        Stream3_Counter_next = Stream3_Counter;
        Stream4_Counter_next = Stream4_Counter;

            Stream1_Counter_next = Stream1_Counter + 1;

            Stream1_Counter_next = Stream2_Counter + 1;

            Stream1_Counter_next = Stream3_Counter + 1;

            Stream1_Counter_next = Stream4_Counter + 1;

        RedRam_Data1_next = RedRam_Data1;
        RedRam_Data2_next = RedRam_Data2;
        RedRam_Data3_next = RedRam_Data3;
        RedRam_Data4_next = RedRam_Data4;       


           if(Stream1_Counter > Bit_1_Compare_Value)
               0: RedRam_Data1_next[7] = 1'b1;
               1: RedRam_Data1_next[6] = 1'b1;
               2: RedRam_Data1_next[5] = 1'b1;
               3: RedRam_Data1_next[4] = 1'b1;
               4: RedRam_Data1_next[3] = 1'b1;
           end // #7

           if(Stream2_Counter > Bit_1_Compare_Value)
               0: RedRam_Data2_next[7] = 1'b1;
               1: RedRam_Data2_next[6] = 1'b1;
               2: RedRam_Data2_next[5] = 1'b1;
               3: RedRam_Data2_next[4] = 1'b1;
               4: RedRam_Data2_next[3] = 1'b1;
           end // #7

           if(Stream3_Counter > Bit_1_Compare_Value)
               0: RedRam_Data3_next[7] = 1'b1;
               1: RedRam_Data3_next[6] = 1'b1;
               2: RedRam_Data3_next[5] = 1'b1;
               3: RedRam_Data3_next[4] = 1'b1;
               4: RedRam_Data3_next[3] = 1'b1;
           end // #7

           if(Stream4_Counter > Bit_1_Compare_Value)
           begin // #7
               0: RedRam_Data4_next[7] = 1'b1;
               1: RedRam_Data4_next[6] = 1'b1;
               2: RedRam_Data4_next[5] = 1'b1;
               3: RedRam_Data4_next[4] = 1'b1;
               4: RedRam_Data4_next[3] = 1'b1;
           end // #7

  • 1
    \$\begingroup\$ Did it work perfectly in all respects, in simulation? If not, synthesis may have identified opportunities for "optimisation" that you did not intend. \$\endgroup\$ – Brian Drummond Feb 19 at 19:00
  • \$\begingroup\$ Simulates as expected. The warning says that the optimizer will remove the FF which suggests to me that execution on the actual FPGA will not match simulation -- or am I wrong in that belief? \$\endgroup\$ – JHinkle Feb 19 at 19:51
  • \$\begingroup\$ Maybe, maybe not. I don't do Verilog, so I can't tell if Stream3_Counter ever gets incremented; I can't see anything that would increment it. So this : " bit 3 of RedRam_Data3 is clearly set" si not at all clear to me. However if you say it simulates as you would expect, normally synth results will do exactly the same. \$\endgroup\$ – Brian Drummond Feb 19 at 20:18
  • \$\begingroup\$ A Thought: RedRam_Data1 is a FF that holds a bit from a Ram Data Byte. I am sending each bit out an output port. The Ram Data Byte does not change during that whole process so could the optimizer just be routing the bit directly from the Data Byte and NOT perform the extra pipline stage I have in place by discreetly pulling the data bit on it's own? \$\endgroup\$ – JHinkle Feb 19 at 20:29
  • \$\begingroup\$ A Thought. Pay attention when using the paste key. \$\endgroup\$ – Brian Drummond Feb 19 at 21:15

"any insights please"

Test reasonably fully in simulation. Preferably with a self checking testbench which reports whether or not what ought to happen, actually is happening.

Almost always - as here - if synthesis is trimming away your code, it is because your code isn't actually doing anything, so it can safely be removed without affecting the result.

Proceeding to synthesis without testing reasonably well in simulation is doing things the hard way.

On quick projects I don't always test everything ... at first.

But if I see something suspicious in synth, as you did here, I revisit the testbench and add tests for it, so that

If you look below - bit 3 of RedRam_Data3 is clearly set.

... is actually demonstrated ... and then if it isn't, further tests to reveal why not (e.g. is that counter counting?)

| improve this answer | |

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.