Warum verschlingt dieses Verilog 30 Makrozellen und Hunderte von Produktbegriffen?

Ich habe ein Projekt, das 34 Makrozellen eines Xilinx Coolrunner II verbraucht. Ich bemerkte, dass ich einen Fehler hatte und verfolgte ihn zu diesem:

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 ;

Der Fehler ist, dass rleverund lleverein Bit breit sind, und ich brauche, dass sie drei Bit breit sind. Wie dumm von mir. Ich habe den Code wie folgt geändert:

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

Also gab es genug Bits. Als ich das Projekt jedoch neu erstellte, kostete mich diese Änderung mehr als 30 Makrozellen und Hunderte von Produktbegriffen. Kann mir jemand erklären was ich falsch gemacht habe?

(Die gute Nachricht ist, dass es jetzt korrekt simuliert ... :-P )

BEARBEITEN -

Ich nehme an, ich bin frustriert, denn ungefähr zu dem Zeitpunkt, an dem ich glaube, dass ich Verilog und CPLD verstehe, passiert etwas, das zeigt, dass ich eindeutig kein Verständnis habe.

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];

Die Logik zur Implementierung dieser drei Zeilen kommt zweimal vor. Das bedeutet, dass jede der 6 Zeilen von Verilog etwa 6 Makrozellen und jeweils 32 Produktterme verbraucht .

BEARBEITEN 2 - Gemäß dem Vorschlag von @ThePhoton zum Optimierungsschalter finden Sie hier Informationen von den von ISE erstellten Zusammenfassungsseiten:

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

Der Code wurde also eindeutig als etwas Besonderes erkannt. Das Design verbraucht jedoch immer noch enorme Ressourcen.

BEARBEITEN 3 -

Ich habe einen neuen Schaltplan erstellt, der nur den von @thePhoton empfohlenen Mux enthält. Die Synthese führte zu einem unbedeutenden Ressourcenverbrauch. Ich habe auch das von @Michael Karas empfohlene Modul synthetisiert. Dies führte auch zu einem unbedeutenden Verbrauch. Es herrscht also eine gewisse Vernunft vor.

Meine Verwendung der Hebelwerte verursacht eindeutig Bestürzung. Da kommt noch mehr.

Endgültige Bearbeitung

Das Design ist nicht mehr verrückt. Ich bin mir jedoch nicht sicher, was passiert ist. Ich habe viele Änderungen vorgenommen, um neue Algorithmen zu implementieren. Ein Faktor, der dazu beitrug, war ein „ROM“ mit 111 15-Bit-Elementen. Dies verbrauchte eine bescheidene Anzahl von Makrozellen, aber vielvon Produktbegriffen - fast alle auf dem xc2c64a verfügbaren. Ich suche danach, hatte es aber nicht bemerkt. Ich glaube, mein Fehler wurde durch die Optimierung versteckt. Die "Hebel", von denen ich spreche, werden verwendet, um Werte aus dem ROM auszuwählen. Ich gehe davon aus, dass ISE bei der Implementierung des (kaputten) 1-Bit-Prioritätscodierers einen Teil des ROM wegoptimiert hat. Das wäre ein ziemlicher Trick, aber es ist die einzige Erklärung, die mir einfällt. Diese Optimierung reduzierte den Ressourcenverbrauch deutlich und wiegte mich in der Erwartung einer bestimmten Grundlinie ein. Als ich den Priority-Encoder (wie in diesem Thread) repariert habe, habe ich den Overhead des Priority-Encoders und des zuvor optimierten ROMs gesehen und dies ausschließlich dem ersteren zugeschrieben.

Nach all dem war ich gut mit Makrozellen, hatte aber meine Produktkonditionen erschöpft. Die Hälfte des ROM war wirklich ein Luxus, da es nur die 2er-Zusammenstellung der ersten Hälfte war. Ich habe die negativen Werte entfernt und sie an anderer Stelle durch eine einfache Berechnung ersetzt. Dadurch konnte ich Makrozellen gegen Produktbedingungen eintauschen.

Im Moment passt dieses Ding in den xc2c64a; Ich habe 81 % bzw. 84 % meiner Makrozellen bzw. Produktbegriffe verwendet. Natürlich muss ich es jetzt testen, um sicherzustellen, dass es das tut, was ich will ...

Danke an ThePhoton und Michael Karas für die Hilfe. Zusätzlich zu der moralischen Unterstützung, die sie mir bei der Lösung dieses Problems gewährt haben, habe ich aus dem von ThePhoton veröffentlichten Xilinx-Dokument gelernt und den von Michael vorgeschlagenen Prioritäts-Encoder implementiert.