std_logic o std_ulogic?


24

Parece que el mundo ha decidido que std_logic(y std_logic_vector) son la forma predeterminada de representar bits en VHDL. La alternativa sería std_ulogic, que no está resuelta.

Esto me sorprende porque por lo general, estás no describir un bus , por lo que usted no quiere que los conductores múltiples y no es necesario para resolver una señal. La ventaja de std_ulogicesto sería que el compilador le advierte desde el principio si tiene varios controladores.

Pregunta: ¿es solo una cuestión cultural / histórica, o todavía hay razones técnicas para usar std_logic?


3
El mundo está equivocado. Los ingenieros inteligentes usan std_ulogic porque tiene la semántica correcta.
wjl

@wjl Interpretaré eso como "es una cosa cultural / histórica". Su respuesta a continuación es mucho más útil que el comentario aquí arriba.
Philippe

Primero escribí el comentario, luego pensé que sería más apropiado dejar una respuesta con más detalles. Lo siento, supongo que suena un poco frívolo. Pero mi comentario es literal en el sentido de que la mayoría de las personas comienzan a usar std_logic porque lo aprendieron de esa manera, luego de un tiempo comienzan a preguntarse sobre std_ulogic, lo buscan, se dan cuenta de que es semántica y luego se convierten a él. =)
wjl

Respuestas:


16

Std_logic es un subtipo de std_ulogic y tiene exactamente una propiedad adicional: se resuelve si hay varios controladores.

Independientemente de la práctica común, std_ulogic es el tipo correcto para usar para señales no resueltas que necesitan lógica de 9 valores. (A menudo, usar "bit" es aún más correcto, por ejemplo, en algunas arquitecturas FPGA que no tienen una 'X' o una 'U').

Básicamente, lo mejor que puede hacer es usar el tipo correcto para el trabajo. A menudo, las malas prácticas se propagan por personas que simplemente repiten el estilo que ven que otros usan, sin entender por qué.


8
Es posible que la arquitectura no tenga una 'U', pero a menudo es útil simular como si lo hiciera, ya que puede encontrar inicializaciones incorrectas. +1 para "lo mejor que se puede hacer es usar el tipo correcto para el trabajo", pero tendemos a aprender a medida que avanzamos sobre lo que es "mejor" :)
Martin Thompson

8

Mi historia es esta:

Comencé (aproximadamente en 1999 IIRC) usando std_ulogic* todo el tiempo, ya que es lo correcto, solo por las razones que usted describe.

Luego tuve que conectarme a un grupo de IP de proveedor generadas por asistente que todas tenían en std_logictoda la interfaz. Lo que significaba conversiones en las asignaciones de puertos (para los _vectorelementos), y me volví perezoso y pasé a usarstd_logic* .

Sin embargo, parece que cometo muy pocos errores de "doble conductor", así que no me he perdido std_ulogictanto como hubiera pensado. Y el driverscomando de Modelsim hace que sea muy fácil encontrar "quién conduce qué" cuando ocasionalmente necesito ...


Sí, los núcleos IP (y especialmente las cosas que se traducen automáticamente de Verilog) tienden a usar std_logic. Su respuesta parece sugerir que la razón es principalmente "cultural / histórica".
Philippe

Nunca tiene que convertir entre std_logic y std_ulogic en los puertos. ¿Quiso decir que tenía que convertir entre std_logic_vector y std_ulogic_vector?
wjl

@wjl: lo siento, sí, eso es lo que quise decir. Actualizaré la publicación.
Martin Thompson

AFAIK, std_logic y std_ulogic son compatibles con la asignación, ya que tienen el mismo tipo base. Por lo tanto, no debería haber necesidad de conversión manual.
Val

@Val: eso es lo que dijo wjl (y estoy de acuerdo), pero las *vectorpartes del puerto todavía necesitan conversiones
Martin Thompson

4

IIRC recomendó el famoso Manual de Metodología de Reutilización std_logic(_vector), por lo que tal vez los grupos de metodología en empresas, etc., lo difundieron aún más en forma de guías de codificación (obligatorias). Personalmente, +1 por usar std_ulogiccuando sea posible.


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.