On 20 Aug 2005 23:41:15 -0700, "Taras_96" <> 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 multi-cycle path exceptions in your timing
analysis tool documentation and set some constraints accordingly.
Also remember that a multi-cycle 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 multi-cycle 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.
|