Easy question about pipeline: Is this code synthesizable?

[Enrique (Gast)]

Hello!

I need to make a complex pipeline operation and I want to use this 
structure like a templeta:

--process for calcultation of the equation.
PROCESS(Clk)
BEGIN
    if(rising_edge(Clk)) then
    --Implement the pipeline stages using a for loop and case statement.
    --'i' is the stage number here.
    --The multiplication is done in 3 stages here.
    --See the output waveform of both the modules and compare them.
        for i in 0 to 2 loop 
            case i is 
                when 0 => temp1 <= a*data;
                when 1 => temp2 <= temp1*b;
                when 2 => result <= temp2*c;
                when others => null;
            end case;
        end loop; 
    end if; 
END PROCESS;

I just want to know if this is synthesizable in an Altera Cyclone IV 
with quartus II. Would I have any problem with the FOOR loop?

Any other suggestions about pipeline templates are also welcome....

Thanks.

[Roger S. (edge)]

yes, for loops work just fine in quartus.
Why do you have to obfuscate this, just write:

PROCESS
BEGIN
    wait until rising_edge(Clk);
    --blah...
    temp1 <= a*data;
    temp2 <= temp1*b;
    result <= temp2*c;
END PROCESS;

[J. S. (engineer)]

I do not see any reason at all to use a loop case construction with 
conditional behaviour like this since there are no divergent cases but 
all of the statements will have to be synthesized to make the circiut 
operating.

More over it was wrong to have any condional branches in pipelines 
regarding the space axis. Conditional synthesis makes sence for those 
applications only when pipeline lengths and micro cycles have to be 
dynamically tuned (conditional time axis), which is rarely required.

Furthermore I would recommend not to use those *temp" naming since there 
is nothing temporary about them- neither during synthesis nor during 
operation but they are solid and ever ready calculation results: present 
in any case.

The different "times" which are generated by such a pipeline construct 
within a rising_edge part, should better be named like *_d1,  *_d2 and 
so on to clarify their time relation to each other. Structures invented 
in later times in the pipeline should be named appropriately.

Taking into account that you apply all the incoming vectors 
synchronously, Im afraid, your construct above might be wrong. "b" and 
"c" for example will have to be applied at a later point of time in the 
pipeline, so you will need copies of those values like this here:

b_d1 <= b
c_d1 <= c
c_d2 <= c_d1

and finally apply "b_d1" for the second, and "c_d2" for the final 
multiplication.