Independent clock FIFOs

Hi all,

I am using a Virtex-II Pro in ISE 8.1i and have generated a couple of
asynchronous FIFOs in Coregen. The data path is shown below:

Input @ 133 MHz ---> Core @ 150 MHz ---> Output @ 133 MHz

The 133 MHz clock is from the DCM and the 150 MHz clock is from the DCM
FX output. The problem is that when compiling, ISE tries to meet a
timing constraint equal to the difference in the two clock periods
(i.e. 0.852ns) for some nets in the FIFOs. Specifically, the nets with
problems are of the form:

source: output_fifo/BU2/U0/fgas/flblk/clkmod/wrx/pntr_gc_*
dest: output_fifo/BU2/U0/fgas/flblk/clkmod/wrx/pntr_gc_x_*

and

source: input_fifo/BU2/U0/fgas/flblk/clkmod/rdx/pntr_gc_*
dest:  input_fifo/BU2/U0/fgas/flblk/clkmod/rdx/pntr_gc_x_*

I am guessing these must be something to do with the Gray code counter
and that it is a false constraint. Is that so? If so, why is ISE
getting confused?

I don't if it is relevant but the FIFOs have full and empty flags which
are not actually being used and count outputs which are (and I have
checked that they are connected in the right clock domains too!).

Any help appreciated.
Thanks,
Rob.

When you have two independent clocks (133 and 150 MHz), the difference
of the two clock periods heas no meaning whatsoever.
These two clocks will have any phase- or delay-difference imaginable.
They just "walk over each other". That's what makes the design so
complex.
Meeting timing constraints between independent clock is an exercise in
futility. Don't do it!
Ignore any complaints!
Peter Alfke, Xilinx

Thanks, I TIG'ed those nets, but unfortunately some new ones in the
FIFOs then had the same issue. I will have to figure out why ISE is
confused.

Cheers,
Rob.

rob.misc@gmail.com schrieb:
> Thanks, I TIG'ed those nets, but unfortunately some new ones in the
> FIFOs then had the same issue. I will have to figure out why ISE is
> confused.

It there somewhere an option to disable cross clock domian timing 
analysis? AFAIK there is such an option in Alteras Quartus-II Software. 
But ISE from Xilinx??

Regards
Falk

Hi Falk,

"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
news:4dj434F1avlqmU1@individual.net...
> rob.misc@gmail.com schrieb:
> > Thanks, I TIG'ed those nets, but unfortunately some new ones in the
> > FIFOs then had the same issue. I will have to figure out why ISE is
> > confused.
>
> It there somewhere an option to disable cross clock domian timing
> analysis? AFAIK there is such an option in Alteras Quartus-II Software.
> But ISE from Xilinx??

The Xilinx timing analyser only examines paths which are constrained, so the
problem here is (I think) that a spurious constraint has found its way into
the system. Usually the constraints are either user-entered or generated by
the synthesis tool (and then used as a guide by the subsequent mapping,
placement and routing stages).

XST has an option to ignore paths between different clock domains for
timing, and not create constraints based on its analysis of such paths.

In this case, the paths are within a FIFO module generated from Coregen. It
sounds to me like these constraints have been written out by coregen (into
the .ngc netlist, probably), when they're actually unnecessary. The
workaround is to TIG these paths manually; the solution is to get the IP
fixed so these spurious constraints are not propagated into the design in
the first place.

Cheers,

    -Ben-

Good luck, everyone!  If you fix this without side effects, I would love
to see an answer.

I believe the problem arises when the two clocks are related and the
Xilinx timing tool figures this out.  It tracks the clocks from the same
DCM and says "aha!, a relationship!" and then does the timing analysis.  

Telling the user to ignore timing errors is silly.  Now I have to peruse
the timing report manually each time to be sure the errors are ones I can
ignore, or write some complicated script to do it for me.  

Yes, you can use TIGs, but my experience is weird things happen when you
use to many of these.  But then, weird things seem to happen in Xilinx
timing on complex designs routinely anyway so maybe that doesn't mean
anything.

Am I a bit frustrated?  Yes.  I've been fighting these kind of issues in a
Virtex 2vp30 design with 99% of slices (but only 60% of LUTs) used for
months.

Seems like the timing tool should also be smart enough to say "Aha!
Coregen version of asynchronous fifo, let's be careful about some paths."



On Wed, 24 May 2006 14:30:43 +0100, Ben Jones wrote:

> Hi Falk,
> 
> "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
> news:4dj434F1avlqmU1@individual.net...
>> rob.misc@gmail.com schrieb:
>> > Thanks, I TIG'ed those nets, but unfortunately some new ones in the
>> > FIFOs then had the same issue. I will have to figure out why ISE is
>> > confused.
>>
>> It there somewhere an option to disable cross clock domian timing
>> analysis? AFAIK there is such an option in Alteras Quartus-II Software.
>> But ISE from Xilinx??
> 
> The Xilinx timing analyser only examines paths which are constrained, so the
> problem here is (I think) that a spurious constraint has found its way into
> the system. Usually the constraints are either user-entered or generated by
> the synthesis tool (and then used as a guide by the subsequent mapping,
> placement and routing stages).
> 
> XST has an option to ignore paths between different clock domains for
> timing, and not create constraints based on its analysis of such paths.
> 
> In this case, the paths are within a FIFO module generated from Coregen. It
> sounds to me like these constraints have been written out by coregen (into
> the .ngc netlist, probably), when they're actually unnecessary. The
> workaround is to TIG these paths manually; the solution is to get the IP
> fixed so these spurious constraints are not propagated into the design in
> the first place.
> 
> Cheers,
> 
>     -Ben-

Terry Brown wrote:
> Seems like the timing tool should also be smart enough to say "Aha!
> Coregen version of asynchronous fifo, let's be careful about some paths."

Does your fifo have to be asynchronous?

  -- Mike Treseler

On Fri, 26 May 2006 07:55:10 -0700, Mike Treseler wrote:

> Terry Brown wrote:
>> Seems like the timing tool should also be smart enough to say "Aha!
>> Coregen version of asynchronous fifo, let's be careful about some paths."
> 
> Does your fifo have to be asynchronous?
> 
>   -- Mike Treseler

Yes, data has to cross clock domains--an asynchronous fifo seemed the
simplest method

Rob, you mntion that you do not use the FULL and EMPTY flags.
In that case, the asynchronous FIFO design becomes trivial.
Just have an address counter in each clock domain, and connect one to
the write port, the other one to the read port. No Gray counters, no
comparators, no anti-metastable re-synchronizers. All that complexity
is only needed to generate reliable flags.

Timing constraints that cross the clock domain are inherently
meaningless, since there is no fixed timing relationship.
Peter Alfke,Xilinx (from home)

Peter Alfke wrote:
> Rob, you mntion that you do not use the FULL and EMPTY flags.
> In that case, the asynchronous FIFO design becomes trivial.
> Just have an address counter in each clock domain, and connect one to
> the write port, the other one to the read port. No Gray counters, no
> comparators, no anti-metastable re-synchronizers. All that complexity
> is only needed to generate reliable flags.
>
> Timing constraints that cross the clock domain are inherently
> meaningless, since there is no fixed timing relationship.
> Peter Alfke,Xilinx (from home)

Yes, I can get away without using those flags, but I do use the VALID
flag for reading. Surely that is just NOT( EMPTY ) and so requires the
same precautions?

Rob