Tengo un proyecto que consume 34 de las macrocélulas de un Xilinx Coolrunner II. Noté que tenía un error y lo rastreé hasta aquí:
assign rlever = RL[0] ? 3'b000 :
RL[1] ? 3'b001 :
RL[2] ? 3'b010 :
RL[3] ? 3'b011 :
RL[4] ? 3'b100 :
RL[5] ? 3'b101 :
RL[6] ? 3'b110 :
3'b111;
assign llever = LL[0] ? 3'b000 :
LL[1] ? 3'b001 :
LL[2] ? 3'b010 :
LL[3] ? 3'b011 :
LL[4] ? 3'b100 :
LL[5] ? 3'b101 :
3'b110 ;
El error es que rlever
y llever
tienen un bit de ancho, y necesito que tengan un ancho de tres bits. Tonto de mí. He cambiado el código para ser:
wire [2:0] rlever ...
wire [2:0] llever ...
así que había suficientes bits. Sin embargo, cuando reconstruí el proyecto, este cambio me costó más de 30 macrocélulas y cientos de términos de productos. ¿Alguien puede explicar lo que he hecho mal?
(La buena noticia es que ahora simula correctamente ... :-P)
EDITAR -
Supongo que estoy frustrado por el momento en que creo que empiezo a entender a Verilog y al CPLD, sucede algo que demuestra que claramente no entiendo no .
assign outp[0] = inp[0] | inp[2] | inp[4] | inp[6];
assign outp[1] = inp[1] | inp[2] | inp[5] | inp[6];
assign outp[2] = inp[3] | inp[4] | inp[5] | inp[6];
La lógica para implementar esas tres líneas ocurre dos veces. Eso significa que cada una de las 6 líneas de Verilog consume aproximadamente 6 macrocélulas y 32 términos de producto cada una .
EDIT 2 - De acuerdo con la sugerencia de @ ThePhoton sobre el cambio de optimización, aquí hay información de las páginas de resumen producidas por ISE:
Synthesizing Unit <mux1>.
Related source file is "mux1.v".
Found 3-bit 1-of-9 priority encoder for signal <code>.
Unit <mux1> synthesized.
(snip!)
# Priority Encoders : 2
3-bit 1-of-9 priority encoder : 2
Claramente el código fue reconocido como algo especial. Sin embargo, el diseño sigue consumiendo recursos tremendos.
EDIT 3 -
Hice un nuevo esquema que incluye solo el mux que recomendó @thePhoton. La síntesis produjo un uso insignificante de los recursos. También sinteticé el módulo recomendado por @Michael Karas. Esto también produjo un uso insignificante. Así que algo de cordura está prevaleciendo.
Claramente, mi uso de los valores de la palanca está causando consternación. Más por venir.
Edición final
El diseño ya no es una locura. Sin embargo, no estoy seguro de lo que pasó. Hice muchos cambios para implementar nuevos algoritmos. Un factor contribuyente fue una 'ROM' de 111 elementos de 15 bits. Esto consumió una cantidad modesta de macrocélulas pero un lote de términos de productos, casi todos los disponibles en el xc2c64a. Busco esto pero no lo había notado. Creo que mi error estaba oculto por la optimización. Las "palancas" de las que estoy hablando se utilizan para seleccionar valores de la ROM. Supongo que cuando implementé el codificador de prioridad de 1 bit (roto), ISE optimizó parte de la ROM. Eso sería un buen truco, pero es la única explicación que se me ocurre. Esta optimización redujo notablemente el uso de recursos y me hizo esperar un cierto nivel de referencia. Cuando arreglé el codificador de prioridad (según este hilo), vi la sobrecarga del codificador de prioridad y la ROM que previamente se había optimizado y se lo atribuí exclusivamente al primero.
Después de todo esto, era bueno en macrocélulas pero había agotado los términos de mis productos. La mitad de la ROM era un lujo, en realidad, ya que era solo la composición de los 2 de la primera mitad. Eliminé los valores negativos, reemplazándolos en otro lugar con un cálculo simple. Esto me permitió intercambiar macrocélulas por términos de productos.
Por ahora, esto encaja en el xc2c64a; He usado el 81% y el 84% de mis términos de macrocélulas y productos, respectivamente. Por supuesto, ahora tengo que probarlo para asegurarme de que hace lo que quiero ...
Gracias a ThePhoton y Michael Karas por la asistencia. Además del apoyo moral que prestaron para ayudarme a resolver esto, aprendí del documento de Xilinx que publicó ThePhoton, e implementé el codificador de prioridad sugerido por Michael.