La mejor respuesta
En el modelado de flujo de datos estructurales, las funciones de diseño digital se definen utilizando componentes como un inversor , un MUX, un sumador, un decodificador, puertas lógicas digitales básicas, etc. Es como conectar y ordenar diferentes partes de los circuitos disponibles para implementar una función que estás buscando.
Implementación de medio sumador utilizando estructuras modelado de flujo de datos: entrada A, B; suma de salida, acarreo; xor (.in1 (A), .in2 (B), .out (suma)); y (.in1 (A), .in2 (B), .out (carry));
El modelado de flujo de datos de comportamiento se utiliza para describir el comportamiento de los circuitos digitales. El diseñador describe la funcionalidad del diseño escribiendo código tipo algoritmo. Se utiliza para explicar el flujo de datos utilizando varias expresiones booleanas como & (y), | (o), ~ (invertir), ^ (xor),? (Condicional), etc … dos subcategorías de este tipo de modelado El esquema es un flujo de datos continuo y un flujo de datos de procedimiento.
1. Flujo de datos continuo En este tipo de modelado de flujo de datos, la asignación de datos a las salidas es continua. Esto se implementará usando declaraciones « assign » en Verilog como se muestra en el ejemplo.
input A, B; suma de salida, acarreo; cable sum, carry; asignar suma = A ^ B; asignar carry = A & B;
Es una asignación continua y, por lo tanto, cualquier cambio en la entrada afectará la salida inmediatamente debido a la ausencia de acciones de control, es decir, la lista de sensibilidad. Aquí, la variable de salida debe definirse como tipo « alambre » porque son controladas continuamente por la lógica digital definida en RHS.
2. Flujo de datos de procedimiento Aquí, las asignaciones de datos no se llevan a cabo de forma continua, sino que ocurre en eventos específicos especificados en la lista de sensibilidad. Este tipo de esquema de modelado se implementa mediante bloques de procedimiento como « siempre » o « inicial «como se muestra en el ejemplo.
input A, B; suma de salida, acarreo; reg sum, carry; siempre @ (A) comenzar suma A + B; llevar A & B; end
El RHS de todas las expresiones se calcula continuamente, pero su asignación a LHS ocurre solo en cualquier cambio en la entrada A pero no en B. En este caso, las variables de salida deben definirse como « reg » porque mantienen el valor anterior hasta que se produce una nueva asignación después de cualquier cambio en la lista de sensibilidad especificada.
Espero que esto aclare sus dudas.
Respuesta
El flujo de datos y el comportamiento no se excluyen mutuamente. Tampoco lo es Flujo de datos y funcional, o Flujo de datos y estructural. Visto de forma clásica, el «flujo de datos» describe una arquitectura en la que un cambio en el valor de un elemento de datos (variable) activa automáticamente el recálculo de todos los demás datos que dependen de él.
Muchos clasifican incorrectamente (en mi humilde opinión) cualquier arquitectura en la que el flujo de datos se gestiona en lugar de controlar la gestión del flujo para que sea «flujo de datos»; pero el término se usa de esta manera con suficiente regularidad para permitir que sea una definición alternativa.
Si consideramos el diseño «conductual», podemos clasificarlo como un enfoque de diseño donde los módulos se modelan con un alto nivel de abstracción donde el diseñador define el comportamiento deseado del módulo y las herramientas de síntesis descomponen ese comportamiento en modelos RTL o estructurales. En el modelado de comportamiento, la función se define algorítmicamente, ignorando en gran medida la sincronización y la carga de nodos. Claramente, los comportamientos se pueden modelar de manera que se adapte al flujo de datos clásico.
Menos abstracto es el modelado «RTL» o de lógica de transferencia de registros. Aquí es donde muchos profesionales dicen que comienza el flujo de datos. La mayoría de las herramientas de síntesis actuales descomponen el código de comportamiento en RTL. Un buen ejemplo son las herramientas de C (o C ++) a RTL como ImpulseC, Cynthesizer, etc.
El modelo menos abstracto es el «estructural» donde el diseño se presenta casi exclusivamente como instancias de componentes con registros de conexión y cables.
Claro como el barro, ¿verdad?