problem switching between nios cores

I am using the latest: Quartus5.0 with SP1.04,1.17, Nios5.01

My custom board uses the Cyclone EP1C12 and is very similar to the '1C12 eval example.

I am using both plls with a 3/2 ratio to produce 49.5Mhz from the same 33Mhz. One pll for the core and one for sdram. Both Plls were

needed because of an early pinout mistake.

The code is stored in flash but executed from SDram. There is no external sram to run code from.

With the E-core this system has been tested at the 49.5Mhz and at 99Mhz. When trying the S-core or F-core (at either frequency),

my test SW downloads, but I get no output on jtag or uart0, and no debug ability.

Previous posts suggest to look at problems with the PLL(s); either they are not stable, not starting up promptly, or have the

wrong clk delay for the sdram, or the addition of cache creates timing critical back-to-back reads which the E-core did not produce.

The sdram clock itself looks OK. I have a large 2sec reset delay block and I also tried ANDing the pll clklock outputs to insure

stability on reset. All the sdram (MT48LC4M32 -7) timing options are set the same as the eval example, since it is the same chip.

I have no delay on my PLL(s), also just like the example. I would not expect the required clk shift on my board to be very different

from any of the kit boards since layout differences should be less than 1ns tpd. I quickly tried clk delays of 0,-3.5ns, +1.1ns but no go.

Only the E-core works with these settings.

I can't measure the clk delay on the board when using the faster cores because they don't run, but I might be able to measure and adjust it

on my working E-core config. Is this a good plan, or will the clk delays change when if I pop in a different core?

Hi,

Have you seen Verify Failed displayed in the IDE console?

If this, it is because sdram cannot work.

You can set the phase shift in PLL Mega-Wizard, test with -2ns, -3ns or -4ns.

Phase shift is changing with system clock frequency. I think reset delay can be deleted.

Regard,

LiangYi

I 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.

I was able to make my 2 pll implementation work with the S-core by measuring and adjusting the phase delay. This is good because I won't need to add a jumper to the board. The required phase entry to produce the same 2ns Tsu is very different between the 1pll and 2pll configuration (0ns and -7ns respectively). Looking at the skew with a scope seems the best way, although with time you could try every 2ns increment covering 360deg of phase.

From the data sheet, the sdram should operate@50Mhz with 2clk cas latency instead of the default 3clks I am using now. Any idea if this is worth doing? If it were non-burst memory (or with no cache), removing a wait state could produce a 20% or more performance boost - well worth it. I don't have a good feel for what the ratio of single-cycle to burst access might be, or if the cache makes this irrelevant. Reducing the cas latency makes the the sdram bus more efficient (higher BW) doesn't it?