std_logic ou std_ulogic?

24

Parece que o mundo decidiu que std_logic(e std_logic_vector) é a maneira padrão de representar bits em VHDL. A alternativa seria std_ulogic, o que não está resolvido.

Isso me surpreende porque, normalmente, você não está descrevendo um ônibus , então você não quer vários drivers e não precisa resolver um sinal. A vantagem std_ulogicseria que o compilador avisa desde o início se você tiver vários drivers.

Pergunta: isso é apenas uma coisa cultural / histórica, ou ainda existem razões técnicas para usar std_logic?

vhdl 
— Philippe
fonte
3
O mundo está errado. Os engenheiros inteligentes usam std_ulogic porque tem a semântica correta.
— Wjl 29/07
@wjl Vou interpretar isso como "é uma coisa cultural / histórica". Sua resposta abaixo é muito mais útil do que o comentário aqui em cima.
— Philippe
Escrevi o comentário primeiro e depois pensei que seria mais apropriado deixar uma resposta com mais detalhes. Desculpe, acho que parece um pouco irreverente. Mas meu comentário é literal: a maioria das pessoas começa a usar std_logic porque aprendeu dessa maneira; depois de um tempo, começa a se perguntar sobre std_ulogic, a procura, percebe a semântica e depois se converte. =)
— wjl

Respostas:

16

Std_logic é um subtipo de std_ulogic e possui exatamente uma propriedade extra: é resolvida se houver vários drivers.

Independentemente da prática comum, std_ulogic é o tipo correto a ser usado para sinais não resolvidos que precisam de lógica com 9 valores. (Geralmente, o uso de "bit" é ainda mais correto - por exemplo, em algumas arquiteturas FPGA que não possuem algo como 'X' ou 'U').

Basicamente, a melhor coisa a fazer é usar o tipo correto para o trabalho. Muitas vezes, as más práticas são propagadas por pessoas que apenas repetem o estilo que elas veem outros usam, sem entender o porquê.

— wjl
fonte
8
A arquitetura pode não ter um 'U', mas geralmente é útil simular como se tivesse, pois você pode encontrar inicializações incorretas. +1 para "a melhor coisa a fazer é usar o tipo correto para o trabalho", mas que tendem a aprender à medida que avançamos sobre o que é "melhor" :)
— Martin Thompson
8

Minha história é esta:

Comecei (por volta de 1999 IIRC) usando std_ulogic*o tempo todo - como é a coisa certa a fazer, pelas razões que você descreve.

Então eu tive que fazer interface com um monte de IP de fornecedor gerado pelo assistente, todos eles std_logicespalhados por toda a interface. O que significava conversões nos mapeamentos de portas (para os _vectorelementos), e fiquei preguiçoso e passei a usarstd_logic* .

No entanto, pareço cometer muito poucos erros de "motorista duplo", por isso não perdi std_ulogictanto quanto pensaria. E o driverscomando do Modelsim torna muito fácil encontrar "quem está dirigindo o quê" quando ocasionalmente preciso ...

— Martin Thompson
fonte
Sim, os núcleos IP (e especialmente as coisas que são traduzidas automaticamente do Verilog) tendem a usar std_logic. Sua resposta parece sugerir que o motivo é principalmente "cultural / histórico".
— Philippe
Você nunca precisa converter entre std_logic e std_ulogic nas portas. Você quis dizer que tinha que converter entre std_logic_vector e std_ulogic_vector?
— Wjl 29/07
@ wjl: desculpe, sim, foi isso que eu quis dizer. Vou atualizar a postagem.
— Martin Thompson
AFAIK, std_logic e std_ulogic são compatíveis com a atribuição, pois têm o mesmo tipo de base. Portanto, não deve haver necessidade de conversão manual.
— Val
@Val: Isso é o que WJL disse (e eu concordo com) -, mas as *vectorpartes de porta ainda precisa de conversões
— Martin Thompson
4

O IIRC recomenda o famoso Manual de Metodologia de Reutilização std_logic(_vector), portanto, talvez grupos de metodologia em empresas etc. se espalhem ainda mais na forma de guias de codificação (obrigatórios). Pessoalmente, +1 para usar std_ulogicquando possível.

— cmarqu
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.