Contributor
Regular ContributorHi
I am tehjingy_Altera, and I will be helping you with your issue.
Does the Linux distro hang every time the f2sdram_bridge is accessed?
Could you elaborate more on the behavior?
ContributorOk, more info for this situation.
KEY 1: If data is kept reading on f2h_sdram0 148M no issue is found.
Once the f2h_sdram1 is enable via some control and start stream at 144M the system stall on distro.
However, the data r/w on bus f2h_sdram0 andf2h_sdram1 are functioning properly.
The only issue is the system aka the CPU is stall and terminal no longer response.
The most interesting thing is that the background FPGA fabric are all functioning like free-run w/o any stall or data stuck.
Well the same design with only slowing down the f2h_sdram1 from 144M to 100M fixed all the issue.
f2h_sdram0 <- mostly read
f2h_sdram1 <- mostly write
So when 144M is used onf2h_sdram1 and once the CPU is stall. All data read / write are still working.
read streams write streams are all functioning via some interface to verify.
Brian
Regular ContributorHi Brian,
There is no definitive answer for the maximum frequency of the F2SDRAM bridge.
For Cyclone V, F2SDRAM bridge access is managed by the SDRAM subcontroller system, and the operating frequency for the L3 Interconnect, which the F2SDRAM bridge uses has a maximum clock rate of 400 MHz for the -1V speed grade.
https://www.intel.com/content/www/us/en/docs/programmable/683801/current/hps-clock-performance.html
The available throughput is shared among all F2SDRAM bridges instantiated in the system. As more bridges are added, we will need to reduce the input frequency to ensure reliable operation and to stay within the total bandwidth limits.
Please also note that the above calculation is theoretical. In practice, real-world throughput may be lower due to various system factors.
Regards
Jingyang, Teh
ContributorPlease use "@" to reply the system did not email notification.
For this explanation, it is not given out the possible cause of stall on distro.
In order for system stall the sdram data must be runed or corrupted.
However with proper address R/W there is no way to trigger such action.
So why during boot or when system is stable once the high throughput write
could introduce this issue?
Could you provide a check method for L3/L4 is enable?
I think there maybe cache that is not turned on?
Regular ContributorHi
Let me know if further assistance is needed .
Do you have any follow up question from the previous comment?
Regards
JIngyang, Teh
