micheleandClaude Sonnet 5
b528901510
Priority B>C>A>D confirmed correct with distinguishable per-port data (not just "someone got served" but "the right requester got its own data back") across 4 contention scenarios. D-alone case confirms low priority does not mean never granted. Found and fixed a real race in the test harness itself: blocking assignments withdrew loser requests in the same clock edge meant to grant the winner, racing the DUT's own synchronous block -- dut.owner never left SEL_NONE, every wait() blocked forever. Fixed by switching request-signal drives to non-blocking assignments throughout. Documented (not filed as a bug) that D can starve indefinitely under sustained continuous B contention -- standard behavior for a fixed-priority arbiter with no aging, and explicitly outside the header's own stated operating assumption (B/C temporally disjoint in normal operation). Flagged the header's "never starves or corrupts A/B/C" wording as ambiguous about whether it promises D's own progress. Full regression: 40/40 real tests pass. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013xXuuRUWZScuo1DeYJxs3v
76 lines
3.7 KiB
Markdown
76 lines
3.7 KiB
Markdown
# C.4 — Arbitro (`mem_arbiter.v`)
|
|
|
|
Data: 2026-09-04.
|
|
|
|
---
|
|
|
|
## 4.1 Priorità B>C>A>D — CERTIFICATO
|
|
|
|
**Metodo**: nuovo test dedicato (`sim/mem_arbiter_priority_tb.v`). Quattro scenari,
|
|
combinazioni decrescenti di richiedenti simultanei, ciascuno con dati distinguibili
|
|
(`m_rdata` eco dell'indirizzo) per confermare che la risposta torni al **richiedente
|
|
corretto**, non solo che "qualcuno" venga servito:
|
|
1. A+B+C+D simultanei → B vince.
|
|
2. A+C+D (B assente) → C vince.
|
|
3. A+D (B,C assenti) → A vince.
|
|
4. D da solo → viene comunque servito (bassa priorità ≠ mai servito).
|
|
|
|
```
|
|
$ iverilog -g2012 -o /tmp/arb6.out rtl/mem_arbiter.v sim/mem_arbiter_priority_tb.v && vvp /tmp/arb6.out
|
|
ALL TESTS PASSED (priority order B>C>A>D confirmed; ...)
|
|
```
|
|
|
|
**Nota di processo — race trovata nella mia stessa testbench**: la prima versione usava
|
|
assegnazioni bloccanti per ritirare le richieste dei "perdenti" nello stesso
|
|
`@(posedge clk)` che doveva concedere la richiesta — una race reale con il blocco
|
|
sincrono del DUT sullo stesso fronte (l'ordine di esecuzione tra processi diversi
|
|
sensibili allo stesso evento non è garantito da Verilog). Diagnosticato con un
|
|
riferimento gerarchico a `dut.owner`, mai uscito da `SEL_NONE` nonostante le richieste
|
|
fossero pilotate — non un difetto dell'RTL. Corretto passando ad assegnazioni non
|
|
bloccanti per i segnali di richiesta in tutta la testbench, come farebbe un master reale
|
|
sincrono allo stesso clock.
|
|
|
|
**Verdetto: CERTIFICATO.** L'ordine di priorità dichiarato nell'header è implementato
|
|
esattamente come descritto, dati instradati al richiedente corretto in ogni caso.
|
|
|
|
---
|
|
|
|
## 4.2 Starvation di D sotto contesa continua — comportamento reale, ambiguità nella documentazione
|
|
|
|
**Test**: `b_req` e `d_req` mantenuti entrambi asserti continuamente per 500 cicli
|
|
(B "ha sempre altro lavoro" nell'istante in cui si libera).
|
|
|
|
**Risultato**: **D non viene MAI concesso in 500 cicli** di contesa continua da B.
|
|
|
|
**Perché non lo classifico come bug**: l'header del modulo dichiara "flash operations
|
|
are ms-scale and never meant to compete with inference for memory bandwidth" e "In
|
|
normal operation B and C are temporally disjoint anyway" — la contesa continua e
|
|
sostenuta testata qui è esplicitamente fuori dallo scenario operativo previsto (un
|
|
`layer_sequencer`/`neuron_memory` che non lascia MAI un buco libero per centinaia di
|
|
cicli di fila non corrisponde a un'inferenza reale). Un arbitro a priorità fissa senza
|
|
invecchiamento (aging) che fa morire di fame il richiedente più basso sotto carico
|
|
sostenuto è un design standard e spesso intenzionale, non un difetto di per sé.
|
|
|
|
**Cosa segnalo**: la frase dell'header "gets stretched out, never starves or corrupts
|
|
A/B/C" è **ambigua** — può essere letta sia come "[D] non affama mai [se stesso]" sia
|
|
come "[la contesa] non fa mai affamare o corrompere A/B/C" (una garanzia solo su A/B/C,
|
|
non su D). Il comportamento osservato è coerente con la SECONDA lettura, non con la
|
|
prima. Non è un bug funzionale, ma la frase andrebbe disambiguata nel commento sorgente
|
|
per evitare che un futuro lettore assuma erroneamente che D abbia una garanzia di
|
|
progresso che il codice non implementa.
|
|
|
|
**Verdetto: CERTIFICATO come comportamento** (nessuna sorpresa rispetto a un arbitro a
|
|
priorità fissa senza aging), **riserva documentale** sulla frase ambigua dell'header.
|
|
|
|
---
|
|
|
|
## 4.3 Verdetto complessivo C.4
|
|
|
|
| Sotto-aspetto | Verdetto |
|
|
|---|---|
|
|
| Priorità B>C>A>D, instradamento dati corretto | **CERTIFICATO** |
|
|
| Starvation di D sotto contesa sostenuta | **CERTIFICATO come comportamento**, riserva sulla chiarezza della documentazione (non un bug) |
|
|
|
|
Nessun bug RTL trovato in questo aspetto. Un difetto di race trovato e corretto nella
|
|
testbench di verifica stessa (stesso schema del resto della campagna).
|