ALTPLL Problem

Hi janhendrik,

What version are you using?? We found a slight SRAM timing bug in the SRAM interface shipped with Nios II 1.0; its been corrected in 1.01 (v1.01 is somewhere between our releasing it and the CDs arriving in customers hands).

To be precise, our SRAM interface wasn't meeting setup time on writes above 50Mhz. Prior to Nios II 1.0 we did test SRAM in this region of clock speeds but observed no problems until the new Stratix II boards came out (we start supporting Stratix II in Nios II 1.01). At this point, due to device timing, we started seeing occasional problems and traced it to a Tsu violation for writes.

You can patch the SRAM timing very easily if you don't yet have Nios II 1.01:

1. Close SOPC Builder

2. Open altera/kits/nios2/components/altera_nios_dev_kit_stratix_edition_sram2/mk_sram.pl (do this for the "stratix_edition_sram" folder as well)

3. In these files locate the following line: "if ($system_frequency.....", and just drop in this text to replace it:

if ($system_frequency > 100E6)

{

$SLAVE_SBI->{Read_Wait_States} = '20ns';

$SLAVE_SBI->{Write_Wait_States} = '10ns';

$SLAVE_SBI->{Hold_Time} = '10ns';

$SLAVE_SBI->{Setup_Time} = '5ns';

}

elsif ($system_frequency > 50E6)

{

$SLAVE_SBI->{Read_Wait_States} = 1;

$SLAVE_SBI->{Write_Wait_States} = 1;

$SLAVE_SBI->{Hold_Time} = 1;

$SLAVE_SBI->{Setup_Time} = 1;

}

The "else" condition, for speeds of 50Mhz or lower, is fine with 0 Tsu because of the effects of our "half-clock" hold time because the outgoing write signal gets gated adding sufficient delay.

4. After you make this change, open SOPC Builder, remove the SRAM(s) from your design and re-add them before re-generating and compiling. This will ensure that the changes take effect.

If there is some other problem please advise!