clock input over an I/O pin

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi

I was wondering if anyone has any advice or experience on th

following

I need to clock some logic with a clock signal that is connected to a

I/O pin (PCB design constraint!). What are the consequences o
connecting this signal to a DCM input? I'm assuming it's possible..

Does anyone have any recommendations? I'm using Virtex II Pro and th

clock signal is in the 100MHz range

thanks



Re: clock input over an I/O pin

Quoted text here. Click to load it
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


Re: clock input over an I/O pin
Quoted text here. Click to load it

> Howdy

Quoted text here. Click to load it
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)


Re: clock input over an I/O pin
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.


Re: clock input over an I/O pin

Quoted text here. Click to load it

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


Site Timeline