JC_FPGA
New ContributorJoined 7 years ago
User Profile
New Contributor
User Widgets
Contributions
Cyclone V transceiver status rx_disperr and rx_errdetect inactive, even when unplugging SMA cable
I'm working on a Cyclone V design that has several transceivers. I've added error counters for the rx_disperr and rx_errdetect status ports. They run on the rrefclk clock domain coming out of the transceiver. I'm unable to ever see these error outputs set to logic one. There's no activity on these ports when disconnecting and reconnecting the SMA cable. The general status outputs appear to be working fine and the link comes up each time I plug the cable back in. I'm using the altera_xcvr_custom_phy IP v19.1 with Quartus v20.1.1 Build 720. Are these status outputs operational for Cyclone V? I'm very surprised that wiggling a loose SMA connector won't cause errors. How can I force an error to prove that my error counters are operational?1KViews0likes2CommentsRe: AXI - Avalon Error in Qsys/Platform Designer
I'm working on a legacy design and just came across this exact error. I'm trying to bring the design into Quartus 20.1. This thread is approaching 900 views, so we can't be the only ones that have run into this problem. Hopefully the support team has some suggestions to try.2KViews0likes1Comment- 2.6KViews0likes0Comments
Re: vhdl 2008: read output / unary operator
I've also encountered this lack of support for VHDL-2008. I often get my code simulating properly in Questa only to find that a VHDL code construct I used isn't supported by Quartus. OSVVM and UVVM are getting more traction. Intel should really focus on supporting more the features of VHDL-2008. Following this thread in case you get a solution...2.6KViews0likes0CommentsRe: FIR II Coefficient Read from Cyclone V HPS Freezing.
The filter itself uses an active low reset and the coefficient reload interface uses an asynchronous active high reset. Don't ask me why. In practice, the coeff_in_areset doesn't appear to do anything (at least in my configuration). Writing a new coefficient appears to take effect immediately. Using a 16-bit or less coefficient width will configure the FIR for a 16-bit coefficient data port. Using a 17-bit or larger coefficient width will configure the FIR for a 32-bit coefficient data port. The two pictures from SignalTap appear to show identical operation for the two different coefficient addresses. Can you point out the difference? Make sure your HPS addressing is being handled properly. You need to read coefficient addresses 0, 1, 2, 3, 4, 5, etc. Don't jump by 4 when using a 32-bit HPS bus. Be aware that you only need to write and read-back half of the coefficients for a symmetrical FIR filter. If you have an odd number of coefficients, write and read one additional address. For example, if you have 41 coefficients, you'll need to write to the first 21 addresses in the FIR filter to reprogram them all. What clock do you have connected to the coeff_in_clk port?4.2KViews0likes0CommentsRe: FIR II Coefficient Read from Cyclone V HPS Freezing.
There's a long standing bug in the FIR filter read-back code. The read signal is messed up. I've attached a python script that will fix the code. You have to re-run the script each time the FIR is regenerated by Quartus. You can place the following in a batch file or shell script to make life easier. python3 fir_filter_read_coeff_fix.py YOUR_PROJECT_DIR/interpolator/interpolator_0002.vhd python3 fir_filter_read_coeff_fix.py YOUR_PROJECT_DIR/interpolator_sim/interpolator.vhd Replace YOUR_PROJECT_DIR with your required path and replace "interpolator" with whatever you named your filter. The main thing is that you have to fix both the implementation and the simulation versions of the filter. Python script: ################################################################################ # # Python3 script to fix bug in Intel/Altera FIR generator code # # Created: 2018-08-16 # Author: Jim Cox ################################################################################ # This script is meant to be used as a post-processing step after creating a # FIR filter using the Quartus tools. The read signal for the coefficients # is not connected properly to the lower level module. import re import sys if (len(sys.argv) != 2): sys.exit("\nUsage: fir_filter_read_coeff_fix.py my_file.vhd\n") ### Lines to delete ### ### signal coeff_in_read_sig : std_logic; ### ### coeff_in_read_sig <= not(coeff_in_we(0)); ### ### Line to modify ### ### busIn_read => coeff_in_read_sig, ################################################################# # Input file my_file = open(sys.argv[1], "rt+") my_file_list = my_file.readlines() # Move back to the begining of the file my_file.seek(0) for line_of_code in my_file_list: if (re.search('^\W+signal coeff_in_read_sig : std_logic;', line_of_code)): continue if (re.search('^\W+coeff_in_read_sig <= not\(coeff_in_we\(0\)\);', line_of_code)): continue if (re.search('^\W+busIn_read => coeff_in_read_sig,', line_of_code)): print(" busIn_read => coeff_in_read,", file=my_file) print("File has been updated\n") continue print(line_of_code, end='', file=my_file) my_file.truncate() my_file.close()4.2KViews0likes0CommentsQuartus v18.1 Failed to launch MegaWizard Plug-In Manager: ROM: 2-PORT
I cannot update an existing 2-Port ROM nor can I create a new one. This issue sounds like it could be related to the .lst (list) problem where some names are "Altera" instead of "Intel FPGA." Similar to this thread: https://forums.intel.com/s/question/0D50P00003yyTl2SAE/quartus-18-megawizard-issue?language=en_US However, I haven't been able to find a .lst file that references the ROM IP. Strangely, I am able to create a 1-Port ROM. It's just the 2-Port ROM that does not work. I'm using Quartus v18.1.0 on 64-bit Windows.3KViews0likes1CommentRe: JESD204B - which modules can be reused from the example design for a single transceiver configuration?
I was able to create a single transceiver test case using most of the components from the canned example design. Unneeded portions of the control_unit state machine were commented out (I did not need the SPI operations). Obviously, the JESD204B core itself had to be regenerated with my custom parameters. A key piece that does not get updated with the required parameters is the core_pll module. The following link provides a couple of important formulas to determine the proper core_pll settings: https://www.intel.com/content/www/us/en/programmable/documentation/bhc1447658054961.html#bhc1447657983877 It's disappointing that this key part of the JESD204B design is not handled by the IP generator. The PLL settings and the JESD204B IP are absolutely tied together based on the chosen parameters. You may still see rx_is_lockedtodata, dev_lane_aligned and the rising edge of sync even when the core_pll is configured improperly. Improper core_pll settings are what caused me to see repeated groups of bytes on the RX side.886Views0likes0Comments