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.