Forum Discussion

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

Timequest reports no constraining problems, hardware still not working

Hello all,

I have a Verilog module (coded in Bluespec) that was working in my Stratix IV Kit. This module internally uses pipelined LPM_DIVIDE.

When I decided to migrate to Stratix V (5SGXEA7K2F40C2), it just stopped working @ 50 MHz. The module is used inside a Qsys system, connected via Avalon-MM to a Nios II Processor. The only I/O pins are CLK, RST_N and jtag pins. All modules inside Qsys use the same input clock (50 MHz).

After setting this input clock in Timequest, it doesn't report any failing path and gives me a maximum frequency of 55 MHz. However, at 50 MHz it fails to work, while at 30 MHz it works flawlessly.

Am I missing anything?

I appreciate anyone's help and I apologise for any beginner's mistake that I might be doing.

Cheers!

4 Replies

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

    hard to say what is causing this but get a can of freezer can and spray your stratix to ice and see if it is timing. You may have wrong io constraints

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

    Hello,

    the Stratix V Dev. Kit does have a cooler fan on the FPGA, so it shouldn't overheat.

    And as I said, the only I/O for this system is clock, reset and jtag. They shouldn't affect the system timing in overall if not constrained, right?

    Thanks for the quick answer.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Hello,

    the Stratix V Dev. Kit does have a cooler fan on the FPGA, so it shouldn't overheat.

    And as I said, the only I/O for this system is clock, reset and jtag. They shouldn't affect the system timing in overall if not constrained, right?

    Thanks for the quick answer.

    --- Quote End ---

    It is not about overheating but testing temperature effect by freezing and if it still fails try heating it with hot air. If design works in this test then it confirms timing issue as delays are changed by temp.

    Other causes related to clk should be considered e.g. rate control, fifo overflowing etc...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    It is not about overheating but testing temperature effect by freezing and if it still fails try heating it with hot air. If design works in this test then it confirms timing issue as delays are changed by temp.

    Other causes related to clk should be considered e.g. rate control, fifo overflowing etc...

    --- Quote End ---

    Problem solved.

    It turns out that I've used an old project as basis, and this project had the pin AH22 labeled as 50 MHz Clock. According to the reference manual, this pin actually is 100 MHz for bottom port of DDR3. Using the correct 50 MHz Clock Pin (AN6) solved my problem! Thus, Timequest was never wrong at all!

    Thank you for any help!