Long Boot Time after update to 5.0

Hi Mike,

This was just brought to our attention at Altera and is actively being looked into. I cannot offer any suggestions for you just yet but will try to post something once any information is available. For what its worth I've traced through the boot-loading code and have found that the issue is with the processor waiting for the EPCS controller to have data ready between successive reads while copying data from flash to ram.

edit: the instructions below have been edited to account for the issue "mir" mentioned in the post below this one!

We now have a workaround to this issue -- a permanent fix will be included in the next Nios II release:

1. Close any open instances of SOPC Builder

2. Open the file altera/kits/nios2/components/altera_avalon_epcs_flash_controller/em_epcs.pm and make the following change to line 323:

Change this line:

extradelay = "1";

--to--

extradelay = "0";

After performing this modification save & close the file.

3. Open the file altera/kits/nios2/components/altera_avalon_epcs_flash_controller/class.ptf and make the same change change to line 83 (extradelay = "1" should be changed to extradelay = "0"). After performing this modification save & close the file.

4. Re-open SOPC Builder for any systems where you wish to use the EPCS controller

5. Delete the EPCS controller from your design

6. Add a new EPCS controller (from the 'memory' group of IP)

7. Re-generate the system in SOPC Builder 8. Re-compile the affected design in Quartus.

OPTIONAL: The same fix can be used to speed-up flash programming times in board components that are used to program EPCS devices, or to speed up access to designs that use the (legacy) ASMI peripheral. To address this issue, open the class.ptf & em_asmi.pm files in the folder altera/kits/nios2/components/altera_avalon_asmi folder and repeat the changes described above (class.ptf line 74 & em_asmi.pm line 68). Again, designs that use ASMI should be opened in SOPC Builder, the ASMI peripheral deleted, added back again, and re-generated/re-compiled.

Background: the 'extradelay' parameter is useful for interfacing to certain SPI devices such as ADCs that require delay between SPI chipselect assertion and clocking. However, its inclusion for the EPCS Flash controller was erroneous.

Hi Jesse,

Thanks for this great help. When changing extradelay to 0 all EPCS-Accesses now work as expected.

But it was not easy to change this value. Changing in 'em_epcs.pm ' didn't also change the value in its corresponding class.ptf and so didn't change it in the ptf file of the CPU. I couldn't get class.ptf updated when reopening SOPC builder and adding an epcs-component. So I've changed it in 'em_epcs.pm' and also in its 'class.ptf' to get it accepted.

In the corresponding custom board design is the asmi-component, also setting its extradelay. Changing this parameter also to zero, shortens Flash-Programmers time remarkable.

But these parameters also were set in version 4.2 / NIOS 1.1 and worked correctly (fast). Why?

Mike

MiR,

Oops, you are correct about the class.ptf. Thanks for that; I'll edit the text I have above to work around this.... we 'make' the .pm file to generate the .ptf with its default parameters and that is where my instructions were flawed.

Also thanks for the tip about the flash programmer! That is really useful although the speed never bothered me... probably because it was on-par with CFI flash programming latency.

To address your question - it was a bug masking a bug. In 5.0 several fixes were put into the SPI controller that basically excited this bug. Previously with 'extradelay' set, the 'extra delay' was not occuring in all cases as it should have, depending on the state of various SPI controller register bits (it was a pretty rarely used feature from what I'm told). With 'extra delay' now in affect for all SPI transfers, the bogus parameter in the epcs/asmi logic started delaying things.

Hi Jesse,

I'm using Quartus/Nios-II 5.0 w/ SP 1.04 -- I'm still seeing the problem.

Was this supposed to be fixed ... or should I follow the instructions below?

Thanks,

--Scott

Hi Scott,

Do you mean Nios II 5.0 SP1? (Just released)? Yes, this was fixed in that release. The fix is in the EPCS peripheral, relevant flash programming files, and all example designs, so that if people make a new design or copy from an example all should be well.

However, my bet is that you are re-generating an existing design and this is a problem of a stale .ptf file. I would reccomend opening your design in SOPC Builder, deleting and then re-adding the EPCS peripheral, and re-generate/re-compile in quartus. This should clear everything up. My apologies for not making this clear.

Hi Jesse & tns1,

First, I thank you both for your attention on this :-)

> Do you mean Nios II 5.0 SP1? (Just released)?

SP 1.04 -- this is SP1 plus the latest "list path" patch.

> The fix is in the EPCS peripheral, relevant flash programming files, and all example designs

I've been testing with the 1c20 example design. All I did was change the reset address

and regenerate ... but no good.

> I would reccomend opening your design in SOPC Builder, deleting and then

> re-adding the EPCS peripheral, and re-generate/re-compile in quartus.

Ok ... done, but ...

> This should clear everything up.

... nope ... just as slow. tns1 mentioned:

> In Quartus5.0SP1, the lines 'extradelay = 1;' are still present in class.ptf and

> em_epcs.pm on lines 84, and 344 respectively.

Are we back to the drawing board on this one ... time to try to old fix?

Thanks

--Scott

I edited the two files to set the extra delay to 0.

Reading a sector (0x10000) went from 8sec to ~2sec or less.

Ok, things are up to speed, this is what I had to do:

1. edit em_epcs.pm

Line 68:

<span style="color:red">-my $default_extradelay = "1";

+my $default_extradelay = "0";</span>

Line 344:

<span style="color:red">-extradelay = "1";

+extradelay = "0";</span>

2. edit class.ptf

Line 83:

<span style="color:red">-extradelay = "1";

+extradelay = "0";</span>

3. update in sopc builder

-remove epcs controller.

-add epcs controller back in again.

-regenerate.

4. rebuild design in quartus

After that all was well.

Regards,

--Scott