Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

BRAM synthesis bug?

Aperta
  • Qualcosa non va?
#55 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Ferma
Ambito
build-system, embedded-iot

Direzione di ricerca

Inizia dagli entry point BRAM2Port/mkBRAM2Server e BRAM_DUAL_PORT/mkBRAMCore2, quindi confronta la sintesi delle BRAM di scrittura da 128 e 256 entry. Riproduci la discrepanza con e senza la proprietà -nolutram, confrontando la simulazione, il Verilog generato e il bitfile risultante. Il lavoro è completato quando la causa nella sintesi o nella configurazione è stata identificata e corretta e il percorso di scrittura funziona con la dimensione maggiore.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

It was noticed that writes to the QSFP modules stopped working. Simulations looked fine. The limited capacity I had to observe on-chip behavior looked fine (writes to the BRAM appeared to happen, as did reads). However, the data that was always being read out was 0x0. Things looked fine in the BSV and I scoured the generated Verilog and could not find anything anomalous. While trying to figure out what could have changed, I remembered that I bumped up the size of the read/write BRAMs from 128 to 256 so place and route would automatically put them in hard RAM blocks, not lutrams. When I reverted the size of the write BRAM back down to 128 (resulting in it synthesizing to lutram), it worked correctly! When I tested a bitfile with 128 and synthesized with the -nolutram property, it also worked and had synthesized to hard logic. Simulations worked the whole time.

Notably, we haven't found any issues with the read BRAM after the size change. I'm guessing that is due to using the higher level BRAM2Port interface provided by mkBRAM2Server, which introduces FIFOs at the ports of the BRAM, compared to the more bare bones BRAM_DUAL_PORT interface given by mkBRAMCore2.

The generated Verilog for 128 vs 256 looks exactly the same aside from the memsize parameter on the BRAM instantiation changing. I am not going to spend the time chasing this down right now given other priorities (DVT/PVT builds, compliance), so I'm opening this issue as a tracker for later.

Lingua principale
VHDL
Stelle
24
Fork
2
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di oxidecomputer/quartz

Tutte le issue di oxidecomputer/quartz

Issue simili

Altre issue su Build System

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.