Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

BRAM synthesis bug?

Abierto
  • ¿Algo no está bien?
#55 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Estancado
Área
build-system, embedded-iot

Línea de trabajo

Comienza con los puntos de entrada BRAM2Port/mkBRAM2Server y BRAM_DUAL_PORT/mkBRAMCore2, y después compara la síntesis de las BRAMs de escritura de 128 y 256 entradas. Reproduce la discrepancia con y sin la propiedad -nolutram, comparando la simulación, el Verilog generado y el bitfile resultante. Se considera terminado cuando se haya identificado y corregido la causa en la síntesis o la configuración, y la ruta de escritura funcione con el tamaño mayor.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
VHDL
Estrellas
24
Forks
2
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de oxidecomputer/quartz

Todos los issues de oxidecomputer/quartz

Issues similares

Más issues de Build System

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.