- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have a working Cyclone V system running both Linux 3.14 and u-boot without any major issues.
Under u-boot we can only achive 11Mb/s transfer speed on QSPI with 90Mhz clock and quad mode enabled. We are using altera derived code configuring the qspi for indirect read transfers and polling the fifo and writting to SDRAM (no DMA or IRQ's involved). We find that the CE line is driving low for only 16.6uS initially and then bursting at 1.2uS (which is one 4 byte transfer). We expect to see CE stay enabled for the duration of the transfer. Tracing the code finds the QSPI fifo fills up (508 bytes) after approx 700 bytes transferred and then the QSPI transfers word at a time off the bus due to fifo being filled. It gives the appearance that the HPS cannot read the fifo data quick enough but we can not find any areas of code that would account for the delay. Even when transferring 65K to internal RAM we see no improvement in transfer speed so it is not the DRAM that is at fault. Even trying highly optimized fifo read (two arm instructions per word in bursts of 16 words) the HPS appears to stall when reading the the FIFO and CE enabled times do not change. All internal clock lines are configured fast with l3/l4 clocks at 450Mhz and qspiclock is 360Mhz. Under DMA in linux the CE line stays low for approx 364uS but then also shows signs of stalling at about 16-17K bytes transferred. But it is the u-boot time we are most interested at this stage. Any insight as to what subsystems we should check out would be greatly appreciated. Attached is sample trace with top trace showing CE line during long transfer. (we are aware that logic analyzer is too slow and clock line is alised but we are only interested in CE time).Link Copied
0 Replies

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page