Pipeline stage was synthesised out?

[Florian Schlembach]

I am dealing with a synchronised design where I implement pipeline stages after each operation:

-------------code snippet start -------------
wire strobe_sq_round;
reg strobe_sq_round_reg;

round_sd #(.WIDTH_IN(31),.WIDTH_OUT(16)) round_q
(.clk(clock),
.reset(reset),
.in({sq_q_reg[35],sq_q_reg[29:0]}),
.strobe_in(strobe_sq_reg),
.out(sq_round_q),
.strobe_out(strobe_sq_round));

always @(posedge clock) begin
if(strobe_sq_round) begin
sq_round_q_reg <= sq_round_q;
end

strobe_sq_round_reg <= strobe_sq_round;
end

always @(posedge clock) begin
if(strobe_sq_round) begin
sq_round_i_reg <= sq_round_i;
sq_round_q_reg <= sq_round_q;
end

strobe_sq_round_reg <= strobe_sq_round;
end

sign_extend #(.bits_in(16), .bits_out(18)) sign_extend_cu_q (.in(sq_round_q_reg), .out(sq_se_q));

MULT18X18 cube_q
(.P(cu_q), .A(sq_se_q), .B(din_se_q_reg));
-------------code snippet end -------------

The pipeline stage strobe_sq_round_reg/sq_round_q_reg gets synthesised out so that the output of the round_q module is routed directly through the sign_extend_cu_q module and the cube_q multiplier. See the synthesis result (actually its RTL schematic, but post-synthesis is the same) here: http://en.zimagez.com/full/087847bf2784decb329a618ec91320d45c13c37f3b44500b6924c0fb25bf0a9df56d98a656f458ebe08c16c817e3357f9596159c2bbcfea7.php

As a consequence, I am getting a critical path because the rounding operation is performed within the same cycle of the mult-op.

How does it come that my pipeline stage gets optimised out and how do I prevent it?

Thanks!

 

[Florian Schlembach]

hopefully, this link works better http://qupload.com/images/087847bf27.png

 

[GaborSzakacs]

Florian Schlembach wrote:

I am dealing with a synchronised design where I implement pipeline stages after each operation:

-------------code snippet start -------------
wire strobe_sq_round;
reg strobe_sq_round_reg;

round_sd #(.WIDTH_IN(31),.WIDTH_OUT(16)) round_q
(.clk(clock),
.reset(reset),
.in({sq_q_reg[35],sq_q_reg[29:0]}),
.strobe_in(strobe_sq_reg),
.out(sq_round_q),
.strobe_out(strobe_sq_round));

always @(posedge clock) begin
if(strobe_sq_round) begin
sq_round_q_reg <= sq_round_q;
end

strobe_sq_round_reg <= strobe_sq_round;
end

always @(posedge clock) begin
if(strobe_sq_round) begin
sq_round_i_reg <= sq_round_i;
sq_round_q_reg <= sq_round_q;
end

strobe_sq_round_reg <= strobe_sq_round;
end

sign_extend #(.bits_in(16), .bits_out(18)) sign_extend_cu_q (.in(sq_round_q_reg), .out(sq_se_q));

MULT18X18 cube_q
(.P(cu_q), .A(sq_se_q), .B(din_se_q_reg));
-------------code snippet end -------------

The pipeline stage strobe_sq_round_reg/sq_round_q_reg gets synthesised out so that the output of the round_q module is routed directly through the sign_extend_cu_q module and the cube_q multiplier. See the synthesis result (actually its RTL schematic, but post-synthesis is the same) here: http://en.zimagez.com/full/087847bf2784decb329a618ec91320d45c13c37f3b44500b6924c0fb25bf0a9df56d98a656f458ebe08c16c817e3357f9596159c2bbcfea7.php

As a consequence, I am getting a critical path because the rounding operation is performed within the same cycle of the mult-op.

How does it come that my pipeline stage gets optimised out and how do I prevent it?

Thanks!



Did you add the register after building the code without it? It looks

like a case of the tools using stale data. I've seen this a million
times with Xilinx ISE. The standard workaround is to "clean up" the
project using Project --> Cleanup Project Files...
When that doesn't work, I exit ISE, and delete the sub-folders it
generated under my project directory. That usually cleans out any
remaining history.

--
Gabor