Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
1,375 Views

Long Boot Time after update to 5.0

after updating to Quartus / NIOS II 5.0 my design needs about 7 seconds to boot (reboot) from EPCS. With an oscilloscope I've measured, that the FPGA configuration is done in 80 msec. After a short pause of 150 msec the bootloader starts to load the firmware from EPCS into SRAM. This procedure lasts now 7 seconds. 

The serial clock on EPCS shows that every 120 usec one byte is serial shifted out (120usec x 65250 = 7 sec total) 

The previous version had a repetitive rate of 1,25 usec (= 81msec total ) 

Facts: 

- Reset signal is stable (PLL with locked-detection) 

- both, design and custom board are re-compiled with new version 5.0 

- EPCS programming is done via Flash-Programmer 

- Environment variables are set to Quartus50 

- firmware size: 65250 bytes 

- Reset Address set to EPCS 

- Exception Address set to SRAM 

- Firmware starts immediately after download ends 

- previous version (4.2 / NIOS II 1.1) needs 200msec total to start. 

- system clock is 49.15 MHz 

- all linker sections set to SRAM 

 

Any suggestions ? 

 

Mike 

 

added due to new experiences : 

- reading from EPCS via HAL ( alt_read_flash() ) is also extremly slow!
0 Kudos
13 Replies
Highlighted
Valued Contributor III

Re: 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.
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

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.
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

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
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

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.
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

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
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

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.
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

In Quartus5.0SP1, the lines 'extradelay = 1;' are still present in class.ptf and em_epcs.pm on lines 84, and 344 respectively.

0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

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
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

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

Reading a sector (0x10000) went from 8sec to ~2sec or less.
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

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
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

BTW: My boot time went from > 8 sec to < 1 sec. 

 

--Scott
0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

Hmmm.... Scott, those edits should&#39;ve been done by the service pack. Just curious, was your recent install/update Quartus 5.0 SP1, or Nios II 5.0 SP1? (they are separate installs)?

0 Kudos
Highlighted
Valued Contributor III

Re: Long Boot Time after update to 5.0

Hi Jesse, 

 

> was your recent install/update Quartus 5.0 SP1, or Nios II 5.0 SP1? 

> (they are separate installs)? 

 

I couldn&#39;t find any service packs for Nios II 5.0. But I found these: 

 

Quartus 5.0 SP1 : https://www.altera.com/support/software/dow...nl-qii50sp1.jsp (https://www.altera.com/support/software/download/service_packs/quartus/dnl-qii50sp1.jsp

Quartus 5.0 SP1.04 : https://www.altera.com/support/software/dow...tical-issue.jsp (https://www.altera.com/support/software/download/service_packs/quartus/dnl-q50sp1-critical-issue.jsp

 

Basically, yesterday I finally upgraded to Quartus 5.0/Nios-II 5.0. I installed the SPs 

listed above. Then made a copy of the 1c20 standard design, changed the reset address 

to epcs ... and then started on this issue. 

 

That&#39;s it -- yesterday morning, I started out with a clean machine after completely 

uninstalling all of 4.2. 

 

--Scott
0 Kudos