bob_bitchen
Occasional ContributorJoined 4 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: Cyclone IV GX project failed migration from 20.1 to 23.1std
The tcl script is renaming a file that it has open. You have to fix their tcl by #file rename -force $temp $filename file copy -force $temp $filename file delete -force $temp Then it works. It appears that no one is using these tools, because no one fixes a simple bug like this that has been around for years.2Views0likes0CommentsRe: There are no hw_builtin.iipx, sw_builtin.iipx and package_builtin.iipx in sopc_builder folder
Canned demo straight out-of-the box, and it does this? Nobody responds. Some helpful user figures this out 6 months later. Does anyone use this product? Does anyone read this stuff?836Views0likes0Commentsnios-bsp fails with commands from readme file
I installed 23.1 in windows and linux. I found a minimal max 10 demo for nios V/c The instructions to make the design don't work. - Invoke the quartus_py shell in the terminal - Run the following command in the terminal from top level project directory: > quartus_py scripts/build_sof.py ^ Those instructions make no sense and have no context. ^ [niosv-shell] D:\altera\kits\Max10_Nios_v> quartus_py scripts/build_sof.py sys Traceback (most recent call last): File "scripts/build_sof.py", line 66, in <module> generate_qsys = subprocess.Popen(["qsys-script","--script={}".format(qsys_tcl_dir),"--quartus-project={}".format(qpf_dir)], stdout=subprocess.PIPE, stderr=subprocess.STDOUT,cwd=cwd_1) File "d:\altera\23.1std\quartus\common\python\lib\subprocess.py", line 858, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "d:\altera\23.1std\quartus\common\python\lib\subprocess.py", line 1327, in _execute_child hp, ht, pid, tid = _winapi.CreateProcess(executable, args, FileNotFoundError: [WinError 2] The system cannot find the file specified That's OK! I did the usual qsys and qpf with the gui and it still works thankfully. From the readme file: c. Creating the bsp, build software sources and download elf - To create software app with HAL OS, run the following commands in the terminal: > niosv-bsp -c --quartus-project=hw/<>.qpf --qsys=hw/<>.qsys --type=hal sw/bsp_hal/settings.bsp [niosv-shell] D:\altera\kits\Max10_Nios_v> niosv-bsp -c --quartus-project=hw/top.qpf --qsys=hw/sys.qsys --type=hal sw/bsp_hal/settings.bsp 2024.04.03.15:04:27 Error: Unrecognized switch <b>quartus-project</b> 2024.04.03.15:04:27 Error: Unrecognized switch <b>qsys</b> 2024.04.03.15:04:27 Error: Failed to validate switches. --help Example Commands ---------------- Creating a BSP * niosv-bsp -c -t=hal -p=top.qpf -r=top -s=sys.qsys bsp/settings.bsp Updating a BSP * niosv-bsp -u -e="set_setting hal.make.cflags_optimization -O3" bsp/settings.bsp Generating files in the "bsp" folder for an existing BSP settings file * niosv-bsp -g -b=bsp settings.bsp Exporting a BSP as a TCL script * niosv-bsp -q -E=bsp.tcl bsp/settings.bsp Re-creating a BSP with a TCL script * niosv-bsp -c -t=hal -p=top.qpf -r=top -s=sys.qsys -x=bsp.tcl bsp/settings.bsp [niosv-shell] D:\altera\kits\Max10_Nios_v> niosv-bsp -c -t=hal -p=top.qpf -r=top -s=sys.qsys bsp/settings.bsp 2024.04.03.14:42:10 Error: Unrecognized switch <b>p</b> 2024.04.03.14:42:10 Error: Unrecognized switch <b>r</b> 2024.04.03.14:42:10 Error: Failed to validate switches. So, at this point the instructions don't work, and the example from the program's own help text is gibberish. MY QUESTION IS: DO YOU HAVE INSTRUCTIONS AND PROGRAMS THAT WORK? CAN I GET THEM?1.1KViews0likes3CommentsRe: Cyclone IV GX Oscillator failures
It's bad FPGAs. The FPGAs failed in a way that was surprising. In the original design, the 50 MHz clock drove a qsys pll that used 32/25 as a divider to produce an 8 MHz output. This divider said that it was exact in the GUI, however it was off by about 1/1000. In the second iteration of the design the 64 MHz clock used a divider of 1 and the 8 MHz output was correct to 50 ppm. The PCIe pll was supposed to produce 50, 125, 312.50 and 1250 outputs. They were actually 64, 160, 400, and 1600, and the PCIe was functioning. There were no indications of a problem unless you looked at the derived clocks from the timing analyzer and noticed the values to be wrong. In the third design, the INCLK of the PCIe pll was fixed to be 64. I communicated with engineers from EPSON and Abricon and both told me that the devices are capable of driving a short circuit indefinitely and then fully recovering when the short is removed. We have replaced 2 FPGAs and they have been operating for 3 days each. I sent 2 more out to be replaced. I have also put a handful of boards that have never failed into a burn-in environment, and they have been in operation for the same amount of time. Somehow, the FPGAs have managed to damage bulletproof oscillators while failing in a very obscure way.3.5KViews0likes2CommentsRe: Cyclone IV GX Oscillator failures
1) 50 MHz oscillator with 50 MHz design in the FPGA was tested w/ no failures. 10 of these units are being used in the field. 2) During qualification testing, it's discovered that an 8 MHz output is actually 8.006 MHz. The internal divider is set to 32/25 and the output should be exact. I couldn't fix this in the FPGA. 3) I change the 50 MHz oscillator to 64 MHz and the PLL to 1/1 and now my 8 MHz is really 8 +/- 50 ppm. 4) All of the boards that I have are re-tested and a few are sent to be used. 5) One of the boards that I have and one in the field show no activity on the PCIe. Then 2 more. 6) The PLL that drives the PCIe still has an INCLK value of 50 MHz. The downstream values of the PLL should be 50, 125, 312.50, and 1250 but are actually running at 64, 160, 400, and 1600. I fixed the INCLK value of that PLL, but the boards do not recover. 7) The failed boards have little or no amplitude on the 64 MHz, so we replace those oscillators. The oscillators all fail within 24 hours. 😎 We bought several different kinds of oscillators -- same results. -- The oscillators all fail within 24 hours. 9) I replaced the 22 ohm series termination with 220 -- same results. -- The oscillators all fail within 24 hours. 10) I contacted EPSON and Abracon engineers who told me that the oscillators will tolerate a short circuit indefinitely and recover when the short is removed. 11) I replaced 2 FPGAs so far and they have been in continuous operation for 3 days now. I'm sending 2 more out to be replaced. 12) I have 11 boards that have never failed in a burn-in environment and have been running for 3 days. So, YES the FPGAs were damaged and somehow killed bulletproof oscillators along the way. In the timing analyzer, the higher clock values are shown to be derived. Other than that, there was no way to tell that my chips were time bombs in the field.3.5KViews0likes0Comments- 3.7KViews0likes0Comments
Re: Cyclone IV GX Oscillator failures
Is this a commercial board or your own design? > One of many that we do. We have done many PCIe designs with the CIVGX and have not seen this problem. Is the location of the oscillator a hot spot on the board? > This one is a PCIe add-in card. It's right next to the fingers. Are the oscillators SMT or DIP? I am guessing SMT. > SMT Were they hand soldered onto the board or soldered in a manufacturing reflow process? > They were all replaced by hand. If you take one of the failed oscillators and mount on a standalone test fixture is it still dead? > I remove the resistor and check the output. It's the same. Are you considering sending the failed part(s) back to the manufacturer or to a test house for failure analysis? > That's probably going to take too long. Yes. It would be interesting to know what part of the oscillator failed. Is it the internal oscillator, or the output driver?3.7KViews0likes0Comments