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 esto:
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 eso rlevery lleverson de un bit de ancho, y necesito que tengan tres bits de ancho. Tonto de mí. Cambié el código para ser:
wire [2:0] rlever ...
wire [2:0] llever ...entonces había suficientes pedazos. 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 porque, cuando creo que empiezo a entender a Verilog y al CPLD, sucede algo que muestra que claramente no entiendo.
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 .
EDITAR 2: según 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 : 2Claramente, el código fue reconocido como algo especial. Sin embargo, el diseño aún consume enormes recursos.
EDITAR 3 -
Hice un nuevo esquema que incluye solo el mux que @thePhoton recomendó. La síntesis produjo un uso insignificante de recursos. También sinteticé el módulo recomendado por @Michael Karas. Esto también produjo un uso insignificante. Entonces prevalece cierta cordura.
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 sucedió. Hice muchos cambios para implementar nuevos algoritmos. Un factor que contribuyó fue una 'ROM' de 111 elementos de 15 bits. Esto consumió un número modesto de macrocélulas pero muchode términos del producto: casi todos los disponibles en el xc2c64a. Busqué 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. Supuse 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 los recursos y me indujo a esperar cierta línea de base. 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 atribuí esto al primero exclusivamente.
Después de todo esto, era bueno en macrocélulas pero había agotado los términos de mi producto. La mitad de la ROM era un lujo, en realidad, ya que solo eran las 2 comp 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 producto.
Por ahora, esta cosa encaja en el xc2c64a; He usado el 81% y el 84% de mis macrocélulas y términos de producto respectivamente. Por supuesto, ahora tengo que probarlo para asegurarme de que hace lo que quiero ...
Gracias a ThePhoton y Michael Karas por la ayuda. Además del apoyo moral que prestaron para ayudarme a resolver esto, aprendí del documento de Xilinx publicado por ThePhoton, e implementé el codificador de prioridad sugerido por Michael.
|lugar de ||.
