Hello, I am encountering an error within generated IP and I'm hoping for some help.
Quartus Pro 21.2 and 17.1
Cyclone 10 gx development board
The overall problem I am trying to solve is calibration of the DDR3 on the Cyclone 10gx board.
The example project provided with the board does calibrate the DDR3 when used in conjunction with Pro 17.1. With some effort it can be upgraded to 21.2 and it still works.
I then attempted to replicate the EMIF controller from scratch (fresh project, same board). The parameters match the example project. All I was attempting to do was calibrate the DDR3. Calibration failed.
The following warning is present for all bidirectional pins to the memory; address, data mask, data etc.
Warning(12620): Input port OE of I/O output buffer "cyc10_mem_interface|emif_c10_0|emif_c10_0|arch|arch_inst|bufs_inst|gen_mem_dm.inst.b|cal_oct.obuf" is not connected, but the atom is driving a bi-directional pin
However these warnings are not present in the example project.
The IP DDR3 controller parameters are exactly the same in platform designer. Pinouts are the same. Board is the same. Quartus version is the same. IP version is the same.
The following KDB article seems to cover it. But the solution (added code, synthesis keep ) is not present in the example project. Furthermore it is very old (2014). I think it should be fixed by now.
If I need to implement this solution. How do I go about it within the IP generated code for the DDR3 controller?
Also, why would I need to do it, if it is not present in the example project (which Is working fine)?
I am very interested in any insight anyone may have into this.
Did you run the pin_assignments.tcl script (I think that's what it's called) generated by the IP to configure the I/O? The example project may have this already done for you, but if you create the IP manually, you have to run a script.
Thanks, sstrell, I had forgotten about those .tcl scripts. I remember having to use them in Quartus Standard, but it also put up a message reminding you to do it. Quartus Pro did not, I guess I just thought it was doing it automatically now.
I ran ...._parameters.tcl without any errors.
But ...._ip_parameters.tcl gives me an error. ( I think this is the one I need, it has a lot of commands that deal with the cal_oct.obuf)
"ERROR: Unable to find active revision name. Make sure there is an open, active revision name."
If I look under Project/Revisions I clearly have an active revision, just one, and there is a green checkmark next to it.
Any idea why this could be happening?
I'm Adzim. Thanks for using Intel Community.
Based on your description above, I think that you have performed the IP Upgrade in Quartus 21.2 for the example project.
And the project is working fine.
Then you create new EMIF IP for your project in Quartus 21.2 but then it's failed.
The calibration failure may be caused between the memory and the PHY.
It's also can be caused by the board but your board is working fine with the example project.
Can you check the memory connection by comparing with the example project?
Do the reset is asserted during the calibration process?
Sometimes the reset may interrupt the calibration process.
Can you check your reset signal as well?
Thanks, Adzim_Intel, but I am not sure what you are asking me.
When you ask about comparing with the example project; I have recreated all the parameters and settings of the example project exactly as far as I can tell. The example project calibrates, my re-creation does not.
The reset signal is tied to a push button on the board. It does not occur during calibration only when I press the button.
Sorry, I completely missed that this was Pro and Cyclone 10 GX. You don't have to run that script for this device.
Did you match the pin locations between the example project and your manually created IP design?
When I checked your pin assignment, I see that you're not used the differential signal for clock.
I think that the clock should has ck and ck_n by referring to the example design.
Can you check about this as well?
And also there is no pll pin in the pin assignment.
How do you connect your pll in the design?
Hi Thank you for taking a look at the project.
If you look in the pin planner you should see that input pin 'clock' is an LVDS signal connected to pins AA18 and AA19. The PLL is connected internally and 'clock' is the pll_reference signal. These are the same pins as the example project signal 'refclk_emif'. The 'clock' is connected to the 'emif_c10_0_pll_ref_clk_clk' signal of the DDR3 controller. This is the same way it is done in the example project.
As confirmation, the signal tap shows that 'pll_locked' does go high.
The calibration report should have been in the archived project. This forum will not allow me to upload .rpt files. I am uploading it as a .txt file, so hopefully it will work for you if you edit it back to .rpt.
Sorry for the delay. I'm OOO since on Thursday last week.
Thanks for sharing the calibration report.
Looks like the calibration is failed at the beginning.
I can see the pin locations after the compiling the design.
I thought you already fit all the pins in your design. That's why I'm wondering.
But you have used the pin locations from the example design right?
Is there any floating pins in you design?
Can you use the Full Calibration mode?
I'm not sure is this can bring any changes.
Yes, Calibration is failing immediately.
I used the exact same pin locations copied from the example design .qsf file. Only names have changed to match my naming conventions.
They have all been through the fitter.
I'm not sure what you are asking about regarding fitting the pins in the design.
No floating pins, definitely no floating pins connected to the memory.
Full Calibration mode refers to simulation only. It will have no effect on the synthesis calibration.
Note, this is also how the example design is configured. Which gets back to my original question, if I created my design and copied all the settings and pinouts exactly from the example design (which I believe I have done correctly), then why does my new controller design fail calibration.
I should not need to deviate from the example design at all.
Of course I may have made a mistake in copying the settings, but I have not yet found one.
The problem has been solved. The Data Mask pins were incorrectly identified as type 'inout' in my top level in stead of type 'out'.
This caused the Warning 12620, and the subsequent calibration failure.
My custom project now calibrates properly with the example project pinouts and parameter settings.