Actualmente estoy diseñando un microcontrolador mips para una clase. Ahora estoy trabajando en la unidad de control para el microprocesador y me pregunto si debería usar la minimización frente al uso del control de flujo (si es el caso).
¿La minimización (por ejemplo, usar Karnaugh) es realmente buena en cuanto al rendimiento cuando se usa vhdl o debería ser fácil de expandir, modificar con el control de flujo?
¿Te refieres a la simulación o al rendimiento de síntesis?
La complejidad computacional de la simulación se controla mediante subprogramas elaborados dinámicamente más la sobrecarga de simulación, todas las expresiones usan operadores (subprogramas) o operaciones básicas (también funciones).
También encontrará que cuanto más abstracto (flujo de control) se puede describir un modelo de diseño, más rápido simulará.
La cantidad de trabajo a minimizar, por lo tanto, está relacionada con la cantidad de bits de control concurrentes que se evalúan por la cantidad de asignaciones elaboradas.
La idea completa de la síntesis es evitar tener que hacer una minimización y mapearte. Cree un par de casos de prueba equivalentes y tómelos en cuenta: la lógica resultante será la misma.
En cuanto a expresar código en términos minimizados, intente esto:
library ieee;
use ieee.std_logic_1164.all;
entity s381 is
port (
signal A,B: in std_logic_vector (3 downto 0);
signal S: in std_logic_vector (2 downto 0);
signal CIN: in std_logic;
signal SUM: out std_logic_vector (3 downto 0);
signal P: out std_logic;
signal G: out std_logic;
signal ZERO: out std_logic
) ;
end entity;
architecture behave of s381 is
signal SEL: std_logic_vector (4 downto 0);
signal CY_EN: std_logic;
signal C: std_logic_vector (3 downto 0);
signal E: std_logic_vector (3 downto 0);
signal LC: std_logic_vector (3 downto 0);
signal F: std_logic_vector (3 downto 0);
begin
SEL(0) <= not S(0) nand not S(1);
SEL(1) <= not S(1) nand not S(2);
SEL(2) <= not S(0) nand S(1);
SEL(3) <= not (S(0) and S(1) and not S(2));
SEL(4) <= (not S(0) and S(2)) nor (not S(1) and S(2));
CY_EN <= (not S(0) nand not S(1)) and not S(2);
C(0) <= not (
(not A(0) and not B(0) and SEL(2) and SEL(1)) or
( SEL(0) and SEL(2) and SEL(3) and not B(0) and A(0)) or
( SEL(1) and SEL(3) and B(0) and not A(0))
);
E(0) <= not (
(not A(0) and not B(0) and SEL(0) and SEL(3) and SEL(4)) or
( SEL(1) and SEL(2) and not B(0) and A(0)) or
( SEL(1) and SEL(2) and B(0) and not A(0)) or
( SEL(0) and SEL(3) and B(0) and A(0))
);
LC(0) <= CIN nand CY_EN;
C(1) <= not (
(not A(1) and not B(1) and SEL(2) and SEL(1)) or
( SEL(0) and SEL(2) and SEL(3) and not B(1) and A(1)) or
( SEL(1) and SEL(3) and B(1) and not A(1))
);
E(1) <= not (
(not A(1) and not B(1) and SEL(0) and SEL(3) and SEL(4)) or
( SEL(1) and SEL(2) and not B(1) and A(1)) or
( SEL(1) and SEL(2) and B(1) and not A(1)) or
( SEL(0) and SEL(3) and B(1) and A(1))
);
LC(1) <= not ((CIN and C(0) and CY_EN) or (C(0) and E(0) and CY_EN));
C(2) <= not (
(not A(2) and not B(2) and SEL(2) and SEL(1)) or
( SEL(0) and SEL(2) and SEL(3) and not B(2) and A(2)) or
( SEL(1) and SEL(3) and B(2) and not A(2))
);
E(2) <= not (
(not A(2) and not B(2) and SEL(0) and SEL(3) and SEL(4)) or
( SEL(1) and SEL(2) and not B(2) and A(2)) or
( SEL(1) and SEL(2) and B(2) and not A(2)) or
( SEL(0) and SEL(3) and B(2) and A(2))
);
LC(2) <= not (
(CIN and C(0) and C(1) and CY_EN) or
(C(0) and C(1) and E(0) and CY_EN) or
(C(1) and E(1) and CY_EN)
);
C(3) <= not (
(not A(3) and not B(3) and SEL(2) and SEL(1)) or
( SEL(0) and SEL(2) and SEL(3) and not B(3) and A(3)) or
( SEL(1) and SEL(3) and B(3) and not A(3))
);
E(3) <= not (
(not A(3) and not B(3) and SEL(0) and SEL(3) and SEL(4)) or
( SEL(1) and SEL(2) and not B(3) and A(3)) or
( SEL(1) and SEL(2) and B(3) and not A(3)) or
( SEL(0) and SEL(3) and B(3) and A(3))
);
LC(3) <= not (
(CIN and C(0) and C(1) and C(2) and CY_EN) or
(C(0) and C(1) and C(2) and E(0) and CY_EN) or
(C(1) and C(2) and E(1) and CY_EN) or
(C(2) and E(2) and CY_EN)
);
F <= LC xor E;
P <= C(0) and C(1) and C(2) and C(3);
G <= (
(C(0) and C(1) and C(2) and C(3) and E(0)) or
(C(1) and C(2) and C(3) and E(1)) or
(C(2) and C(3) and E(2)) or
(C(3) and E(3))
);
SUM <= F;
ZERO <= not (F(3) or F(2) or F(1) or F(0));
end architecture;
No se puede mantener sin recurrir a otra documentación que muestre qué operaciones define S y por qué hay términos intermedios particulares.
Desde el LRM, IEEE Std 1076-2008, 1.2 Propósito:
El lenguaje VHDL se definió para su uso en el diseño y la documentación de sistemas electrónicos.
¿Cuánta documentación es inherente al código VHDL anterior?
Compare la descripción minimizada anterior con una expresión de flujo de control ( código VHDL para una ALU de 74 series (el chip 74LS381) )
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
-- s2 s1 s0 operation
--------------------------
-- L L L clear
-- L L H B minus A
-- L H L A minus B
-- L H H A plus B
-- H L L A xor B
-- H L H A + B
-- H H L AB
-- H H H PRESET
entity IC74381 is
port( a: in std_logic_vector (3 downto 0);
b: in std_logic_vector (3 downto 0);
s: in std_logic_vector (2 downto 0);
f: out std_logic_vector (3 downto 0)
);
end IC74381;
architecture arch of IC74381 is
signal BminusA,AminusB,AplusB,AxorB,AandB,AB: std_logic_vector(3 downto 0);
signal au,bv0,bv1,bv2,bv3: unsigned(3 downto 0);
signal p0,p1,p2,p3,prod: unsigned(7 downto 0);
begin
BminusA <= std_logic_vector(signed(b)-signed(a));
AminusB <= std_logic_vector(signed(a)-signed(b));
AplusB <= std_logic_vector(signed(a)+signed(b));
AxorB <= a xor b;
AandB <= a and b;
au <=unsigned(a);
bv0 <=(others=>b(0));
bv1 <=(others=>b(1));
bv2 <=(others=>b(2));
bv3 <=(others=>b(3));
p0 <="0000" & (bv0 and au);
p1 <="000"&(bv1 and au) & "0";
p2 <="00" & (bv2 and au) & "00";
p3 <="0" & (bv3 and au) & "000";
prod<=((p0+p1)+(p2+p3));
AB<=std_logic_vector(prod(3 downto 0));
f <= "0000" when s="000" else
BminusA when s="001" else
AminusB when s="010" else
AplusB when s="011" else
AxorB when s="100" else
AandB when s="101" else
AB when s="110" else
"1111";
end arch;
(Y personalmente hubiera reemplazado BminusA , etc. con las expresiones en el lado derecho de sus asignaciones en la asignación a f < em>. Encontrar un equivalente fue fortuito, alrededor de 20 años separan su autoría.)
Sin validar ambos, espero que ambos puedan producir la misma lógica de complejidad después de la síntesis. La cantidad de herramientas de síntesis de trabajo de alto rendimiento no es el factor de control en EDA hoy. Además, la verificación del diseño y la documentación es cada vez más importante (también del LRM, mismo párrafo):
Se ha revisado para incorporar capacidades que mejoren la utilidad del lenguaje para el propósito previsto y lo extiendan para abordar metodologías de verificación de diseño que se han desarrollado en la industria.
Ahora pregúntese, ¿desde cuál de los dos formularios anteriores puede la persona bloqueada en la verificación determinar más fácilmente cuál debe ser el resultado esperado?
Es posible que note que hay dos errores en el segundo ejemplo. La distinción de estar allí es casi suficiente información para solucionarlo a partir de la descripción del diseño. Lo que falta es una descripción más completa de las 8 operaciones:
-- eight function ALU
-- S(0) S(1) S(2)
-- 0 0 0 CLEAR
-- 1 0 0 B MINUS A
-- 0 1 0 A MINUS B
-- 1 1 0 A PLUS B
-- 0 0 1 A XOR B
-- 1 0 1 A OR B
-- 0 1 1 A AND B
-- 1 1 1 PRESET
Una descripción del hardware es más que solo lógica.
La versión de expresión minimizada se realizó en un momento en que la síntesis de funciones aritméticas cuesta más en costos de licencias. El rendimiento de la CPU y los tamaños de memoria hicieron que la distinción en el tiempo (expresada en el valor agregado) fuera cada vez menos significativa.
Tendíamos a documentar mejor los objetivos ASIC que lo que generalmente se hace para los FPGA, se podría consultar en la especificación de diseño, además de que eran libros de datos de hojas de datos con esquemas.
No es una proposición de uno u otro.
Independientemente de la sintaxis que use para expresar la lógica en su código fuente VHDL, las herramientas de síntesis lo convertirán en una representación interna canónica y realizarán la minimización / optimización apropiada antes de asignarlo a la tecnología de implementación objetivo (puertas, LUTs, etc.).
No dude en utilizar cualquier sintaxis en el código fuente que exprese su intención con mayor claridad.
Lea otras preguntas en las etiquetas vhdl flow-control