Why do I get a Fatal Error in Assembler when having ALTLVDS TX with a design?
Description You may see this error in the Quartus® Prime Software Standard version 17.0 or earlier. This error is due to either LVDS data output port “tx_out[*]” or external clock port “tx_outclock” of ALTLVDS TX IP is not assigned to LVDS I/O standard. Resolution To work around this problem, you should assign both the data output port and external clock output to the LVDS I/O standard.Is there a known issue with the Triple Speed Ethernet (TSE) LVDS Receive (Rx) and Transmit (Tx) general purpose PLLs merging in Quartus II software version 10.1?
Description Yes, the Triple Speed Ethernet IP has enhanced the LVDS Rx PLL reset sequence in Quartus® II software version 10.1. The LVDS Rx PLL now has pll_areset controlled via the tse_lvds_reset_sequencer, whilst the Tx PLL has its pll_areset tied inactive. As the input sources to the two PLLs are now different, Quartus II is no longer able to merge the two PLLs. This issue will be address in a future version of the IP.Is the hard transceiver 8B/10B encoder/decoder in Stratix, Arria, and Cyclone family transceiver devices Fibre Channel compliant?
Description No, the 8B/10B encoder/decoder does not satisfy all the requirements for the Fibre Channel protocol in Stratix® GX, Stratix II GX, Stratix IV GX/T, Arria® GX, Arria II GX, or Cyclone® IV GX devices. 1) Fibre Channel protocol requirements for 1.062 and 2.125 Gbps states that the transmitter needs to start up with negative running disparity. Further, the standard has disparity rules for Ordered Sets. -The embedded 8B/10B encoder does start up with negative disparity. However, the encoder does not contain the functionality to force negative current running disparity at any time. This is required to be able to meet the disparity rules for Ordered Sets. 2) Fibre Channel protocol requirements for "Detection of Invalid transmission Word" for 1.062 and 2.125 Gbps state that Ordered Sets received with incorrect beginning running disparity be flagged as an error. -The current 8B/10B implementation determines running disparity on a character-by-character basis and not Ordered Sets. Due to these non-compliances, customers may or may not be able to use the embedded 8B/10B encoder/decoder in the transceiver megafunction. This decision would have to be based on how the customer is implementing their Fibre Channel or Fibre Channel-like architecture. Possible workarounds: User would have to implement 8B/10B encoding and decoding blocks in the PLD core to be able to meet the specific requirements in both the transmit and receive directions. User could use 8B10B Encoder/Decoder MegaCore Function from Altera Corporation User could use Multi-Gigabit Fibre Channel Transport Core from MorethanIP References: Fibre Channel, Physical Signaling Interface (FC-PH) REV 2.13 December 4, 1991 Fibre Channel Framing and Signaling (FC-FS) REV 1.90Is it possible to retain data in a memory device during the UniPHY calibration process?
Description No, it is not recommended to rely on data being preserved in memory during UniPHY calibration as no refresh commands are issued to the external memory devices during calibration. Only the locations with calibration data patterns get refreshed by accesses to these locations. If you need to find out the actual address locations used in the UniPHY calibration, the recommended approach is to simulate the UniPHY IP example design for your memory IP configuration with the full calibration option. For further details refer to the External Memory Interface handbook, Chapters : Implementing and Parameterizing Memory IP (PDF) Simulating Memory IP (PDF) Functional Description - UniPHY (PDF)Are there any issues with the UniPHY IP Global Signal assignments seen in the Quartus II software Assignments editor after running the <variation_name>_pin_assignments.tcl script?
Description These assignments which are applied to UniPHY based IP's reset and clock signals are correct and no changes are required by the user. The assignments are shown with Status “?”. This is due to a display issue in Assignments editor and is planned to be fixed in a future version of the Quartus® II software.Why cant I use a transceiver recovered clock to feed a transmitter PLL reference clock on Altera transceiver devices?
Description The Quartus® II Software will deliberately prevent you from connecting a recovered clock from a receiver to the reference clock input of a transmitter PLL. The recovered clock is extracted from the clock embedded in the received datastream. As the datastream has propagated across a channel, the recovered clock will have undefined jitter characteristics which if fed into the reference clock of a transmitter PLL, may cause the transmit jitter to exceed a given protocols' transmit jitter specification. The recommended method of implementing a recovered clock synchronous architecture is to route the recovered clock outside of the FPGA, and to pass the clock through a jitter cleaner before routing back onto the FPGA through one of the dedicated transceiver reference clock pins.Why assertion of reset may cause low probablity lock up of UniPHY NIOS sequencer resulting in incomplete calibration
Description UniPHY IP does not complete calibration after asserting and deasserting global_reset_n or soft_reset_n signal low for UniPHY IP. EMIF debug toolkit cannot be connected to that interface (link project to device). This condition does not change even if multiple resets are issued later. This condition can be recovered only by reconfiguring the device. These symptoms can be caused by the internal reset structure of the EMIF UniPHY IP. An asynchronous reset assertion to the logic driving the address bus of an M20K RAM can cause asynchronous logic propagation. This can impact functionality of M20K address row/column decoders, opening more than one word line which can result in charge sharing between bit cells, corrupting the contents of the M20K. Note that the probability of M20K corruption due to asynchronous reset assertion is very low. PLL reset during M20k read or write operation can also contribute to embedded RAM/ROM corruption because PLL lock loss may result in a clock glitch during reset and this may impact the functionality of M20K address row/column decoders. This corruption affects the UniPHY IP because it contains a Nios (R) II processor that is used for calibration, and the processor's program code is stored in M20K RAM. If the corruption occurs within the Nios (R) II program memory, this can cause the Nios (R) II sequencer to lock up, resulting in incomplete calibration. Recovery from this situation is only possible by reprogramming the device, as M20K contents are only loaded during device programming. It is important to note that common EMIF failures listed below does not necessarily mean the M20K RAM is corrupted or Nios (R) II sequencer is locked up - If calibration never passes (i.e. calibration always fails). - If calibration margins are very slim, and occasionally fail calibration. - If design passed calibration, and occasional data errors are observed while running the design. - If design says it passed calibration, but design is not working as expected. Resolution UniPHY IP core has two reset inputs Global_reset_n: is connected to everything in UniPHY IP including PLL. Soft_reset_n: is connected to everything in UniPHY IP except PLL. 1. Altera strongly recommends using only soft_reset_n at all times. Use global_reset_n only for Power on reset. To reset PLL during Power on, Use the following sequence a. Assert Global_reset_n (PLL reset ) b. Power up and reconfigure the chip c. De-assert Global_reset_n 2. The fix changes the internal reset controller and reset structure of the UNIPHY IP core to use synchronous resets, as well as pre-emptively deasserting the M20K clock_enable port during a reset condition. This prevents any metastable transitions from propagating into the M20K address decoder. This fix will be provided as part of 13.0dp1, 13.0sp1, and all subsequent versions of Quartus. Users will need to regenerate the UnipHY IP and recompile the design. Altera recommends moving to one of these versions of Quartus. If a fix is required more urgently, or a fix is required for Quartus version 12.1sp1, the UniPHY IP core can be manually updated. The following procedure must be followed: Locate the source files for the Altera UniPHY IP within your design. There are 5 files that need to be modified. altera_reset_synchronizer.v altera_reset_controller.v altera_mem_if_sequencer_mem_no_ifdef_params.sv <interface_name>_if0_p0_reset.v <interface_name>_if0_s0.v Steps 1. Download altera-reset-synchronizer.v from the following link and place in the same directory as the UniPHY IP source files: Altera_reset_synchronizer.v 2. Download altera-reset-controller.v from the following link and place in the same directory as the UniPHY IP source files: Altera_reset_controller.v 3. In altera_mem_if_sequencer_mem_no_ifdef_params.sv’ – Ensure that the input ‘s1_clken’ connects to the ‘clocken0’ input of the ‘the_altsyncram’ 4. In instance<interface_name>_if0_p0_reset.v – modify the defparam statements for the “dut_if0_p0_reset_sync” instances so that the parameters “RESET_SYNC_STAGES” and “NUM_RESET_OUTPUT” are set according to the attached sample file (dut_if0_p0_reset.v). (Do not download the sample file in the UniPHY IP source file directory) dut-if0-p0-reset.v (sample file for <interface_name_if0_p0_reset.v) 5. In <interface_name>_if0_s0.v (Do not download the sample file dut_if0_s0.v in the UniPHY IP source file directory) dut-if0-s0.v (sample file for <interface_name>_if0_s0.v ) – Add the following port to the top level: wire early_rst_controller_reset_out_reset; - Wire the output port “m20k_gate” on the “rst_controller” module to the ‘s1_clken’ input of ‘sequencer_mem’ module. Since the M20k_gate output is active-low, you need to invert the output as follows: .s1_clken (~early_rst_controller_reset_out_reset), // on sequencer_mem, line 785 of the attached sample file (dut_if0_s0.v) .m20k_gate (early_rst_controller_reset_out_reset), // on rst_controller, line 2572 of the attached sample file 6. Once these changes have been made, your design will need to be recompiled. Related Articles How do I address known software issues for Stratix V, Arria V and Cyclone V devices in the Quartus II software version 13.0? Why does the Qsys on-chip memory (RAM or ROM) content get corrupted after asynchronous reset?Why does my ARRIA II GX Nios II design fail to boot up in V13.1 and V14.0
Description Due to a problem in the Quartus® II software versions 13.1 and 14.0, Nios® II designs targeting ARRIA II GX devices using the EPCS IP may not boot correctly. Resolution To work around this problem follow the steps below: Open /ip/altera/sopc_builder_ip/altera_avalon_epcs_flash_controller/em_epcs_qsys.pm file in a text editor Add the ARRIAIIGX device into the condition check logic at line 704 Before: ( eq "CYCLONEIVE")) After: ( eq "CYCLONEIVE") || ( eq "ARRIAIIGX")) This problem is scheduled to be fixed in the next release of the Quartus II software.ModelSim-Altera Simulation of IP Compiler for PCI Express is Slow
Description Simulation that uses the PCI Express BFM, or simulation of an IP Compiler for PCI Express variation that targets a Stratix IV GX or Arria II GX device, is slow in the ModelSim-Altera simulator. This issue affects simulation of all IP Compiler for PCI Express variations when the simulator runs the PCI Express BFM, and simulations of variations that target a Stratix IV GX device that do not run the BFM. Resolution This issue has no workaround. You can use a different simulator to simulate your design. This issue will be fixed in a future version of the IP Compiler for PCI Express.