UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Scholar embedded
Scholar
3,387 Views
Registered: ‎06-09-2011

Clock to Reset timing failed!.

Hi all,

 

I am designing with XC7A15t-3FGG484. I have ADC data bus of 500 MHz DDR coming to FPGA. I also write these data to External SRAM memory with 250MHz clock - by doubling the data width. For reading ADC I first use IBUFDS, then I use IDDR and input clock is fed to MMCM(PLL) with a shift!. So, I have 500MHz clock and data bus. I have read in FPGA datasheet that I can use 506 MHz maximum clock for Built-in FIFO with -3 speed grades!. 

I don't see why timing fails in this part!. Below picture shows the schematic of failing paths which are all Reset Synchronizer clock to reset pin of IDDR module?!

Untitled.jpg

Here is details regarding these failed paths:

Summary				
Name	Path 1			
Slack	-1.104ns			
Source	AdcReset_INST/oSyncRst_reg/C   (rising edge-triggered cell FDPE clocked by oClk_AdcClk  {rise@0.250ns fall@1.250ns period=2.000ns})			
Destination	Adc_INST[5].ChbIDDR_inst/R   (rising edge-triggered cell IDDR clocked by oClk_AdcClk  {rise@0.250ns fall@1.250ns period=2.000ns})			
Path Group	oClk_AdcClk			
Path Type	Setup (Max at Slow Process Corner)			
Requirement	1.000ns (oClk_AdcClk fall@1.250ns - oClk_AdcClk rise@0.250ns)			
Data Path Delay	1.419ns (logic 0.341ns (24.039%)  route 1.078ns (75.961%))			
Logic Levels	0  			
Clock Path Skew	-0.037ns			
Clock Uncertainty	0.051ns			
				
Source Clock Path				
Delay Type	Incr (ns)	Path (ns)	Location	Netlist Resource(s)
(clock oClk_AdcClk rise edge)	(r) 0.250	0.250		
	(r) 0.000	0.250	Site: V4	iAdcClk_P
net (fo=0)	0.000	0.250		AdcClk_INST/U0/iClk_p
IBUFDS (Prop_ibufds_I_O)	(r) 0.818	1.068	Site: V4	AdcClk_INST/U0/clkin1_ibufgds/O
net (fo=1, routed)	0.987	2.055		AdcClk_INST/U0/iClk_AdcClk
PLLE2_ADV (Prop_plle2_adv_CLKIN1_CLKOUT0)	(r) -6.485	-4.429	Site: PLLE2_ADV_X1Y0	AdcClk_INST/U0/plle2_adv_inst/CLKOUT0
net (fo=1, routed)	1.268	-3.161		AdcClk_INST/U0/oClk_AdcClk
BUFG (Prop_bufg_I_O)	(r) 0.076	-3.085	Site: BUFGCTRL_X0Y0	AdcClk_INST/U0/clkout1_buf/O
net (fo=107, routed)	1.291	-1.794		AdcReset_INST/oClk
			Site: SLICE_X65Y28	AdcReset_INST/oSyncRst_reg/C
				
Data Path				
Delay Type	Incr (ns)	Path (ns)	Location	Netlist Resource(s)
FDPE (Prop_fdpe_C_Q)	(r) 0.341	-1.453	Site: SLICE_X65Y28	AdcReset_INST/oSyncRst_reg/Q
net (fo=16, routed)	1.078	-0.375		sAdcRst
IDDR			Site: ILOGIC_X1Y48	Adc_INST[5].ChbIDDR_inst/R
Arrival Time		-0.375		
				

I may ignore these errors by setting set_max_delay constraint. However, I don't know if it affects my final system or not?

 

I would appreciate any help,

Hossein

0 Kudos
5 Replies
Historian
Historian
3,344 Views
Registered: ‎01-23-2009

Re: Clock to Reset timing failed!.

Please see your other post (https://forums.xilinx.com/t5/Timing-Analysis/ODDR-Clock-to-reset-Timing-Failure/td-p/783485) for answers to both issues (which are really the same).

 

So, I have 500MHz clock and data bus. I have read in FPGA datasheet that I can use 506 MHz maximum clock for Built-in FIFO with -3 speed grades!. 

 

Be very careful with these numbers. These simply mean that the cells themselves will operate at these clock rates. It doesn't imply that it will be easy to get timing closure at these clock rates. Meeting timing is a function of the path, and the path needs to be placed and routed, and has issues such as clock skew and jitter. In theory, if Xilinx publishes a number, then some circuit can be designed that will run this cell at that frequency, but no one said it would be easy.

 

In general, running at or near these frequencies is VERY challenging - it requires very careful design, and "ideal" conditions for the tools (very low utilization, very little fanout, very low jitter clocks, etc...)

 

It is also worth noting that paths to and from "fixed" resources (BRAMs, DSP48s, and IOB resources) tend to be the hardest ones to meet timing at high clock rates.

 

Avrum

Tags (1)
0 Kudos
Highlighted
Scholar embedded
Scholar
3,325 Views
Registered: ‎06-09-2011

Re: Clock to Reset timing failed!.

Hi @avrumw

thank you so much for you helpful comment. yes, Your are right removing reset or fixing it to 0 would solve this issue. I could do it. However, I got stuck to another problem I have explained in the part of my first post. I am going to write this data in the Block RAM. if I decrease the RAM capacity that helps PAR use just one block I don't see any timing issue - With this boundary speed of 500MHz write. If I use higher RAM capacity which means more than one block I see timing errors specially for internal routing!. i am wondering if I can do anything to solve this problem of not!..

Below is a description of internal signals for this Dual Port RAM when capacity forces the PAR to use to memory blocks!.. 

Summary				
Name	Path 1			
Slack	-0.032ns			
Source	MyFifo_INST/U0/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gl0.wr/wpntr/gic0.gc1.count_d1_reg[0]_replica/C   (rising edge-triggered cell FDRE clocked by oClk_AdcClk  {rise@0.500ns fall@1.500ns period=2.000ns})			
Destination	MyFifo_INST/U0/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gl0.wr/gwas.wsts/ram_full_fb_i_reg/D   (rising edge-triggered cell FDRE clocked by oClk_AdcClk  {rise@0.500ns fall@1.500ns period=2.000ns})			
Path Group	oClk_AdcClk			
Path Type	Setup (Max at Slow Process Corner)			
Requirement	2.000ns (oClk_AdcClk rise@2.500ns - oClk_AdcClk rise@0.500ns)			
Data Path Delay	2.161ns (logic 1.299ns (60.120%)  route 0.862ns (39.880%))			
Logic Levels	4  (CARRY4=2 LUT4=2)			
Clock Path Skew	0.145ns			
Clock Uncertainty	0.048ns			

 Below picture is a vague schematic of those internal signals:

Untitled.jpg

I appreciate any help.

0 Kudos
Historian
Historian
3,320 Views
Registered: ‎01-23-2009

Re: Clock to Reset timing failed!.

 i am wondering if I can do anything to solve this problem of not!..

 

It will be very difficult.

 

As I said earlier, 500MHz is very aggressive. Your design has to be very carefully architected to attain this speed. This path appears to be in an IP core generated FIFO, and hence you have little control over how it is implemented. The path in question has 4 levels; 2 LUTs and 2 CARRY chains, - this is likely just too much for 500MHz clock operation. 

 

The problem gets worse as you add more storage since the block RAMs are big blocks. The physical separation from eachother means any shared signals have to travel far to get to both RAMs. This routing cost is simply too much for operation at this speed.

 

The ideal solution is to drop the clock speed. Investigate whether your datapath could be implemented at twice the width at half the clock rate - all of these problems will disappear at 250MHz. You can keep your 500MHz clock domains near the I/O but rapidly move stuff to the 250MHz domain and do all the work there.

 

Also, it looks like this is a block RAM based FIFO - you might get better timing from the built-in FIFO - this is an option in the IP catalog.

 

Avrum

Tags (1)
0 Kudos
Scholar embedded
Scholar
3,314 Views
Registered: ‎06-09-2011

Re: Clock to Reset timing failed!.

Hi,

Thank you for your answers. I should add that the incoming data has 500 MHz of clock. I use concatenation to change the length of data and this way I use WE signal at half of the input data speed. Is this change the clock constraint and paths to something like multi-cycle? Would it then help me correct this error?

 

 

Thanks,

Hossein

0 Kudos
Historian
Historian
3,311 Views
Registered: ‎01-23-2009

Re: Clock to Reset timing failed!.

I use concatenation to change the length of data and this way I use WE signal at half of the input data speed. Is this change the clock constraint and paths to something like multi-cycle? Would it then help me correct this error?

 

If you use the same 500MHz clock, do the concatenation and write on every other clock cycle, then this does (at least partly) become a multicycle path - this would not change the clock constraint, but would use the set_multicycle_path exception.

 

BUT you cannot use multicycle path constraints to the address ports of RAM (that will cause system failures) - it would probably be OK for the data, but not the address (there is a specific note in the user guide about this - (see UG473, Table 1-18, footnote 1). In general, I stay away from things like that.

 

Instead, you should generate a clock that runs at 250 and is in phase with your 500MHz clock. You are using a PLL, so just generate the 250MHz clock from another output of the PLL and use the same kind of buffer (BUFG). These clocks will be in phase, so you just need to do your concatenation and then do a synchronous transfer between the two domains - this will be a 2ns path, but will be the "last" 2ns path in your system. Then you can do any other processing you need on the 250MHz domain.

 

Avrum