cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
10,248 Views
Registered: ‎02-17-2009

Input constraint without external clock

I have a problem constraining an input. This is my situation:

I generate a clock (CLK100), using the CLKFX output of a DCM (Spartan 3A). This clock has no relation with the incoming clock. CLK100 is then routed to an output, to clock an external device. This device generates data and feeds it back to an input on the FPGA. There is NO return clock.

Can anyone tell me how to constrain the setup and hold times for this input, for there is no external input clock to use with the OFFSET constrain.
0 Kudos
7 Replies
Highlighted
Historian
Historian
10,232 Views
Registered: ‎02-25-2008


xilinxbert wrote:
I have a problem constraining an input. This is my situation:

I generate a clock (CLK100), using the CLKFX output of a DCM (Spartan 3A). This clock has no relation with the incoming clock. CLK100 is then routed to an output, to clock an external device. This device generates data and feeds it back to an input on the FPGA. There is NO return clock.

Can anyone tell me how to constrain the setup and hold times for this input, for there is no external input clock to use with the OFFSET constrain.

First -- the CLKFX DCM output absolutely DOES have a relationship with the incoming clock that drives it!

 

The real question: these return data coming into the FPGA are synchronized with what clock INSIDE the FPGA?

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Visitor
Visitor
10,208 Views
Registered: ‎02-17-2009

Sorry, my mistake: You're right that CLKFX (100MHz) has a relation to CLKIN (85MHz), but what I ment was, that the return data setup and hold times are not directly related to the CLKIN. The return data is synchronized to CLKFX. The problem is, that the external device has a significant delay and PCB routing delays are also added. Also, the CLKFX has a considerable delay (3ns) to the output pad and also to the IOB data FF (1ns), both of which can vary with multiple builds.

 

I can calculate the data window relation to CLKFX at the output pad by hand. Idealy, I would constrain the data input relative to the CLKFX output pad. But as far as I know, an OFFSET can only be used with an external clock input.

 

All external delays are fixed. If I could constrain a data input like this, I do not have to check all internal routing delays by hand every new build.

0 Kudos
Highlighted
Historian
Historian
10,199 Views
Registered: ‎02-25-2008


xilinxbert wrote:

Sorry, my mistake: You're right that CLKFX (100MHz) has a relation to CLKIN (85MHz), but what I ment was, that the return data setup and hold times are not directly related to the CLKIN. The return data is synchronized to CLKFX. The problem is, that the external device has a significant delay and PCB routing delays are also added. Also, the CLKFX has a considerable delay (3ns) to the output pad and also to the IOB data FF (1ns), both of which can vary with multiple builds.

 

I can calculate the data window relation to CLKFX at the output pad by hand. Idealy, I would constrain the data input relative to the CLKFX output pad. But as far as I know, an OFFSET can only be used with an external clock input.

 

All external delays are fixed. If I could constrain a data input like this, I do not have to check all internal routing delays by hand every new build.


Oy, I just checked the constraints guide, and you are correct: "Because the constraint specifies the clock and data relationship at the external pads of the FPGA, the OFFSET IN constraint cannot be specified using an internal clock net." But then it goes on to say, "However, the OFFSET IN constraint automatically accounts for any phase or delay adjustments on the clock path due to components such as the DCM, PLL, or IDELAY when analyzing the setup and hold timing requirements at the capturing synchronous element." Which probably isn't very helpful.

 

Perhaps you can do a "FROM-TO" type of constraint:

 

TIMESPEC "TS_IN_TO_FLOPS" =  FROM "PADGRP" TO "CLKFXFLOPS" 10 ns;

 

and you have to create PADGRP as a TIMEGRP with all of the relevant input pads, and you need to create CLKFXFLOPS as another TIMEGRP with the relevant synchronizing flops (which are hopefully in the IOB), and the 10 ns is your delay constraint.

 

A second way to do this is to route the CLKFX output pad back into the FPGA on a clock input. You might wish to make this clock trace on your PCB the same length as the data traces with which it is synchronous.

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Visitor
Visitor
10,176 Views
Registered: ‎02-17-2009

Unfortunately the PCB is an existing one, so there's no possibility to route an external clock. However it is a good idea for the next PCB.

 

I've tried to use the FROM-TO constraint, this would seem like a valid option. There's only one problem: the input pads aren't synchronous elements. The result is an ignored timing constraint during PAR.

0 Kudos
Highlighted
Historian
Historian
10,168 Views
Registered: ‎02-25-2008


xilinxbert wrote:

Unfortunately the PCB is an existing one, so there's no possibility to route an external clock. However it is a good idea for the next PCB.

 

I've tried to use the FROM-TO constraint, this would seem like a valid option. There's only one problem: the input pads aren't synchronous elements. The result is an ignored timing constraint during PAR.


The FROM-TO shouldn't care about whether an element is synchronous or not ... perhaps open a WebCase and see what the geniuses say?

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Visitor
Visitor
8,947 Views
Registered: ‎05-06-2009

xilinxbert were you able to find a solution? I'm stuck in the same problem and no constraint seems to suit the given situation.
Message Edited by vijay82 on 05-06-2009 09:48 PM
0 Kudos
Highlighted
Visitor
Visitor
8,941 Views
Registered: ‎02-17-2009

Hi Vijay82,

 

I have not found a solution. I can work around it for now.

 

Regards,

Bert

0 Kudos