On 20 Aug 2005 23:41:15 0700, "Taras_96" <(EMail Removed)> wrote:
>Hi everyone
>
>Currently our architecture consists of 1024 really fast loops, with
>each result being loaded into a register, followed by a single long
>1024 bit ripple carry addition that uses the end result of the 1024
>loops, and loads the addition into a register. This entire sequence is
>repeated 1024 times. The addition is supposed to take place over
>multiple clock cycles  the design has a state machine that allocates
>a configurable number of states for this addition to take place. This
>is essential because it is undesirable to be running the fast loop at
>the frequency it takes to do one extremely long addition.
>
>
>  loop repeated 1024 times
> 
>^ v
> REG
> 
>.
> 
> 
> ADDER
> 
> v
> REG
>
>Everything synthesises fine, and Xilinx spits out a maximum clock
>frequency at the end of the synthesis. However, I suspect that the
>value of the clock frequency obtained assumes that the addition
>operation between the two registers should be completed in one clock
>cycle (I don't see why Xilinx would assume otherwise).
>
>My question is: is there anyway of either telling Xilinx that the
>addition is supposed to take over multiple clock cycles or using Xilinx
>or its results to determinine the maximum clock frequency assuming that
>the addition takes place over a variable number of clock frequencies?
>
>TIA
>
>Taras
You should read about multicycle path exceptions in your timing
analysis tool documentation and set some constraints accordingly.
Also remember that a multicycle path helps you meet timing and/or
reduce area. I don't know your speed requirements but you say you are
using a ripple carry adder. If you're really meeting timing with a
ripple carry adder then you don't need to go any faster and you can't
add in less area than a carry ripple adder. So a multicycle path may
not help you. Of course you can divide the adder into multiple
sections and add smaller numbers at a time to reduce the area of your
adder.
HTH.
