cancel
Showing results for
Show  only  | Search instead for
Did you mean:
Contributor
1,200 Views
Registered: ‎04-13-2018

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

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?

Founder https://trustcoinmining.com
I'm a Donde Voy with Poolish.
1 Solution

Accepted Solutions
Xilinx Employee
1,192 Views
Registered: ‎05-22-2018

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

9 Replies
Xilinx Employee
1,193 Views
Registered: ‎05-22-2018

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

Teacher
1,183 Views
Registered: ‎06-16-2013

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,

Xilinx Employee
1,182 Views
Registered: ‎05-14-2008

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

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------
Contributor
1,157 Views
Registered: ‎04-13-2018

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

thanks.

Founder https://trustcoinmining.com
I'm a Donde Voy with Poolish.
Moderator
1,130 Views
Registered: ‎03-16-2017

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.

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
Guide
1,107 Views
Registered: ‎01-23-2009

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

Contributor
1,073 Views
Registered: ‎04-13-2018

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.

Founder https://trustcoinmining.com
I'm a Donde Voy with Poolish.
Guide
1,052 Views
Registered: ‎01-23-2009

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

Xilinx Employee
1,039 Views
Registered: ‎05-14-2008

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

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------