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 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. > > > Does anybody have any insight into the best way to solve this problem? > Send identical 96 MHz clocks to each FPGA and multiply up internally to get the 384 MHz. KJ
|
Pages: 1 Prev: order Next: Ethernet PCIe boards and PHY daughter cards? |