Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

How to constrain a clock coming from HPS as input clock to FPGA?

Hi

I am Using Cyclone V SoC 5CSXFC6C6U23I7. to build the system I have used HPS output clock for FPGA. so there is no clock PIN I have used in My design from FPGA side.

Hence I am unable to apply create_clock constrains to this system. so please let me know how to constrain this clock? since it is not PIN or PORT nor REGISTER, not available in nets list also.

My system is giving lots of timing errors since no constrains are applied to it. got stuck

Thanks and Regards

Kushal

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Which version of Quartus are you using and which user clock are you exposing to the FPGA fabric? I thought these were automatically constrained but it doesn't sound like that's the case after all.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Also moving this post to the device discussion since more people will see it up there.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Which version of Quartus are you using and which user clock are you exposing to the FPGA fabric? I thought these were automatically constrained but it doesn't sound like that's the case after all.

    --- Quote End ---

    Quartus II 64 bit Version 14.0.2 Build 209 09/17/2014 SJ Full version

    I am using "HPS-to-FPGA user 0 clock" with frequency 25 Mhz for FPGA fabric

    It is input to pll with name SubClk as shown below and several outputs are taken from PLL

    alteraplliiop alteraplliiop // Altera's PLL macro

    (

    // Outputs

    .locked (PllLock)

    , .outclk_0 (Clk125) // 125MHz

    , .outclk_1 (Clk625) // 62.5MHz (IBCMCLK)

    , .outclk_2 (RxClk625) // 62.5MHz

    , .outclk_3 () // 100MHz (Not use)

    , .outclk_4 (Clk25) // 25MHz

    , .outclk_5 () // 15.625MHz (Not use)

    // Inputs

    , .refclk (SubClk) // Refclk 25MHz

    , .rst (~nPllReset) // Reset

    );

    Total logic utilization is 66%.

    If you need some more information related to it them please ask me because there are lot of timing violation
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    Looks like this issue is fixed in 14.1 I added a 100Mhz user0 clock to the GHRD and this was in the FPGA interfaces .sdc file:

    create_clock -period 10.0 [get_pins -compatibility_mode *|fpga_interfaces|clocks_resets|h2f_user0_clk]

    So I think all you need to do is create/add this constraint in your own user constraints file:

    create_clock -period 40.0 [get_pins -compatibility_mode *|fpga_interfaces|clocks_resets|h2f_user0_clk]
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    One more thing, are you driving the HPS 25MHz clock into a PLL in the FPGA fabric? I highly advise against that because you'll need to perform jitter analysis to ensure the FPGA PLL will remain stable. PLLs loose lock if the input clock jitter exceeds the tolerance of the PLL so feeding a PLL output from the HPS (which will have clock jitter) into a FPGA PLL input could be problematic. When a PLL looses lock then the PLL output clocks will become unstable and can lead to functional failures in the hardware. It would be less problematic to drive a common clock into the FPGA that drives PLLs in the HPS as well as the HPS PLL inputs, but this also means that the FPGA must be configured first before the HPS boots.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    --- Quote Start ---

    One more thing, are you driving the HPS 25MHz clock into a PLL in the FPGA fabric? I highly advise against that because you'll need to perform jitter analysis to ensure the FPGA PLL will remain stable. PLLs loose lock if the input clock jitter exceeds the tolerance of the PLL so feeding a PLL output from the HPS (which will have clock jitter) into a FPGA PLL input could be problematic. When a PLL looses lock then the PLL output clocks will become unstable and can lead to functional failures in the hardware. It would be less problematic to drive a common clock into the FPGA that drives PLLs in the HPS as well as the HPS PLL inputs, but this also means that the FPGA must be configured first before the HPS boots.

    --- Quote End ---

    I understood what you have advised, since I have used all the FPGA pins for other functionality I dont have any pin so that I can get clock input from it and feed it to FPGA PLL. For the time being design is giving positive results, but if such problematic thing arises what will you suggest I should do?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    Is your board already designed or can you still make changes? If that's a possibility and you have slow I/O like push buttons, LEDs, etc... on the FPGA side of the device perhaps you can wire them up to the HPS I/O to free up a clock pin. I assume you want the FPGA PLL because you have multiple frequencies or need a higher frequency than what the HPS can provide to the FPGA? If not then you could drive everything off that same clock but I'm guessing you have your reasons for wanting a FPGA PLL.

    When you daisy chain PLLs you have to make sure the jitter from the first PLL doesn't exceed the jitter tolerance of the second PLL. So in your case you need to make sure the jitter from the HPS PLL is low enough that the PLL in the FPGA doesn't loose lock. So if you can move a pin I would recommend do that since chasing PLL issues is not fun.