Forum Widgets
Recent Discussions
Cyclone 10 LP Bitstream Compression Failing
I am using the Altera Cyclone 10 LP Development Kit with the 10CL025YU256I7G Device. Do do the design, I am using Quartus Prime Version 24.1 Standard. I am trying to compress my bitstream in order to have a faster configuration. I am using Active Serial with the on-board flash device. Altera documentation suggests two ways of performing the compression: Cyclone 10 LP bitstream compression I can get the compression to work using the 2nd way, where the .sof file is compressed during "Convert Programming Files" by accessing the file properties. The 1st suggested way of compression is not working: "To enable compression before design compilation: Click Assignment Menu > Device. Select the appropriate Intel ® Cyclone ® 10 LP device and then click Device and Pin Options. In the Device and Pin Options window, select Configuration under the Category list and turn on Generate compressed bitstreams. Click OK." The checkbox for "Generate compressed bitstreams" is checked, but after compilation, the .sof file is not compressed and configuration takes the same amount of time as when the checkbox is not checked. Why is this occurring?
Updated .brd file for Stratix 10 GX dev kit
Referencing this post: EK-10M08E144 PCB .brd file corrupted | Altera Community - 302242 The .brd file that comes in the documentation at: https://www.altera.com/products/devkit/po-3028/stratix-10-gx-signal-integrity-development-kit-h-tile ...was done in Allegro, prior to version 16.6. The only available Allegro viewer gives an error because it was done prior to version 16.6, and you need the DB Doctor utility to update the file. The only way to get the DB Doctor utility is to install Allegro. If I had Allegro...I would not be installing the Allegro viewer. Altera: As mentioned in the post above (well over a year ago), it would make sense for you to update your files so customers can view the board of their $10K+ development board. How do we make that happen? Thanks!Agilex 5 D-Series HVIO IOPLL runtime reconfiguration: C0 write succeeds, but output remains 100 MHz
I am trying to change an Agilex 5 D-Series HVIO IOPLL output from 100 MHz to 50 MHz at runtime through the core_avl reconfiguration interface. The register transactions appear to work correctly: C0 at 0x05C can be written and read back successfully, and Signal Tap confirms that the reset (0x080), recalibration enable (0x048), and recalibration request (0x088) commands all reach the IOPLL interface with the expected data. However, the physical output clock still remains at 100 MHz, and locked stays high throughout the procedure. My main problem is that I cannot determine whether the new C0 divider is actually being applied to the active PLL, or whether the recalibration cycle is not really starting/completing. Problem: Runtime writes to the Agilex 5 HVIO IOPLL reconfiguration registers succeed, including C0 write/readback and the documented reset/recalibration sequence, but the output frequency does not change from 100 MHz to 50 MHz. locked remains high, so I cannot tell whether recalibration actually starts or whether the new C0 value is applied to the active divider. Environment: Device: Agilex 5 A5ED013BB32AE4S Board: Terasic DE25-Standard Rev. Quartus Prime Pro: 26.1 Reference clock: 50 MHz Initial IOPLL output: 100 MHz Target runtime output: 50 MHz What I have verified HVIO dynamic reconfiguration is enabled. core_avl_clk is running at 50 MHz Register access at 0x010[0] is enabled. Calibration status bits 0x058[7] and [21] are cleared according to the Agilex 5 D-Series 25.1.1 guide. C0 register address is 0x05C. C0 can be written and read back correctly. For the 50 MHz test, I use: high_count = 32 low_count = 32 bypass = 0 odd = 0 which gives: C0 = 0x10000C20 The hardware readback after writing C0 is also 0x10000C20. Signal Tap confirms that the following writes reach the actual IOPLL core_avl interface: 0x080 = 0x00000004 // PLL reset 0x048 = 0x00004000 // recalibration enable 0x088 = 0x00000800 // recalibration request. The 0x080[2] reset pulse is longer than 10 ns, and there are no bridge errors, rejected transactions, or timeouts. I also compared known-good static 100 MHz and 50 MHz Quartus-generated configurations. The main implemented difference is: Static 100 MHz: C0 divide = 32 high/low = 16/16 Static 50 MHz: C0 divide = 64 high/low = 32/32 M, N, VCO, compensation mode, phase, and the other relevant PLL parameters remain unchanged. Observed result: After the complete runtime sequence: C0 final readback = 0x10000C20 locked = 1 output clock = still 100 MHz. So the register value is retained, but the active output divider does not appear to change. Questions: If locked is already high before asserting 0x088[11], how can I confirm that a new recalibration cycle actually starts and completes?Does successful C0 readback at 0x05C mean the new divider value is ready to be applied to the active PLL, or is another condition required?Is there any additional documented step after 0x080[2], 0x048[14], and 0x088[11] before the new C0 divider becomes active?Is the Agilex 5 HVIO IOPLL runtime reconfiguration example #16029156620 available? I can provide Signal Tap captures for the 0x080, 0x048, and 0x088 transactions, as well as the complete UART register log if needed. Thanks.Is VCCPD = 3.3V and VCCIO = 2.5V allowed on an Arria V?
Hi, I am currently using an Arria V 5AGXMA1D4F27 device. I would like to use 3.3V on VCCPD and 2.5V on VCCIO for the IO bank. The intent is to have JTAG programming done at 3.3V(the processor doing the programming has 3.3V GPIOs). All pins on the bank will be using 2.5V for normal operation in addition to having true LVDS pins on the same bank after configuration. I could not find any documentation for this. It would be of great help to have a confirmation on if this is valid? Thank you for your time.TSE MAC+PCS (SGMII, Cyclone 10 GX): mdio_out/mdio_oen never toggle, no matter what I write
Cyclone 10 GX (10CX220Y), Triple-Speed Ethernet IP: core_variation=MAC_PCS, transceiver_type=NONE (external LVDS SERDES, TBI), enable_sgmii=true, enable_use_internal_fifo=true, useMDIO=true. Trying to read/write an external Marvell 88E1111 over MDIO via the MAC's control_port (System Console + JTAG-to-Avalon). Verified working: basic CSR read/write (rev, scratch_pad), tse_rst=0 / xcvr_ready=1 (out of reset), mdc toggling correctly at 1.25MHz on the pin, MDIO_ADDR0 (0x0F) and MDIO_ADDR1 (0x10) are real R/W registers (write/readback matches), mdio_oen tri-state glue matches Intel's own reference template exactly. Not working: I added (* preserve *) to mdio_in/mdio_out/mdio_oen and tapped them directly with SignalTap on TSEIP's own ports. With a falling-edge trigger on mdio_out, and while repeatedly writing MDIO_ADDR0/MDIO_ADDR1 and reading/writing both the phy0 (0x40+n) and phy1 (0x60+n) windows with genuinely varying values — mdio_out never shows a single transition. Since even a bare MDIO read frame must produce at least one falling edge (end of the all-1s preamble), this looks like no real MDIO transaction is ever being started from the CSR side. What am I missing — is there another enable/start bit or busy/status flag needed to actually kick off an MDIO transaction on this core_variation/config? Any pointer to the MDIO register section for this exact IP version (Quartus Prime Pro 24.1) would help too.
Cyclon 5 tampering protection bit
I have a cyclone V with an AS scheme. I have generated an key-file (ekp) with tampering protection bit set according to AN556 Then I open it in the programmer programmer and generate a jam-file now in the jam-file the procedure DO_KEY_SECURE is optional which means I have to enable that procedure manualy with "-e DO_KEY_SECURE" in the command, for example: quartus_jli -c <n> keys.jam -e DO_KEY_SECURE -a <action> is it possible to make this procedure non-optional so it will program the tampering bit by default when programming the key?
10CL040YF484 Programming fails
1st Vendor Batch (Date Code: 2525): - First Test (3 FPGAs): - Card 1: ISP and JTAG programming successful; functioning correctly. - Card 2: Programmed in ISP mode, but fails to execute and returns a JTAG error. Replacing the FPGA on this board with another one resulted in the same issue. - Second Test (3 FPGAs): - Cards 3 & 4: ISP and JTAG programming successful; functioning correctly. - Card 5: ISP and JTAG programming successful, but the device is not functioning correctly, and most pins are not working as required. - Mouser Batch (Date Code: 2619): - Third Test (2 FPGAs): - Card 6: ISP and JTAG programming successful, but the device fails to function properly, with most pins not meeting requirements. - Card 7: ISP programming successful, but returns a JTAG error and fails to execute. Based on these outcomes, could you please help us identify where the problem lies?