std_logic o std_ulogic?


24

Sembra che il mondo abbia deciso che std_logic(e std_logic_vector) sono il modo predefinito di rappresentare i bit in VHDL. L'alternativa sarebbe std_ulogic, che non è stata risolta.

Questo mi sorprende, perché di solito, si sta non descrive un bus , in modo da fare non si vuole più driver e non è necessario per risolvere un segnale. Il vantaggio di std_ulogicsarebbe che il compilatore ti avvisa in anticipo se hai più driver.

Domanda: è solo una questione storico / culturale o ci sono ancora ragioni tecniche per usare std_logic?


3
Il mondo è sbagliato. Gli ingegneri intelligenti usano std_ulogic come perché ha la semantica corretta.
WJL

@wjl lo interpreterò come "è una cosa storico / culturale". La tua risposta di seguito è molto più utile del commento qui sopra.
Philippe,

Ho scritto prima il commento, poi ho pensato che sarebbe stato più appropriato lasciare una risposta con più specifici. Mi dispiace, immagino che sembri un po 'irriverente. Ma il mio commento è letterale in quanto la maggior parte delle persone inizia a usare std_logic perché l'hanno imparato in quel modo, poi dopo un po 'iniziano a chiedersi di std_ulogic, lo guardano, si rendono conto della sua semantica e poi si convertono in esso. =)
wjl

Risposte:


16

Std_logic è un sottotipo di std_ulogic e ha esattamente una proprietà in più: si risolve se ci sono più driver.

Indipendentemente dalla pratica comune, std_ulogic è il tipo corretto da utilizzare per segnali non risolti che richiedono una logica a 9 valori. (Spesso, usare "bit" è ancora più corretto, ad esempio su alcune architetture FPGA che non hanno una "X" o una "U").

Fondamentalmente, la cosa migliore da fare è usare il tipo corretto per il lavoro. Spesso le cattive pratiche vengono propagate dalle persone semplicemente pappagallo nello stile che vedono usare gli altri, senza capire perché.


8
L'architettura potrebbe non avere una "U", ma è spesso utile simulare come se fosse possibile poiché è possibile trovare inizializzazioni errate. +1 per "la cosa migliore da fare è usare il tipo corretto per il lavoro", ma tendiamo a imparare mentre andiamo avanti su ciò che è "migliore" :)
Martin Thompson,

8

La mia storia è questa:

Ho iniziato (all'incirca nel IIRC del 1999) usando std_ulogic*tutto il tempo - poiché è la cosa giusta da fare, solo per i motivi che descrivi.

Quindi ho dovuto interfacciarmi con un gruppo di IP generatori generati da procedura guidata che avevano std_logictutti su tutta l'interfaccia. Il che significava conversioni sui port-mapping (per gli _vectorelementi), e sono diventato pigro e sono passato all'utilizzo std_logic*.

Tuttavia, mi sembra di commettere pochissimi errori di "doppio pilota", quindi non mi sono perso std_ulogicquanto avrei pensato. E il driverscomando di Modelsim rende molto facile trovare "chi sta guidando cosa" quando lo faccio ogni tanto devo ...


Sì, i core IP (e specialmente i contenuti tradotti automaticamente da Verilog) tendono a usare std_logic. La tua risposta sembra suggerire che il motivo sia principalmente "culturale / storico".
Philippe,

Non devi mai convertire tra std_logic e std_ulogic sulle porte. Volevi dire che dovevi convertire tra std_logic_vector e std_ulogic_vector?
wjl

@wjl: scusa, sì, è quello che volevo dire. Aggiornerò il post.
Martin Thompson,

AFAIK, std_logic e std_ulogic sono compatibili con le assegnazioni poiché hanno lo stesso tipo di base. Pertanto, non dovrebbe essere necessario eseguire la conversione manuale.
Val

@Val: questo è ciò che Wjl ha detto (e sono d'accordo) - ma le *vectorparti della porta hanno ancora bisogno di conversioni
Martin Thompson

4

Consigliato IIRC il famoso Manuale di metodologia di riutilizzo std_logic(_vector), quindi forse gruppi di metodologia nelle aziende ecc. Lo diffondono ulteriormente sotto forma di guide di codifica (obbligatorie). Personalmente, +1 per l'utilizzo std_ulogicquando possibile.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.