clock input over an I/O pin

an

Howdy,

Yes, it should be possible. You'll probably pick up a little jitter, and definitely will have a phase offset due to prop delay, but probably nothing that is a show stopper.

You didn't say if you need to clock I/O signals into the part with this clock. Or out of the part. For the out direction, is there a requirement that the I/O's toggle with a particular phase relationship to the input clock? If you do have I/O requirements, I believe you can work around it by using the fixed phase offset of the DCM to dial in a compensation for the prop delay of the input buffer, internal routing to the DCM, GBUF, and global clock delay - may take a few experiments to get it right. I/O requirements are the toughest thing to meet with a situation like yours, but at 100 MHz, it should be doable by locking down the routing from the input IOB to the DCM(s).

If you have lax or no I/O timing requirements, most of the above doesn't apply and your job will be even easier.

Good luck,

Marc

jitter

probabl

thi

relationshi

ca

routin

experiment

wit

lockin

Hi Marc

Yes, I do need to clock IO signals in with this clock. The specifi

core I'm using is the PLB GEMAC, and the signal is gmii_rx_clk Taking the naive approach and connecting the clock input to a DC works...in that the device can send and receive packets successfully However, if I add a peripheral to the OPB, the GEMAC stops working and I'm led to believe that it only worked by chance in the firs instance. The GEMAC data sheet is not terribly helpful I'm afrai (either that, or I'm not seeing the helpful data)

You might want to check the load as it may very well be that once your load increase the delay increase and your clock and data are no more meeting the timing requirements and hence the fail in the second case.

Many time just inverting the clock solve the problem but you should check your timing report and don't forget of course you give the timing requirements, as you might need to use something in between and not as "drastic" as 180

Have Fun.

Ah, now I better understand what you're trying to do. I would have to agree with you that the GEMAC "data sheet", at least that I have access to, is suprisingly brief and lacking of detail. I suppose they are expecting that you'll just take their source and use it, no questions asked.

Anyway, back to your clock problem. The two global clocks that the GEMAC core says it needs are almost certainly the rx clock from the GMII device and a main reference clock - and it almost certainly assumes those global clocks come in on GCLK pins. Since yours doesn't, you'll probably need to try to come close to duplicating the IBUFG ->

BUFG prop delay with your path:

IBUF -> chip routing -> DCM -> BUFG

You can do that by using the fixed or variable phase offset of the DCM to dial in a delay that compensates for your overly lagged clock network. The only problem with the routing to the DCM is that you need to nail it down so that the delay doesn't change every other build - look into using directed routing for that.

Once you have that locked down, you can go about moving the clock around with the DCM so that it's output is lined up with where it needs to be (may take some trial, error, and patience). You might even be able to use the "working" version of your design to get some idea of what the clock phase should be - you can bring the clock out using a DDR flop... this will give you external visability of the clock phase with relation to the input clock phase.

Have fun,

Marc