FPGA timming

Does anyone know of a good reference for timing concepts in synchronous
FPGA designs.
I know what false and multi-cycle paths are, but need some examples to
understand how they occur in real designs.

Let me elaborate a bit more.
My understanding:

False Paths: Paths that are not timming critical but show up in the
timming report with a -ve slack. Can't think of an example.

multi-cycle paths : Paths which can take 2 or more cycle to complete.
But this would mean you gate the clock of the output/second resgiter in
a multi cycle path so that it resgisters the right input after x clock
cycles. Wouldn't that violate the sync design rules byt gating the
clock and thus introducing skew? Aren't you better off pipelining it
anyway, so that you get a result after every clock cycle after the
inital pipeline latency.

Kunal wrote:

> Aren't you better off pipelining it anyway

Yes, if you can make timing that way, it's less trouble.
The pipeline requires no special constraints.
Multicycle does.

http://groups.google.com/groups?q=fpga+false+path+multicycle

   -- Mike Treseler

Kunal wrote:
> Let me elaborate a bit more.
> My understanding:
> 
> False Paths: Paths that are not timming critical but show up in the
> timming report with a -ve slack. Can't think of an example.
> 
> multi-cycle paths : Paths which can take 2 or more cycle to complete.
> But this would mean you gate the clock of the output/second resgiter in
> a multi cycle path so that it resgisters the right input after x clock
> cycles. Wouldn't that violate the sync design rules byt gating the
> clock and thus introducing skew? Aren't you better off pipelining it
> anyway, so that you get a result after every clock cycle after the
> inital pipeline latency.

Or use a clock enable.

False paths are paths that you (as the designer) know aren't timing 
critical.  (Such as a an output pin clocked on a 50 Mhz clock that 
drives an led).

Multicycle paths are paths that you (as the designer) know are allowed 
to take multiple cycles to resolve.  For instance, if you have a section 
of logic running off a 100Mhz clock, but clock enables running to every 
flip-flop in that section of logic, then you know that every signal has 
two cycles to resolve before it will be sampled by the next stage.

Jeremy

"Kunal" <kunal.shenoy@gmail.com> wrote in message 
news:1129583827.348591.276200@g43g2000cwa.googlegroups.com...
> Let me elaborate a bit more.
> My understanding:
>
> False Paths: Paths that are not timming critical but show up in the
> timming report with a -ve slack. Can't think of an example.
>
> multi-cycle paths : Paths which can take 2 or more cycle to complete.
> But this would mean you gate the clock of the output/second resgiter in
> a multi cycle path so that it resgisters the right input after x clock
> cycles. Wouldn't that violate the sync design rules byt gating the
> clock and thus introducing skew? Aren't you better off pipelining it
> anyway, so that you get a result after every clock cycle after the
> inital pipeline latency.
> 

Hey Kunal,
So, I have two questions.
A) If you're posting from Xilinx's IP address, why not ask the local 
populace?
B) How did you hack into Xilinx's server to post?
C) Why can I neither count or use a touchpad without multi-posting?
Cheers, Syms.
;-)
"Kunal" <kunal.shenoy@gmail.com> wrote in message 
news:1129583827.348591.276200@g43g2000cwa.googlegroups.com...
> Let me elaborate a bit more.
> My understanding:
>
> False Paths: Paths that are not timming critical but show up in the
> timming report with a -ve slack. Can't think of an example.
>
> multi-cycle paths : Paths which can take 2 or more cycle to complete.
> But this would mean you gate the clock of the output/second resgiter in
> a multi cycle path so that it resgisters the right input after x clock
> cycles. Wouldn't that violate the sync design rules byt gating the
> clock and thus introducing skew? Aren't you better off pipelining it
> anyway, so that you get a result after every clock cycle after the
> inital pipeline latency.
> 

You can't count?

I said that in my post. Twice!
"Luke" <lvalenty@gmail.com> wrote in message 
news:1129592997.709631.130560@g43g2000cwa.googlegroups.com...
> You can't count?
> 

I thought it would a good discussion to have on the FPGA group, rather
than me asking experts and keeping it to myself. I am sure others new
to FPGA design will have the same questions as well. It would be nice
for a generic discussion to show up if someone typed 'FPGA timing' into
the search box, that is if I didnt SPELL the topic wrong ! :-)

..and, you cheeky bugger, posting from Intel.com is not a good idea if 
you're slagging off people's arithmetic!  ;-)
http://www.maa.org/mathland/mathland_5_12.html

Cheers, Syms.

"Luke" <lvalenty@gmail.com> wrote in message 
news:1129592997.709631.130560@g43g2000cwa.googlegroups.com...
> You can't count?
>