Global Clock

N

nfirtaps

Guest
On a Xilinx Spartan 3.

If I have a clock that comes into the FPGA through the following order

1.) Onto IO line pin
2.) Into IBUFG
3.) Out of IBUFG
4.) Into DCM
5.) Output of DCM goes to signal, just 1x multiplication, feeback is
this signal
6.) DCM 1x output signal goes into a BUFG
7.) Output of BUFG goes into a component
8.) Component drives control signals based on the input clock
9.) Output of control signals go to OBUF's and out the FPGA

Are there any problems with this?


I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.

Thanks,
Lloyd
 
Does the 1x output of the DCM (step 5) or the output of the BUFG (step 6)
connect to the feedback input? For proper deskewing, the feedback should come
from the BUFG (step 6).

John Jensen

On 12/4/2006 4:14:35 PM, "nfirtaps" wrote:
On a Xilinx Spartan 3.

If I have a clock that comes into the FPGA through the following order

1.) Onto IO line pin
2.) Into IBUFG
3.) Out of IBUFG
4.) Into DCM
5.) Output of DCM goes to signal, just 1x multiplication, feeback is
this signal
6.) DCM 1x output signal goes into a BUFG
7.) Output of BUFG goes into a component
8.) Component drives control signals based on the input clock
9.) Output of control signals go to OBUF's and out the FPGA

Are there any problems with this?


I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.

Thanks,
Lloyd
Click to expand...
 
John Jensen wrote:
Does the 1x output of the DCM (step 5) or the output of the BUFG (step 6)
connect to the feedback input? For proper deskewing, the feedback should come
from the BUFG (step 6).

John Jensen

On 12/4/2006 4:14:35 PM, "nfirtaps" wrote:
On a Xilinx Spartan 3.

If I have a clock that comes into the FPGA through the following order

1.) Onto IO line pin
2.) Into IBUFG
3.) Out of IBUFG
4.) Into DCM
5.) Output of DCM goes to signal, just 1x multiplication, feeback is
this signal
6.) DCM 1x output signal goes into a BUFG
7.) Output of BUFG goes into a component
8.) Component drives control signals based on the input clock
9.) Output of control signals go to OBUF's and out the FPGA

Are there any problems with this?


I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.

Thanks,
Lloyd
Click to expand...

John, Thanks so much for the reply. The feedback does not go through a
BUFG before going back into the DCM. I will change my design so the
feedback goes through a BUFG, and the output CLK0 goes through a BUFG
and is then used as the main clock.
 
On 12/8/2006 9:18:34 AM, "nfirtaps" wrote:
John Jensen wrote:
Does the 1x output of the DCM (step 5) or the output of the BUFG (step 6)
connect to the feedback input? For proper deskewing, the feedback should come
from the BUFG (step 6).

John Jensen

On 12/4/2006 4:14:35 PM, "nfirtaps" wrote:
On a Xilinx Spartan 3.

If I have a clock that comes into the FPGA through the following order

1.) Onto IO line pin
2.) Into IBUFG
3.) Out of IBUFG
4.) Into DCM
5.) Output of DCM goes to signal, just 1x multiplication, feeback is
this signal
6.) DCM 1x output signal goes into a BUFG
7.) Output of BUFG goes into a component
8.) Component drives control signals based on the input clock
9.) Output of control signals go to OBUF's and out the FPGA

Are there any problems with this?


I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.

Thanks,
Lloyd




John, Thanks so much for the reply. The feedback does not go through a
BUFG before going back into the DCM. I will change my design so the
feedback goes through a BUFG, and the output CLK0 goes through a BUFG
and is then used as the main clock.
Click to expand...
Lloyd,

Just to clarify your response, are you going to use two BUFGs (one for the
feedback and one for CLK0)? You probably want to use a single BUFG derived
from the CLK0 output to source the feedback into the DCM and clock your
circuit.

Xilinx has a good application note on how to use the DCM in a variety of
configurations. The link is
http://direct.xilinx.com/bvdocs/appnotes/xapp462.pdf . The ISE architecture
wizard can also help build up these DCM circuits with various configuration
options. Hope this helps.

John Jensen
 
nfirtaps wrote:

Are there any problems with this?
Click to expand...
If there are "clocking issues", there is a problem

I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.
Click to expand...
I count about four clock domains.
The ideal situation is to clock everything
from the same global net (one clock domain).
If this is not possible standard practice is
to employ PLL constraints, synchronized handshakes,
or fifos to make clean crossings.

-- Mike Treseler
 
I don't see a way around using this many clock domains. The Spartan 3
data sheet recommends having the output of a DCM go out into a bufg or
bufgmux, and the input to the DCM should be in from an ibufg I assume.
Having the clock port mapped into a component this does not switch
clock domains does it? In all the code examples I have seen this is
how the clock is handled.


Mike Treseler wrote:
nfirtaps wrote:

Are there any problems with this?

If there are "clocking issues", there is a problem

I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.

I count about four clock domains.
The ideal situation is to clock everything
from the same global net (one clock domain).
If this is not possible standard practice is
to employ PLL constraints, synchronized handshakes,
or fifos to make clean crossings.

-- Mike Treseler
Click to expand...
 
The ISE should have inferred a single clock for this but are you doing
hand routing?


nfirtaps wrote:
I don't see a way around using this many clock domains. The Spartan 3
data sheet recommends having the output of a DCM go out into a bufg or
bufgmux, and the input to the DCM should be in from an ibufg I assume.
Having the clock port mapped into a component this does not switch
clock domains does it? In all the code examples I have seen this is
how the clock is handled.


Mike Treseler wrote:
nfirtaps wrote:

Are there any problems with this?

If there are "clocking issues", there is a problem

I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.

I count about four clock domains.
The ideal situation is to clock everything
from the same global net (one clock domain).
If this is not possible standard practice is
to employ PLL constraints, synchronized handshakes,
or fifos to make clean crossings.

-- Mike Treseler
Click to expand...
 
Yes I am doing this by hand routing. I am literally instantiating
buffer components in my code.


Neo wrote:
The ISE should have inferred a single clock for this but are you doing
hand routing?


nfirtaps wrote:
I don't see a way around using this many clock domains. The Spartan 3
data sheet recommends having the output of a DCM go out into a bufg or
bufgmux, and the input to the DCM should be in from an ibufg I assume.
Having the clock port mapped into a component this does not switch
clock domains does it? In all the code examples I have seen this is
how the clock is handled.


Mike Treseler wrote:
nfirtaps wrote:

Are there any problems with this?

If there are "clocking issues", there is a problem

I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.

I count about four clock domains.
The ideal situation is to clock everything
from the same global net (one clock domain).
If this is not possible standard practice is
to employ PLL constraints, synchronized handshakes,
or fifos to make clean crossings.

-- Mike Treseler
Click to expand...
 
I work with Virtex more than Spartan, but it looks like your connection
is valid.

Try connecting the output of the BUFG into the feedback as opposed to
DCM output directly into CLKFB. By the way, when you say clock 1x, you
really mean CLK0 output of DCM right?

nfirtaps wrote:
Yes I am doing this by hand routing. I am literally instantiating
buffer components in my code.


Neo wrote:
The ISE should have inferred a single clock for this but are you doing
hand routing?


nfirtaps wrote:
I don't see a way around using this many clock domains. The Spartan 3
data sheet recommends having the output of a DCM go out into a bufg or
bufgmux, and the input to the DCM should be in from an ibufg I assume.
Having the clock port mapped into a component this does not switch
clock domains does it? In all the code examples I have seen this is
how the clock is handled.


Mike Treseler wrote:
nfirtaps wrote:

Are there any problems with this?

If there are "clocking issues", there is a problem

I seem to have some clocking issues where a control signal from this
clock is not going low before another rising egde of the clock.

I count about four clock domains.
The ideal situation is to clock everything
from the same global net (one clock domain).
If this is not possible standard practice is
to employ PLL constraints, synchronized handshakes,
or fifos to make clean crossings.

-- Mike Treseler
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top