Cyclone VGT Dev Kit boards - some new boards failing to boot from NOR Flash

That's rather disappointing to hear, actually. The Max V design is Altera's design. One of the boards fails to boot with multiple retries even with the factory binary. 

If I remove the factory_user input inversion (a simple NOT statement) then the factory Max V design fails on 5 out of say about 20 boards, since Rev B boards came out. Why? I am not convinced that these new boards are identical to the working ones, sorry. 

I suspect the "pass/fail" OQC for these boards includes checking that they configure without error, but under the hood, some of them are failing and retrying configuration multiple times. At the performance of the parts on board, a single configuration failure is a board failure. I suggest the factory bootloader be reconfigured to fail at one single retry, then you will notice the board issues before shipping them out. 

This Max V design is Altera's loaded up to 99% utilization. Not my doing. 

In short, I have a new build that "works" with the new boards, but no evidence as to why. None of the timing reports on a "failing" design are showing up with errors, they are just mildly different from the "working" design. 

I am not pleased with this outcome at all, sorry to say. 

Hello,

We are seeing the exact same issue on our Cyclone V GT Dev Kit boards. We run our own custom FPGA firmware, which is known-good and has been in use for quite some time, and we have already adapted to the rev. A to rev. B flash changes, so that is not a factor.

Over the last few weeks, several brand-new Dev Kit boards have started behaving exactly as GordWait described: the board retries configuration multiple times, with nStatus and nConfig toggling, until it hits the timeout. This happens with both our custom firmware and the factory image. It was intermittent at first and has gotten progressively worse, and we also noticed a dependence on board temperature, which could be relevant for a timing issue.

The failing board we have on hands now are the 5CPCIE00100214 and 5CPCIE00100263, both with the QS3861. We also have an older board that works 100% of the time (5CPCIE00100041) which uses the QS3VH800.

As OP suggested we briefly tried changing the MAX 5 design to improve timing and the situation improved greatly. Still, this is a disappointing situation with a lot of time lost chasing ghosts.

Thanks.

We just received 5 new boards from Terasic. 
Terminology:
"Rev B good boards" - these are Rev B, and work fine with our previous default release that has been stable since the start of the rev B release. 
"New marginal boards" - these only work with the "timing improved" rebuild of the Altera Max V bootloader code, but do not work with our previous default release. 
"Bad new boards" - these do not work with any of our custom Max V bootloaders, any edition. They also either do not work at all with the factory Max V binary, or will boot up eventually, just making it under the timeout limit of the factory bootloader (which seems to be about 6 seconds). These boards (when investigated) run dozens of "fail then retry" cycles. 

Of the five new ones we ordered from Terasic, four are the same as the "Rev B good boards". 
One is a "Bad new board" and will not boot even with the factory installed firmware. 

We will request an RMA/replacement for this one, and will do so for any more that we receive in the "Bad new board" state. 

For anyone receiving these boards, first run the quartus programmer and examine the Max V part (5M2210Z) to see what the checksum is. The factory max5.pof seems to be: Checksum 008D0C68, Usercode 008DOC49. 

See how long it takes to boot out of the box. If it's not instantaneous (say well under 100 ms?) then it's probably ok. If it takes seconds to boot, or turns on the red ERROR LED, I'd send it back for replacement. 

This is extremely frustrating and tedious. 

One more update. I spent the last few days creating a very dumb basic bootloader, so that I could: 1. simulate the RTL code in Questasim, and 2. Sample internal nets of the same code using the ISSP function. I ran it on the "very bad" boards I have and on one "mostly bad" board (it fails 1/5 even with my new slightly better Max5 bootloader). I also tried it on fully good known boards. What I found is that the bad boards CVGT FPGA are triggering a "Framing/CRC" error on the bit stream, at RANDOM offsets in the NOR flash memory. IE every reset of the Max5 CPLD fails but fails at a different address in NOR flash. I also had ISSP capture some of the NOR data bytes that the CPLD was about to send to the FPGA config port, around a failure event. The data seemed stable, although not enough samples were captured to guarantee this statement. In short, there is something wrong with the hardware on the bad boards. Note also this dumb basic bootloader runs at 25 mhz, lots of time for the NOR flash output to settle. Altera continues to send out a mix of good/notsogood/bad boards at this point. We will be sending back any that fail normal bootloading for refund/replacement. 

I too have discovered that the Factory Max5 bootloader source code has inadequate or missing timing constraints. 

Note now we have two useless CVGT dev kits on hand, and we still need RMAs for them. We are about to order 7 more boards - we only need 5 working ones but we assume 2 out of 7 will fail in the same way.

This is a lot of cash we have tied up in bad boards. 

Here are the details of my timing investigations of the factory build: 

## Summary list of unconstrained I/O pads (as-shipped SDC)

There are two distinct categories of "unconstrained" here, and the difference matters: one is caught by Quartus's own built-in `report_ucp` (Report Unconstrained Paths) command, the other is invisible to it entirely.

**Category 1 — truly and completely unconstrained.** No `set_input_delay`/`set_output_delay`/`set_false_path`/max-skew assignment of any kind exists for these ports. This is exactly what `report_ucp` is designed to catch, and does catch, against the as-shipped SDC:

Pad | Direction | Function | Quartus's own flag |

| `factory_user` | Input | Physical 2.5 V DIP switch selecting Factory vs. User image at power-up; feeds directly into the `p2` megafunction's own page-select logic (`pfl_pagesel_int[0]`) and `image_sel2` | `report_ucp`: "No input delay, min/max delays, false-path exceptions, or max skew assignments found" |

| `max_as_conf` | Output | Driven by `pfl_control`'s internal `msel_reset_n` | `report_ucp`: "No output delay, min/max delays, false-path exceptions, or max skew assignments found" |

`factory_user` is a slow, manually-operated switch, so the missing constraint is plausibly benign in practice — but nothing in the SDC records that as a deliberate decision (contrast with `factory_load`, `pgm_sel`, `cpu_resetn`, and several other genuinely-async inputs elsewhere in the same SDC, which *do* have explicit `set_false_path` entries marking them as intentionally excluded). `max_as_conf` has no such treatment either way.

**Category 2 — nominally constrained, but the constraint is dead.** These ports *do* have a `set_output_delay` assignment in the SDC, so Quartus considers them "constrained" and **`report_ucp` does not flag them at all** — but the assignment references the wrong clock and is silently voided by the `clk_config`↔`clkin_50` false-path exception described above. This category is the one worth emphasizing: it is invisible to the standard unconstrained-paths audit, and would only surface by manually checking that every `-clock` argument matches the signal's actual driving domain.

| Pad | Direction | Nominal constraint | Why it's actually dead |

| `flash_oen` | Output | `set_output_delay -clock clkin_50 ...` | Driven by `clk_config`; false-pathed against `clkin_50` |

| `flash_wen` | Output | `set_output_delay -clock clkin_50 ...` | Same |

| `flash_cen` | Output | `set_output_delay -clock clkin_50 ... {flash_cen[*]}` | Same wrong-clock bug, **plus** the bracket never matches (`flash_cen` is a scalar port) — doubly unconstrained |

| `flash_resetn` | Output | `set_output_delay -clock clkin_50 ...` | Same wrong-clock bug (a separate, deliberate `set_false_path -to flash_resetn` also exists, so this one is arguably intentionally excluded from setup/hold checking anyway — flagged here for completeness) |

| `fpga_config_d[0]` … `fpga_config_d[7]` (8 pins) | Output | `set_output_delay -clock clkin_50 ... {fpga_config_d[*]}` | Same wrong-clock bug |

That's **14 physical pads total** with no effective timing verification in the as-shipped design: 2 in Category 1 (`factory_user`, `max_as_conf`) and 12 in Category 2 (`flash_oen`, `flash_wen`, `flash_cen`, `flash_resetn`, and the 8 bits of `fpga_config_d`). Of those, `flash_resetn` is arguably intentionally exempt (it has its own deliberate `set_false_path`, separate from the wrong-clock bug) — so 11 pads have a genuinely missing, non-deliberate setup/hold check. The `flash_oen`/`fpga_config_d[*]` group is the one directly implicated in the real, measured Slow-model setup violation reported below.

Hi,

Thanks for the detailed information and for outlining the debug steps taken.

From our side, there are known changes in the RevB board (including NOR flash device and routing), and there is a related knowledge base article that may be relevant to what you are seeing:

• Why can’t I access the EPCQ flash device on the Cyclone V GT FPGA Development Kit (DK-DEV-5CGTD9N-B)?
  https://community.altera.com/kb/knowledge-base/why-cant-i-access-the-epcq-flash-device-on-the-cyclone®-v-gt-fpga-development-ki/344352

Before concluding this is the same root cause, could you help confirm a few points:

1. Are all failing boards confirmed to be RevB, and using the same NOR flash device (Micron)?
2. Does the issue persist even with the factory image without any modification?
3. Are you able to consistently program and verify the NOR flash contents via JTAG on failing boards?
4. Is the retry behavior reproducible across power cycles, or intermittent?

This will help us determine if your case aligns with the known issue or if something else is contributing.

Looking forward to your feedback.

Regards,
Fakhrul

Some more updates and summary info:
Update 11 June 2026 at 1:32 PM

1. We have 5 CVGT Dev Kit boards that will not boot the FPGA with our released production firmware. We do have Rev B boards that work fine with our firmware, so it is not all boards. Our production released firmware has been working for the old Rev A boards, and the new Rev B boards except for these bad 5.
2. I have diagnosed that the bad boards retry the FPGA configuration multiple times, then ultimately fail, as a watchdog timer in the MaxV design times out and turns on the ERR led on the CVGT board. On a rare occasion a couple of the boards may actually manage to fully boot, but then the next power cycle it will fail again.
3. For our production, we make a minor edit to the factory source - setting the final image to a read only version, and we use a write enabled version of that in our programming sequence:
1. Load the read/write edition MaxV image
2. Program the FPGA using Quartus tools
3. Load the read only MaxV image.
4. Three of the “bad” boards - if we load the factory max5.pof from Altera and switch the Factory Image over to the “User” setting, then they boot up and appear to be fine. The other two bad boards still fail in this mode. 
5. If I just recompile the Factory image - as is - using Quartus 23.1 Std 1, that compiled image does not work with ANY of the 5 bad boards. It does work with known good boards. 
6. Some of the bad boards fail to boot randomly when loaded with the “restore to factory” firmware, but they all seem to retry many times before they pass or fail. Retrying just once is an indication that something is wrong with the board. 
7. We notice one of the new bad boards has a different silk screen (it does not say UK/CA on it). Why are there two variants of the Rev B dev kit? Not sure if this is relevant but it seems odd.

Questions: 

1. Why did Altera invert the Factory/User switch state in the V22 CVGT Dev Kit Release?
2. Why does my compiled version of the V22 MaxV device act differently (behave worse) than the binary max5.pof that came with the V22 edition source code? It seems like the source code is not able to build the same design as the Altera binary. 
3. Is anyone else having issues with some of the CVGT Dev Kits booting from NOR flash? 

Hi Fakhrul, I looked into your questions. 

I have 4 of the bad boards in hand, so I can verify the following serial numbers and the U29 part. All four have the same part that the schematic calls for: 

5CPCIE 00100129 - has IDT QS3861
5CPCIE 00100142 - has IDT QS3861
5CPCIE 00100147 - has IDT QS3861
5CPCIE 00100148 - has IDT QS3861

An older Rev B I have here is a good board, it has an IDT Q53VH8COQG device on board. 

You mention : " The difference between the factory .pof and self-compiled version may point to differences in fitter/timing results." - since I am using the same provided source files, and the same Quartus version, should it not create the exact same max5.pof binary? 

More answers:

1. For the 3 boards that work with the factory .pof, do they complete configuration in a single attempt or still show retries? - it seems like the configure in a single attempt, based only on the boot up speed. 
   
   
2. For the 2 boards that still fail, is the retry behavior identical across all images? - yes, random N number of retries until the ERR led turns on. 
   
   
3. Have you compared settings between your compiled .pof and the factory .pof (e.g. compression, configuration options)?  - I used the exact factory source files with the factory QSF and constraints files, I get a different checksum, and my compiled factory image does not work at all. 
   
   
4. Could you share the serial numbers of the affected boards? There may be a specific affected range for certain revisions. - yes, see above.  (missing one, I don't have it at the moment)
   
   
5. For the silk screen difference, if possible, please share board markings or photos for comparison.
   For my older good working board, there is a silk screen label UK/CA that is in the open to the "East" of the USB jack. For the new bad boards, the UK/CA label is there partly covered by the FPGA fan, further "East". 

This will help us check if your boards fall within any known affected batch or if this is a new variation.

Here is the photo of the different U29 from my (dusty but working fine) engineering test CVGT:

Our 3 known bad boards are SN: 

5CPCIE00100119
5CPCIE00100129
5CPCIE00100262