Hi everybody , we used Arria 10 FPGA with PHY Lite in our last design. In our new design , we migrate to Stratix 10 and we use PHY Lite to interface DDR4 DRAM. The architecture of Arria 10 PHY Lite is very similar to Stratix 10 PHY Lite , however we encounter an issue on the Stratix 10 PHY Lite Avalon bus waitrequest signal. When we try to access the PHY Lite basic information through the Avalon bus , the waitrequest signal is always asserted (at logic high). At the moment the waitrequest signal is asserted , the avl_read and avl_write are both low. We should have set the reset signals correctly , but we have no idea why the waitrequest signal is always asserted. When we go back to our Arria 10 system and we check the waitrequest signal on signal tap , the waitrequest looks normal as what it should look like. Is there anybody have an idea of the above situation ?
Please accept my apology for the delay in response due to workload.
Can you please help to verify following ?
1. Ensure reset_n is toggle out of reset mode. From 0 to 1
2. Ensure correct clock frequency is supplied to DDR4 pll_refclk input pin. This will enable DDR4 PLL to operate and generate all desired output clk to DDR4 IP
3. Ensure the pll_locked and interface_locked is high. Data transfer should start after the assertion of this signal.
Hi Aida ,
Thank you for your reply ,
- we are sure that the reset_n is at 1 , we checked it on signal tap.
Our interface clock frequency is 1200MHz , and we select 150MHz for the PLL reference frequency.
We measured the input clock frequency and we are sure that it is 150MHz.
And I measured the clock output frequency , it is exactly 1200MHz.
We used Arria 10 PHY Lite in our last project , I believe that we should have set the PHY Lite settings correctly.
Other than clock signal output , we already have the control , address , DQ , DQS signals correctly output ,
thus our next step is to control the timing , however we don't know why the waitrequest signal of the avalon bus is always high ,
and we failed to access the avalon bus information.
3. Yes , we checked the pll_locked as well , it is 1 after the reset_n goes high.
We are currently using a 50MHz clock on the avl_clk , according to the specification , maximum frequency of avl_clk allowed is 167MHz , is it right ?
Looking forward to hearing from you , please let us know the possible reasons of having the waitrequest signal tied high.
Thanks for checking.
When you migrate the design (from Arria 10 PHY Lite to Stratix 10 PHY Lite), just wonder whether do you make any changes or just migrate the design only? As I know there is a different on bit address mapping between Arria 10 and Stratix 10. As you can see below, for Arria 10 it have 28 bits but for Stratix 10 is 31 bits.
I can see that you are enabling dynamic configuration in the design. Have you try run the reference design ? You may find it useful to run the reference design simulation and see whether the waitrequest signal issue is able to replicate and compare the signal with your custom design. The reference design files can be downloaded from Intel Design Store and restore the design using Intel Quartus Prime Pro Edition software. It is always recommended to use latest version of Quartus software. You can use this reference design as a starting point design and modify as required to suit your design application.
Refer to this Application Note (AN) on the steps to set up and run the simulation reference design --> https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an888.pdf
Let me know your feedback.
Some additional info:
Regarding the waitrequest stuck, probably it is due to the rd/wr command asserting in wrong way. This might cause the wait request stuck. Please check on this.
Another thing to take note is please try not to send any Avalon transaction before calibration is completed and the controller is ready to accept user Avalon command.
Hi Aida ,
We have carefully checked the wr/rd signals before , anyway we will double check it.
We have disconnected the OCT calibration block at the moment , I will check if there is any other calibration in progress.
Thank you so much , the information you provided is very helpful to us.
Hi Aida ,
We have checked all the connections in our design but we do not find any thing wrong yet.
Could we send you part of our codes which involves PHY Lite and have Altera AE help us to take a look ?
Please accept my apology for not follow-up sooner.
Do you have a chance to try out the reference design given and compare the signals with your custom design? If yes, can you share with me the results seen? Is the waitrequest issue replicate-able with reference design ?
Regarding the code, i really wish I could help but unfortunately, I'm not the expert on the coding area. But, I will try my best to help you. Allow me sometime to consult my colleague that have this expertise. I'll get back to you later regarding this.
Hello Aida ,
I downloaded the reference design , and I looked at the code of the reference design.
It involves NIOS II soft core , it differs from what we do , we simply use the PHY Lite in our logic.
Our R&D team have been stuck on this issue for a while ,
could you please help us to contact the PHY Lite code expert to take a look on our PHY Lite connection ?
Thank you so much for your support.
I have reached out my colleague and I received few inputs as below. Please take a look.
- Check the register address, we should confirm the lane and pin addresses are correct.
- Please check the pin assigned correctly.
- Suspected avl_readdata and avl_writedata are always empty that represents no data receive or send out to Avalon.
RE-copy from email to Forum for tracking purpose :
Sorry for the long wait.
From what I discussed with my colleague, please refer to comments below:
1.Reference Design ( from AN 888) :
- Firstly, we need to know whether this is IP problem or user traffic problem.
- Hence, please run the ref design. Yes, the ref design use NIOS is true. And it differs from what you are doing. I acknowledge that. But you can proceed to run it regardless use nios or not and check if the waitrequest signal stuck or behave as expected. The reason behind is from the ref design, you can observe how the Nios control the PHYLite and get the idea on how it works so that you are able to do the same on your side. Most importantly, this is the way to isolate whether the failure is due to IP issue or user traffic issue.
2. Signal Tap:
- Have you tried to run using signal tap on the Stratix 10 design, see if there is any anomaly? I checked the design (IO_Library.qar), but I can’t see any Signal Tap file.
- The waitrequest signal comes from Nios and Nios is driven by avl_clk. You may want to re-check if avl_clk is correctly connected to PHYLite IP.
4. I/O Column:
- Does the EMIF IP and PHYLite IP located in the same IO column? I recall there was issue with EMIF IP in the same column.
- Both the local_cal_fail signal and the local_cal_success signal may not assert high after EMIF calibration when both EMIF IP and an PHYLite IP with dynamic reconfiguration enabled are placed in the same I/O column.