DSP48 Blöcke werden durch Logik ersetzt

[Tobias B. (sessl3r)]

Hallo.

Ich hoffe hier finde ich Hilfe. Zuerst mal meine Problemstellung:

Aufgabe ist es mit möglichst wenig VHDL Code möglichst viele Ressourcen 
eines Xilinx Virtex-5 FPGA's zu verbrauchen (um diesen richtig zu 
fordern und zu überprüfen ob das Leiterplattendesign passt usw.)

Der Ansatz dies zu erreichen ist ein Prozess in welchem eine Schleife 
ist die etwas tut wie z.B.:

PROCESS(clk, ce)
   BEGIN
      IF rising_edge(clk) THEN
         IF ce = '1' THEN
            FOR i IN number_of_dsps - 1 DOWNTO 0 LOOP
               a(i) <= NOT a(i);
               tmp(i) <= STD_LOGIC_VECTOR(UNSIGNED(a(i)) * b + c);
               dout(i) <= tmp(i)(0);
            END LOOP;  -- i
         END IF;
      END IF;
   END PROCESS;

Und genau hier ist mein Problem. Es funktioniert (dadurch das tmp mit 
dem Attribute keep belegt wurde), dass mir in der Synthese soviele 
DSP48-Blöcke erstellt werden wie tmp groß ist. Allerdings nur bis die 
Hälfte der DSP48-Blöcke verbraucht ist (320 Stück von 640). Sollen mehr 
als 320 DSP-Blöcke erstellt werden kommt folgende Meldung bei der 
Synthese:

# Info: [14505]: Resource Allocation was performed for DSP48Es based on 640 available in the device.
# Info: [14503]: 320 Instance(s) were allocated to logic implementations instead of 640 DSP48Es.

Nun habe ich schon Attribute wie "use_dsp_block" oder "mult_style" auf 
das Signal tmp wie folgt angewendet

ATTRIBUTE mult_style : STRING;
ATTRIBUTE mult_style OF tmp : SIGNAL IS "Block";

ATTRIBUTE use_dsp_block : STRING;
ATTRIBUTE use_dsp_block OF tmp : SIGNAL IS "Yes";

ATTRIBUTE dedicated_mult : STRING;
ATTRIBUTE dedicated_mult OF tmp : SIGNAL IS "ON";

allerdings ohne Erfolg (gut möglich das ich diese Falsch verwende?)

Habt ihr mir einen Tipp welche Attribute ich verwenden könnte und wie 
damit die Synthese gezwungen wird DSP48-Blöcke für Multiplikationen zu 
verwenden und diese nicht in Logik aufzubauen?

Als Synthesetool ist übrigens Precision im Einsatz.

Vielen Dank für eure Unterstützung!

Grüße
Tobias B.

[Martin S. (strubi)]

Moin,

hast Du mal das ganze ohne den Addierer getestet?
Glaube, ich hatte da mal auch sowas, dass auf älteren Spartans die 
DSP-Blöcke nicht komplett in DSP48x-Slices synthetisiert werden konnten.
Ich benutze allerdings xst, ab und an war da in skurrilen Fällen einfach 
mal ein Optionsflag nötig.

[Tobias B. (sessl3r)]

> hast Du mal das ganze ohne den Addierer getestet?

Habe ich mal getestet - bringt leider keine Änderung.

> ab und an war da in skurrilen Fällen einfach
mal ein Optionsflag nötig.

Was ist ein Optionsflag? Leider habe ich bisher nur sehr wenig Erfahrung 
mit FPGAs - das gleiche wie ein Attribute oder etwas anderes?

Was evtl. noch wichtig sein könnte: Die Signale b und c im obigen 
VHDL-Code sind Konstanten. Nur das Signal a ist Variabel.

Gibt es sonst noch Ideen wie ich das Problem lösen könnte?

Vielen Dank mal soweit!

Gruß
Tobias B.

[Christian R. (supachris)]

Schau mal bei der Synthese in die Process Properties (Advanced Mode dann 
aktivieren) Da ist bei HDL Options eine Use DSP48 Option, die kannst du 
mal umstellen auf "Yes"

[Tobias B. (sessl3r)]

Diese Option hatte ich schon getestet (im RTL-Schematic für den 
betroffenen Block mit Set Attribute Use_DSP48 auf Yes - wobei dieses 
oder ein ähnliches interessanterweise nicht in der Auswahlliste 
vorhanden ist!!) allerdings ohne Erfolg!

Meine Vorgehensweise bisher:

In Precision Compiliere ich das Projekt.
Dann gehe ich auf View RTL Schematic -> auf den betroffenen Block -> 
Rechtklick Set Attribute -> New -> Name: use_dsp48 Value: Yes

Vermutlich mache ich hier etwas falsch?

[Lattice User (Gast)]

Ich kenne mich mit Xilinx nur wenig aus, aber sind nicht immer 2 DSO48 
Slices in einem DSP48 Tile zusammengefasst?
Könnte also sein, dass die sich gegenseitig blockieren, wenn man einfach 
nur eine VHDL Multiplikation nutzt.
Klappt dann vielleicht besser wenn das ganze z.B. eine FIR Struktur 
darstellt, statt einfache Multiplikationen.

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Tobias B. schrieb:
> Aufgabe ist es mit möglichst wenig VHDL Code möglichst viele Ressourcen
> eines Xilinx Virtex-5 FPGA's zu verbrauchen (um diesen richtig zu
> fordern und zu überprüfen ob das Leiterplattendesign passt usw.)

Wie soll dir dieser Test sagen, dass etwas mit dem Board-Design nicht 
i.O. ist?
Problematisch wird es immer dann, wenn sich der Stromverbrauch des FPGAs 
stark ändert. Das ist insbesondere dann der Fall, wenn die PLL gelockt 
hat und dieses Signal genutzt wird, um FSM/Zähler frei zu geben. Mehr 
oder weniger gleichzeitig verlassen alle FSMs ihren init-Zustand und die 
Zähler rennen los. Dann steigt plötzlich der Stromverbrauch. U.U sind 
die Regler alle im Anschlag, weil das ganze Board hoch läuft. Bei einem 
Spannungseinbruch kippen dann FFs.
Dieser Effekt tritt besonders gut bei One-Hot-Encoded FSM auf, weil die 
dann ein einen ungültigen Zustand geraten und nicht wieder zurück 
finden. Wenn bei einem Zähler mal ein Bit kippt, springt der 
Zählerstand. Das fällt nicht so schnell auf. Ein gekipptes Bit in einem 
DSP-Core womöglich in einem Filter ist völlig irrelevant, das mittelt 
sich weg. Zumal beim Anlauf eines Designs die Filter so wieso 
Einschwingen müssen.
Diesen Effekt (ungültige FSM-Zustände) hatte ich bisher zweimal (ECP2M 
und Spartan3A-DSP). In beiden Fällen hatte der Schaltungsentwickler 
deutlich weniger als 50 % der geforderten Anzahl von Block-Cs für die 
Core-Spannung verwendet. Wenn dann die Designs ordentlich angelaufen 
sind, immer noch in > 90% aller Fälle, trat im Betrieb nie ein Fehler 
auf. Der Effekt trat nur auf, wenn das Design aus dem Flash geladen 
wurde, nie wenn man es direkt in den FPGA geschrieben hat.
In beiden Fällen hat es geholfen, das Freigabe/Reset-Signal für einzelne 
Teile der Logik zu verzögern.
Ein ganz anderes Thema sind Singalintegritätsprobleme auf dem Board, die 
findest du mit deiner Methode nicht. Da heißt das Stichwort SSO.

Tom

[Tobias B. (sessl3r)]

> Wie soll dir dieser Test sagen, dass etwas mit dem Board-Design nicht
i.O. ist?

Dieser Test ist nur der Vollständigkeit halber dabei. Die anderen Teile 
des FPGA's werden schon auch gefordert. Z.B. werden alle FF's die sonst 
nicht genutzt werden mit jeder steigenden Flanke umgeschaltet - auf 
einen Schlag usw.
Aber das Funktioniert so schon alles nur die DSP-Blöcke machen mir eben 
Probleme.

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Tobias B. schrieb:
>> Wie soll dir dieser Test sagen, dass etwas mit dem Board-Design nicht
> i.O. ist?
>
> Dieser Test ist nur der Vollständigkeit halber dabei. Die anderen Teile
> des FPGA's werden schon auch gefordert. Z.B. werden alle FF's die sonst
> nicht genutzt werden mit jeder steigenden Flanke umgeschaltet - auf
> einen Schlag usw.
> Aber das Funktioniert so schon alles nur die DSP-Blöcke machen mir eben
> Probleme.

Deine Antwort beantwortet nicht die Frage. Wie weist du nach, dass es 
keine Probleme mit dem Board gibt? Überprüfst du irgend welche Daten? 
Woher weißt du, dass wirklich alle anderen FFs kippen? Misst du irgend 
welche Spannungen?

Tom

[Tobias B. (sessl3r)]

Ja es werden Spannungen und Ströme gemessen. Es ist auch klar zu 
erkennen das z.B. die FF's das tun was sie sollen in diesem Fall - 
nämlich Strom verschwenden.

Allerdings Hilft mir deine Antwort bei meinem Problem leider bisher auch 
noch nicht weiter. Es muss doch irgendwo einen Schalter geben der die 
Synthese dazu zwingt Multiplikationen in DSP-Blöcken durchzuführen, oder 
nicht?

Vielen Dank nochmal für die Hilfe!

Grüße

[Duke Scarring (Gast)]

Tobias B. schrieb:
> Es muss doch irgendwo einen Schalter geben der die
> Synthese dazu zwingt Multiplikationen in DSP-Blöcken durchzuführen, oder
> nicht?
Zur Not mußt Du eben die DSP-Blöcke dirket instanziieren.

Duke