regarding clock routing

[praveen]

hi all,

i have no of D flip flops cascaded now there are two ways clock can be routed.

1) in the direction of the data flow.
2) opposite to the direction of the data flow.

which of the above is good??

thanks in advance

rgds,
praveen

 

[Jonathan Bromley]

"praveen" <praveen@cg-coreel.com> wrote in message
news:2dfdd359.0311182226.32bcbd3@posting.google.com...

i have no of D flip flops cascaded now
there are two ways clock can be routed.

1) in the direction of the data flow.
2) opposite to the direction of the data flow.

which of the above is good??

Opposite direction will maximise hold time,
which is probably what you need.

But this is not an FPGA question. In an FPGA
you probably have no choice about clock routing -
it's done for you by the dedicated clock networks.
--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Peter Alfke]

praveen wrote:

i have no of D flip flops cascaded now there are two ways clock can be routed.

1) in the direction of the data flow.
2) opposite to the direction of the data flow.

which of the above is good??

Good question, Praveen. Since 1988, every young engineer that I
interviewed for employment here at Xilinx ( i.e. a couple of hundred)
had to come up with an answer to that question.

If you have a choice ( in an FPGA you should use global clocks, so you
have no measurable delay difference anyhow) there is a trade-off:

Running the clock against the data flow sacrifices performance by
increasing the set-up time, but it is the safeest method, and therefore recommended.

Running the clock in the direction of the data flow reduces set-up time
and thus alllows a higher clock rate, but changes the input requirements
in the direction of a positive (or more positive) hold time. If
overdone, this can create a race condition, and "failure at any clock
speed".
Therefore not recommended.

Peter Alfke, Xilinx Applications

 

[praveen]

Hi peter,

first of all thanks for your reply . But in your reply one of the
sentences was not clear here it goes.

"Running the clock against the data flow sacrifices performance by
increasing the set-up time".

what was not clear to me was you say that it sacrifices perfomance.
Could you please elaborate on what parameters it is based.

rgds,
praveen


Peter Alfke <peter@xilinx.com> wrote in message news:<3FBBA6A5.D509B341@xilinx.com>...

praveen wrote:

i have no of D flip flops cascaded now there are two ways clock can be routed.

1) in the direction of the data flow.
2) opposite to the direction of the data flow.

which of the above is good??

Good question, Praveen. Since 1988, every young engineer that I
interviewed for employment here at Xilinx ( i.e. a couple of hundred)
had to come up with an answer to that question.

If you have a choice ( in an FPGA you should use global clocks, so you
have no measurable delay difference anyhow) there is a trade-off:

Running the clock against the data flow sacrifices performance by
increasing the set-up time, but it is the safeest method, and therefore recommended.

Running the clock in the direction of the data flow reduces set-up time
and thus alllows a higher clock rate, but changes the input requirements
in the direction of a positive (or more positive) hold time. If
overdone, this can create a race condition, and "failure at any clock
speed".
Therefore not recommended.

Peter Alfke, Xilinx Applications

 

[Peter Alfke]

Well, Praveen, that's why I used this as an interview question...
Think of a shift register. Min clock period is the sum of clock-to-Q +
routing + set-up time.
Now assume that the downstream flip-flop is clocked earlier than the
upstream one. You have lost that time from your clock period. That's
lower performance!

Take pencil and paper and draw the timing diagram...
Peter Alfke
============================
praveen wrote:

Hi peter,

first of all thanks for your reply . But in your reply one of the
sentences was not clear here it goes.

"Running the clock against the data flow sacrifices performance by
increasing the set-up time".

what was not clear to me was you say that it sacrifices perfomance.
Could you please elaborate on what parameters it is based.

rgds,
praveen


Peter Alfke <peter@xilinx.com> wrote in message news:<3FBBA6A5.D509B341@xilinx.com>...
praveen wrote:

i have no of D flip flops cascaded now there are two ways clock can be routed.

1) in the direction of the data flow.
2) opposite to the direction of the data flow.

which of the above is good??

Good question, Praveen. Since 1988, every young engineer that I
interviewed for employment here at Xilinx ( i.e. a couple of hundred)
had to come up with an answer to that question.

If you have a choice ( in an FPGA you should use global clocks, so you
have no measurable delay difference anyhow) there is a trade-off:

Running the clock against the data flow sacrifices performance by
increasing the set-up time, but it is the safeest method, and therefore recommended.

Running the clock in the direction of the data flow reduces set-up time
and thus alllows a higher clock rate, but changes the input requirements
in the direction of a positive (or more positive) hold time. If
overdone, this can create a race condition, and "failure at any clock
speed".
Therefore not recommended.

Peter Alfke, Xilinx Applications

 

[Muthu]

Hi Peter,

Yes. I too clear with this.

I have one question regarding clock skew.

As you said, In FPGA we can't control over the clock skew since it is
being routed via dedicated lines.

When i am looking in to the timing reports, Some times i am getting
the Clock Skew value as 0.102ns.. ie., in Positive

And some times, -0.123 ie., in Negative.

Actually, what it means.??? How the timing report tells the clock
skew?

How it is being measured?

Regards,
Muthu


Peter Alfke <peter@xilinx.com> wrote in message news:<3FBCF4AD.6D4EE682@xilinx.com>...

Well, Praveen, that's why I used this as an interview question...
Think of a shift register. Min clock period is the sum of clock-to-Q +
routing + set-up time.
Now assume that the downstream flip-flop is clocked earlier than the
upstream one. You have lost that time from your clock period. That's
lower performance!

Take pencil and paper and draw the timing diagram...
Peter Alfke
============================
praveen wrote:

Hi peter,

first of all thanks for your reply . But in your reply one of the
sentences was not clear here it goes.

"Running the clock against the data flow sacrifices performance by
increasing the set-up time".

what was not clear to me was you say that it sacrifices perfomance.
Could you please elaborate on what parameters it is based.

rgds,
praveen


Peter Alfke <peter@xilinx.com> wrote in message news:<3FBBA6A5.D509B341@xilinx.com>...
praveen wrote:

i have no of D flip flops cascaded now there are two ways clock can be routed.

1) in the direction of the data flow.
2) opposite to the direction of the data flow.

which of the above is good??

Good question, Praveen. Since 1988, every young engineer that I
interviewed for employment here at Xilinx ( i.e. a couple of hundred)
had to come up with an answer to that question.

If you have a choice ( in an FPGA you should use global clocks, so you
have no measurable delay difference anyhow) there is a trade-off:

Running the clock against the data flow sacrifices performance by
increasing the set-up time, but it is the safeest method, and therefore recommended.

Running the clock in the direction of the data flow reduces set-up time
and thus alllows a higher clock rate, but changes the input requirements
in the direction of a positive (or more positive) hold time. If
overdone, this can create a race condition, and "failure at any clock
speed".
Therefore not recommended.

Peter Alfke, Xilinx Applications