Forum Discussion
Altera_Forum
Honored Contributor
20 years agoI have the S-core@50Mhz working now. My plan to use the E-core to adjust the sdram clk phase delay worked, and seems a quicker/easier method than adding on-chip ram to run test code from. The E-core is very forgiving when it comes to the sdram timings, probably because there is no cache and no back-to-back reads.
I added a jumper on my board so I could satisfy the core and sdram clks from the same pll instead of two separate plls. This may not have been necessary - I'll revisit this later. The Cyclone chapter on the PLLs does not explain how my two pll configuration was ever working in the first place. Next I measured the actual skew at the sdram pins, by measuring the rising sdram clk to falling ras# or cas# (Tsu). I could see this Tsu changed consistent with the different sdram phase delays I tried: 0, -3.5ns, -6ns. The more negative the number, the more setup time is added - opposite of what I originally thought. I found that a phase delay of 0 produced about 2ns of setup - the worst-case minimum required for the sdram. When I replace the E-core with the S-core it works, and the measured sdram clk skew remains the same. The performance increase is very noticable, and should be enough to solve my BW limitations. Later I may try the F-core or higher (100Mhz) operation. There are some good reasons for keeping both the reset delay block and for resetting if the pll ever loses lock. The datasheet says that if the pll ever loses lock, even briefly, none of the phase settings are guaranteed and a pll reset is required. Also, the timing of the first few PLL clocks may not be correct. Even with no pll, the fpga may come out of reset before a (higher voltage) external parallel flash is ready, and begin fetching instructions too soon. Any of these situations may produce unstable, erratic behavior - for me, it is better to have an unexpected board reset to debug than flakey operation.