Timing Analysis

[david.gill]

I am fairly new to FPGA design but have not found a clear answer for this yet in either the forums or the Timing Constraints User guide (ug612).

What I would like to know is how to properly specifity offset in and out constraints with respect to an internal pll or dcm clock?

The way my design is set up, I have a single clock going into FPGA that is multiplied up using the DCM.  The DCM clock is then used to sample a few input pins and control timing for some outputs.  From what I have read, the offset constraints must be specified with regards to an input clock net only, and cannot be referenced to an internal clock (DCM output).  The problem with that is the Post-PAR Timing Report shows that the input clock path delay and delay through the DCM is taken into account during the offset timing analysis.  This may be where I am misunderstanding things, but the extra delay in the clock path seems like it could give false passes for input timing and false failures for output timing.

The inputs I am concerned about are asynchronous with respect to the FPGA, but I would still like to ensure that certain groups of pins all are sampled within 1 DCM clock cycle of each other, so I need some type of constraint there.  It seems like I should care about timing starting only from the output of the DCM but I don't know how to specify that properly.

I am using a Spartan 6 XC6SLX25T and running ISE 13.2.

Thanks.

[eteam00 · Accepted solution]

I think you are on a fool's errand.  Without a timing reference from input signal to DCM-generated clock, OFFSET IN constraints cannot be applied.

You will have to "settle" for the very best that the FPGA can do -- which is quite simple to accomplish.

• Distribute the clock for registering the input signals properly (e.g. BUFG buffer), so that clock skew between the inputs is negligible.

• Force the input register to be located at the IOB (the I/O cells), where the input-to-register delays are as small as possible.  The constraint to force IOB register placement is described in the IOB section of UG625 (in version 13.4, this begins on page 125).

• If you have pinout flexibility, locate all the data inputs within the same half-IO-bank of the FPGA.

You have not mentioned the bit rates or clock frequency involved.  This might be interesting, but probably does not matter.  The key is to minimise skews (data delay and clock) between the various inputs.

The same principles and approach hold for both inputs and outputs.  Use identical input registers and output registers, placed in the IOBs.

-- Bob Elkind

[david.gill]

Thanks for your response.  I will go ahead and use those techniques.

It does still seem to me that the tools should be able figure out some sort of timing reference between the DCM clock and inputs pins, since if you look at the timing report, all the numbers for all the different sections of the path are there.  In this case I should be able to force inputs into the IOBs but I imagine there are scenarios out there where that is not possible, in which case the timing would be in question, and being able to do an accurate clock path vs. data path would be useful.  I'll have to think about it a bit more, or not overthink it so much. 

[eteam00]

In this case I should be able to force inputs into the IOBs but I imagine there are scenarios out there where that is not possible...

Can you describe an example of such a scenario?  The only one which comes to mind is where minimum latency is a high priority requirement.

-- Bob Elkind

[david.gill]

---

eteam00 wrote:

In this case I should be able to force inputs into the IOBs but I imagine there are scenarios out there where that is not possible...

Can you describe an example of such a scenario?  The only one which comes to mind is where minimum latency is a high priority requirement.

---

Well, if you had some additional logic between the input and the registers you would not be able to force the IOBs, but you may still want to minimize the data path.  Maybe that scenario is not common in real world designs.  

[eteam00]

Well, if you had some additional logic between the input and the registers you would not be able to force the IOBs, but you may still want to minimize the data path.  Maybe that scenario is not common in real world designs.

The scenario you describe may not be common. but neither is it uncommon.  The workaround would be to apply the additional logic after the input register.

-- Bob Elkind