# What's the actual cause of unbalanced combinational logic?

So far when I find timing issues, I try to pipeline combinational logic. It always works.

Today, my Quartus Compilation Report show up -ve slack values. I double check it with TimeQuest Timing Analyzer and found the Data Path is crossed over two pipelines.

It is strange to me as most of the time the data path starts and ends within a pipeline.

I check the Report timing Closure Recommendations and it recommend:

In general, balancing the number of combinational nodes on the timing paths within a domain
results in optimal performance.
The number of combinational nodes on each listed path is greater than the number of combinational
nodes that drive its source or are driven by its destination.

The following suggestions may help resolve this issue:
- Restructure the appropriate HDL code to balance the number of combinational nodes.
- Turn on physical synthesis retiming.

See the Top Recommendations section for potential solutions for each path.

Move 4 combinational nodes before the source and 0 after the destination for the path from ref_data...ue:queue|wptr[0] to ref_data...an0~2_OTERM13646 [hide details]
Issue: Unbalanced Combinational Logic

From:ref_data_top:ref_data_top_inst | ref_data_core:ref_data_core_inst | entity53_parser2:parser53 | queue:queue|wptr[0]
To:ref_data_top:ref_data_top_inst | ref_data_core:ref_data_core_inst | trgs:trgs_inst | trg:gen_trg[11].trg | LessThan0~2_OTERM13646

TimeQuest analysis: report timing

Nodes to move after dest:
0
Nodes to move before source:
4

• Without looking at your code, I am guessing that you have opportunity to add a pipeline register between *wptr[0] and *OTERM13646 by moving some (4?) nodes after *wptr[0]. Please share the code if you'd like more help. – shparekh Mar 27 at 19:37