Request of private case

Hello,

1. Programming files are device-specific — recompilation is required for a different density target

The configuration data in a Cyclone V SE programming file (.sof, .pof, .rbf) is generated by Quartus Prime for a specific device member code. The clock source selection for the RCLK select block is controlled statically using configuration bit settings in the configuration file (.sof or .pof) generated by Quartus Prime. Cyclone V Device Handbook Volume 1: Device Interfaces and Integration Similarly, when a clock network is powered down, all the logic fed by it enters off-state; unused GCLK, RCLK, and PCLK networks are automatically powered down through configuration bit settings in the .sof or .pof generated by Quartus Prime. Cyclone V Device Handbook Volume 1: Device Interfaces and Integration These device-specific configuration bit fields mean the bitstream is structurally tailored to the exact target device's resources and routing — an A2-targeted file does not describe the larger fabric of an A5 or A7.

2. Each density variant has a unique IDCODE — and this is checked at configuration time

The Cyclone V SE density variants carry distinct IDCODE part-number fields. For Cyclone V SE, the 32-bit IDCODE Part Number bits differ across member codes: A4 = 0010 1101 0000 0001, A5 = 0010 1101 0001 0010, A6 = 0010 1101 0000 0010. Cyclone V Device Handbook Volume 1: Device Interfaces and Integration These are not the same — the A2 member code similarly has its own unique IDCODE.

During JTAG configuration, the IDCODE instruction identifies devices in a JTAG chain; when IDCODE is selected, the device identification register is loaded with the 32-bit vendor-defined identification code, which is placed between TDI and TDO to allow serial shifting out of TDO. IDCODE is the default instruction at power-up and in the TAP RESET state. Cyclone V Device Handbook Volume 1: Device Interfaces and Integration This means the programmer will read the physical device's IDCODE at the start of configuration and compare it against the target encoded in the programming file. A mismatch (e.g., A2 file → A5 device) will be caught at this stage.

That said, the IDCODE check is not the only enforcement mechanism — the configuration data itself is structurally incompatible across densities because the fabric resources (ALMs, M10K blocks, DSP blocks, routing) are categorically different between, say, an A2 and an A5. Even if you were to bypass the IDCODE check, the bitstream would not correctly configure a device with a different resource count.

3. "Vertical migration" in Cyclone V SE is a PCB/pin-compatibility feature — not programming-file portability

Altera's documented "vertical migration" capability for Cyclone V SE is specifically about I/O pin and PCB footprint reuse across densities, not about bitstream reuse. Vertical migration is supported in the U672 packages of Cyclone V SE and SX devices; however, vertical migration between these devices was disabled in Quartus II 13.0 SP1 and earlier software. To enable it, install patch 1.33 for Quartus II 13.0 SP1. Vertical migration is enabled in Quartus II version 13.1 and above. Is vertical migration supported in Cyclone V SoC devices? The intent of this feature is to allow the same PCB to accommodate different densities — you still recompile Quartus Prime targeting the specific density member code you are populating.

To enable vertical migration support for Cyclone V SX and SE devices in Quartus II software version 13.0 SP1, download and install patch 1.31 (available for Windows and Linux). Cyclone V Device Handbook Volume 1: Device Interfaces and Integration

To check what is pin-compatible across densities, use the Pin Migration View in the Quartus Prime Pin Planner. Cyclone V Device Handbook Volume 1: Device Interfaces and Integration

4. ES vs. production incompatibility is explicitly documented

As a related compatibility note: you cannot use a Cyclone V ES configuration file to program a Cyclone V production device. Can I use a Cyclone V ES configuration file to program a Cyclone V production device? This is a separate (but illustrative) restriction showing that Altera explicitly enforces programming file compatibility boundaries and documents them when they exist.

Summary

• A .sof/.pof/.rbf compiled for Cyclone V SE A2 cannot be programmed into an A5 or A7 without recompilation. The configuration data is device-specific, and the IDCODE encoded in the file will not match the target device's IDCODE.
• The IDCODE check during JTAG configuration enforces this, but the bitstream incompatibility is deeper — the configuration fabric description itself is different.
• Vertical migration in Cyclone V SE addresses PCB pin footprint reuse across densities, not bitstream portability.
• Recompile your design in Quartus Prime targeting the specific member code (A2, A5, A7, etc.) you intend to program.