Forum Discussion

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

SRAM interface timing discrepancy from Quartus-II 7.0 and 9.0

I have a design which contains an SRAM interface with the default PLL phase shift, -4.8ns for this SRAM. It was compiled by Quartus-II 7.0 and it works perfectly on my target board with an EP2C20F484C7. Recently, I updated the design software to Quartus-II 9.0 SP1, the same design was compiled successfully. However, the design didn't work on my target board. The NIOS-II didn't start. The debugger stopped before my application code. It took a while for me to find what causes the problem. I found that it was caused by SRAM interface timing from Quartus-II 9.0 SP1. When I reduce the PLL phase shift to -4.5ns, it starts to work while in Quartus-II 7.0, it can work when the PLL phase shift is set upto -6.7ns. Although this problem has been resolved, I want to know if there are other discrepancies or any implications. Many thanks.

13 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    It is all pointing to unstable timing window. It is difficult to blame the tool. You may blame the build after each compilation. Even the slightest change of code means a different fitting. In particular you need to check the actual Tco at your output pins in the timing report. These could vary from build to build. especially so if you are not using fast io registers. You must constrain Tco, even though you get what you want or better but no fixed values. You must also constrain Tsu,Th of inputs which should be fast registers.

    It is hard to measure PLL phase and say there is a difference of 2ns from version to version. PLLs may go wrong of course but needs proof.

    The issue of temperature is to test the fpga/sram timing over a good range of operation. You will also need to check several boards. If you are reading and writing to sram on same clk then there is the added complexity of clk/data direction being either together or opposite.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Kaz,

    Thank you very much for your reply. I am trying to find what causes timing discrepancy.

    I agree with you on tco,pd, and tsu assignments. Although the slightest change of code means a different fitting, a few examples show that timings only change very slightly from the same compiler, e.g. Quartus-II 9.0 SP1. However, you can't assign tco, th, tpd and tsu to every path although the values of every path can be reported. Sometimes, the compiler creats warning meassages such as "no timing path applicable to specified source and destination". I think that this applies to the paths from the SSRAM interface clock to the SSRAM interface outputs.

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

    Hi,

    Tsu and Th plus fast input registers are meant for your inputs from sram.

    Tco and fast output registers are for outputs to sram. If the tool rejects these constraints on grounds of no path available then this indicates that there is no register on those paths at one end and this is a good indication that some of your inputs or outputs are not registered. You better register every input and every output in order for the constraints to be applicable and for timing to be consistent.