What's difference? on synthesis logic, when TNS/WNS problem solve?

[trustfarm]

Hello,

I've synthesis problem , over 300Mhz clock and UART code.

original codes are

	reg [15:0] delay_cnt = 16'd0;
	reg [9:0] state = 10'd1023, outgoing = 10'd1023;

	assign uart_tx = outgoing[0];
	assign tx_ready = state[0] & ~rx_new_byte;


	always @ (posedge clk)
	begin
		delay_cnt <= delay_cnt + 16'd1;

And, then synthesized Error with WNS/TNS negative value.

So, changed following ways of loop reduction way. (I don't assure it will reduce loop or not, anyway it solve WNS/TNS problem on spot.)

codes' are here :: insert temporal register  reg [15:0] next_cnt = 16'd0;

for doing increment counter.

	reg [15:0] delay_cnt = 16'd0;
	reg [15:0] next_cnt = 16'd0;
	reg [9:0] state = 10'd1023, outgoing = 10'd1023;

	assign uart_tx = outgoing[0];
	assign tx_ready = state[0] & ~rx_new_byte;


	always @ (posedge clk)
	begin
	    next_cnt = delay_cnt + 1;
	    delay_cnt <= next_cnt;
		//delay_cnt <= delay_cnt + 16'd1;

What's difference?

And , I've changed clock more higher, another place has inform TNS/WNS warns.

and, then another place TNS/WNS error.
Is there more good way of solve this issues?

[rshekhaw · Accepted solution]

Hi @trustfarm ,

What you just did was pipelining  due to which logic level has reduced and the design met the timing. In you figure you will see under the Levels column that it has value of 5.

So if you check the same path in the working RTL design it should have been reduced.

Thanks,

Raj

[watari]

Hi @trustfarm 

I guess it was changed clock path delay or clock uncertainty value by modification of RTL code.

I suggest you to make sure them in report file.

Best regards,

[viviany]

If you're checking the timing result only in the Synthesized design, it is not necessary to make changes only to resolve a -0.025ns slack.

The post-synthesis timing result is estimated as no place and routing at this point.

Usually a -25ps slack can be resolved by placement and routing.

If you see >-300ps slack in the synthesized design, that should be taken care of at this stage of the flow.

It is common that you resolves this timing violation but sees other paths fail.

You can try to resolve the most worst violations first and then the others.

For timing closure techniques, you can refer to UG949.

-vivian

[trustfarm]

please refer this thread for problem solving when PNR.

https://forums.xilinx.com/t5/Timing-Analysis/After-PNR-TNS-has-very-big-failure-and-Running-FPGA-it-stops/td-p/964104

@viviany  @watari  @rshekhaw  

thanks.

[hemangd]

Hi @trustfarm ,

I do not see any issues at synthesis level. Please close the thread if you do not expect anything further from this thread.

Synthesis shows estimated values of timing paths. Hence, prefer after implementation.

[avrumw]

What you just did was pipelining due to which logic level has reduced and the design met the timing.

Based on the code that was posted this isn't the case.

The assignment to 'next_cnt' is a blocking assignment (uses the = assignment, not the <= assignment). Since it is a blocking assignment, it behaves as a temporary variable to the remainder of the clocked process - hence this temporary variable does not infer a pipeline level. If the next_cnt is not used anywhere outside this process, and is given a value before it is used on all branches of the block where it is used, then this infers a net in the synthesized design (not a flip-flop).

Assuming next_cnt is only assigned and used where you show it, then the code with next_cnt is functionally identical to the increment operation shown in the comments. The timing difference (of 0.025ns) is, as others have said, is meaningless, and is from the chaotic nature of synthesis - while the two forms are structurally identical, they are not identical code, and that can lead to different (but equivalent) implementations with different timing characteristics.

Avrum

[trustfarm]

@avrumw  Thanks for reply. 

So, I did correct codes like this , change = to <=

next_cnt <= delay_cnt + 1;

then what's different?

And, Can you check and Advice on implementation process timing problem solving?

https://forums.xilinx.com/t5/Timing-Analysis/After-PNR-TNS-has-very-big-failure-and-Running-FPGA-it-stops/m-p/964289#M16558

Thank you very much.

[avrumw]

So, I did correct codes like this , change = to <=

next_cnt <= delay_cnt + 1;

then what's different?

This is a completely different piece of code. Now you no longer have a counter that increments on every clock, but, instead, have a counter that increments on every other clock. On one clock edge "next_cnt" takes its new value (delay_cnt+1), and on the next clock that new value ("next_cnt") gets loaded back into "delay_cnt".

Avrum

[viviany]

I would run a simulation to check the difference after the code change rather than ask others.

You can also check the schematic in the synthesized design to see the difference in netlist.

-vivian