Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Global Clock

Reply
Thread Tools

Global Clock

 
 
nfirtaps
Guest
Posts: n/a
 
      12-04-2006
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

 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      12-05-2006
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
 
Reply With Quote
 
 
 
 
nfirtaps
Guest
Posts: n/a
 
      12-06-2006
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


 
Reply With Quote
 
Neo
Guest
Posts: n/a
 
      12-06-2006
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


 
Reply With Quote
 
nfirtaps
Guest
Posts: n/a
 
      12-06-2006
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


 
Reply With Quote
 
markus_1401@yahoo.com
Guest
Posts: n/a
 
      12-06-2006
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


 
Reply With Quote
 
John Jensen
Guest
Posts: n/a
 
      12-08-2006
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
>
>


 
Reply With Quote
 
nfirtaps
Guest
Posts: n/a
 
      12-08-2006

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.

 
Reply With Quote
 
John Jensen
Guest
Posts: n/a
 
      12-09-2006
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.
>


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP Hoffa Cisco 1 10-25-2006 06:50 PM
FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP Hoffa Cisco 0 10-25-2006 01:04 PM
What is the best way to clock data in on one clock edge and out on another? simon.stockton@baesystems.com VHDL 4 04-26-2006 11:36 PM
Sync for PC clock and server clock PS Computer Support 3 05-13-2005 05:27 AM
Are clock and divided clock synchronous? Valentin Tihomirov VHDL 11 10-28-2003 01:18 PM



Advertisments