cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
abyssion
Observer
Observer
492 Views
Registered: ‎06-24-2016

Correction of HDL using post synthesis timing report

Jump to solution

Dear community,

First I would like to apologize in advance if my question has already been asked, I couldn't find my answer. I also would like to apologize if the matter is trivial, I am still learning!

---- Context ----

As written in the title, I am hard time to understand the timing report and to modify the HDL to meet the timing requirement after synthesis. I am aware that the timing report of the synthesis part is only an estimation. However, the synthesis takes 2h to run when implementation needs more than 12h (depending on the implementation strategy) and gives a large timing violation. I would like to reduce the timing issues at the synthesis level before going to the implementation part. Does it make sens?

The problem is, even after reading many documents and watching some Xilinx videos I am still not able to understand how to correct the timing issues from the information that are given by the timing report of Vivado. I tried to apply the recommendation of the Xilinx documents (see sources) for clocking, pipelining, CDC, constraints etc but I am still not able to understand. I cannot share the whole design, but I will show an example that represent most of my timing issues (this circuit is reproduced 1008 times using generate notation of VHDL language).

---- Example ----

VHDL

 

-- clk_xi is a Clock at 300MHz provided by a BUGCE_DIV
Xi_Output : process(clk_xi) 
	Variable Xireg0 	: signed(INT+DEC downto 0);
begin
	if rising_edge(clk_xi) then		
                -- Signal Pm2 from a DSP
		Xireg	<= shift_right(Pm2, 5); 
                -- Xiprev_reg is a pipelined value, attribute shreg_extract: false
		Xireg0 	:= Xiprev_reg(8) & "000000"; 
                -- Addition using Carry8
		Xireg1 	<= Xireg(INT+2*12 downto (2*12)-DEC) + Xireg0;
                -- Output and conversion from signed to std_logic
		Xi      <= std_logic_vector(Xireg1);
	end if;
end process;

 

Timing report

clk_xi_summury.PNGclk_xi_summury_detail.PNG

The path 10001

PathV1.PNGPathV2.PNG

Schematic

Schematic_clocking.PNGSchematic_path.PNG

---- Constraints ----

My constraints file currently possess

  • The properties related to I/O
  • The primary clock: create_clock -period 10.000 -name clk_primary [get_ports clk_p]
  • The property USER_MAX_PROG_DELAY set at 3 for the 3 clock I am using (it seems that it does not change a lot for synthesis)
  • A bunch of set_false_path for unrelated signal (unrelated to the timing issues I am showing here).
  • And, a set of USER_SLL_REG and USER_SLR_ASSIGNMENT (which does not seems to change much things for synthesis either)

---- Problem ----

I still don't understand if the problem is from the clock or from the circuit. In any case, why does it occurs and how to fix it? If it is from the clock (whose input is in SLR1 that is currently spanning all the device), would it be better to have a clock input per SLR (which is the case in the XUP-VPP board)? I may have missed some part of the documents (see sources) or might have missed some document. Any help would be greatly appreciated. Please let me know if you need more details.

Thanks a lot!

---- Configuration----

Windows 10

Vivado 2018.3

FPGA: XCVU13P

Board: XUP-VVP provided by Bittware

---- Sources ----

UG972 on large FPGA

UG899 io and clock planning

UG901 on synthesis

UG903 using contraints

UG906 design analysis

UG938 closure tutorial

UG949 design methodology

WP380 SSI technology

WP480 timing closure methodology

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
433 Views
Registered: ‎01-23-2009

* Why hold time failures are expected and how the implementation process solve such "failures"?

Hold time failures are when the data path delay is shorter than the sum of the clock skew and the clock uncertainty. The clock skew is a function of placement - at synthesis time only an estimate is used. So it is pointless to fix it at synthesis time.

At implementation time, if there is a hold time failure, the tool fixes it by adding some extra delay to the data path in order to make it larger than the sum of the skew and the uncertainty. The delay is done by adding extra routing - taking a longer path between the cells on the data path. This fix is purely a routing fix - there is no change to the netlist (synthesis only creates/understands the netlist - not the physical implementation). For all these reasons hold time fixing is done at implementation time.

* Basically, the answer is, it does not make sens to try to fix Hold time < 100ps after synthesis, why 100ps? Is it a hardware limitation?

Hold time failures can exist for two reasons

  • The "normal" skew between flip-flops on the same clock or on closely related clocks, which is what I described above
    • These will be very small violations; less than 100ps or 200ps; the magnitude is bounded by the sum of the clock skew and uncertainty, which should be in this range in these cases
    • These will be fixed during implementation
  • When there is a "bad" clock crossing between clock domains that are not properly balanced have different freqencies
    • These would be much larger violations
    • These are errors that must be fixed in the design
    • So if you see large hold violations after synthesis, you need to look at them to see what you did wrong

Avrum

View solution in original post

4 Replies
avrumw
Guide
Guide
469 Views
Registered: ‎01-23-2009

This is a hold time violation. Hold times are only fixed during implementation. Small hold time failures (less than a few hundred picosecond) are normal and expected after synthesis, and should be ignored.

You can tell it is a hold time from the "Path Type" in the timing report (and the fact that you selected it from the "Hold" part of the path navigation pane.

Avrum

0 Kudos
abyssion
Observer
Observer
446 Views
Registered: ‎06-24-2016

Thank you for your answer.

 

* Why hold time failures are expected and how the implementation process solve such "failures"?

* Basically, the answer is, it does not make sens to try to fix Hold time < 100ps after synthesis, why 100ps? Is it a hardware limitation?

 

Thanks

0 Kudos
avrumw
Guide
Guide
434 Views
Registered: ‎01-23-2009

* Why hold time failures are expected and how the implementation process solve such "failures"?

Hold time failures are when the data path delay is shorter than the sum of the clock skew and the clock uncertainty. The clock skew is a function of placement - at synthesis time only an estimate is used. So it is pointless to fix it at synthesis time.

At implementation time, if there is a hold time failure, the tool fixes it by adding some extra delay to the data path in order to make it larger than the sum of the skew and the uncertainty. The delay is done by adding extra routing - taking a longer path between the cells on the data path. This fix is purely a routing fix - there is no change to the netlist (synthesis only creates/understands the netlist - not the physical implementation). For all these reasons hold time fixing is done at implementation time.

* Basically, the answer is, it does not make sens to try to fix Hold time < 100ps after synthesis, why 100ps? Is it a hardware limitation?

Hold time failures can exist for two reasons

  • The "normal" skew between flip-flops on the same clock or on closely related clocks, which is what I described above
    • These will be very small violations; less than 100ps or 200ps; the magnitude is bounded by the sum of the clock skew and uncertainty, which should be in this range in these cases
    • These will be fixed during implementation
  • When there is a "bad" clock crossing between clock domains that are not properly balanced have different freqencies
    • These would be much larger violations
    • These are errors that must be fixed in the design
    • So if you see large hold violations after synthesis, you need to look at them to see what you did wrong

Avrum

View solution in original post

abyssion
Observer
Observer
427 Views
Registered: ‎06-24-2016

Thanks a lot for your clear and complete explanation!

0 Kudos