EMIF Maximum Frequency Specification Update
Description This problem affects DDR2 and DDR3 products. DDR2 and DDR3 interfaces on Arria V GX/GT/SoC or Cyclone V and SoC devices may experience problems achieving timing closure at certain maximum frequencies. Resolution The workaround for this issue is to apply the appropriate solution for your configuration, as described below. (The stated performances apply to component topologies only; DDR2 DIMM configurations are not affected, and DDR3 DIMM configurations are not supported.) DDR2 SDRAM EMIF Maximum Frequency Specification Update for Arria V GX/GT/SoC or Cyclone V and SoC Devices For Arria V GX, -C5 speed grade device interfacing with a DDR2 SDRAM component with 2 chip selects using hard memory controller at 350 MHz: Upgrade the 400 MHz DDR2 SDRAM component to a 533 MHz DDR2 SDRAM component to achieve an interface frequency of 333 MHz. For Arria V GX, -C5 speed grade device interfacing with a DDR2 SDRAM component with 1 chip select using hard memory controller at 400 MHz: Upgrade the 400 MHz DDR2 SDRAM component to a 533 MHz DDR2 SDRAM component to achieve the specified maximum frequency. * If you experience timing failure with this configuration in version 13.0 SP1 DP5, file a service request to Altera. This specification is supported in version 13.1. For Arria V GX/GT, -I5 speed grade device interfacing with a DDR2 SDRAM component with 1 chip select using hard memory controller at 400 MHz: Upgrade the 400 MHz DDR2 SDRAM component to a 533 MHz DDR2 SDRAM component to achieve the specified maximum frequency. * If you experience timing failure with this configuration in version 13.0 SP1 DP5, file a service request to Altera. This specification is supported in version 13.1. DDR3/DDR3L SDRAM EMIF Maximum Frequency Specification Update for Arria V GX/GT/SoC or Cyclone V and SoC Devices For Cyclone V SoC (SE/SX), -A7 speed grade device interfacing with a DDR3 or DDR3L SDRAM component, with 1 chip select using HPS hard memory controller at 400 MHz: Upgrade the 533 MHz DDR3 SDRAM component to a 667 MHz DDR3 SDRAM component to achieve the specified maximum frequency. * If you experience timing failure with this configuration in version 13.0 SP1 DP5, file a service request to Altera. This specification is supported in version 13.1. For Cyclone V GX/E, -C6 speed grade device interfacing with a DDR3 or DDR3L SDRAM component, with 2 chip selects using hard memory controller at 400 MHz: Upgrade the 533 MHz DDR3 SDRAM component to a 667 MHz DDR3 SDRAM component to achieve the specified maximum frequency. For Cyclone V SoC (SE/SX/ST), -I7 speed grade device interfacing with a DDR3 or DDR3L SDRAM component, with 1 chip select using HPS hard memory controller at 400 MHz: Upgrade the 533 MHz DDR3 SDRAM component to a 667 MHz DDR3 SDRAM component to achieve the specified maximum frequency. For Arria V GX/GT, -I3 speed grade device interfacing with a DDR3 or DDR3L SDRAM component, with 1 chip select using hard memory controller at 533 MHz: Upgrade the 533 MHz DDR3 SDRAM component to a 667 MHz DDR3 SDRAM component to achieve the specified maximum frequency. For Arria V GX, -C4 speed grade device interfacing with a DDR3 or DDR3L SDRAM component, with 1 chip select using hard memory controller at 533 MHz: Upgrade the 533 MHz DDR3 SDRAM component to a 667 MHz DDR3 SDRAM component to achieve the specified maximum frequency. For Arria V GX, C5 speed grade device interfacing with a DDR3 or DDR3L SDRAM component, with 1 chip select using either soft or hard memory controllers at 533 MHz: Upgrade the 533 MHz DDR3 SDRAM component to a 667 MHz DDR3 SDRAM component to achieve the specified maximum frequency and avoid running memory interface at 425-449 MHz. For Arria V GX/GT, I5 speed grade device interfacing with a DDR3 or DDR3L SDRAM component, with 1 chip select using either soft or hard memory controllers at 533 MHz: Upgrade the 533 MHz DDR3 SDRAM component to a 667 MHz DDR3 SDRAM component to achieve the specified maximum frequency and avoid running memory interface at 420-449 MHz. This issue will not be fixed. The solutions for maximum frequency specifications have been updated in the External Memory Interface Spec Estimator.Is there an issue with the output clock frequency if you set the duty cycle values other than 50% in the PLL Intel® FPGA IP?
Description Yes, you may encounter an issue with the output clock frequency when setting duty cycle values other than 50% in the PLL Intel FPGA IP. This can occur when using the Quartus® II software version 13.0sp1 and earlier. The problem occurs if the C-Counter Hi Divide and C-Counter Low Divide parameters are calculated incorrectly by the PLL Intel FPGA IP. The Compilation report => Fitter => Resource Section => PLL Usage Summary will show the actual output clock frequency. If the reported output clock frequency is not correct, then the C-Counter Hi Divide or C-Counter Low Divide parameter is not correct. Resolution The C counters are used to divide the voltage-controlled oscillator (VCO) frequency to the desired output frequency. The sum of the C-Counter Hi Divide and C-Counter Low Divide parameters is the resulting divider value of the VCO frequency. For example, if the VCO is running at 840 MHz, and the desired output clock is 105 MHz, then a total divide value of 8 is required. For a 50% duty cycle, the high and low counts should be divided evenly between the C-Counter Hi Divide and C-Counter Low Divide parameters, in which the divide value for each parameter is 4. To create other duty cycle values, you can adjust the C-Counter Hi Divide and C-Counter Low Divide parameters as required. You need to ensure the sum of these parameters is equal to the total divide value in order to generate the desired output clock frequency. If the total divide value is an odd value, then you need to turn on the C-Counter Odd Divide Enable parameter if a 50% duty cycle is required. For example, if the VCO is running at 840 MHz and the desired output clock frequency is 120 MHz, then a total divide value of 7 is required. In this case the C-Counter Hi Divide parameter would be 4, the C-Counter Low Divide parameter would be 3, and set the C-Counter Odd Divide Enable parameter to True. If a duty cycle other than 50% is required, you will need to adjust the C-Counter Hi Divide parameter and C-Counter Low Divide parameter as required. You need to ensure the sum of these parameters is equal to the total divide value in order to generate the desired output clock frequency. To fix this problem in your design, open the <PLL instance name>_0002.v file and locate the C-Counter Hi Divide and C-Counter Low Divide parameters for the affected output clock(s). Adjust these parameters as required to create the correct output clock frequency and desired duty cycle. Referring to the examples above, if the VCO is running at 840 MHz and the desired output clock frequency is 105 MHz with a 12.5% duty cycle, the following parameters will be required: C-Counter Hi Divide = 1 C-Counter Low Divide = 7 C-Counter Odd Divide Enable = False Due to the problem in the PLL Intel FPGA IP calculation, set the following parameters for a 120 MHz output clock frequency: C-Counter Hi Divide = 1 C-Counter Low Divide = 6 C-Counter Odd Divide Enable = True To fix the parameters in this example, the C-Counter Low Divide parameter should be set to 7, and the C-Counter Odd Divide Enable parameter should be set to False in the <PLL instance name>_0002.v file.Error: Error during execution of "{C:/altera/12.1/quartus//../nios2eds/Nios II Command Shell.bat} make all 2>> stderr.txt": child process exited abnormally
Description You may experience the above error when generating a UniPHY-based memory controller. The error occurs because one of the system environment variables 'TEMP' points to a network drive and not a local drive. Resolution The workaround is to point the TEMP variable to the local machine, such as the C: drive. Also the variable HOMEDRIVE should point to the local machine.Infrequent Host Replay Timer Timeout for Stratix V Hard IP for PCI Express IP Core
Description Infrequent host replay timer timeouts can occur, because the Stratix V Hard IP for PCI Express IP Core infrequently skips transmitting ACK DLLP for a given received packet. This issue only occurs when the Stratix V Hard IP for PCI Express IP Core is receiving a discrete stream of packets with large time lags between packets. This issue does not occur when receiving a continuous stream of packets. This issue does not affect functionality because the replay timer mechanism ensures data retransmission.This issue does not affect throughput due its very infrequent occurrence. Resolution No workaround is available.What is the recommended termination guideline for mem_reset_n when using DDR3 SDRAM controller with UniPHY?
Description Altera® does not recommend terminating the mem_reset_n signal. DDR3 DIMMs typically do not use any termination on the memory reset signal. Refer to the memory vendor datasheet for any memory reset termination guidelines. Resolution Related Articles Can I use a USB Blaster download cable for AES key programming? Timing violation when enable 'Extra Timing Report Clock' in DDR3 UniPHY based controller Can I place bonded transceiver channels non-contiguously in Stratix® V and Arria® GZ transceiver devices?Why does my Avalon Memory Mapped bus hang when accessing the transceiver reconfiguration controller in Arria V, Cyclone V and Stratix V devices?
Description Avalon® Memory Mapped accesses to the transceiver reconfiguration controller in the Arria® V, Cyclone® V, and Stratix® V, devices will hang if the accesses are made to addresses outside of the specified address space of Table 16-8 of the Altera Transceiver Phy IP Core User Guide. http://www.altera.com/literature/ug/xcvr_user_guide.pdfWhy does the Transceiver Reconfiguration Controller's reconfig_busy output get stuck high after a reset?
Description The transceiver reconfiguration \'reconfig_busy\' output port may become stuck, asserted high after a reset assertion. The transceiver channels connected to the affected reconfiguration controller may also become stuck in reset. The \'reconfig_busy\' output port remains stuck even after resetting the reconfiguration controller; only reprogramming the device can resolve the issue. This symptom can be caused by the internal reset structure of the Transceiver Reconfiguration controller. An asynchronous reset assertion to the logic driving the address bus of an M20K RAM can cause asynchronous logic propagation. This can cause multiple address lines into the M20K to become asserted simultaneously, which can cause charge sharing between bit cells, corrupting the contents of the M20K. This corruption affects the Stratix® V and Arria® V GZ devices Transceiver Reconfiguration Controller because it contains a Nios® II processor that is used for PMA calibration, and the processor\'s program code is stored in M20K RAM. If the corruption occurs within the Nios® II program memory, this can cause the processor to lock up, resulting in the reconfig_busy output port becoming stuck asserted high. Recovery from this situation is only possible by reprogramming the device, as M20K contents are only loaded during device programming. Resolution The fix for this issue will change the internal reset controller and reset structure of the Transceiver Reconfiguration Controller to use synchronous resets, as well as pre-emptively deasserting the M20K clock_enable port during a reset condition. The fix will be available in a future version of the Quartus® II software. A patch can be provided for earlier versions of the Quartus II software by submitting a service request in mySupport. If a solution is required immediately, the fix can be manually applied using the following instructions. There are 9 files that need to be added or modified: altera_reset_controller_early_ce_mod.v (add) altera_reset_synchronizer_early_ce_mod.v (add) QIP file associated with the Transceiver Reconfiguration Controller (modify) alt_xcvr_reconfig.sv (modify) alt_xcvr_reconfig_soc.sv (modify) alt_xcvr_reconfig_cpu.v (modify) alt_xcvr_reconfig_cpu_ram.sv (modify) sv_xrbasic_lif_csr.sv (modify) sv_xcvr_reconfig_mif_avmm.sv (modify) These 9 files should be located in the directory where the Transceiver Reconfiguration Controller was generated. Download altera_reset_controller_early_ce_mod.v and place it in the directory where the Transceiver Reconfiguration files are kept: Download altera_reset_synchronizer_early_ce_mod.v and place it in the directory where the Transceiver Reconfiguration files are kept: In order to add these two files to your design, locate and modify the .qip file associated with the Transceiver Reconfiguration Controller instance and add the following two lines to the file: set_global_assignment -library "LIBRARY_NAME" -name VERILOG_FILE [file join $::quartus(qip_path) "LIBRARY_PATH/altera_reset_controller_early_ce_mod.v"] set_global_assignment -library "LIBRARY_NAME" -name VERILOG_FILE [file join $::quartus(qip_path) "LIBRARY_PATH/altera_reset_synchronizer_early_ce_mod.v"] In the above two lines, modify LIBRARY_NAME and LIBRARY_PATH to match the other entries in the Transceiver Reconfiguration Controller’s .qip file. For alt_xcvr_reconfig.sv, make the following modifications: Locate the alt_xcvr_resync module instantiation, and reverse the connections between the ‘d’ and ‘reset’ ports. Once modified, the instantiation should look like the following: alt_xcvr_resync #( .INIT_VALUE (1) ) inst_reconfig_reset_sync ( .clk (mgmt_clk_clk ), .d (mgmt_rst_reset ), .reset (1\'b0 ), .q (r_mgmt_rst_reset ) ); For alt_xcvr_reconfig_soc.sv, make the following modifications: Add the following wire definition near the top of the module: wire cpu_reset_req; Locate the instantiation of the alt_xcvr_reconfig_cpu module and add the following port: .ram_ce (cpu_reset_req), Locate the instantiation of the alt_xcvr_reconfig_cpu_ram module and add the following port: .ram_ce (cpu_reset_req), For alt_xcvr_reconfig_cpu.v, make the following modifications: Add the following port to the top level: output wire ram_ce, Add the following code to the module: wire m20k_gate; wire altera_ram_clock_enable; assign altera_ram_clock_enable = ~ m20k_gate; assign ram_ce = altera_ram_clock_enable; Find the instantiation of altera_reset_controller and change this to an instantiation of altera_reset_controller_early_ce_mod. Add the m20k_gate port to this instantiation, and connect it to the m20k_gate signal. After making these modifications, the instantiation should look like the following: altera_reset_controller_early_ce_mod #( .NUM_RESET_INPUTS (1), .OUTPUT_RESET_SYNC_EDGES ("deassert"), .SYNC_DEPTH (2) ) rst_controller ( .reset_in0 (~reset_reset_n), // reset_in0.reset .clk (clk_clk), // clk.clk .reset_out (reconfig_ctrl_reset_reset), // reset_out.reset .m20k_gate (m20k_gate), .reset_in1 (1\'b0), // (terminated) .reset_in2 (1\'b0), // (terminated) .reset_in3 (1\'b0), // (terminated) .reset_in4 (1\'b0), // (terminated) .reset_in5 (1\'b0), // (terminated) .reset_in6 (1\'b0), // (terminated) .reset_in7 (1\'b0), // (terminated) .reset_in8 (1\'b0), // (terminated) .reset_in9 (1\'b0), // (terminated) .reset_in10 (1\'b0), // (terminated) .reset_in11 (1\'b0), // (terminated) .reset_in12 (1\'b0), // (terminated) .reset_in13 (1\'b0), // (terminated) .reset_in14 (1\'b0), // (terminated) .reset_in15 (1\'b0) // (terminated) ); For the alt_xcvr_reconfig_cpu_ram.sv file, make the following modifications: Add the following input port: input ram_ce, Find the altsyncram instantiation and modify the clocken0 port to connect it to the new ram_ce input port: .clocken0 (ram_ce), Modify the defparam clock_enable_input/output_a/b definitions as follows: altsyncram_component.clock_enable_input_a = "NORMAL", altsyncram_component.clock_enable_input_b = "NORMAL", altsyncram_component.clock_enable_output_a = "NORMAL", altsyncram_component.clock_enable_output_b = "NORMAL", For the sv_xrbasic_lif_csr.sv file, make the following modifications: Locate the sequential always block that controls the logical channel address. This always block can be identified by the comment “// logical channel register” above it. Remove the reset condition from the sensitivity list. Once modified, the start of the always block should look like the following: // logical channel register always @(posedge reconfig_clk) begin if (reset == 1) begin … Locate the sequential always block that controls the native reconfig address register. This always block can be identified by the comment “// native reconfig address register, can be interpretted as channel offset address, or physical address” above it. Remove the reset condition from the sensitivity list. Once modified, the start of the always block should look like the following: // native reconfig address register, can be interpretted as channel offset address, or physical address always @(posedge reconfig_clk ) begin if (reset == 1) begin … For the sv_xcvr_reconfig_mif_avmm.sv file, this change is only necessary if channel or PLL reconfiguration is enabled in the Transceiver Reconfiguration Controller Megawizard GUI. Make the following modification: Locate the sequential always block that has the “// Avalon output and internal storage” comment above it and remove the reset condition from the sensitivity list. Once modified, the start of the always block should look like the following: // Avalon output and internal storage always @(posedge clk ) begin if (reset) begin … Once all these changes have been made, your design will need to be recompiled. Related Articles Why does the Qsys on-chip memory (RAM or ROM) content get corrupted after asynchronous reset?Error (10232): Verilog HDL error at bitec_dp_rx_ss_audio.v(420): index 64 cannot fall outside the declared range [63:0] for vector "fifo_data_x2chan_mux"
Description Due to a problem in the Quartus® II software version 14.0, you may see this error when compiling a design that contains the DisplayPort IP that has more that 2 Audio receive channels enabled. Resolution To work around this problem in the Quartus® II software version 14.0, replace the existing file <IP variation name>/bitec_dp/rx/ss/bitec_dp_rx_ss_audio.v with the attached version of this file. bitec_dp_rx_ss_audio.v This problem has been fixed starting in the v14.1 release of the Quartus® II software.How do I determine the phase shift and duty cycle for the required clocks if I am using ALTLVDS_RX and ALTLVDS_TX in external PLL mode?
Description You can determine the phase shift and duty cycle for the required clocks when using ALTLVDS_RX and ALTLVDS_TX in external PLL mode by first compiling an example design with ALTLVDS_RX or ALTLVDS_TX using an internal PLL. Use the settings that the Quartus® II software uses to configure the internal PLL in the example design as the settings you enter in the external PLL. To check the PLL settings in the Fitter report, expand the Resource section, and then expand PLL Usage. The report shows the duty cycle, phase shift and clock frequency for each of the required clocks for the ALTLVDS_RX and ALTLVDS_TX interfaces. You can then use these parameters for the external PLL settings in your design. Related Articles How do I implement ALTLVDS in External PLL Mode for Stratix V, Arria V, and Cyclone V devices? How do I implement the ALTLVDS_RX and ALTLVDS_TX megafunctions with External PLL mode in Arria II GX devices? How do you implement the altlvds megafunction with the External PLL option in Stratix III devices?How should the data in the RPD file be set up for programming quad-serial (EPCQ) devices that are 256Mb or larger?
Description When programming EPCQ devices that are 256Mb or larger with an RPD file in Active Serial (AS) mode, you need to set it in 4-byte addressing mode before programing, otherwise it will cause a configuration failure. Resolution To set the EPCQ device in 4-byte addressing mode, refer to 4BYTEADDREN operations in Quad-Serial Configuration (EPCQ) Devices Datasheet (PDF).