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: 
Contributor
Contributor
1,727 Views
Registered: ‎01-08-2014

Timing issue with slack ...

Jump to solution

 

Hi,

 

I have a problem in my design with EDK 14.7.

 

The problem is negative slack, this is a report:

 

 15 paths analyzed, 15 endpoints analyzed, 2 failing endpoints
 2 timing errors detected. (2 setup errors, 0 hold errors)
 Maximum delay is   5.139ns.
--------------------------------------------------------------------------------
Slack:                  -0.139ns (requirement - (data path - clock path skew + uncertainty))
  Source:               interpolator_a/interpolator_a/INTERPOLATOR/interpolator_x0/interpolator_00b59b03ac/expression1/pipe_11_18_0 (FF)
  Destination:          fifo_a/fifo_a/FIFO_DUAL_CLOCK_128B/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[8].ram.r/s6_noinit.ram/SDP.SIMPLE_PRIM18.ram (RAM)
  Requirement:          5.000ns
  Data Path Delay:      4.260ns (Levels of Logic = 1)
  Clock Path Skew:      -0.612ns (2.064 - 2.676)
  Source Clock:         clk_200_0000MHz_pos rising at 95.000ns
  Destination Clock:    clk_10_0000MHz_pos rising at 100.000ns
  Clock Uncertainty:    0.267ns

  Clock Uncertainty:          0.267ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter (TSJ):  0.070ns
    Discrete Jitter (DJ):       0.286ns
    Phase Error (PE):           0.120ns

  Maximum Data Path at Slow Process Corner: interpolator_a/interpolator_a/INTERPOLATOR/interpolator_x0/interpolator_00b59b03ac/expression1/pipe_11_18_0 to fifo_a/fifo_a/FIFO_DUAL_CLOCK_128B/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[8].ram.r/s6_noinit.ram/SDP.SIMPLE_PRIM18.ram
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X32Y155.AQ     Tcko                  0.476   interpolator_a_rd
                                                       interpolator_a/interpolator_a/INTERPOLATOR/interpolator_x0/interpolator_00b59b03ac/expression1/pipe_11_18_0
    SLICE_X33Y156.B6     net (fanout=4)        0.337   interpolator_a_rd
    SLICE_X33Y156.B      Tilo                  0.259   modulator_a/modulator_a/sysgen_dut/modulator_x0/dvb_t_encoder_2a6b5213ee/dvb_t_ifft_70a903e8b6/black_box/INTERLEAVER_CORE/sig00001092
                                                       fifo_a/fifo_a/FIFO_DUAL_CLOCK_128B/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/tmp_ram_rd_en1
    RAMB16_X3Y78.ENB     net (fanout=15)       2.938   fifo_a/fifo_a/FIFO_DUAL_CLOCK_128B/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/tmp_ram_rd_en
    RAMB16_X3Y78.CLKB    Trcck_ENB             0.250   fifo_a/fifo_a/FIFO_DUAL_CLOCK_128B/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[8].ram.r/s6_noinit.ram/SDP.SIMPLE_PRIM18.ram
                                                       fifo_a/fifo_a/FIFO_DUAL_CLOCK_128B/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.mem/gbm.gbmg.gbmga.ngecc.bmg/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[8].ram.r/s6_noinit.ram/SDP.SIMPLE_PRIM18.ram
    -------------------------------------------------  ---------------------------
    Total                                      4.260ns (0.985ns logic, 3.275ns route)
                                                       (23.1% logic, 76.9% route)

The data path reaches the constraints without problems with Levels of Logic = 1, but how resolve slack ?

 

 

How can I instruct the tool to solve automatically ?

 

It is possible ?

 

Thanks.

 

moreasm

0 Kudos
1 Solution

Accepted Solutions
Scholar watari
Scholar
2,238 Views
Registered: ‎06-16-2013

Re: Timing issue with slack ...

Jump to solution

Hi @moreasm

 

Sorry.

I'm sure that ISE doesn't support a constraint of clock latency.

So, I just show previous command.

 

I think that if you implemented clock buffer and this buffer was clock source and set location constraint, you might be able to adjust clock skew.

But it is difficult or can't do it...

 

Best regards,

0 Kudos
12 Replies
Scholar watari
Scholar
1,722 Views
Registered: ‎06-16-2013

Re: Timing issue with slack ...

Jump to solution

Hi @moreasm

 

Do you want to fix this negative slack even if clock domain is different ?

If yes, I recommend to use PLL to adjust clock phase. But I think that this is asynchronous path.

 

Generally, this path is asynchronous path, if this constraint is correct, and no body fix this negative slack.

 

Best regards,

 

0 Kudos
Contributor
Contributor
1,697 Views
Registered: ‎01-08-2014

Re: Timing issue with slack ...

Jump to solution

Hi watari,

 

thanks for replay.

 

  Source Clock:         clk_200_0000MHz_pos
  Destination Clock:    clk_10_0000MHz_pos

This two clock is synchronous with same PLL.

 

> If yes, I recommend to use PLL to adjust clock phase.

 

The clock domain is the same, 200 MHz is main clock of FIR, 10 MHz is data clock a input of FIR.

 

Without phase shift is possible ?

 

moreasm

0 Kudos
Scholar watari
Scholar
1,692 Views
Registered: ‎06-16-2013

Re: Timing issue with slack ...

Jump to solution

Hi @moreasm

 

I'm sure that the route cause is clock path skew and/or fanout issue.

I suggest to reduce this clock path skew or change this value from minus value to plus value or duplicate ff to fix fanout issue.

Ex. floor plan or force placement, set duplicate ff and so on.

 

Best regards,

 

 

0 Kudos
Contributor
Contributor
1,682 Views
Registered: ‎01-08-2014

Re: Timing issue with slack ...

Jump to solution

Hi watari,

 

> I'm sure that the route cause is clock path skew and/or fanout issue.

 

I am convinced too, I thought that the tool alone could fix it.

 

> I suggest to reduce this clock path skew or change this value from minus value to plus value ...

 

How reduce clock path skew ?

 

It is not possible that the tool does it automatically, do you confirm ?

 

Thanks.

 

moreasm

 

0 Kudos
Scholar watari
Scholar
1,662 Views
Registered: ‎06-16-2013

Re: Timing issue with slack ...

Jump to solution

Hi @moreasm

 

Would you refer the followings ?

 

# How to adjust clock skew

Here is description to adjust clock skew in XDC

 

set_clock_latency -source -early x.xx [get_clocks targetClock]

set_clock_latency -source -late y.yy [get_clocks targetClock]

 

# Other solution

You describe FF's location to reduce path delay. (This is example. You need to modify "SLICE_X5Y70" which is location information.)

 

set_property LOC SLICE_X5Y70 [get_cells interpolator_a/interpolator_a/INTERPOLATOR/interpolator_x0/interpolator_00b59b03ac/expression1/pipe_11_18_0]

 

Best regards,

 

0 Kudos
Contributor
Contributor
1,652 Views
Registered: ‎01-08-2014

Re: Timing issue with slack ...

Jump to solution

Hi watari,

 

> Here is description to adjust clock skew in XDC

 

Sorry but how use "XDC" with EDK 14.7 ? Is possible ? I have no idea how you can use it, can you explain it to me ?

 

> You describe FF's location to reduce path delay.

 

I preferred the tool to do it by itself, but if there is no other way, I will follow your advice.

 

Thanks very much.

 

moreasm

 

 

0 Kudos
Scholar watari
Scholar
1,643 Views
Registered: ‎06-16-2013

Re: Timing issue with slack ...

Jump to solution

Hi @moreasm

 

Sorry.

Could you describe the following command on UCF file ?

You need to adjust the location constraint (SLICE_X5Y70).

 

INST“interpolator_a/interpolator_a/INTERPOLATOR/interpolator_x0/interpolator_00b59b03ac/expression1/pipe_11_18_0”LOC=SLICE_X5Y70

 

Best regards,

0 Kudos
Contributor
Contributor
1,637 Views
Registered: ‎01-08-2014

Re: Timing issue with slack ...

Jump to solution

Hi watari,

 

the command:

 

 

INST“interpolator_a/interpolator_a/INTERPOLATOR/interpolator_x0/interpolator_00b59b03ac/expression1/pipe_11_18_0”LOC=SLICE_X5Y70

 

 

place the component "pipe_11_18_0" exactly in slice positionated at "SLICE_X5Y70", on this I agree. With this "constraint" I should meed timing.

 

But how adjust clock skew in XDC with EDK 14.7 ? Or is it enough to use manual positioning ?

 

I'm sorry for the stupid questions, but it's still not clear enough to me.

 

Thanks.

 

moreasm

0 Kudos
Scholar watari
Scholar
2,239 Views
Registered: ‎06-16-2013

Re: Timing issue with slack ...

Jump to solution

Hi @moreasm

 

Sorry.

I'm sure that ISE doesn't support a constraint of clock latency.

So, I just show previous command.

 

I think that if you implemented clock buffer and this buffer was clock source and set location constraint, you might be able to adjust clock skew.

But it is difficult or can't do it...

 

Best regards,

0 Kudos
Historian
Historian
1,104 Views
Registered: ‎01-23-2009

Re: Timing issue with slack ...

Jump to solution

OK - lets take a couple of steps back...

 

First, what are you trying to do here. It appears that you have a RAM that is running at 10MHz, but that the control signals (the only one we can see is the ENA) is coming from a clock domain that is running at 200MHz.

 

Even assuming that

  - these two clocks come from the same source - i.e. the same MMCM or PLL

  - these two clocks go through the same kind of buffer (i.e. both BUFG)

 

This path makes very little sense. If you can only write to the RAM at 10MHz how does your 200MHz domain figure out when to assert the control signals to the 10MHz domain? Do you have a state machine that is providing the cycle relationship between the two domains? i.e. is there a control signal in the 200MHz domain that says "The next edge of the 200MHz clock will correspond to the rising edge of the 10MHz clock", or are you just keeping every signal asserted for twenty 200MHz clocks to be sure that one of them corresponds to the rising edge of the 10MHz clock (where the RAM operation will happen?

 

Second, how big is this RAM. You show us one instance, but the fanout on the ENB signal is 15 - does this mean that you are simultaneously enabling 15 RAMs? In fact, the fanout of 15 comes from a LUT, and the flip-flop driving it has a fanout of 4 - are there more RAMs in this group of RAMs?

 

RAMs are big - physically big. They are also arranged in columns on the die, and the columns of RAMs are physically far apart from each other. Having one signal drive the enable of a large number of RAMs means that there is a single driver that has to be routed from go from somewhere (usually the middle of the column of RAMs) to both the top and the bottom. This distance requires a significant amount of routing, and is the source of your problem here - it cannot place the driver in a place that it can meet timing to all the destinations.

 

Furthermore, you have made this worse by making this a (synchronous) clock crossing path. Even if the clocks come from the same MMCM and go through the same buffer, the clock skew between these is more than you will see on a single clock domain.

 

These two things added together are the source of your problem.

 

So first, look at this architecturally - if you are driving a large number of RAMs in parallel you may need to think (carefully) about the fanin/fanout of the RAM - you may need more pipeline stages to distribute these control signals.

 

Second, if you are going to do this, don't do it on a clock crossing path. Can you (for example) cross between the FFs on the 200MHz domain to generate FFs on the 10MHz domain and then have these FFs drive the RAM? This increases your latency to the RAM by one 10MHz clock, but will completely fix the RAM fanout issue. And while the 200MHz FF -> 10MHz FF path will still have a larger than normal clock skew, it has no fanout, so it won't be a problem.

 

So, this is not a tool issue - no tool option or constraint is going to fix it. This is an architecture problem; you need to modify your architecture to make a system that can meet timing.

 

Finally, the path report looks a little odd (but it has been a while since I used ISE). Can you give us the TIMESPEC that this failing path belongs to? Is it a normal PERIOD constraint, or is it some kind of FROM TO constraint?

 

Avrum

0 Kudos
Highlighted
Contributor
Contributor
1,094 Views
Registered: ‎01-08-2014

Re: Timing issue with slack ...

Jump to solution

Hi avrumw,

thank you for your interest.

> First, what are you trying to do here.

 

FIR structure.png

I have a FIR interpolator along 70 taps (Half-Band) with 8 channels. The input sample rate is 10 MHz and FIR uses a clock of 200 MHz for use only 8 DSPs (one per channel). The interpolator are made with System Generator.

The "rfd" signal si generate from 200 MHz domain clock and ramain high for 20 clock cycle (200 MHz / 10 MHz = 20 cycles). This "rfd" signal go to "RD" input FIFO, dual clock FIFO "wr" 100MHz / "rd" 10 MHz "2K * 128 bit" (8 ch * 16 bit), on 10 MHz domain.

I thought it would be more "smooth" to restrict the 200 MHz only to the necessary parts (FIR interpolator) and use a slower clock for the input. The output of FIR interpolator go to other very small distribuited FIFO (16 * 128 bit) that run at 200 MHz.

All clocks are synchronous and generated by the same PLL :

- 200 MHz
- 100 MHz
- 10  MHz

Using System Generator in the 200 MHz clock domain, then 10 MHz signals are generated by this domain.

> ... how big is this RAM ...

The RAM is used by dual clock FIFO that have size of "2048 x 128 bit".

> So, this is not a tool issue - no tool option or constraint is going to fix it.

> This is an architecture problem; you need to modify your architecture to

> make a system that can meet timing.

This is my actual structure :

FIR interpolator.png

> Finally, the path report looks a little odd (but it has been a while since I used ISE).

> Can you give us the TIMESPEC that this failing path belongs to? Is it a normal PERIOD

> constraint, or is it some kind of FROM TO constraint?

I tried to insert a constraint that would allow the resolution of the timing problem :

## FIFO --> Interpolator (5.000 ns)
TIMESPEC "TS_fifo_a_to_interpolator_a" = FROM : RAMS("fifo_a/*") : TO : FFS("interpolator_a/*") : 5.000 ns;  

## Interpolator ---> FIFO (5.000 ns)
TIMESPEC "TS_interpolator_a_to_fifo_a" = FROM : FFS("interpolator_a/*") : TO : RAMS("fifo_a/*") : 5.000 ns;   

Do you have any other tips ?

 

Thanks very much.

 

moreasm

 

0 Kudos
Historian
Historian
1,066 Views
Registered: ‎01-23-2009

Re: Timing issue with slack ...

Jump to solution

The RAM is used by dual clock FIFO that have size of "2048 x 128 bit".

 

This is 8 block RAMs. With a 5ns period and a clock crossing (between two different MMCM clocks), the tools cannot meet this.

 

Do you have any other tips ?

 

What I suggested above (move to the 10MHz domain in flip-flops) should fix your problem.

 

I tried to insert a constraint that would allow the resolution of the timing problem :

 

Constraints were never the problem. Furthermore, these constraints are incorrect, since they make the tool ignore clock skew and jitter. Remove them and let the PERIOD constraints (generated by the MMCM) constrain the paths.

 

Avrum

0 Kudos