SRAM interface timing discrepancy from Quartus-II 7.0 and 9.0

[Altera_Forum]

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.

[Altera_Forum]

looks like you haven't optimised the sdram IF timing window, so it is edgy. try heating up your board with a hair dryer or cool it down with freezing spray and see what happens.

[Altera_Forum]

Kaz, 

 Thank you very much indeed for your looking into my problem.   It is SRAM not SDRAM. The compiled design by Quartus-II 7.0 worked on the same target board at almost the same time as the design by Quartus-II 9.0SP1. I would say that any difference of physical conditions can be ruled out.    Best regards,   BC

[Altera_Forum]

even with SRAM, if your phase shift might be a problem then heat the target up and also cool it down. if your target has temperatur problems then you should recheck for setup and hold time. if your design is cooled down, the fpga gets faster and the hold time becomes more critical. also check your quartus settings fast input out registers and other stuff.

[Altera_Forum]

It might affect timing a little bit by heating up and then cooling down the board. I don't think that it can cause as much difference as 2ns. My target boards are in production and don't have temperature problem.

[Altera_Forum]

hmmm i had different experiences. 

startung with quartus 4.2 the product family design was finished in quartus 7.2  with quartus 8 some of these targets were not working properly and the more the enviromental temperature differs from 25 degree celcius the more worse these targets were and some others started to fail too.  at the end, i had to recalculate the pll phase again with newer reported values and all targets were working again as expected.  up to quartus 7.2 no change needed in phase shift, from quartus 8 and never the new calculated values must be used.

[Altera_Forum]

Hi Michael, 

 Thank you so much for you sharing your experience with me. Really appreciated.   I started from Quartus-II 5.0 more than 4 years ago. Every time when I upgraded Altera design software, I always had different issues. Up to Quartus-II 7.0, I did not want to take risk to upgrade it 7.2 becuase it is not backwards compatible. Now, I am going to start a new design and ideally I can use the latest design software. I upgraded it to 9.0 SP1 and tried to the existing design. Then I found the problem.    I agree with your "from quartus 8 and never the new calculated values must be used." Beyond this, I have lots of other timings as well in my design. Should I re-calculate all the timings, verify and validate all of them?   Best regards,   BC

[Altera_Forum]

well, i had recalculated _ALL_ timings and also verified them with a LeCroy Scope in real life target. as nearly all fpga's here rely on the same sources and use the same software binary, i had to do this a dozend times.  

also check your quartus settings. for the sdram if here, i rechecked that fast input outregisters and other settings are as needed. and i guess you have checked the pin output current settings to prevent over and undershots. thats why i checked it with a very fast scope

[Altera_Forum]

The oscilloscope I have been using is LeCroy WaveRunner 6050A, 500MHz. If necessary, I will verify and validate them. Do you think that the SSRAM interface with SOPC 9.0SP1 is significantly different from the SSRAM interface with SOPC 7.0? Many thanks.

[Altera_Forum]

sorry i have no information about that 

so just check that and you know you haven't missed to check the settings. i had verfied that all projects don't miss the quartus settings i had to setup to gain the needed setup that the design runs, after updateding to Q8.1

[Altera_Forum]

I treied a very simple example with absolutely necessary components and I am sure that the settings are the same for Quartus-II 7.0 and Quartus-II 9.0. But timings are different from Quartus-II 7.0 and Quartus-II 9.0SP1. Thank you very much.

[Altera_Forum]

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]

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]

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.