Need a way to designate sim-only files from the local project
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- build-system, tooling
Direzione di ricerca
Inizia leggendo la configurazione delle librerie esterne in vw.toml e la direttiva di sintesi in hdl/nmu_inst_wrap.vhd, quindi confronta il modo in cui vengono individuate le sorgenti locali del progetto. Esamina i tre approcci proposti nell'issue prima di scegliere un design. Il lavoro è completato quando un progetto può contrassegnare chiaramente le sorgenti utilizzabili solo per la simulazione e selezionarle per la simulazione senza che le build di sintesi/FPGA le utilizzino.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
For testing, we want to have simulation-only entities in the same project that we swap for real IP in synthesis/FPGA build. One example of this is for testing/simulating the Versal NoC. We want to be able to swap between our own NMU/NSU entities (units for sending and receiving on the NoC) for simulation and the XPM IP cores for FPGA builds, because the XPM IP cores provided by Vivado require use of their simulator.
The only avenue to designate files sim-only at the moment is via bringing them in as an external library in vw.toml as we do here and then binding them via component with a synthesis directive as done here. This solution works if the IP has no dependence on any libraries other than the standard ones, but it is not the most clear that the entity itself is sim-only entity.
We briefly discussed and @rcgoodfellow suggested the following options:
• having some kind of marker at the top of a file like -- #vw(sim-only)
• having something in vw.toml
• having sim-only sources live in some particular subfolder by convention
- Lingua principale
- Rust
- Stelle
- 6
- Fork
- 1
- Merge medio
- 6h 31m
- PR unite (30g)
- 2
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di oxidecomputer/vw
-
simulation
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
oxidecomputer/vw#41 ·
-
bug cloud
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
oxidecomputer/vw#40 ·
-
bug htcl lsp
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
oxidecomputer/vw#35 ·
-
enhancement htcl
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
oxidecomputer/vw#34 ·
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
oxidecomputer/vw#29 ·
Tutte le issue di oxidecomputer/vw
Issue simili
-
defect
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
enhancement user-priority/P3
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno