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

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.