cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
5,589 Views
Registered: ‎06-30-2011

Constraining intups to a related clock output

Jump to solution

Hi,

 

I have a PHY connected to my FPGA using RMII. The FPGA is clock source for the REF_CLK by using a DDR Flip Flop source by an interanl 50MHz clock. It is easy to defined the timing constraints for the TX-signals using the OFFSET OUT with REFERENCE_PIN constraint.

But no my question, how to constrain the RX-signals? The PHY drive the RX-signals related to the clock at the FPGA output pad and not the 50MHz oszillator, which sources the FPGA, so i cannot use the OFFSET IN constraint. The only way I see, is to use the FROM PADS TO FFS constraint, but this does not automaticaly covers the delay from the internal 50MHz tree through the DDR Flip-Flop to the output pin.

Any other ideas?

 

Thanks martin

0 Kudos
1 Solution

Accepted Solutions
Highlighted
5,718 Views
Registered: ‎06-30-2011

Hello Faraj,

 

No not for ISE. But I used a register for every RMII signal and force them into the IOB. That gave me a known timing according to the datasheet, so I did the calculation manually and came to the conclusion that an internal clock of 50MHz divided by 2 with the IOB register was sufficient.

Once you came back to the same problem but targeting a new FPGA that is supported by Vivado, check these pages:

http://www.xilinx.com/support/answers/63174.html

https://forums.xilinx.com/t5/Timing-Analysis/How-to-set-input-delay-and-output-delay-when-source-Synchronous/td-p/549028

View solution in original post

0 Kudos
8 Replies
Highlighted
Xilinx Employee
Xilinx Employee
5,569 Views
Registered: ‎08-12-2008
you may want to find out the delay between the 50MHz clock that is input to the FPGA and the output clock that source the RX signals and then use OFFSET:IN with respect to the 50MHz clock by taking the delay value into consideration in the OFFSET:IN
0 Kudos
Highlighted
Contributor
Contributor
3,488 Views
Registered: ‎01-09-2009

Hello Martin,

 

I know that this is an old post regarding RMII Timing. I would like to ask if you were able to constrain your interface to PHY using ISE? 

 

Regards,

Faraj

 

0 Kudos
Highlighted
5,719 Views
Registered: ‎06-30-2011

Hello Faraj,

 

No not for ISE. But I used a register for every RMII signal and force them into the IOB. That gave me a known timing according to the datasheet, so I did the calculation manually and came to the conclusion that an internal clock of 50MHz divided by 2 with the IOB register was sufficient.

Once you came back to the same problem but targeting a new FPGA that is supported by Vivado, check these pages:

http://www.xilinx.com/support/answers/63174.html

https://forums.xilinx.com/t5/Timing-Analysis/How-to-set-input-delay-and-output-delay-when-source-Synchronous/td-p/549028

View solution in original post

0 Kudos
Highlighted
Contributor
Contributor
3,455 Views
Registered: ‎01-09-2009

Hello Martin,

 

Thank you for your reply. I have a working implementation for Artix7 with Vivado, constraining with tool was not an issue because of the virtual clock concept.

 

my goal is to have my design working on Spartan 6. Could you explain more on how you got your system working?

 

Best Regards,

Faraj

0 Kudos
Highlighted
Guide
Guide
3,433 Views
Registered: ‎01-23-2009

constraining with tool was not an issue because of the virtual clock concept

 

From what I understand of your system, you probably wouldn't/shouldn't use a virtual clock for the interface, but a generated clock (as shown in the post referenced by @martinnetmodule)

 

Avrum

0 Kudos
Highlighted
Contributor
Contributor
3,421 Views
Registered: ‎01-09-2009

Hello Avrum,

 

Yes, I would use a generated clock (as shown in the post referenced by @martinnetmodule).

 

 

system.png

 

The figure above depicted the system which im trying to implement. This system is as well very similar to frank's system in his post: https://forums.xilinx.com/t5/Timing-Analysis/RMII-Timing/td-p/273822, except that in my system, the 50 Mhz phy_ref_clk is a regenerated signal based on 100 MHz.

 

Ofcourse I can use ODDR in my design if it already worked. I do not know, if frank were able to constrain his design using ISE. Indeed, you did a very good timing analysis for his design.

 

I used a virtual clock for my experiments with Artix7, which worked very fine, but my goal is to implement this system on spartan 6.

 

Regard,

Faraj

 

 

 

0 Kudos
Highlighted
Guide
Guide
3,397 Views
Registered: ‎01-23-2009

I used a virtual clock for my experiments with Artix7, which worked very fine,

 

Again, a virtual clock is not the correct thing to use for this interface - a virtual clock is created using a create_clock command with no sources. The correct thing to use is a generated clock, created by the create_generated_clock command.

 

As for doing it in a Spartan-6 (in ISE), there is no way to constrain this interface - neither the inputs nor the outputs. You have to design the interface to be correct by using IOB flip-flops and proper cycle based delays or multiple phases of the clock. The return path is nearly impossible to analyze...

 

For the outputs, look at this forum post for designing the output interface.

 

For the inputs, the best I can do is refer you to this post, which describes the analysis of a similar RMII interface.

 

Avrum

0 Kudos
Highlighted
Contributor
Contributor
3,367 Views
Registered: ‎01-09-2009

Hello Avrumw,

 

Thank you for your reply.

 

Again, a virtual clock is not the correct thing to use for this interface - a virtual clock is created using a create_clock command with no sources. The correct thing to use is a generated clock, created by the create_generated_clock command.

 

Yes you are right. Actually I used create_generated_clock command with VIVADO as follow:

create_generated_clock -name phy_ref_clk -source [get_pins i_clock_gen_xilinx_mmcm_0/i_MMCME2_BASE_0/CLKOUT0] -divide_by 2 [get_ports phy1_ref_clk]

 

For Spartan-6, I have designed the interface using IOB flip-flops and multiple phases of the clock.

 

As shown in the following timing diagram, the rising edge of clock clk_100mhz is used to generate the phy_ref_clk. The inputs from PHY are sampled on the falling edge of clk_100 MHz, every two cycles of this clock. The diagram also shows the worst and best case analysis. For worst case analysis (Slowest paths), the FPGA needs 4.7 ns to generate phy_ref_clk on its output and from this point the PHY itself needs 14 ns to deliver a new data. If in FPGA the inputs are sampled with the rising edge of clk_100 MHz, then this results in a setup violation (1.3 ns, required 3.621 ns from pad to register input). Therefore, the falling edge of clk_100mhz is used to sample the inputs (setup time 6.3 ns).

 

For best case analysis (fastest paths), the FPGA needs 2.0 ns to generate phy_ref_clk on its output and from this point the PHY itself needs 2.0 ns to deliver a new data. If in FPGA the inputs are sampled with the falling edge of clk_100 MHz, then this results in a hold violation where new data is sampled instead of having the old and required data at that time.

 

  rmii_timing_diagram.png

These analysis are almost similar to the referred post which describes the analysis of a similar RMII interface.

 

Is there any chance to get this interface working on Spartan-6? Or shall I use a system synchronous approach?

 

Best Reagards,

Faraj

0 Kudos