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!
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.
In Quartus5.0SP1, the lines 'extradelay = 1;' are still present in class.ptf and em_epcs.pm on lines 84, and 344 respectively.
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
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
Hmmm.... Scott, those edits should'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)?
Hi Jesse,> was your recent install/update Quartus 5.0 SP1, or Nios II 5.0 SP1? > (they are separate installs)? I couldn'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's it -- yesterday morning, I started out with a clean machine after completely uninstalling all of 4.2. --Scott