¿Cuáles son sus principales consideraciones al escribir código HDL? ¿Crea una jerarquía adecuada? ¿Mantiene un diseño síncrono? ¿Registra sus entradas y salidas? Sugiera preocupaciones básicas. Encontrar buenos nombres para las cosas. Piense por un momento cómo sería su vida de codificación HDL si se tomara el tiempo de dar nombres distintos a las distintas E/S, señales, registros, módulos, etc.
¿Cuáles son sus principales consideraciones al escribir código HDL? ¿Crea una jerarquía adecuada? ¿Mantiene un diseño síncrono? ¿Registra sus entradas y salidas?
Yo sugeriría una preocupación más básica. Encuentra buenos nombres para las cosas.
Piense por un momento cómo sería su vida de codificación HDL si se tomara el tiempo de dar nombres distintos a las distintas E/S, señales, registros, módulos, etc.
• Escribirás mejor documentación.
El código HDL en sí mismo ayuda a contar la historia de cómo el diseño realiza su propósito previsto. Esto significa que los comentarios circundantes pueden enfocarse en comunicar por qué el diseño se construyó de la manera que es.
• Crear documentación menos explícita.
El nombre HDL ayuda a la documentación, por lo que en realidad se necesitan menos comentarios. Además, el “por qué” del diseño cambia con más frecuencia que el “cómo” de cómo funciona realmente, por lo que no es necesario actualizar estos comentarios cada vez que cambia el diseño.
• Menos errores.
Los errores encuentran su camino en el código, generalmente porque están confundidos acerca de lo que está haciendo el diseño. Un buen nombre transmite el significado del problema que el diseño intenta resolver, haciéndolo más fácil de recordar. De esa forma, puede gastar menos energía mental devolviendo variables al dominio del problema y más tiempo escribiendo el código correcto.
• Sesiones de depuración más sencillas.
Por la misma razón, los errores son más fáciles de rastrear y encontrar cuando el depurador muestra variables cuyos nombres se refieren directamente a elementos en el dominio del problema.
• Sus diseños se reutilizarán con más frecuencia.
Si un diseño es fácil de entender y cambiar, lo mismo ocurre con los demás, que son más propensos a utilizarlo.
Aquí hay otro ejemplo que muestra la importancia de nombrar. “El poder de los nombres de variables” en Code Complete es un 25 % más extenso que cualquier otro capítulo. Puede dejar de leer esto ahora e ir a leer ese capítulo, pero resumiré los puntos pertinentes para usted:
• Los nombres de las variables deben describir lo que representan.
Por ejemplo, heightOfAscent es un buen nombre para una variable de módulo de telemetría que registra la altitud actual del cohete. No es así para las variables llamadas h o (peor) x.
• Las variables deben referirse al dominio del problema, no a la implementación.
Por ejemplo, nombrar la variable heightCounter significa que la altitud del cohete se mantiene dentro del contador. Esto muestra cómo se calcula la altitud en el circuito, pero está sujeto a cambios si cambia la implementación del diseño. No es necesario cambiar el nombre de la variable si cambia la lógica. Peor aún, el nombre también puede proporcionar información engañosa sobre cómo funciona el diseño.
• Los nombres de las variables deben tener entre 10 y 16 caracteres.
Esto hace que la variable sea más fácil de entender sin dejar de transmitir significado (aunque extender esto a 8-20 caracteres es un poco peor). Por supuesto, los nombres de variables que describen dominios problemáticos pueden ser bastante largos (heightOfAscent ya tiene 14 caracteres). Por lo tanto, se deben emplear algunas técnicas para acortar variables, como eliminar vocales no principales (hghtOfAscnt) y eliminar artículos (hghtAscnt).
• Cuanto más amplio sea el alcance de la variable, más descriptivo debe ser el nombre.
Por ejemplo, un ciclo de generación corto podría usar i como índice, pero un bloque de código de 1000 líneas no lo haría (bueno, nada bueno para eso).
Además de los principios generales anteriores, también existen reglas sobre cómo se decoran los nombres en el código VHDL. Use letras mayúsculas y agregue sufijos para que pueda generar fácil y rápidamente nombres significativos y coherentes. También muestra de dónde proviene la señal y dónde se puede utilizar. Las reglas que uso son:
• Nombres de entidad, arquitectura, procedimiento, función, tipo: CamelCase con mayúscula inicial.
• Paquetes: CamelCase con mayúsculas al principio y Pckg al final.
• Instanciación de componentes: CamelCase que comienza con U.
• Constantes y genéricos: todo en mayúsculas, con un sufijo de subrayado y _C o _G.
• Señales y variables: CamelCase con primera letra minúscula y uno o más de los siguientes sufijos:
– _i: Puerto de entrada.
– _o: Puerto de salida.
– _s: Señales locales a la arquitectura.
– _v: variables locales al proceso.
– _b: Señal activa LOW (complementaria).
– _r: Valor del registro actual.
– _x: siguiente valor de registro después del borde del reloj.
– _a: Señal asíncrona.
– _d: Versión retardada de la señal.
– _e: Versión efectiva de la señal.
Para mostrar cómo se puede usar mi convención, aquí hay un ejemplo artificial de un módulo que integra la diferencia entre dos señales.
Los comentarios en el código muestran algunos lugares donde mi convención de nomenclatura es útil. Sin embargo, hay algunos lugares donde se rompe la convención.
• Usamos nombres breves y descriptivos para las entradas a_i y b_i. En mi defensa, no hay un buen nombre para estos, ya que este es solo un módulo para realizar cálculos de propósito general utilizados en algunas aplicaciones a gran escala. También traté de mitigar esto poniendo AminusB en el nombre de salida para indicar que estoy tratando con la diferencia entre estas dos entradas.
• La versión correcta de intgrlAminusB_r parecía bastante extraña y difícil de leer, violando el formato de nomenclatura CamelCase para algunas señales como intgrlAminusB_r.
Estas violaciones apuntan a la última y más importante convención de nomenclatura. Si encuentra lugares en los que su código está ofuscado, vulnerarlos o cambiar sus reglas para adaptarse a estas nuevas situaciones. No hay razón para que un esclavo se ciña a algún estándar si produce un código pobre.
Memorizar un nuevo conjunto de convenciones de nomenclatura puede ser difícil. Para ayudarme, creé un conjunto de macros para el editor Notepad ++ que genera automáticamente VHDL de acuerdo con las convenciones de nomenclatura. No recomiendo mis reglas a todo el mundo, pero quiero una convención rectora. Es posible que pueda modificar mis macros para adaptarlas a su entorno de diseño. Si tiene alguna adición o mejora en mente, háganoslo saber en los comentarios.