cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
11,438 Views
Registered: ‎08-15-2007

Timing constraints when using IOB FFs

All of the IO in my design uses IOB registers; all clock paths are derived from a central 50 MHz input oscillator and then a series of DCMs generates the needed clocks. Given that 1. all pads should be clocked by their adjacent IOB register and 2. I don't care about the phase relationship between the rest of the system and the 50 MHz input clock, is there any reason to use any of the OFFSET series of constraints?

 

I'm trying to nail some  apparent erratic behavior, and this seemed like a good place to start.

0 Kudos
9 Replies
Highlighted
Historian
Historian
11,410 Views
Registered: ‎02-25-2008

Re: Timing constraints when using IOB FFs


ericmjonas wrote:

All of the IO in my design uses IOB registers; all clock paths are derived from a central 50 MHz input oscillator and then a series of DCMs generates the needed clocks. Given that 1. all pads should be clocked by their adjacent IOB register and 2. I don't care about the phase relationship between the rest of the system and the 50 MHz input clock, is there any reason to use any of the OFFSET series of constraints?

 

I'm trying to nail some  apparent erratic behavior, and this seemed like a good place to start.


Offset constraints only affect input set-up and output clock-to-out time. The period constraint will cover everything from the input flop to the rest of the internal logic, and from the internal logic to the D input of the output flop.

 

If you have concerns about meeting set-up and hold times of external devices, or interfacing an external driver to the FPGA input, then you need OFFSET constraints.

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,383 Views
Registered: ‎11-28-2007

Re: Timing constraints when using IOB FFs


ericmjonas wrote:

All of the IO in my design uses IOB registers; all clock paths are derived from a central 50 MHz input oscillator and then a series of DCMs generates the needed clocks. Given that 1. all pads should be clocked by their adjacent IOB register and 2. I don't care about the phase relationship between the rest of the system and the 50 MHz input clock, is there any reason to use any of the OFFSET series of constraints?

 

I'm trying to nail some  apparent erratic behavior, and this seemed like a good place to start.


Do you see "erratic behavior" in software or hardware? If it's software, OFFSET constraints can hardly be the problem. If it's hardware, unconstrained IO timing (i.e. no OFFSET constraints) could be a good suspect.

 

Cheers,

Jim

 

Cheers,
Jim
0 Kudos
Highlighted
Visitor
Visitor
11,379 Views
Registered: ‎08-15-2007

Re: Timing constraints when using IOB FFs

Jim, can you expand on that a bit ? I'm not seeing the erratic behavior in simulation (is that what you meant by software?) but in the physical device. It seems sometimes things won't boot up, etc. I've triple-checked, and every IO device has an associated IOB flip-flop. I was under the impression that, in this state, especially when you don't depend on the external clock, OFFSET macros just don't matter, you're going to get the clock-to-pad performance that a IOB reg gives you.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,371 Views
Registered: ‎11-28-2007

Re: Timing constraints when using IOB FFs

By software I mean any tool (xst, ngdbuild, map, par, etc) in the ISE tool chain.It's good that you're not seeing any problem in the tools.

 

When you put your FPGA design in a system interfacing to other devices, it almost always requies some IO timing constraints (both OFFSET IN and OUT constraints) to be met for the system/FPGA to work properly. Why do you think that your design doesn't need IO timing constraints? Even though you pack all FFs into IOB, there are still things you can do that affects IO timing. Since it's always about clock and data, you can change either the clock path or the data path delay to make the IO timing better or worse.

 

Cheers,

Jim

 

 

Message Edited by jimwu on 03-04-2009 10:35 AM
Cheers,
Jim
0 Kudos
Highlighted
Visitor
Visitor
11,367 Views
Registered: ‎08-15-2007

Re: Timing constraints when using IOB FFs

Jim,

   My core FPGA doesn't depend on any external system clocks to time the registers. That is, it takes in a single clock from an oscillator, and derives all timing from there. I was under the impression that the OFFSET macros only ended up impacting the relationship between an external clock and the pad timing, and that internally, they were of no use (instead the FF constraints are what mattered, which were implicitly set by the PERIOD constraint). 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,364 Views
Registered: ‎11-28-2007

Re: Timing constraints when using IOB FFs

Are you saying that your core FPGA doesn't have any input coming in from external device and it doen't have any output driving external devices? 

 

OFFSET constraints currently don't really impact the IO timing. They are more for timing analysis to make sure the IO timing of your design is met. For input, the PERIOD constraint doesn't cover the path from a pad to the first FF (IOB FF in your case). This is where you can use OFFSET IN constraint to make sure the extenal data can be captured correctly by the FPGA. It's true that the OFFSET constrains always use an extenal clock input as the reference point. The internal clock that you use to capture the extenal data has to eventually come from an input pin, so the internal clock can be traced by to the same reference point used by the OFFSET constraints.

 

Cheers,

Jim

Cheers,
Jim
0 Kudos
Highlighted
Historian
Historian
11,361 Views
Registered: ‎02-25-2008

Re: Timing constraints when using IOB FFs


ericmjonas wrote:

Jim,

   My core FPGA doesn't depend on any external system clocks to time the registers. That is, it takes in a single clock from an oscillator, and derives all timing from there. I was under the impression that the OFFSET macros only ended up impacting the relationship between an external clock and the pad timing, and that internally, they were of no use (instead the FF constraints are what mattered, which were implicitly set by the PERIOD constraint). 


Eric,

 

To expand upon what Jim says -- your oscillator IS the external clock. So you still need to make sure that any FPGA inputs meet setup requirements to that clock, regardless of whether the driving device is synchronous to it or not.

 

Sounds like you have some asynchronous inputs which need to be synchronized before use. The usual synchronizer is two flops in series. Be aware of any latency caused by these flops.

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Visitor
Visitor
11,357 Views
Registered: ‎08-15-2007

Re: Timing constraints when using IOB FFs

Jim,

   Thanks again for the help. My core FPGA does have IO, but it's all synchronous to clocks that this core FPGA itself drives. For example, one of the elements is a DDR2 DRAM interface that I designed. 

 

Now, maybe I'm mistaken, but I thought that each IOB was associated with a specific device pad. So even if I used OFFSET IN, it wouldn't really change anything, because since i'm using that IOB FF, the delay there is hard-wired.  

 

Now, given that, if it helps with the timing analysis, it's clearly the right thing to do, and I'll happily add the constraint :) 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,349 Views
Registered: ‎11-28-2007

Re: Timing constraints when using IOB FFs

OFFSET constraints themselves don't change anything. However, depending on the device you are using, there are different things you can do in your design to improve the margin on the OFFSET constraints.

 

* PAD to IOB FF delay is NOT fixed.  I suggest you take a look at the user guide/data sheet for your device and check the IO capabilities of the device (such as IODELAY, IDELAY, etc).

* Shift the clock by using DCM, PLL, programmable delay, etc to improve the IO timing.

 

Cheers,

Jim

Cheers,
Jim
0 Kudos