¿Por qué este Verilog cerdo abajo 30 macrocells y cientos de términos de productos?

Question

Tengo un proyecto en el que se consume 34 de Xilinx Coolrunner II macrocells. Me di cuenta de que tenía un error y relacionarlo con 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 que rlever y llever son un poco ancho, y las necesito para ser tres bits de ancho. Tonto de mí. He cambiado el código:

wire [2:0] rlever ...
wire [2:0] llever ...

así fueron suficientes bits. Sin embargo, cuando reconstruye el proyecto, este cambio me costó más de 30 macrocells 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 me siento frustrado porque sobre el tiempo creo que empiezo a entender Verilog y la CPLD, ocurre algo que muestra claramente me tienen ninguna comprensión.

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 alrededor de 6 macrocells y 32 términos de productos cada uno.

EDICIÓN 2 - Como por @ThePhoton sugerencia acerca de la optimización de cambio, aquí está la información de las páginas de resumen producido 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

Así que claramente el código fue reconocido como algo especial. El diseño se sigue consumiendo enormes recursos, sin embargo.

EDICIÓN de 3

He hecho un nuevo esquemático incluyendo sólo los mux que @thePhoton recomendado. Síntesis producido insignificante el uso de los recursos. Yo también sintetiza el módulo recomendado por @Michael Karas. Esto también se produce insignificante de uso. Así que un poco de cordura es predominante.

Claramente, mi uso de la palanca de valores está causando consternación. Más Por Venir.

Última Edición

El diseño ya no es una locura. No estoy seguro de lo que pasó, sin embargo. He hecho un montón de cambios con el fin de implementar nuevos algoritmos. Un factor que contribuyó fue un 'ROM' de 111 15 bits elementos. Este consume un número modesto de macrocells pero un montón de términos de productos - casi todos de los que están disponibles en el xc2c64a. Miro para esto, pero no se había dado cuenta. Creo que mi error fue escondido por la optimización. Las 'palancas' estoy hablando se utilizan para seleccionar los valores de la ROM. Mi hipótesis es que cuando he implementado la (roto) de 1 bit de prioridad de codificador, ISE optimizado algo de la ROM. Eso puede ser un truco, pero es la única explicación que se me ocurre. Esta optimización reduce el uso de recursos notablemente, y arrullado a mí a la espera de una cierta línea de base. Cuando me fijo el codificador de prioridad (como por este hilo,) yo vi la sobrecarga de la prioridad del codificador y la ROM que previamente habían sido optimizado de distancia , y lo atribuyeron a la ex exclusivamente.

Después de todo esto, yo era bueno en macrocells pero había agotado mi producto de los términos. La mitad de la ROM era un lujo, de verdad, ya que era sólo el 2 comp de la primera mitad. He quitado los valores negativos, en sustitución de ellos en otro lugar con un simple cálculo. Esto me permitió comercio macrocells para el producto de los términos.

Por ahora, esta cosa encaja en el xc2c64a; he usado el 81% y el 84% de mi macrocells y producto, respectivamente. Por supuesto, ahora tengo que probarlo para asegurarse de que hace lo que yo quiero...

Gracias a ThePhoton y Michael Karas para la ayuda. Además del apoyo moral que prestó para que me ayude a resolver esto, he aprendido de la Xilinx documento ThePhoton publicado, y he implementado el codificador de prioridad sugieren por Michael.

Answer 1

El código que muestran es esencialmente un codificador de prioridad. Es decir, tiene una entrada de muchas señales, y su resultado indica que de esas señales, dando prioridad a la izquierda del conjunto de la señal si hay más de un conjunto.

Sin embargo, veo en conflicto definiciones de la norma de comportamiento de este circuito en los dos lugares en los que he comprobado.

De acuerdo a Wikipedia, la prioridad estándar codificador números de sus entradas a partir del 1 de. Es decir, si el menos significativo de entrada está establecido el bit, salidas 1, no 0. La Wikipedia codificador de prioridad de las salidas 0 cuando ninguno de los bits de entrada se establecen.

Xilinx del XST Guía del Usuario (p. 80), sin embargo, define un codificador de prioridad más cerca de lo que en el código. Las entradas son numeradas de 0, así que cuando la entrada de la lsb es el conjunto da un 0 en la salida. Sin embargo, el Xilinx definición no da especificaciones para la salida, cuando todos los bits de entrada son claras (Su código de salida será de 3'd7).

El Xilinx guía del usuario, por supuesto, va a determinar lo que el Xilinx software de síntesis está esperando. El punto principal es que una directiva especial (*priority_extract ="force"*) es necesario para XST a reconocer esta estructura y generar óptimos resultados de la síntesis.

Aquí Xilinx de la forma recomendada por 8 a 3 codificador de prioridad:

(* priority_extract="force" *)
module v_priority_encoder_1 (sel, code);
input [7:0] sel;
output [2:0] code;
reg [2:0] code;
always @(sel)
begin
    if (sel[0]) code = 3'b000;
    else if (sel[1]) code = 3'b001;
    else if (sel[2]) code = 3'b010;
    else if (sel[3]) code = 3'b011;
    else if (sel[4]) code = 3'b100;
    else if (sel[5]) code = 3'b101;
    else if (sel[6]) code = 3'b110;
    else if (sel[7]) code = 3'b111;
    else code = 3'bxxx;
end
endmodule

Si usted puede reorganizar sus alrededores lógica para permitir el uso de Xilinx recomienda estilo de codificación, que es probablemente la mejor manera para obtener un mejor resultado.

Creo que usted puede conseguir esto mediante la creación de instancias de la Xilinx codificador de módulo con

v_priority_encoder_1 pe_inst (.sel({~|{RL[6:0]}, RL[6:0]}), .code(rlever));

He ni juntos todos los bits de RL[6:0] para obtener una 8 bits de la entrada que va a desencadenar el 3'b111 de salida cuando todos RL de bits baja.

Para el llever lógica, probablemente, usted puede reducir el uso de recursos, haciendo una modificación de codificador de módulo, siguiendo el Xilinx plantilla, pero que requieren de sólo 7 bits de entrada (6 bits de LL más un bit adicional que se va alto cuando los otros 6 son todas bajas).

El uso de esta plantilla supone la versión de ISE lo que usted tiene es el uso de la XST motor de síntesis. Parece que el cambio de las herramientas de síntesis en cada una de las principales rev de ISE, a fin de comprobar que el documento vinculado en realidad corresponde a su versión de ISE. Si no es así, compruebe el estilo recomendado en la documentación para ver lo que su herramienta de espera.

Answer 2

ThePhoton la respuesta es excelente. Me gustaría añadir alguna información adicional para su consideración. Esto se deriva del hecho de que aunque hemos estado del arte de la fantasía de la FPGA y CPLD utilización de dispositivos de Hdl y systhesis herramientas que pueden ser útiles para examinar de cerca las cosas diseñado años atrás. Quédate conmigo mientras yo paseo a través de este mi recomendación al final.

Hay discretos lógica de las partes que realizan la prioridad de la función de codificación. La lógica implementada por estas partes ha sido de alrededor durante mucho tiempo, cuando era esencial para reducir el número de transistores en un mínimo. Usted puede buscar en la web para la lógica de las piezas con la parte genérica de los números, tales como 74HC148 o MC14532B encontrar hojas de datos que incluyen el equivalente de los diagramas de la lógica para estas partes. El siguiente diagrama es un ejemplo tomado de la TI en la hoja de datos de la 74HC148 parte.

En esta lógica se implementa la siguiente tabla de verdad (tomado de la misma hoja de datos):

Tenga en cuenta que la parte de arriba de la familia utiliza la baja actividad de las señales de entrada. Otro de los datos en la hoja de la de ON Semiconductor MC14532B parte se muestra una tabla de verdad para el codificador de la función con activos de alta señales de entrada similares a los de su Verilog ejemplo.

La misma hoja de datos se muestra la lógica de las ecuaciones para el MC14532B de la siguiente manera:

Puede que desee considerar la codificación similar ecuaciones directamente en su código Verilog para ver cómo se compara con el presente ejemplo. Es muy probable que resulte en una posición mucho más favorable resultado.