Do i need to use DCM ?

[Muthu]

Hello,

Although i have gone through the Discussion on this forum regarding
the DLL usage, i would like to clarify a point.

I.e, I am having a single clock. I don't have phase shifting, clock
division, clock multiplication requirements. And ofcoures i don't
bother about the clock jitter.

Now do i require DCM? If so why ?

Thanks in advance

Regards,
Muthu

 

[Sylvain Munaut]

Muthu wrote:

Hello,

Although i have gone through the Discussion on this forum regarding
the DLL usage, i would like to clarify a point.

I.e, I am having a single clock. I don't have phase shifting, clock
division, clock multiplication requirements. And ofcoures i don't
bother about the clock jitter.

Now do i require DCM? If so why ?

Thanks in advance

Regards,
Muthu

That depends of the clock frequency and timing requirement to meet.
I'd say no, else, you'd know you want it

 

[Hal Murray]

I.e, I am having a single clock. I don't have phase shifting, clock
division, clock multiplication requirements. And ofcoures i don't
bother about the clock jitter.

The DLL is normally used to reduce the clock-out delay. Is
that interesting to you?

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Bob]

"Muthu" <muthusnv@yahoo.co.in> wrote in message
news:4f8e807b.0407100405.1f0b8dde@posting.google.com...

Hello,

Although i have gone through the Discussion on this forum regarding
the DLL usage, i would like to clarify a point.

I.e, I am having a single clock. I don't have phase shifting, clock
division, clock multiplication requirements. And ofcoures i don't
bother about the clock jitter.

Now do i require DCM? If so why ?

Thanks in advance

Regards,
Muthu

For data into the FPGA:

The FPGA IOB's input setup/hold time requirement is defined with respect to
the clock at the IOB registers.

If your input clock (to the FPGA) is connected to an IBUFG (a clock-capable
IOB), then to a DLL or DCM, then to a BUFG (with the output of the BUFG
connected to the DLL/DCM's feedback port), then the edges of your input
clock will be coincident with the clock edges on the FPGA's internal clock
net (i.e., the output of the BUFG). This is known as "de-skewing" an input
clock. This clock net can be used to clock the IOB registers -- and when you
do this, the timing relationship, at the IOB's register input, is known with
respect to your external clock. This is critical when your data rate is
fairly high.

You'll have to do a timing analysis to see if de-skewing your input clock is
required. If you don't de-skew, then you'll have a more unpredictable
relationship between your input clock and the internal clock net (that is
clocking your input data).


For data out of the FPGA:

You can route the BUFG-to-DLL/DCM feedback path outside of the FPGA (using
an external trace). This will have the effect of making your output data
edges coincident with those of your input clock.

Hope this helps.

Bob

 

[Hal Murray]

If your input clock (to the FPGA) is connected to an IBUFG (a clock-capable
IOB), then to a DLL or DCM, then to a BUFG (with the output of the BUFG
connected to the DLL/DCM's feedback port), then the edges of your input
clock will be coincident with the clock edges on the FPGA's internal clock
net (i.e., the output of the BUFG). This is known as "de-skewing" an input
clock. This clock net can be used to clock the IOB registers -- and when you
do this, the timing relationship, at the IOB's register input, is known with
respect to your external clock. This is critical when your data rate is
fairly high.

Good point. Thanks.

Note that any delay in the clock distribution turns into hold time
requirements at the input to the IOB. Hold times are evil. They
hurt even if the clock is not running fast.

Older Xilinx chips had a delay in the IOB that was long enough
to cover that hold time, and an option to bypass it in order
to reduce the setup time.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Muthu]

hmurray@suespammers.org (Hal Murray) wrote in message news:<P5idnUTP6qa7023d4p2dnA@megapath.net>...

If your input clock (to the FPGA) is connected to an IBUFG (a clock-capable
IOB), then to a DLL or DCM, then to a BUFG (with the output of the BUFG
connected to the DLL/DCM's feedback port), then the edges of your input
clock will be coincident with the clock edges on the FPGA's internal clock
net (i.e., the output of the BUFG). This is known as "de-skewing" an input
clock. This clock net can be used to clock the IOB registers -- and when you
do this, the timing relationship, at the IOB's register input, is known with
respect to your external clock. This is critical when your data rate is
fairly high.

Good point. Thanks.

Note that any delay in the clock distribution turns into hold time
requirements at the input to the IOB. Hold times are evil. They
hurt even if the clock is not running fast.

Older Xilinx chips had a delay in the IOB that was long enough
to cover that hold time, and an option to bypass it in order
to reduce the setup time.

Thanks all for you Inputs.

Regards,
Muthu S