cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
vjose1
Observer
Observer
11,213 Views
Registered: ‎11-01-2013

Setup Hold time violation

Hi ,

 

I am having a hold time vioaltion. The following is the desctiption 

Chip : XC3S4000 

Inputs : CLK_IN , DATA_IN  inputs from extenal device to FPGA

 

 

## Define input clock period (100MHz)
NET "CLK_IN " CLOCK_DEDICATED_ROUTE = FALSE;
NET "CLK_IN " TNM_NET = CLK_IN _TNM;
TIMESPEC TS_CLK_IN  = PERIOD "CLK_IN_TNM" 9.8 ns HIGH 50%;

 

### Define input data to input clock relationship
### Todo review these setup/hold times, 3/6 is working guess
TIMEGRP "DATA_IN " OFFSET = IN 3 ns VALID 6 ns BEFORE "CLK_IN ";

 

I am not able to meet the setup time constraints. The CLK_IN signal comes to the FPGA through a ordinary IOB and not a CLK IOB. This is a contraint of the board and cannot be changed. 

 

 I have the follwing questions.

 

1) How do I derive the setup time for the data Tsu(3 ns ) before the clock CLK_IN arrive ?.

(I know that we have compute the delay from the extenal device to the FPGA IO pin). Is there any other thing I need to consider. 

2) How do I derive the hold time for the data Tht(6 ns ) ?.

 

Is there any minimum value for setup and hold time based on  the clock speed ?.

 

With regards

Vintu

 

 

0 Kudos
3 Replies
bassman59
Historian
Historian
11,077 Views
Registered: ‎02-25-2008


@vjose1 wrote:

 

I am not able to meet the setup time constraints. The CLK_IN signal comes to the FPGA through a ordinary IOB and not a CLK IOB. This is a contraint of the board and cannot be changed.  

 


That's a huge screwup. You have to respin the board. Always verify FPGA pin placement and timing and routing before committing to a PCB fab.

----------------------------Yes, I do this for a living.
0 Kudos
avrumw
Guide
Guide
11,038 Views
Registered: ‎01-23-2009

So, first, I agree with Bassman - always verify your pins before manufacturing the board.

 

That being said, if the interface has VERY generous in its timing, you may be able to make this work. However, you are currently misinterpreting the meaning of the OFFSET IN command, and you MUST MUST MUST validate the timing of the interface as determined by the board.

 

What you have now is telling the FPGA tools that the data on the input pin of the FPGA becomes valid 3ns before the rising edge of the clock (at the pin of the FPGA) and remains valid for 6ns (thus until 3ns after the clock edge). This is a very generous window (6ns) for an interface running at slightly over 100MHz (9.8ns). If this window is really true, then you have a chance to be able to capture this interface - even with the clock on a non clock-capable pin.

 

But, this data must come from the driving devices data sheet - we don't have any information on the driving device to know if this is even reasonable.

 

If it is, then you will have to decide how to clock it. This is a Spartan3 so has only two real options - directly with a BUFG or using a DCM - you will pretty much need to use the DCM for this. To do this you will have to convince the tool to route from the clock from a pin that is not a global clock to the DCM (probably setting the CLOCK_DEDICATED_ROUTE=FALSE). You will also have to capture the incoming data in the input flip-flops in the IOBs (IFF).

 

Once done, you will have to analyze the timing, and maybe use the static phase adjustment of the DCM (or a different phase of the DCM) to put the clock in the data valid window. Since the FPGA (when clocked properly) needs around a 2.5ns window, then even with this improper clocking you should be able to find a setting on the DCM that satisfies both the setup check and hold check in your 6ns window.

 

But, if your interface doesn't really have a 6ns window, and the real window is significantly smaller, then you are most certainly cooked, and need to respin the board.

 

Avrum

0 Kudos
avrumw
Guide
Guide
11,034 Views
Registered: ‎01-23-2009

Oh, and one other thing...

 

Since the clock is not on a dedicated clock input, the timing of the interface will change from implementation run to implementation run. You will be at the mercy of your OFFSET IN constraints to try and constrain the tools to generate "good" routing for the input clock to meet your input timing and ultimately report if your input interface passes on each implementation run.

 

This reinforces the requirement that your OFFSET IN constraint must be 100% correct, taking into account all sources of variation:

  - jitter

  - board propagation

  - edge derating

  - ...

 

Avrum