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

  

¿Cuál es la motivación de usar lenguajes de descripción de hardware (HDL) como Verilog y VHDL en lenguajes de programación como C o algún ensamblado?

C y ensamblaje son buenos idiomas para decirle a la CPU qué hacer. Describen las acciones que deben realizarse secuencialmente por una sola máquina de estado.

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

  

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

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

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

  

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

Depende del tipo de hardware que tengas. Si tienes una CPU, usa 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 consultar uno de los idiomas intermedios, como SystemVerilog.

  

He leído que el firmware se quema 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 de firmware?

Creo que te estás quedando colgado con el término "firmware". Esta palabra originalmente significaba que el código se ejecutaba en un sistema integrado, que no era accesible para que lo cambiara el usuario final. Si le vendió una PC a alguien, existe una gran posibilidad de que el usuario cambie el software que se ejecuta en ella. Si les vendiera un osciloscopio, no querría que cambiaran 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 variable que el hardware (cosas que se sueldan). Pero realmente el "firmware" que configura un FPGA es diferente del "firmware" que se ejecuta en una unidad de control de usuario. 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 los valores que se almacenarán en las tablas de consulta.

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

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

C se traduce en código de ensamblaje (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 adición, etc.).

Por otro lado, un HDL se sintetiza en el hardware. En VHDL, por ejemplo, puedes escribir algo como:

output <= input1 + input2;

(vea 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 núcleo blando Processors vs Hard core Processors ), y escriba el software para él en C ...

Sobre el firmware: en realidad, todo depende de cómo se define la palabra. Un firmware puede ser un programa (software) que se ejecuta en un microcontrolador (escrito, 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 contenga 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 configure un FPGA (probablemente sintetizado a partir de VHDL o Verilog).

1. Depende de tu arquitectura. Si tiene una CPU (o, típicamente, un microcontrolador), necesita 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 (a mi entender) generar programas que puedan ejecutarse de manera eficiente mediante una CPU convencional, y un FPGA no ejecuta programas convencionales de manera inmediata. 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 estricta entre el firmware y el software. En muchos dispositivos, el firmware se almacenaría en, por ejemplo, memoria flash, pero en un teléfono moderno, casi todo está almacenado en la memoria flash, y la distinción entre firmware y software no está clara (la mayoría de la gente probablemente consideraría el código para programar el firmware del procesador de banda base, y la mayoría de la gente consideraría el software de los 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.

La concurrencia de hardware es una motivación importante.

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

En VHDL, si escribes algo como:

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

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

• x , y , z , a y b son cables
• a y b son señales de entrada
• x está conectado a la salida de un circuito or , que toma a y b como entrada
• y así sucesivamente para las otras líneas

Es fácil ver cómo se sintetizará eso en el hardware real, y que x y y se evalúan al mismo tiempo.

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

Luego, cuando sea el momento, simule el circuito, el simulador (que suele ser un programa secuencial) simula la física del circuito de esta manera:

• ¿ha cambiado a o b ? ¿Sí? Hey, x depende de a . Actualicemos x .
• y también depende de a . Actualiza eso también.
• z depende de x . Actualícelo porque se actualizó x .
• ¿se ha actualizado algo de lo que x depende ( a o b )? ¿No? Lo mismo para y y z . OK, hemos terminado con este paso.

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

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

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

• solo un subconjunto de VHDL en sintetizable
• se realizan muchas simplificaciones físicas, en particular, que las señales se propagan infinitamente rápido, consulte enlace PARA HACERLO es posible modelar retrasos en Verilog: enlace

Al final, VHDL proporciona un buen equilibrio entre la funcionalidad del circuito comprensible para humanos de nivel superior y la capacidad de síntesis a nivel inferior.

C, por otro lado, está más centrado en hablar con la CPU de forma secuencial.

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 System C sí, pero nunca lo he probado).

Pero esencialmente estarías reimplementando un simulador VHDL y con un lenguaje más detallado. Herramienta correcta para el trabajo correcto, supongo.

También hay herramientas que convierten C a VHDL enlace pero espera un rendimiento más bajo, ya que son conversiones difíciles de nivel superior.

Los HDL se utilizan para describir (sintetizar) hardware, mientras que el lenguaje de programación se usa para programar el hardware ya sintetizado, es decir, la CPU.

Puedes obtener versiones de soft core de cpus como VHDL o bitstream para sintetizar esa cpu en un FPGA.

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

Un FPGA contiene una serie de circuitos que no pueden, al menos individualmente, realizar operaciones particularmente sofisticadas, pero todos 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 que se encuentran la supervisión de 15 entradas y:

• Al establecer una salida alta en cualquier momento, todas las entradas han permanecido estables durante al menos 21 ms y la cantidad de entradas que son altas es un múltiplo de tres
• La configuración de salida baja siempre que todas las entradas hayan permanecido estables durante al menos 21 ms y la cantidad de entradas que sean altas no es un múltiplo de tres
• Cambiando la salida de manera arbitraria entre el momento en que cualquier entrada cambia y la hora en que todas las entradas han permanecido estables durante al menos 20 ms.

Si uno tiene un microcontrolador que está haciendo otras cosas, pero puede ahorrar unos pocos 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 se podrán utilizar. la tarea indicada anteriormente, por lo que será necesario dedicar muy pocos circuitos (aparte de algunos ROM y quizás RAM) a esa tarea. Por otro lado, puede tomar un tiempo entre el tiempo que cambia una entrada y el tiempo 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. Un dispositivo de este tipo probablemente podría hacer que la salida produzca una indicación correcta dentro de 100 ns, ó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. p>