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
- 7
- 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
-
bug cloud simulation
Difficoltà 3/5 Mezza giornata Idoneità per principianti 54/100
oxidecomputer/vw#44 ·
-
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 ·
Tutte le issue di oxidecomputer/vw
Issue simili
-
build: Update rust versionForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertadependencies
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
ibm-granite-community/granite-cli#229 ·
I maintainer di solito rispondono entro 1 giorno
-
setTargetAtTime booked ahead of time starts its curve early (values blow up before start_time)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
orottier/web-audio-api-rs#658 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
aosama/astronomical#1318 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
shep-pm/shep-kelpie#980 ·
I maintainer di solito rispondono entro 1 giorno