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

Indexing order for 3D `integer_array_t` doesn't make sense

Aperta
  • Qualcosa non va?
#1,011 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
30/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Ambito
backend

Direzione di ricerca

Start with integer_array_pkg-body.vhd at the linked 3D and 2D get implementations, then inspect set and the reshape behavior mentioned in the issue. Determine the indexing order that preserves 2D consistency and gives sensible results after reshaping; done means the 3D indexing behavior is defined, tested, and documented. The issue has had no comments for 895 days.

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

Descrizione

The indexing order for the 3D version of integer_array_t doesn't make any sense. You can see the code for get here:

https://github.com/VUnit/vunit/blob/3032da050f11bdf038053f67fc664c39ee19f9f6/vunit/vhdl/data_types/src/integer_array_pkg-body.vhd#L219

y is multiplied by both width and depth, x is only multiplied by depth, and z isn't multiplied by anything.

The indexing of get is consistent with set, which is why it hasn't been caught until now. The problem comes when you try to index after a reshape, which is how I discovered the problem. If you reshape a 3D array into a 2D array, you can't get results that make sense.

The "obvious" solution would be

< return get(arr.data, (y*arr.width + x)*arr.depth + z);
---
> return get(arr.data, (x*arr.width + y)*arr.depth + z);

But this solution would end up inconsistent with the 2D version of get:

https://github.com/VUnit/vunit/blob/3032da050f11bdf038053f67fc664c39ee19f9f6/vunit/vhdl/data_types/src/integer_array_pkg-body.vhd#L208

I'm not really sure what to do here. It seems like the change that would be least likely to break existing code would be

return get(arr.data, (z*arr.depth + y)*arr.width + x);

since that is consistent with the existing indexing order for 2D arrays.

Has anyone ever decided whether integer_array_t stores data in row-major or column-major order? The indexing for 2D arrays suggests column-major, but that goes against C and Python. It seems like that is something that should be documented and guaranteed.

Lingua principale
VHDL
Stelle
850
Fork
305
Merge medio
2g 10h
PR unite (30g)
7

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 VUnit/vunit

Tutte le issue di VUnit/vunit

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.