Having trouble with Xilinx timing constraints [FPGA]

Prev: order
Next: Ethernet PCIe boards and PHY daughter cards?

From: Paragon on 11 Nov 2009 11:38

Hello all,

I have having trouble figuring out how to properly define some timing
constraints for an interface between two Xilinx Virtex-4 LX100's. If
anybody has any insight on the best way to solve this problem, it
would be appreciated.

Here are the fixed system parameters (these cannot be changed no
matter how much easier it would make the design).

1) Each FPGA is provided with an identical 384 MHz clock.
2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96
MHz.
3) There are some control signals which need to be sent back and forth
between the FPGAs which are generated in the 96 MHz clock domain.
4) Between the FPGAs there are pins which are connected directly,
including 2 pins in each direction which are capable of driving
differential clocks if needed. All of these signals are in 2.5 V
banks.
5) There is a worst case of 0.95 ns propagation time on the lines
between the two FPGAs.

The problem is that due to the 96 MHz clock being derived in each
FPGA, there is not a defined phase relationship between the two 96 MHz
clocks (there could be any one of 4 relative phases), so data can not
just be sent back and forth as if it were synchronous.

I have tried constraining with OFFSET IN and OFFSET OUT constraints
that can handle these 4 relative phases (basically constrain as if it
were a 384 MHz clock) but this appears to be too much for the FPGA to
handle.

Here are the constraints I defined in this case:

NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;

NET "outputData<*>" OFFSET = 0.6 ns AFTER "clk_384mhz_p";
NET "inputData<*>" OFFSET = IN 1 ns VALID 1.6 ns BEFORE
"clk_384mhz_p";

Another idea I have tried is to use source synchronous design to
forward the 96 MHz clock (as a differential clock) with the data and
then use a FIFO to move it into the "receiving" 96 MHz clock domain
after clocking it in with the "originating" 96 MHz. Once again
though, the design has trouble meeting timing.

Here are the constraints I defined in this case:

NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;

NET "originatingClk_p" TNM_NET ="originatingClk_p";
TIMESPEC "TS_originatingClk_p" = PERIOD "originatingClk_p" 10.4 ns
HIGH 50%;

NET "outputData<*>" OFFSET = 5 ns AFTER "clk_384mhz_p";
NET "inputData<*>" OFFSET = IN 4 ns VALID 4 ns BEFORE
"originatingClk_p";

Does anybody have any insight into the best way to solve this problem?

Thanks!

From: Gabor on 11 Nov 2009 13:25

On Nov 11, 11:38 am, Paragon <paragon.j...(a)gmail.com> wrote:
> Hello all,
>
> I have having trouble figuring out how to properly define some timing
> constraints for an interface between two Xilinx Virtex-4 LX100's. If
> anybody has any insight on the best way to solve this problem, it
> would be appreciated.
>
> Here are the fixed system parameters (these cannot be changed no
> matter how much easier it would make the design).
>
> 1) Each FPGA is provided with an identical 384 MHz clock.
> 2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96
> MHz.
> 3) There are some control signals which need to be sent back and forth
> between the FPGAs which are generated in the 96 MHz clock domain.
> 4) Between the FPGAs there are pins which are connected directly,
> including 2 pins in each direction which are capable of driving
> differential clocks if needed. All of these signals are in 2.5 V
> banks.
> 5) There is a worst case of 0.95 ns propagation time on the lines
> between the two FPGAs.
>
> The problem is that due to the 96 MHz clock being derived in each
> FPGA, there is not a defined phase relationship between the two 96 MHz
> clocks (there could be any one of 4 relative phases), so data can not
> just be sent back and forth as if it were synchronous.
>
> I have tried constraining with OFFSET IN and OFFSET OUT constraints
> that can handle these 4 relative phases (basically constrain as if it
> were a 384 MHz clock) but this appears to be too much for the FPGA to
> handle.
>
> Here are the constraints I defined in this case:
>
> NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
> TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;
>
> NET "outputData<*>" OFFSET = 0.6 ns AFTER "clk_384mhz_p";
> NET "inputData<*>" OFFSET = IN 1 ns VALID 1.6 ns BEFORE
> "clk_384mhz_p";
>
> Another idea I have tried is to use source synchronous design to
> forward the 96 MHz clock (as a differential clock) with the data and
> then use a FIFO to move it into the "receiving" 96 MHz clock domain
> after clocking it in with the "originating" 96 MHz. Once again
> though, the design has trouble meeting timing.
>
> Here are the constraints I defined in this case:
>
> NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
> TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;
>
> NET "originatingClk_p" TNM_NET ="originatingClk_p";
> TIMESPEC "TS_originatingClk_p" = PERIOD "originatingClk_p" 10.4 ns
> HIGH 50%;
>
> NET "outputData<*>" OFFSET = 5 ns AFTER "clk_384mhz_p";
> NET "inputData<*>" OFFSET = IN 4 ns VALID 4 ns BEFORE
> "originatingClk_p";
>
> Does anybody have any insight into the best way to solve this problem?
>
> Thanks!

I vote for your second approach. Which timing constraint are
you having trouble with? For source-synchronous data you don't
need to concern yourself with offset output constraints as long
as all of your data and clock signals are registered in the IOB's.

Use DDR flip-flops for the clock and standard flops for data
unless you need DDR rates. Center the active clock edge in the
data window. Use the same IO standard for clock and data for
lowest skew. At 96 MHz this should give the other end of the
link close to 5 ns setup and hold.

Regards,
Gabor

From: John on 11 Nov 2009 15:16

On Nov 11, 1:25 pm, Gabor <ga...(a)alacron.com> wrote:
> On Nov 11, 11:38 am, Paragon <paragon.j...(a)gmail.com> wrote:
>
>
>
>
>
> > Hello all,
>
> > I have having trouble figuring out how to properly define some timing
> > constraints for an interface between two Xilinx Virtex-4 LX100's. If
> > anybody has any insight on the best way to solve this problem, it
> > would be appreciated.
>
> > Here are the fixed system parameters (these cannot be changed no
> > matter how much easier it would make the design).
>
> > 1) Each FPGA is provided with an identical 384 MHz clock.
> > 2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96
> > MHz.
> > 3) There are some control signals which need to be sent back and forth
> > between the FPGAs which are generated in the 96 MHz clock domain.
> > 4) Between the FPGAs there are pins which are connected directly,
> > including 2 pins in each direction which are capable of driving
> > differential clocks if needed. All of these signals are in 2.5 V
> > banks.
> > 5) There is a worst case of 0.95 ns propagation time on the lines
> > between the two FPGAs.
>
> > The problem is that due to the 96 MHz clock being derived in each
> > FPGA, there is not a defined phase relationship between the two 96 MHz
> > clocks (there could be any one of 4 relative phases), so data can not
> > just be sent back and forth as if it were synchronous.
>
> > I have tried constraining with OFFSET IN and OFFSET OUT constraints
> > that can handle these 4 relative phases (basically constrain as if it
> > were a 384 MHz clock) but this appears to be too much for the FPGA to
> > handle.
>
> > Here are the constraints I defined in this case:
>
> > NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
> > TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;
>
> > NET "outputData<*>" OFFSET = 0.6 ns AFTER "clk_384mhz_p";
> > NET "inputData<*>" OFFSET = IN 1 ns VALID 1.6 ns BEFORE
> > "clk_384mhz_p";
>
> > Another idea I have tried is to use source synchronous design to
> > forward the 96 MHz clock (as a differential clock) with the data and
> > then use a FIFO to move it into the "receiving" 96 MHz clock domain
> > after clocking it in with the "originating" 96 MHz. Once again
> > though, the design has trouble meeting timing.
>
> > Here are the constraints I defined in this case:
>
> > NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
> > TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;
>
> > NET "originatingClk_p" TNM_NET ="originatingClk_p";
> > TIMESPEC "TS_originatingClk_p" = PERIOD "originatingClk_p" 10.4 ns
> > HIGH 50%;
>
> > NET "outputData<*>" OFFSET = 5 ns AFTER "clk_384mhz_p";
> > NET "inputData<*>" OFFSET = IN 4 ns VALID 4 ns BEFORE
> > "originatingClk_p";
>
> > Does anybody have any insight into the best way to solve this problem?
>
> > Thanks!
>
> I vote for your second approach. Which timing constraint are
> you having trouble with? For source-synchronous data you don't
> need to concern yourself with offset output constraints as long
> as all of your data and clock signals are registered in the IOB's.
>
> Use DDR flip-flops for the clock and standard flops for data
> unless you need DDR rates. Center the active clock edge in the
> data window. Use the same IO standard for clock and data for
> lowest skew. At 96 MHz this should give the other end of the
> link close to 5 ns setup and hold.
>
> Regards,
> Gabor

Thanks for the response. I was having trouble with both timing
constraints but I didn't have the data registered in the IOBs and I
wasn't using a DDR register to output the clock.

I've updated my design so the output clock is going through an ODDR to
center the edge in the data window. All of the output data signals
and the output clock are now registered in the IOBs. All of the input
data is now registered in the IOBs and the input clock goes into a
BUFR. Both clock and data are now single ended and LVCMOS25.

I've removed the OFFSET OUT timing constraint and updated the OFFSET
IN timing constraint to

NET "inputData<*>" OFFSET = IN 4 ns VALID 8 ns BEFORE
"originatingClk_p";

I just finished building the first FPGA and it passed timing. Now
onto the second one....we'll see how it goes!

From: rickman on 16 Nov 2009 15:10

On Nov 11, 11:38 am, Paragon <paragon.j...(a)gmail.com> wrote:
> Hello all,
>
> I have having trouble figuring out how to properly define some timing
> constraints for an interface between two Xilinx Virtex-4 LX100's. If
> anybody has any insight on the best way to solve this problem, it
> would be appreciated.
>
> Here are the fixed system parameters (these cannot be changed no
> matter how much easier it would make the design).
>
> 1) Each FPGA is provided with an identical 384 MHz clock.
> 2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96
> MHz.
> 3) There are some control signals which need to be sent back and forth
> between the FPGAs which are generated in the 96 MHz clock domain.
> 4) Between the FPGAs there are pins which are connected directly,
> including 2 pins in each direction which are capable of driving
> differential clocks if needed. All of these signals are in 2.5 V
> banks.
> 5) There is a worst case of 0.95 ns propagation time on the lines
> between the two FPGAs.
>
> The problem is that due to the 96 MHz clock being derived in each
> FPGA, there is not a defined phase relationship between the two 96 MHz
> clocks (there could be any one of 4 relative phases), so data can not
> just be sent back and forth as if it were synchronous.
>
> I have tried constraining with OFFSET IN and OFFSET OUT constraints
> that can handle these 4 relative phases (basically constrain as if it
> were a 384 MHz clock) but this appears to be too much for the FPGA to
> handle.
>
> Here are the constraints I defined in this case:
>
> NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
> TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;
>
> NET "outputData<*>" OFFSET = 0.6 ns AFTER "clk_384mhz_p";
> NET "inputData<*>" OFFSET = IN 1 ns VALID 1.6 ns BEFORE
> "clk_384mhz_p";
>
> Another idea I have tried is to use source synchronous design to
> forward the 96 MHz clock (as a differential clock) with the data and
> then use a FIFO to move it into the "receiving" 96 MHz clock domain
> after clocking it in with the "originating" 96 MHz. Once again
> though, the design has trouble meeting timing.
>
> Here are the constraints I defined in this case:
>
> NET "clk_384mhz_p" TNM_NET "clk_384mhz_p";
> TIMESPEC "TS_clk384mhz_p" = PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%;
>
> NET "originatingClk_p" TNM_NET ="originatingClk_p";
> TIMESPEC "TS_originatingClk_p" = PERIOD "originatingClk_p" 10.4 ns
> HIGH 50%;
>
> NET "outputData<*>" OFFSET = 5 ns AFTER "clk_384mhz_p";
> NET "inputData<*>" OFFSET = IN 4 ns VALID 4 ns BEFORE
> "originatingClk_p";
>
> Does anybody have any insight into the best way to solve this problem?
>
> Thanks!

I would use the 384 MHz clock to move the data across the interface
with a clock enable. This gives you the full 10.4 ns cycle of the 96
MHz clock to move the data across and only the enable signal needs to
operate at the full 384 MHz rate. Inside the receiving chip the data
then needs to be synchronized to the internal 96 MHz clock.
Internally the sync circuit will need to operate at the full 384 MHz
rate, but that shouldn't be a problem. The clock enable might want to
be a differential signal.

Rick

From: KJ on 16 Nov 2009 17:01

|
Pages: 1
Prev: order
Next: Ethernet PCIe boards and PHY daughter cards?