¿Cuál es la motivación al usar Verilog o VHDL sobre C?

12

Vengo de un fondo de programación y no me metí demasiado con el hardware o el firmware (a lo sumo un poco de electrónica y Arduino).

¿Cuál es la motivación al usar lenguajes de descripción de hardware (HDL) como Verilog y VHDL sobre los lenguajes de programación como C o algunos ensamblajes?

¿Es esta cuestión una cuestión de elección?

Leí que el hardware, cuyo firmware está escrito en un HDL, tiene una clara ventaja al ejecutar instrucciones en paralelo. Sin embargo, me sorprendió ver discusiones que expresaban dudas acerca de si escribir firmware en C o ensamblado (¿cómo es apropiado ensamblar si no necesariamente tiene una CPU?) Pero concluí que también es una opción.

Por lo tanto, tengo algunas preguntas (no dudes en explicar nada):

  1. ¿Un firmware realmente se puede escribir en HDL o en un lenguaje de programación de software, o es simplemente otra forma de realizar la misma misión? Me encantaría ver ejemplos del mundo real. ¿Qué restricciones resultan de cada opción?

  2. Sé que un uso común del firmware sobre el software es en los aceleradores de hardware (como GPU, adaptadores de red, aceleradores SSL, etc.). Según tengo entendido, esta aceleración no siempre es necesaria, sino que solo se recomienda (por ejemplo, en el caso de SSL y la aceleración de algoritmos complejos). ¿Se puede elegir entre firmware y software en todos los casos? De lo contrario, me agradaría ver casos en los que el firmware es claro e inequívocamente apropiado.

  3. He leído que el firmware se grabó principalmente en ROM o flash. ¿Cómo se representa allí? ¿En bits, como el software? Si es así, ¿cuál es la profunda diferencia? ¿Es la disponibilidad de circuitos adaptados en el caso del firmware?

Supongo que cometí un error aquí y allá en algunas suposiciones, por favor perdóname. ¡Gracias!

Reflexión
fuente
14
Los lenguajes de programación son para describir software, los lenguajes de descripción de hardware son para describir hardware.
Ignacio Vazquez-Abrams
1
No escribe firmware con Verilog o VHDL: usa Verilog o VHDL para diseñar chips, programar FPGA y diseñar placas base. Utiliza C o ensamblaje para escribir el firmware. También puede usar C / C ++ para diseñar placas base: hay una biblioteca llamada SystemC que puede ser compilada por un compilador de C para crear un programa que simule su diseño, pero también puede ser compilado por un compilador de SystemC en circuitos.
slebetman
FWIW, ya que tienes experiencia en Arduino, el software de escritura para un Arduino se llama firmware de escritura. Firmware puede ser sistemas operativos completos - Linux, por ejemplo, se utiliza en el firmware de la mayoría de los routers y Windows se utiliza en el firmware de la mayoría de los cajeros automáticos
slebetman

Respuestas:

28

¿Cuál es la motivación al usar lenguajes de descripción de hardware (HDL) como Verilog y VHDL sobre los lenguajes de programación como C o algunos ensamblajes?

C y ensamblado son buenos lenguajes para decirle a una CPU qué hacer. Describen las acciones que debe realizar secuencialmente una sola máquina de estado.

Las HDL son buenos lenguajes para describir o definir una colección arbitraria de circuitos digitales. Pueden expresar operaciones realizadas en paralelo de formas que los lenguajes de programación no pueden. También pueden describir las limitaciones de tiempo para las interfaces entre bloques de formas que los lenguajes de programación no pueden.

Me sorprendió ver discusiones que expresaban dudas sobre si escribir firmware en C o Assembly (¿cómo es apropiado el ensamblaje si no necesariamente tiene una CPU?)

En esa pregunta, lo que se pregunta es: "Si está escribiendo código para un microcontrolador, ¿hay alguna diferencia real si escribe en ensamblador o en C o en algún otro lenguaje de alto nivel?".

Dado que está preguntando específicamente sobre los sistemas con un microcontrolador (una CPU con periféricos), C o ensamblaje son opciones razonables para el desarrollo de la primera guerra, y las HDL no lo son.

¿Un firmware realmente se puede escribir en HDL o en un lenguaje de programación de software, o es simplemente otra forma de realizar la misma misión?

Depende del tipo de hardware que tenga. Si tiene una CPU, use un lenguaje de programación. Si tiene un FPGA o está diseñando un ASIC, use un HDL. Si está diseñando una gran cantidad de lógica digital, puede buscar uno de los idiomas intermedios como SystemVerilog.

He leído que el firmware se grabó principalmente en ROM o flash. ¿Cómo se representa allí? ¿En bits, como el software? Si es así, ¿cuál es la profunda diferencia? ¿Es la disponibilidad de circuitos adaptados en el caso del firmware?

Creo que te estás quedando atrapado en el término "firmware". Esta palabra originalmente significaba que el código se ejecutaba en un sistema incrustado, al que el usuario final no podía cambiar. Si le vendió una PC a alguien, hay muchas posibilidades de que el usuario cambie el software que se ejecuta en ella. Si les vendió un osciloscopio, no querrá que cambien el código que se ejecuta en el microprocesador interno, por lo que lo llamó firmware.

Los usuarios de FPGA se apropiaron de la palabra "firmware" para la salida de sus diseños, porque es más cambiante que el hardware (material que se suelda). Pero realmente el "firmware" que configura un FPGA es diferente del "firmware" que se ejecuta en un uC. El firmware de uC dirige la uC a través de una serie de estados para realizar su función. El firmware FPGA define un conjunto de interconexiones entre elementos lógicos y valores que se almacenarán en tablas de búsqueda.

En cualquier caso, el firmware generalmente se almacena como bits en un eeprom (o en un disco en una máquina host que no lo descargará cada vez que se reinicie el sistema integrado). Pero eso no los hace similares entre sí.

El fotón
fuente
Cuando escribe en VHDL / Verilog, es mucho más fácil visualizar la lógica que se implementará y, por lo tanto, optimizar. No se puede decir lo mismo de C. Incluso el SystemC todavía está lo suficientemente divorciado de la implementación física real como para que se produzcan resultados inesperados de síntesis
JonRB
@ JonRB, si estás codificando para un uC o uP, en realidad no conozco ninguna forma de hacerlo con un HDL. Estoy de acuerdo en que cuando se codifica la lógica, SystemVerilog o SystemC son para sistemas que son tan grandes que simplemente no es práctico tratar de diseñar todo a nivel de puerta individual.
El Photon
2
Tenga en cuenta que VHDL y Verilog también se usan cuando no tiene ningún hardware. Se pueden compilar directamente en circuitos en lugar de flujo de bits FPGA. Apple, por ejemplo, solía diseñar sus placas base usando Verilog en lugar de la captura esquemática de la GUI, ya que hay un mejor soporte para el control de versiones, grepping y simplemente análisis mediante scripts cuando su diseño es texto plano en lugar de dibujos binarios patentados.
slebetman
10

Para la primera parte de su pregunta, sobre las motivaciones del uso de uno u otro: hay una diferencia fundamental entre C y HDL (VHDL / Verilog) . C es un lenguaje de programación de software (como lo es el ensamblado), VHDL / Verilog son lenguajes de descripción de hardware . No están destinados para el mismo propósito.

C se traduce en código ensamblador (en su forma binaria, es decir, lenguaje de máquina) cuando se compila . Este código es una serie de instrucciones que le indican a la CPU que realice una serie de operaciones básicas (cambiar un valor de registro, realizar una suma, etc.).

Por otro lado, un HDL se sintetiza en hardware. En VHDL, por ejemplo, podría escribir algo como:

output <= input1 + input2;

(Ver también un ejemplo más completo aquí ). Esto se sintetizaría en un sumador (hardware). Si el código se sintetiza para un FPGA , esto significaría un flujo de bits que puede configurar el FPGA específico para implementar un sumador (como lógica combinacional ).

En realidad, podría diseñar una CPU en VHDL (consulte Procesadores de núcleo blando VS Procesadores de núcleo duro ), y escribir el software en C ...

Sobre el firmware: en realidad todo depende de cómo se defina la palabra. Un firmware puede ser un programa (software) que se ejecuta en un microcontrolador (escrito así, por ejemplo, en C o ensamblador), o puede ser un flujo de bits para configurar un dispositivo lógico programable (hardware) (CPLD o FPGA). A veces puede ser un paquete que contiene ambos: si toma el firmware para algunos modelos de FritzBox (un módem ADSL), en realidad contienen un sistema Linux completo (escrito en ensamblador, C y muchos otros lenguajes de programación) y un flujo de bits para configurar un FPGA (probablemente sintetizado desde VHDL o Verilog).

Cerveza inglesa
fuente
3
  1. Depende de tu arquitectura. Si tiene una CPU (o, por lo general, un microcontrolador), debe escribir el firmware en un lenguaje de programación regular (incluido el ensamblaje). Si tiene algo como un FPGA, su firmware debe estar escrito en un HDL. Los HDL no pueden (que yo sepa) generar programas que puedan ser ejecutados eficientemente por una CPU convencional, y un FPGA no ejecuta programas convencionales listos para usar. Sin embargo, podría configurar su FPGA como una CPU y luego ejecutar un programa convencional con eso. Esto requeriría dos capas de firmware, la capa inferior escrita en un HDL para construir la CPU, y la capa superior escrita en un lenguaje de programación convencional para ejecutarse en esa CPU.
  2. No existe una distinción clara entre firmware y software. En muchos dispositivos, el firmware se almacenaría en, por ejemplo, memoria flash, pero en un teléfono moderno, casi todo se almacena en la memoria flash, y la distinción entre firmware y software no está clara (la mayoría de las personas probablemente considerarían el código para programar el firmware del procesador de banda base , y la mayoría de la gente consideraría el software de programas de aplicación, pero ¿dónde está el límite exacto?
  3. Como dije en 2, no hay una distinción clara, aparte de la idea de que el firmware es un poco más permanente.
microtherion
fuente
3

La concurrencia de hardware es una gran motivación.

Los electrones pueden fluir al mismo tiempo en cables paralelos, por lo que queremos tener eso en cuenta al diseñar el hardware.

En VHDL, si escribe algo como:

x <= a or b;
y <= a and b;
z <= x xor y;

(fuera de un processo function, que lo marca explícitamente como secuencial), entonces ha codificado el hecho de que:

  • x, y, z, aY bson alambres
  • ay bson señales de entrada
  • xestá conectado a la salida de un orcircuito, que toma ay bcomo entrada
  • y así sucesivamente para las otras líneas

Es fácil ver cómo se sintetizará en el hardware real, y eso xy yevaluarlo al mismo tiempo.

        +-----+
A--+----+     |  X
   |    | OR  +-----+
B----+--+     |     |  +-----+
   | |  +-----+     +--+     |
   | |                 | XOR +-- Z
   | |  +-----+     +--+     |
   | +--+     |  Y  |  +-----+
   |    | AND +-----+
   +----+     |
        +-----+

Luego, cuando es hora de simular el circuito, el simulador (que generalmente es un programa secuencial) simula la física del circuito de esta manera:

  • ha ao bcambiado? ¿Si? Hey, xdepende a. Vamos a actualizar x.
  • yTambién depende a. Actualiza eso también.
  • zdepende x. Actualízalo porque xse actualizó.
  • ¿Se ha actualizado algo que xdependa de ( ao b)? ¿No? Lo mismo para yy z. OK, hemos terminado con este paso.

Esto lleva a posibles resultados "interesantes" que no tienen un análogo secuencial, pero que representan posibles situaciones físicas:

  • x <= not xconduciría a una recursión infinita de la simulación. Los simuladores pueden simplemente cortar después de cierta profundidad.
  • x <= 0; x <= 1conduce a un error (cortocircuito). Esta es una de las razones por las cuales std_logicexiste.

Aún así, a pesar de que VHDL modela el hardware más de cerca que C, no es en sí una descripción perfectamente detallada:

Al final, VHDL proporciona un buen equilibrio entre la funcionalidad de circuito comprensible para humanos de nivel superior y la capacidad de sintetización de nivel inferior.

C, por otro lado, está más enfocado en hablar con la CPU secuencialmente.

Por supuesto, podría codificar un circuito con estructuras C, enumeraciones y matrices, y luego simularlo como lo hace VHDL (esto se parece más o menos a lo que hace el Sistema C , pero nunca lo he intentado).

Pero esencialmente volvería a implementar un simulador VHDL y con un lenguaje más detallado. Herramienta adecuada para el trabajo correcto, supongo.

También hay herramientas que convierten C a VHDL /programming/8988629/can-you-program-fpgas-in-c-like-languages pero esperan un rendimiento más bajo ya que esas son conversiones difíciles de alto nivel.

Ciro Santilli 新疆 改造 中心 法轮功 六四 事件
fuente
0

Las HDL se usan para describir (sintetizar) hardware donde, como lenguaje de programación, se usa para programar el hardware ya sintetizado, es decir, la CPU.

Puede obtener versiones de cpus de núcleo blando como VHDL o bitstream para sintetizar esa CPU en un FPGA.

chintu
fuente
-1

Un procesador usa una cantidad modesta de circuitos para realizar una gran cantidad de operaciones, secuencialmente, al permitir que la mayoría de los componentes se usen para realizar diferentes operaciones en diferentes momentos.

Un FPGA contiene varios circuitos que no pueden, al menos individualmente, realizar operaciones particularmente sofisticadas, pero que son capaces de actuar de manera simultánea e independiente.

Supongamos que uno quiere tener un chip que realice una serie de tareas, entre las cuales se encuentran monitorear 15 entradas y:

  • Establecer una salida alta en cualquier momento en que todas las entradas hayan sido estables durante al menos 21 ms y el número de entradas que es alto es un múltiplo de tres
  • Establecer la salida baja en cualquier momento todas las entradas han sido estables durante al menos 21 ms y el número de entradas que es alto no es un múltiplo de tres
  • Cambiar la salida de manera arbitraria entre el momento en que cambia cualquier entrada y el tiempo en que todas las entradas han estado estables durante al menos 20 ms.

Si uno tiene un microcontrolador que está haciendo otras cosas, pero puede ahorrar unos microsegundos cada 20 ms para examinar esas entradas y configurar la salida, entonces la mayoría de los circuitos que utiliza el microcontrolador para realizar otras tareas también serán utilizables para realizar la tarea indicada arriba, por lo que se necesitará dedicar muy poca circuitería (aparte de algo de ROM y quizás RAM) a esa tarea. Por otro lado, puede llevar un tiempo entre el momento en que cambia una entrada y el tiempo en que la salida lo refleja correctamente.

Usando Verilog o VHDL, uno podría construir un circuito de hardware que pudiera monitorear continuamente las 15 entradas y realizar el cálculo indicado. Tal dispositivo probablemente podría hacer que la salida produzca una indicación correcta dentro de 100ns, órdenes de magnitud más rápidas que el microcontrolador, pero la cantidad de circuitos dedicados a esa tarea e inutilizables para cualquier otro propósito sería mucho mayor.

Super gato
fuente
Esto no parece ser un ejemplo particularmente claro para ilustrar una distinción: hay suficientes puntos discutibles en sus detalles que realmente no pueden ayudar a familiarizar a alguien que aún no está familiarizado. Alguien que se enfrente de manera realista a este problema probablemente elegiría una MCU moderna con una palabra de datos amplia y buenas interrupciones de cambio de pin. Decidir qué solución está consumiendo más lógica requeriría decidir si cuenta los numerosos periféricos no utilizados en la MCU o las rebanadas sin tocar en la FPGA. El primero será bastante más barato.
Chris Stratton
@ChrisStratton: ¿Quizás debería haber sugerido que las cosas pueden cambiar si los requisitos de tiempo se vuelven más estrictos? Requerir que una CPU tenga unos pocos microsegundos disponibles cada 20 ms puede no requerir ningún cambio en un sistema subyacente, pero si el tiempo de respuesta debe ser de 200 us, tal requisito podría requerir una CPU más rápida de lo que sería necesaria, si fuera necesario. bajo 20us, puede ser necesario agregar una CPU adicional solo para manejarlo, y si es menor de 200ns puede ser imposible lograrlo con una CPU.
supercat
Eso es porque no estás aprovechando las capacidades de la MCU. En la interrupción de cambio de pin, inicie un bloque de temporizador de hardware que establecerá la salida 20 ms más tarde. Luego decida, sin prisa, si eso realmente está justificado, y si no, cancélelo. Realmente no es un gran ejemplo para hacer que su FPGA apunte porque hay mucha interdependencia: la única parte que realmente se ejecuta en paralelo es la detección de eventos, y una MCU moderna ya le brinda eso en hardware en gran parte paralelo. Mientras tanto, el resto es efectivamente secuencial, ¿entonces construyes una máquina de estado ultra rápida que mira un reloj muy lento?
Chris Stratton
@ChrisStratton: si existe una función adecuada de interrupción de cambio de clavija y no se está utilizando para otra cosa, eso puede evitar la necesidad de un sondeo constante, pero si suceden muchas cosas a la vez, deberán procesarse secuencialmente a cualquier velocidad la CPU puede manejarlos.
supercat
El procesamiento secuencial no es un problema dado el gran retraso que impone la declaración del problema entre la entrada y la respuesta. E incluso si el MCU actual estuviera demasiado ocupado, agregar uno para este propósito sería una fracción del costo de agregar un FPGA. Siendo realistas, la única forma en que este problema se resuelve en un FPGA es porque ya hay uno con rebanadas de repuesto y las señales enviadas a él, o como un proyecto artificial en un contexto educativo o de pasatiempo.
Chris Stratton