VHDL - ¿Cuándo es un bloque de proceso demasiado largo? [cerrado]

Fundamentalmente, la única restricción real para esto es el TIEMPO.

Uno podría poner un límite arbitrario en la lista de sensibilidad (personalmente yo siempre presionaría CLK y RST solo en la lista de sensibilidad para asegurar una operación síncrona)

Uno podría poner un límite arbitrario en el SLOC, pero este es un estilo personal o un esquema de la empresa

Uno podría poner mérito en la reutilización y, por lo tanto, abogar por procesos que hacen un trabajo específico realmente bien y configurable a través de genéricos, PERO de nuevo el estilo personal o el esquema de la compañía

... número de IN / OUT en una entidad ... estilo, esquema

... adherencia a algún proceso como DO254 con respecto a la auditoría de código ... estilo, esquema

Al final del día, lo que se escribe debe sintetizarse y enrutarse. Si el código que se escribe produce una cadena de lógica serializada, de modo que el tiempo de propagación no se complete para cuando llegue el próximo reloj, habrá problemas.

Siempre presionaría entidades pequeñas, solo clk-rst en sensibilidad, etc., como la mejor práctica para su reutilización y auditoría, pero fundamentalmente si viola las restricciones de tiempo de configuración & espera, realmente no importa cómo codifiques porque no funcionará

El código es demasiado largo si encuentra que cuando necesita encontrar una parte específica del mismo (por ejemplo, para realizar un cambio o para verificar exactamente lo que hace) se tarda más de unos minutos en localizarlo. Como la mayoría de los lenguajes de alto nivel, VHDL proporciona muchas formas que se pueden usar para dividir un bloque grande de código en módulos más pequeños; úsalos cuando comiences a encontrar que es difícil navegar.

Mientras el código no sea complejo, podría ser largo. De hecho, la complejidad es igual a un error o, al menos, a una capacidad de mantenimiento baja. Es cierto para el software y HDLs. En ingeniería de software hay una métrica con el nombre Halstead. en esta métrica, puede tener un número estimado de errores de su código. Esta métrica funciona según el número de John Stroud (un psicólogo). el número de Stroud para ingenieros informáticos se establece en 18 (el máximo es 20) y significa que si tenía un código con más de 18 fichas, probablemente había cometido un error en algún lugar. El número de Stroud ha sido extraído de las capacidades naturales del cerebro humano. por lo tanto, existen las mismas limitaciones para hacer HDL hechas por el hombre. Las métricas basadas en el número de Stroud se usan para estimar el tiempo del proyecto. La siguiente tesis podría ser un poco útil. enlace

No hay un número fijo para determinar si un bloque de código es demasiado grande o no. En general trato de separar distintas funcionalidades en diferentes procesos. Significa que tengo un proceso para la sincronización de la señal, tal vez uno para la funcionalidad del contador, uno para la máquina de estado. Por otro lado, especialmente el proceso que contiene la máquina de estadísticas puede tener varios cientos de líneas de código. Por supuesto, aquí tiene diferentes enfoques, a algunos les gusta dividirlos en un proceso next_state que solo evalúa los estados y un proceso signal que aplica el estado de señal correspondiente a cada estado de la máquina de estados ... pero eso es diferente tema.

En pocas palabras, todo se trata de mantenimiento, si el proceso se divide en secciones claras (como una máquina de estados), puede ser mucho más grande antes de que sea ilegible que si tiene un proceso que "solo" hace alguna señal. manipulación.

Además, puede aumentar la legibilidad y la capacidad de mantenimiento con el uso de comentarios significativos y nombres de señales autoexplicativos.

El libro está equivocado, pero no en el sentido de que los procesos largos deberían ser aceptables, es simplemente que los procesos múltiples que se comunican entre sí son aún más difíciles de depurar (tenga en cuenta que hay algunos paradigmas para escribir VHDL, soy un Defensor del estilo de proceso único, hay algunas personas que prefieren el estilo de los dos procesos por buenas razones, no hay nadie que valga la pena que necesite o necesite usar más de dos procesos para un módulo de un solo reloj).

Lo que es cierto es que si tiene un proceso largo, probablemente podría dividir las porciones recurrentes en funciones y procedimientos (preferiblemente puros). Probablemente definido en la parte de declaración del proceso, pero las funciones podrían / deberían estar en paquetes externos.

Aspectos negativos del uso de múltiples procesos:

• Las listas de sensibilidad se vuelven repentinamente relevantes, los principiantes ni siquiera hacen bien sus listas de sensibilidad con solo unos pocos procesos
• Algunas herramientas de simulación combinan todos los procesos con listas de sensibilidad equivalentes, por lo que su vista en el simulador ya no es lo mismo que lo que escribió en el código
• Los canales de comunicación entre sus procesos serán señales, lo que disminuye su velocidad de simulación. En un solo proceso, puede hacer todo con variables, lo que hace que el código sea más fácil de leer: las asignaciones no se programan, pero ocurren donde usted cree que serán
• Relacionado con el punto anterior, es que el cambio de código inevitablemente terminará con múltiples controladores o código de espagueti: 3 procesos cada uno irán a su antojo e impulsarán sus señales designadas, ahora una especificación cambia y una decisión en el proceso 1 debe influir la conducción de una señal en el proceso dos: ahora tiene varios controladores (imposible) o tiene que introducir una comunicación extra entre los procesos (espagueti). Con un proceso, introduce una sobrescritura de la señal de salida y se infiere un mux limpio.

La única razón para usar más de 2 procesos por módulo es si tiene varios relojes, en cuyo caso usted termina con uno o dos procesos por reloj (dependiendo del estilo que use), utilizando señales sincronizadas para comunicarse entre el reloj. dominios.

En general, me gusta mantener un proceso en una función particular, especialmente cuando se escribe para síntesis. No he escrito VHDL durante varios años, y las herramientas de síntesis de entonces necesitaban ayuda para optimizar diseños elaborados. Además, me gusta que un bloque de proceso represente un bloque esquemático (desde el pasado en el que las personas dibujaban esquemas). Sospecho que a medida que avanzan las herramientas de síntesis y simulación, puede que se convierta en un problema más estilístico, pero mi regla general para el código secuencial o HDL es que cuando lo está depurando, si está viendo un bloque y descartando partes de como no relacionado con su problema, ese bloque debe ser al menos dos bloques diferentes.