is there a way to implement a UniPHY DDR2 SDRAM controller leaving RUP and RDN pins unconnected i.e. without OCT?
I think it is possible, you must precise in the Pin Planner tool. In the section "Output/input Termination", you just have to put without calibrationCheck if you can fit your design with these parameters
Nope. It doesn't. I set Output Termination to "series 50 Ohm (without calibration)" and disabled Input Termination "parallel 50 Ohm", but fitter stops reporting several errors of type:- I/O "<name>" has a termination control block assignment, but does not use calibrated on-chip termination - Output buffer atom "<name>" has port "<name>" connected, but does not use calibrated on-chip termination. While if I leave the input/output termination with calibration enabled, compilation successfully completes (with critical warnings regarding unconnected RUP and RDN), but with a quick test with signalTap on the automatically generated example project it shows afi_cal_fail asserted.
Did you ever find a resolution to this issue? I'm having a similar problem. If I connect rup/rdn to some external pins, Quartus 10.1 errors out because it says there's already a calibration block connected. If I leave them unconnected, I get the error mentioned in the first post. I can't use the name that Quartus creates automatically for the rup/rdn pins because of the silly tilde in the name, so I have created my own pin names and assigned them to the rup/rdn pin locations manually.
This is also driving me crazy. I have a DDR3 core and a QDR core, both using UNIPHY, and created inside SOPC. Both cores bring out the rup,rdn pins in the VHDL ports of the Nios core,but when I wire them up to the real pins I get the errors stating the pins are already busy. I also see auto generated rup and rdn pins in the log files for these cores. Which one is it Quartus?? I "Think" what is going on is that I have constraints that set the pins to 50 Ohm termination. I'm testing a theory that this causes Quartus to generate the OCT hardware automagically which then interferes with the manually instantiated cores in SOPC. I commented out the 50 Ohm settings in my constraints and am trying again. Is this documented somewhere? OCT - auto vs manual instantiation?
Part one of my theory looks to be confirmed (see below). What to do if a core brings out the pins in VHDL or Verilog?From http://www.altera.com/support/devices/io/features/io-features.html#onchiptermination On-Chip Termination When to Use An OCT output pin provides on-chip impedance matching capability to a 25-ohm or 50-ohm trace to reduce reflections-induced noise on the signal. Use OCT with calibration in Cyclone III FPGAs for higher calibration accuracy to account for temperature and voltage condition variations. How to Use In the Assignment Editor, from I/O standard assignments, select from a list of available OCT I/O standards. Valid choices are 25-ohm or 50-ohm termination type, at various VCCIO levels, and with a calibration option. When using series OCT with calibration on a pin, the RUP pin and RDN pin in the same side bank where the target pin resides must be connected to an external resistor, and each tied to VCCIO and GND, respectively. Use a 25-ohm resistor for 25-ohm termination type, and a 50-ohm resistor for 50-ohm termination type. When using series OCT without calibration, an external resistor to the RUP and RDN pins is not required. In that case, the RUP and RDN pins can be used as regular I/O.
Results from stripping out all mention of "50 Ohm" in my constraints:Same failure as Antti - Error: Output buffer atom "mts_core_nios:mts_core_nios_1|uniphy_qdrii_0:the_uniphy_qdrii_0|uniphy_qdrii_0_controller_phy:controller_phy_inst|uniphy_qdrii_0_memphy_top:memphy_top_inst|uniphy_qdrii_0_memphy:umemphy|uniphy_qdrii_0_io_pads:uio_pads|uniphy_qdrii_0_write_pads:uwrite_pads|uniphy_qdrii_0_write_d_iobuf:uwrite_d_iobuf|obufa_0" has port "SERIESTERMINATIONCONTROL" connected, but does not use calibrated on-chip termination File: C:/firmware/projects/Proj_137_UC_S2_Extremecard_Stratix/trunk/mts_core_testing_q10/uniphy_qdrii_0_write_d_iobuf.v Line: 74
I'm currently wading through this doc:http://www.altera.com/literature/ug/ug_altoct.pdf Looks like one might have to instantiate the control block, then set up a constraint to tell the tools to use that instantiated block.. UPDATE: I managed to complete a compilation. I still need to test it but it got passed the OCT errors. What I found - reading the uniphy docs for both ddr3 and qdr found here: hhttp://www.altera.com/literature/lit-external-memory-interface.jsp?GSA_pos=6&WT.oss_r=1&WT.oss=uniph... The SOPC builder generated a tcl file per core: uniphy_ddr3_0_pin_assignments.tcl uniphy_qdrii_0_pin_assignments.tcl and some readme.txt files. What I had to do was run "Analysis ans Synthesis" first, then source these two files in the Quartus tcl console, then finish the compilation. It sets up the constraints properly for the SOPC versions of these cores. Since I prefer command line scripting (for version control and repeatability) I exported a tcl script from the quartus gui using the Project->generate tcl file for project menu item to use in my batch system. I let both of these cores be "master" OCT so that each core has the OCT embedded in it. I manually instantiated the rup and rdn pins and connected them to the rup and rdn pins that the nios core vhdl file brings out. On to testing.
Thanks for all the hints. Had the same problem with OCT.Erasing the .qsc entries which I made manually using the Assignment Editor and rerunning the whole compilation did the job. Obviously the UniPhy IP core generates the OCT settings itself an thereby a concurring ressource utilization was created. br