# Remaining ISE warnings and limits

This records the first test image (`5016887`). For the follow-up after the
7 MHz pass / 60 MHz red-screen report, see [R2 results](r2-results.txt).
The current [R4 candidate](r4-results.txt) reports 53 XST warnings, unchanged
from [R3](r3-results.txt), and retains the same categories of physical routing
and unused-interface warnings.

The core still has warnings. Some describe deliberately unused interfaces;
others identify timing, routing, or compatibility limits that require further
review. A smaller warning count does not establish board stability at 60 MHz.

This audit uses the final `build/release-60mhz-03` source snapshot and its
completed ISE reports. XST reports **54 warnings, down from 250 in the
baseline**, using ISE's own summary counts; no warning filter was added.
Translation reports one warning, MAP two, PAR three, and bitstream generation
one. Some stages repeat the same physical warning, so these totals do not
represent distinct defects. The main, component, and slow-mode timing reports
each report **zero timing errors** under the documented constraints and
mode-specific exceptions.

See [optimization-results.txt](optimization-results.txt) for the image's
implementation results and hashes. Build reports are local generated
artifacts and are excluded from Git.

## XST categories

Counts include repeated messages emitted at different hierarchy/optimization
stages; they are not counts of distinct bugs.

| Warning | Count | Meaning and disposition |
| --- | ---: | --- |
| `Xst:647` | 19 | Unused input ports or input bits. See the interface table below; several reflect a limited implementation rather than a fully implemented feature. |
| `Xst:646` | 9 | Assigned signals have no consumer: legacy boot state, unused multiplier result bits, even-sprite attach outputs, floppy configuration bit 1, and DTR. |
| `Xst:737` | 1 | The CPU bridge infers a 16-bit transparent input latch. This remains timing-sensitive. |
| `Xst:1293` | 4 | CIA interrupt registers become constant because their sources are tied inactive in this integration. |
| `Xst:1710` | 4 | Constant CIAB input synchronizers and a board-status bit for a disabled autoconfig device are removed. |
| `Xst:2677` | 16 | Unconnected sequential bits are trimmed. These mostly repeat the CIA, sprite, configuration, and status-output cases below. |
| `Xst:1336` | 1 | XST's preliminary slice estimate exceeds the device. MAP fits this implementation, but placement remains dense. |

### CPU input latch: `Xst:737`

In `m68k_bridge` in [Minimig1.v](../Minimig1.v), `ldata_in` follows
`data_in` while the 7 MHz `clk` is low, then retains that value while `clk`
is high. The incomplete assignment is intentional latch behavior, not an
omitted combinational default.

A flip-flop replacement would change the bus capture window and cannot be
justified solely to remove the warning. The current implementation still
depends on the phase and stability of returned memory/peripheral data and
the CPU's sampling time. Targeted RTL tests do not establish those physical
setup/hold margins. See [timing-model.txt](timing-model.txt).

### Device occupancy: `Xst:1336`

For `release-60mhz-03`, XST estimates 3,882 slices against 3,584 available.
Subsequent MAP packs the design into **3,510/3,584 slices**, with **140/141
IOBs** and **14/16 BRAMs**. This explains why the synthesis warning does not
prevent that build from fitting. It does not remove the congestion risk:
there are only 74 free slices in this implementation, and placement or a
small RTL change can materially affect routing and timing. Judge capacity
using completed MAP/PAR reports for the exact source snapshot.

### Unused inputs: `Xst:647`

| Module/input | Explanation and retained limit |
| --- | --- |
| `Amber.scanline[1]` | Amber uses bit 0 for its scanline effect. Bit 1 is used separately as cache bypass in the top-level CPU bridge connection, so it is not globally unused. |
| `m68k_bridge.eclk[7:4]`, `[2:0]` | The bridge uses E-clock phases 3, 8, and 9. The full phase bus remains its interface. |
| `m68k_bridge.memory_config[1:0]` | Cache-bank enable uses the slow-memory size in bits `[3:2]`; chip-memory size bits are used elsewhere. Configuration changes must occur with reset/invalidation. |
| `sram_bridge.sel_fast` | The present six-SRAM implementation uses the resolved bank/address signals. The separate legacy fast-select input has no consumer in this bridge. |
| `sprdma_engine.vpos[10]` | Sprite DMA uses a narrower vertical-position range. This warning is not evidence that every possible extended vertical mode is supported. |
| Blitter `address_generator.reset` | Pointer/modulo storage is loaded by register writes rather than reset by this port. Existing reset behavior is preserved; software must initialize the registers it will use. |
| `ps2mouse.test_data[9:8]`, `[1:0]` | The test-load path writes only the upper six bits of each mouse counter. The unused low bits are not newly implemented by this cleanup. |
| `playfields.bplcon2[2:0]` | This submodule does not consume those priority bits. Denise's separate sprite/playfield priority logic does consume them. |
| `ciaint.data_in[6:5]` | Only the set/clear bit 7 and interrupt-mask bits `[4:0]` are decoded. |
| `minimig_autoconfig.data_in`, `rd` | Autoconfig advances on selected configuration-write addresses. The implementation uses a predetermined memory map and does not program general board base addresses from write data. Its ROM output is qualified by select rather than this read input. |
| `gayle.address_in[23:16]`, `[11:5]`, `[1]` | High-level selection comes from Gary; Gayle locally decodes `[15:12]` and `[4:2]`. Undecoded bits preserve existing register aliases. |
| `bitplanes.hpos[8:4]`, `[1:0]` | This module only needs the local pixel/word phase; wider position decoding occurs elsewhere. |
| `Denise.cck` | The implementation uses its other clocks/enables. The unused port is retained. |

Narrowing these interfaces would remove messages but would require coordinated
caller changes. Adding dummy logic to consume them would obscure their actual
meaning. Neither was needed for the implemented timing changes.

### Unused or constant state: `646`, `1293`, `1710`, `2677`

- **Legacy boot state:** `syscontrol._boot` is written, but `boot` is tied
  inactive in this board integration. This is a disabled legacy boot-ROM path,
  not a newly functional boot mechanism.
- **Blitter multiplier bits:** `shifted_old/new[35:32]` belong to the full
  36-bit multiplier primitive outputs. The barrel shifter consumes the lower
  32 bits. Preserve the verified shifter result when altering this interface.
- **Sprite attach state:** paired sprites use the odd sprite's attach flag.
  Attach outputs/state from sprites 0, 2, 4, and 6 therefore have no consumer.
- **CIA interrupt sources:** CIAA's external FLAG input and CIAB's serial
  interrupt input are tied inactive. Their pending/mask logic is optimized
  away. These sources remain unsupported by the current top-level wiring;
  their removal is not proof of complete 8520 compatibility.
- **CIAB input bits:** `porta_in2[5]` and `[3]` sample constants from the
  top-level `{1'b0, cts, 1'b0}` connection. CTS is the live input. The other
  two external input functions are not connected.
- **Board outputs/configuration:** DTR has no output pin; floppy configuration
  bit 1 is unused; `clk7n_en` is unconnected; autoconfig completion and board
  status outputs are unconnected. The top-level disables the extra 64 MB
  autoconfig device, making its board-status bit constant. Removing status
  outputs would also remove useful module-level test visibility.
- **OSD vertical bit:** OSD frame qualification consumes selected lower
  `verbeam` bits, leaving bit 8 unobserved. This records the existing display
  window logic rather than proving all extended display modes behave alike.

## Translation, implementation, and bitstream warnings

The final implementation has one translation warning, two MAP warnings,
three PAR warnings, and one bitstream-generation warning. These need
different treatment from unused RTL signals.

| Warning | Cause | Remaining concern |
| --- | --- | --- |
| `ConstraintSystem` (translation) | `chip7_and_cpu` reaches a DCM, but ISE does not derive new TNM groups through the `chip7` group expression that excludes `cpu` and `chip28`. | Timing coverage depends on the explicit disjoint clock groups and separate DCM input/component audit. Those reports pass for this snapshot; changes to the clock tree or groups require another coverage review. |
| `LIT:176` | The global 7 MHz net also drives `CLOCK1/clk7_sample` as data (`CLOCK1/c3` before R3) and the CPU clock-mux inversion logic. | R3 adds a dedicated phase-path audit. These non-clock branches need timing analysis; renaming the net or suppressing the warning would not change their routing. |
| `PhysDesignRules:812` (MAP and bitstream generation) | `DOA15` of Amber's delayed line-buffer BRAM is unused; the delayed pixel buffer carries 15 bits. Both stages report the same pin. | An unused physical BRAM output does not require a dummy load. Any future widening must reconnect and verify the intended pixel bits. |
| `Place:1019` | SPI clock pin P90 cannot use the dedicated input-to-`sckbuf1` route in this placement. The existing `CLOCK_DEDICATED_ROUTE=FALSE` override permits implementation. | This is a real pin/buffer routing limitation. The override does not prove SPI timing. A remedy requires a legal dedicated pin/buffer placement, a board pin change, or a separately verified interface redesign; characterize the existing path with the actual controller. |
| `Route:455` (two nets) | `clk` and `cpu_clk_OBUF` have respectively two and one non-clock loads routed outside a clock template. The report lists zero affected clock pins. | The warnings concern those non-clock branches, not a reported failure to route every register clock. Their delay and external-clock relationship still require review. |

The previous Floppy `Pack:266` conflicts were removed by the track-selection
and arithmetic changes; they are absent from this implementation's MAP log.
Bitstream DRC reports zero errors and the single repeated `PhysDesignRules:812`
warning. ISE successfully generated both `.bit` and `.bin` files.

## Limits beyond the warning count

The final `Minimig1.twr`, `timing-components.twr`, and `timing-slow.twr`
all report zero timing errors. The slow-mode audit models CPU rising edges
at chipset falling edges with an explicit `PHASE + 70.484178 ns` and uses
two narrowly scoped exceptions for paths inactive in settled slow mode:

- Turbo acknowledgment `_ta_t1` cannot assert, so its path to the first
  synchronizer stage `_ta_t2` is excluded. The second stage remains timed.
- Slow mode holds cache invalidation asserted, so memory configuration bits
  `[3:2]` cannot affect the three cache RAM write ports. Only those
  configuration paths are excluded.

The audit script checks the source snapshot before applying these exceptions.
Turbo constraints and the crossing inventory retain these paths. Cache refill
uses the synchronized turbo acknowledgment `_ta_t`; the slow acknowledgment
`_ta_n` no longer feeds `t_dtack`. Regression checks mode switching separately.
See [timing-model.txt](timing-model.txt) for the constraint model and scope.

Complete interface closure still needs additional evidence:

- The CPU-to-chipset crossings include protocol-dependent and single-stage
  sampling paths. Independent CPU PERIOD closure does not certify them.
- The installed CPU, SRAM speed grade, board delays, SPI timing, and external
  setup/hold budgets have not been fully characterized. The retained 20/33 ns
  path budgets do not by themselves establish these requirements.
- The 0.5 ns system-jitter setting is an engineering allowance, not measured
  board jitter. Digital DCM models do not characterize analog jitter or
  metastability.
- SRAM writes now use held data and a half-cycle output-enable extension.
  Data setup and hold relative to write-enable/chip-enable release still need
  a board-level budget. Maximum data-path constraints alone do not provide it;
  see [sram-write-timing.txt](sram-write-timing.txt).

The next practical evidence is the workload and repeat-reset testing in
[hardware-test.txt](hardware-test.txt), using the exact image hash.

## Startup/cache interaction review

The startup and invalidation sequencing was reviewed with these invariants:

1. Only the first DCM delays configuration startup. It can lock without the
   downstream fabric reset pipelines running, avoiding a lock/GWE circular
   dependency. The build script explicitly orders lock wait before GWE and
   DONE.
2. `clocks_ready` starts low, clears asynchronously on any DCM lock loss,
   and asserts only after all locks and three 7 MHz edges. CPU reset is held
   directly while readiness is low; internal `reset` starts asserted.
3. If the 7 MHz clock stops, its internal reset register can wait for clock
   recovery, but the CPU remains held reset through `~clocks_ready`. Reset
   reaches the cache before the subsequent system reset release.
4. Cache validity starts disabled. Reset, host ownership, or slow CPU mode asserts the
   invalidation synchronizer; release requires CPU-clock edges, a full
   2,048-entry byte-valid clear, and an extra read-output refresh edge.
   The completed-counter transition cannot admit an old fill during
   invalidation because cache activity is already inhibited. Returning to turbo
   therefore starts with uncached operation until the clear finishes; slow
   reads do not pre-fill the cache.
5. MIA ownership invalidates cached data; it does not add CPU bus arbitration.
   Host access must respect the existing CPU reset/quiescence protocol.
   Memory-map configuration must remain stable during active CPU accesses.
6. Turbo read misses and all turbo writes reach `_ta_t` and can fill the cache.
   Read hits need no refill. Partial-byte replacement still invalidates an
   unrequested byte when changing tags, and preserves its valid sibling on a
   matching tag. Slow-mode writes cannot leave a reusable stale line because
   validity remains inhibited until the subsequent turbo-mode clear completes.

No new logical startup/invalidation bug was found in this static review.
The cache and clock regressions exercise digital sequencing; they do not
establish board-level setup/hold margins, complete-system recovery after an
oscillator fault, or full Amiga software compatibility.
