Maximale Geschwindigkeit der Multiplier

[Michael W. (Gast)]

Bei einem Artix habe ich das Problem, dass eine Multiplikation nicht 
timen will. Es handelt sich um eine Quadrierung eines 10 Bit Wertes.

Ich habe schon vor und nach dem Multiplier FFs spendiert, es ändert sich 
aber nichts. Er meckert den Pfad von br_offs_reg nach br_val_xx_reg an:

br_offs ist ein signed mit 10 Bit, bra_val_xx_reg ein solcher mit 20 
bit.

Path 1  -0,59  10  20  mk_det/br_offs_reg[2]__0/C  mk_det/br_val_xx_reg[19]/D  5,56  3,21  2,35  5,00  clk_out1_synpll_200  clk_out1_synpll_200    0,06

Path 2  -0,57  9  20  mk_det/br_offs_reg[2]__0/C  mk_det/br_val_xx_reg[16]/D  5,55  3,20  2,35  5,00  clk_out1_synpll_200  clk_out1_synpll_200    0,06

Path 3  -0,57  9  20  mk_det/br_offs_reg[2]__0/C  mk_det/br_val_xx_reg[18]/D  5,54  3,19  2,35  5,00  clk_out1_synpll_200  clk_out1_synpll_200    0,06

und so weiter...

signal br_offs   : std_logic_vector( 9 downto 0) := (others => '0');
signal br_val_xx : std_logic_vector(19 downto 0) := (others => '0');

br_val_xx  <= std_logic_vector( signed (br_offs) * signed (br_offs));

Das net delay von 2,35 ns scheint mir sehr viel. Ich brauche 200 MHz.

An anderen Stellen der Schaltung in anderen Modulen hat er keine 
Probleme zwei Werte als signed zu multiplizieren, z.B. eine Skalierung 
eines Messwertes von 16 Bit mit 14 Bit zu 30 Bit.

Was wäre zu tun?

Ich habe für Synthese und Implementierung "performace retiming" 
eingestellt.

[Duke Scarring (Gast)]

Erstmal würde ich schauen, was er da synthetisieren will. Idealerweise 
sollte das inklusive der Register in einen DSP48-Block gemappt werden.

Wie das prinzipiell aussehen muß beschreibt Xilinx in den Synthesis User 
Guides.
Für Vivado steht ein Beispiel im UG901 (Complex Multiplier Examples).
Für XST findet sich eine ausführlichere Beschreibung im UG627 (Pipelined 
Multipliers HDL Coding Techniques).

Duke

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Und auch mal nach dem P&R schauen wo er die DSPs hinpflanzt. Das riecht 
danach, dass die DSPs sehr weit weg sind, weil in unmittelbarer Naehe 
keine verfuegbar sind. In dem Fall die FF Stage einfach mal erweitern 
und nochmal eine oder mehrere Stufen davorsetzen.

[Michael W. (Gast)]

Duke Scarring schrieb:
> Erstmal würde ich schauen, was er da synthetisieren will. Idealerweise
> sollte das inklusive der Register in einen DSP48-Block gemappt werden.

Ja, es wird ein DSP verwendet. Ob "alles" dort drin steckt sehe ich aber 
nicht. Ich habe inzwischen den Schaltungsausschnitt isoliert und alleine 
simuliert und gebaut und das Problem bleibt. Der Artix 324 kann in dem 
verbauten speed grade keine 200 MHz.

Ich fasse es nicht.

Das Perverse ist, dass ich nach all dem Herumprobieren mit 
Synthesekonstrukten nun bei einer optimierten Optimalversion gelandet 
bin, die 30% mehr FFs hat, fast 50% großer ist und dreimal so lange baut 
...

... und trotzdem ein mieseres Timing hat, als die default-Einstellung.

Mit welchen Einstellungen fährt man denn das aktuelle Vivado, dass er 
das beste Timing schafft?

[Michael W. (Gast)]

Tobias B. schrieb:
> Und auch mal nach dem P&R schauen wo er die DSPs hinpflanzt. Das riecht
> danach, dass die DSPs sehr weit weg sind, weil in unmittelbarer Naehe
> keine verfuegbar sind. In dem Fall die FF Stage einfach mal erweitern
> und nochmal eine oder mehrere Stufen davorsetzen.

Nein, das design ist noch ziemlich leer an der Stelle und wie schon 
geschrieben, habe ich mal alles andere weggelassen. Keine Verbesserung. 
Ich habe vor und nach dem Multiplier jeweils 3 FF-Stufen. Er kann also 
optimal platzieren. Ich glaube, der Chip kann nicht mehr. Ich nutze den 
speed grade 2.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Also 200 MHz muesste er eigentlich schaffen? Kannst du das minimale 
Design (oder ein aequivalentes Beispiel) mal irgendwo ablegen, damit man 
sich das anschauen kann?

Die DSPs koennen beim 2er Speedgrade ohne Pipeline bis 220 MHz takten. 
Der Global Clock Tree geht auch bis max. 628 MHz. Da muesste sich 
eigentlich was finden lassen das bei 200 MHz vernuenftig funktioniert.

[Michael W. (Gast)]

Gerade noch etwas gefunden:

Im Hauptdesign findet man bei anderen Multiplikationen, die breiter
sind, folgenden Hinweis:

****************************************************
DPOP #1 Warning DSP ...se/...xyz_reg output ...se/...xyz_reg/P[47:0] is
not pipelined (PREG=0). Pipelining the DSP48 output will improve
performance and often saves power so it is suggested whenever possible
to fully pipeline this function.  If this DSP48 function was inferred,
it is suggested to describe an additional register stage after this
function.  If the DSP48 was instantiated in the design, it is suggested
to set the PREG attribute to 1.
****************************************************

Dazu ist zu sagen, dass alle Multiplikationen implizit über VHDL gehen,
also keine DSPs instanziiert werden. Folglich kriegen die auch keine
ausdrücklichen Optionen von mir mit. Interessanzt ist, dass diese
Meldung weiter besteht, auch wenn ich weitere Register dahinter hänge.
Kann es sein, dass für die "breite Multiplikation" kein PREG möglich
ist? Oder macht die Synthese aus anderen Gründen das nicht richtig?

Wie auch immer, deren Timing scheint nicht das Problem, weil diese Pfade
geschafft werden! Interessant ist dabei, dass das kritische Register von
oben nicht angemeckert wird, in Sachen mangelndem pipelining, er aber
genau das nicht timen kann!

Es ist seltsam: Diese Multiplier haben nicht mehr Register dahinter
(zunächst sogar weniger) - er schafft aber das timing. Es ist daher um
so verrückter, dass er ausgerechnet die Quadrierung von nur 10 Bits
nicht hinbekommt. Die anderen Multis sind breiter, nur eben keine
Quadrierungen.

Zu wenige DSPs sind es nicht und auch ein placement-Problem würde ich
ausschließen: Insgesamt stehen genug zur Verfügung, es sind keine 20%
verbaut. Im isolierten Schaltungsdesign sind es < 10 Multiplier.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Markus W. schrieb:
> Dazu ist zu sagen, dass alle Multiplikationen implizit über VHDL gehen,
> also keine DSPs instanziiert werden.

Und wer entscheidet das keine DSPs verwendet werden? Die Vivado
Toolchain ist clever genug eine Multiplikation zu erkennen und
entsprechend einen DSP zu instanzieren.

Markus W. schrieb:
> Dazu ist zu sagen, dass alle Multiplikationen implizit über VHDL gehen,
> also keine DSPs instanziiert werden. Folglich kriegen die auch keine
> Optionen von mir mit. Interessant ist, dass das kritische Register nicht
> mehr angemeckert wird, in Sachen mangelndem pipelining.

Deshalb wuerde ich auch empfehlen, nicht blind im Nebel rumzustochern,
sondern sich das P&R Resultat anzusehen und mal den angemeckerten Pfad
aus dem Timing Report zu verfolgen. Dann sollte eigentlich relativ
schnell klar werden, wo das Problem liegt.

Wie gesagt: die Randbedingungen sind ein Klacks fuer den besagten Artix.
Das schreit nach einem unguenstigen Design und wenn du bereit bist mehr
davon preiszugegeben (oder zumidnest mal ein aequivalentes Beispiel,
welches das Problem reproduziert), kann man vll. sogar helfen. ;-)

[Strubi (Gast)]

Tobias B. schrieb:
> Deshalb wuerde ich auch empfehlen, nicht blind im Nebel rumzustochern,
> sondern sich das P&R Resultat anzusehen und mal den angemeckerten Pfad

.. oder einfach mal die RTL view bemuehen. Da lassen sich schon vorab 
eine Menge Probleme im Design analysieren. Wo wir im andern Thread 
gerade beim Dauerbrenner std_logic_arith waren: Man kann es auch 
schaffen, dass die Synthese unnoetige implizite Logik erzeugt und damit 
um die DSP48* Verstopfung auftreten kann.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Strubi schrieb:
> .. oder einfach mal die RTL view bemuehen.

Das setze ich als gegeben voraus. ;-)

[Michael W. (Gast)]

Tobias B. schrieb:
> Und wer entscheidet das keine DSPs verwendet werden?
Ich meinte damit, dass die DSPs nicht ausdrücklich- sondern indirekt 
intanziiert werden. Schon richtig. Nur habe ich bei einer Nutzung per 
"*" keine Möglichkeit, irgendwelche Einstellungen mitzugeben. Mich 
interessiert in dem Zusammenhang das mit dem PREG.

Ich hatte mich bisher nicht um solche Dinge gekümmert, weil es keine 
solchen schrägen Probleme mit Multiplikationen gab.

wie dargestellt, hat er ausgerechnet bei dem 10-Bit-Ding ein Problem. 
Ich denke, dass er das in fabric bauen möchte und scheitert.

Tobias B. schrieb:
> Deshalb wuerde ich auch empfehlen, nicht blind im Nebel rumzustochern,
> sondern sich das P&R Resultat anzusehen und mal den angemeckerten Pfad
> aus dem Timing Report zu verfolgen.

Dem ist nicht zu entnehmen, worin das Problem besteht und wie ich es 
lösen kann. Den Timing Report habe ich ja verfolgt und eben jenen Mul 
aufgefunden, der Ärger macht. Es ist nur nicht zu erkennen, wieso er da 
Probleme hat.

Ist es gfs zweckmässiger DSPs ausdrücklich zu instanziieren?


Strubi schrieb:
> Man kann es auch
> schaffen, dass die Synthese unnoetige implizite Logik erzeugt und damit
> um die DSP48* Verstopfung auftreten kann.
Ich hatte deshalb ja bereits vor und nach dem Mul 2 Stufen eingebaut. 
Das Ärgerliche ist, dass es dann teilweise schlechter wurde.

Ich habe, um das zu zeigen, alles wieder auf default gestellt und dann 
nochmals alles gelöscht. Dann wieder Timing Optimiert und Performce 
Explorer eingestellt und nun bringt er es knapp hin. 0,003 budget statt 
- 0,2xx. Schräg.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Markus W. schrieb:
> wie dargestellt, hat er ausgerechnet bei dem 10-Bit-Ding ein Problem.
> Ich denke, dass er das in fabric bauen möchte und scheitert.

Dann schau dir doch einfach mal an, was die Synthese aus deinem Code 
gemacht hat?

Markus W. schrieb:
> Dem ist nicht zu entnehmen, worin das Problem besteht und wie ich es
> lösen kann. Den Timing Report habe ich ja verfolgt und eben jenen Mul
> aufgefunden, der Ärger macht. Es ist nur nicht zu erkennen, wieso er da
> Probleme hat.

Ja wurde der Mul nun in Logik oder als DSP Slice realisiert?

Markus W. schrieb:
> Ist es gfs zweckmässiger DSPs ausdrücklich zu instanziieren?

Nein, sicher nicht. Im Zweifel nimmst das USE_DSP Attribut. Siehe UG901 
da wird genau erklaert was zu tun ist. Sollte bei 200 MHz aber wirklich 
egal sein.

Markus W. schrieb:
> Ich habe, um das zu zeigen, alles wieder auf default gestellt und dann
> nochmals alles gelöscht. Dann wieder Timing Optimiert und Performce
> Explorer eingestellt und nun bringt er es knapp hin. 0,003 budget statt
> - 0,2xx. Schräg.

Schau dir doch eifnach mal Synthese und P&R Resultate an und nicht nur 
den Report. Da siehst du doch genau was wie, wann, wo instanziert und 
verbunden wird. Es den Reports allein wirst du da nicht schlau.

Und wie gesagt: Wenn du das Beispiel zur Verfuegung stellst, dann ist 
das Ratzfatz mal angeschaut. Aber wenn du schon nur im Nebel 
rumstocherst, dann koennen andere mit den paar Infos auch nicht besser 
helfen. ;-)

[Michael W. (Gast)]

Tobias B. schrieb:
> Ja wurde der Mul nun in Logik oder als DSP Slice realisiert?
DSP!

Tobias B. schrieb:
> Und wie gesagt: Wenn du das Beispiel zur Verfuegung stellst,
Habe den code, der relevant ist doch gepostet. Der ganze Rest dreht sich 
um andere Dinge die damit überhaupt nichts zu tun haben.

[Gustl B. (-gb-)]

Strubi schrieb:
> .. oder einfach mal die RTL view bemuehen.

Zeigt leider nicht die Realität. Ich stelle das hier gerade nach und 
bekomme im RTL einen RTL_MULT und da wird Logik draus. Auf einem Artix7 
mit Speedgrade 1 schafft das keine 200 MHz.

Man kann die Attribute setzen:

attribute use_dsp48 : string;
attribute use_dsp48 of data_out : signal is "yes";

Der RTL Schaltplan bleibt dabei exakt gleich, wie zu erwarten, aber 
jetzt wird ein DSP48 verwendet. Aber da bekomme ich keine Timing 
Ergebnisse sondern diese Warnung:

[Place 46-29] place_design is not in timing mode. Skip physical 
synthesis in placer

Dann habe ich über den Wizard einen Multiplizierer eingebaut und der 
schafft das Timing.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Markus W. schrieb:
> Tobias B. schrieb:
>> Und wie gesagt: Wenn du das Beispiel zur Verfuegung stellst,
> Habe den code, der relevant ist doch gepostet. Der ganze Rest dreht sich
> um andere Dinge die damit überhaupt nichts zu tun haben.

Der Code Schnipsel ist nicht der relevante Teil, sondern das aussemrum, 
die Projektsettings, Constraints und alles was dazu gehoert. Wenn du das 
Projekt oder ein Minimalbeispiel zur Verfuegung stellen wuerdest, 
koennte man das einmal nachbauen, sich die Reports, den RTL View und 
alles relevante anschauen und man wuerde dem Problem ganz schnell auf 
die Schliche kommen.

Kann dann allerdings auch nicht so wichtig sein. ;-)

[Duke Scarring (Gast)]

Gustl B. schrieb:
> Strubi schrieb:
>> .. oder einfach mal die RTL view bemuehen.
>
> Zeigt leider nicht die Realität. Ich stelle das hier gerade nach und
> bekomme im RTL einen RTL_MULT und da wird Logik draus.

Da gibt es noch einen 'Technology View'. Der ist zwar noch 
unübersichtlicher, aber man sieht, was er wie mappen konnte.
Unter ISE gibt es noch den FPGA-Editor. Da kann man das fertige ncd-File 
einladen. Nicht erschrecken: die GUI vom FPGA-Editor ist sowas von 
90er-Jahre-Style ;-)

Duke

[Michael W. (Gast)]

Tobias B. schrieb:
> alles was dazu gehoert.

das gehört gewissermaßen dem Kunden und der wird nicht erfreut sein, 
sein Projekt in einem Forum wiederzufinden.

Es ging auch um die allgemeine Frage, was man grundsätzlich tun kann, um 
das Problem zu fassen. Ich sehe die Ursache inzwischen darin, dass er 
unglücklich routet und einige MUL bemüht, die weitab vom Schuss sind und 
daher mit großem delay daher kommen und dies, weil er diesen "kleinen" 
Multiplizierer zu letzt anfasst. Reine Theorie, aber das Routing Delay 
ist ungewöhnlich groß.

Unverständlich ist es so oder so, weil die Hinzunahme weiterer Einheiten 
im Design mit zusätzlichen "normalen" Multiplizierern, die nicht 
quadrieren, kein Problem mit dem timing aufwirft: Die Schaltung timed 
trotz größerer Flächenauslastung im FPGA sehr wohl, wenn man den 
Quadrierer weglässt.

Das ist für mich einfache ein Defizit des Werkzeugs.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Markus W. schrieb:
> Es ging auch um die allgemeine Frage, was man grundsätzlich tun kann, um
> das Problem zu fassen. Ich sehe die Ursache inzwischen darin, dass er
> unglücklich routet und einige MUL bemüht, die weitab vom Schuss sind und
> daher mit großem delay daher kommen und dies, weil er diesen "kleinen"
> Multiplizierer zu letzt anfasst. Reine Theorie, aber das Routing Delay
> ist ungewöhnlich groß.

Das hatte ich schon ganz am Anfang vermutet:

Beitrag "Re: Maximale Geschwindigkeit der Multiplier"

Das koenntest du aber via Pipelining in Griff bekommen, sofern die die 
extra Taktzyklen dir leisten kannst.

Markus W. schrieb:
> das gehört gewissermaßen dem Kunden und der wird nicht erfreut sein,
> sein Projekt in einem Forum wiederzufinden.

Deshalb die Frage ob du ein minimales Beispiel machen kannst, welches 
das Problem reproduziert. Alles raus, bis auf den DSP Part. Wenn du da 
auch schon Timing Probleme hast, kann man da relativ schnell 
nachvollziehen wo die Probleme liegen.

Im Zweifel schickst mir das Design mit NDA mal zu, dann gugg ich dir 
rein. Mehr faellt mir erstmal spontan nicht ein. :-(

Ich muss heute Abend noch ein paar stupide Loetaufgaben erledigen. 
Vielleicht hilft der meditative Charakter nochmal in Ruhe ueber das 
Problem zu senieren. :-)

[Michael W. (Gast)]

Tobias B. schrieb:
> Deshalb die Frage ob du ein minimales Beispiel machen kannst, welches
> das Problem reproduziert. Alles raus, bis auf den DSP Part.

Wie oben gepostet:

signal br_offs   : std_logic_vector( 9 downto 0) := (others => '0');

signal br_val_xx : std_logic_vector(19 downto 0) := (others => '0');

br_val_xx  <= std_logic_vector( signed (br_offs) * signed (br_offs));

[Gustl B. (-gb-)]

Also bei mir bekomme ich einen Timing Report. Aber damit der erstellt 
wird muss br_offs eingetaktet sein. Der Code sieht also so aus:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.ALL;
 
entity forum_mul_timing is port(
  CLK           : in  std_logic;
  br_offs       : in  std_logic_vector(9 downto 0);
  br_val_xx     : out std_logic_vector(19 downto 0));
end forum_mul_timing;
 
architecture rtl of forum_mul_timing is

signal br_offs_reg : std_logic_vector(9 downto 0):=(others => '0');

begin

process begin
  wait until rising_edge(CLK);
  br_offs_reg <= br_offs;
  br_val_xx  <= std_logic_vector(signed(br_offs_reg)*signed(br_offs_reg));
end process;

end;

CLK, br_offs und br_val_xx gehen direkt an FPGA IOs und CLK muss 
natürlich constrained sein.

Edit:
Beim Speedgrade 1 schafft der keine 200 MHz. Aber es wird auch kein DSP 
verwendet.

Edit2:
Und mit DSP via Xilinx IP schafft auch der Speedgrade 1 die 200 MHz. 
Weiterhin muss der (alle Beiden) Faktor getaktet sein damit ein 
Timingreport erzeugt wird.

library ieee;
use ieee.std_logic_1164.all;
 
entity forum_mul_timing is port(
  CLK       : in  std_logic;
  br_offs   : in  std_logic_vector(9 downto 0);
  br_val_xx : out std_logic_vector(19 downto 0));
end forum_mul_timing;
 
architecture rtl of forum_mul_timing is

component mult_gen_0 is port(
    CLK       : in  std_logic;
    A         : in  std_logic_vector(9 downto 0);
    B         : in  std_logic_vector(9 downto 0);
    P         : out std_logic_vector(19 downto 0));
end component;

signal br_offs_reg : std_logic_vector(9 downto 0):=(others => '0');

begin

inst_mult_gen_0 : mult_gen_0 port map(
    CLK       => CLK,
    A         => br_offs_reg,
    B         => br_offs_reg,
    P         => br_val_xx);

process begin
  wait until rising_edge(CLK);
  br_offs_reg <= br_offs;
end process;

end;

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Markus W. schrieb:
> Tobias B. schrieb:
>> Deshalb die Frage ob du ein minimales Beispiel machen kannst, welches
>> das Problem reproduziert. Alles raus, bis auf den DSP Part.
>
> Wie oben gepostet:signal br_offs   : std_logic_vector( 9 downto 0) :=
> (others => '0');
> signal br_val_xx : std_logic_vector(19 downto 0) := (others => '0');
> br_val_xx  <= std_logic_vector( signed (br_offs) * signed (br_offs));

Und wie geschrieben, das ist kein minimales Beispiel. Aber ok, dann 
musst deine HAusaufgaben halt selbst loesen. Wer nicht will der hat 
schon. ;-)

[my 50 Cents (Gast)]

Markus W. schrieb:
> Das net delay von 2,35 ns scheint mir sehr viel. Ich brauche 200 MHz.
Das sagt doch schon alles. Die eingehenden oder ausgehenden Signale 
sitzen an Punkten, die zu weit auseinander liegen. Das ist ein Problem 
der gesamten Verschaltung in Verbindung mit der mangelnden Fähigkeit des 
Routers, das timing beim Platzieren einzuhalten, entweder weil er es 
nicht geschickt macht, oder es eben wegen der Enge nicht können kann. 
Verdächtig ist hat das hier:

Markus W. schrieb:
> mit
> Synthesekonstrukten nun bei einer optimierten Optimalversion gelandet
> bin, die 30% mehr FFs hat, fast 50% großer ist und dreimal so lange baut

Die Vivado-Synthese scheint nicht der Weißheit letzter Schluss. Kenne 
das noch von XST. Was dort gebaut wurde, war ein Logik-Grab. Mit 
Werkzeugen von Drittherstellern waren unsere Schaltungen regelmäßig 20% 
kleiner und dafür 10% schneller. Sie wurden auch erheblich schneller 
gebaut, als mit XST.

Wahrscheinlich ist das "timing driven placement" noch nicht so 
ausgereift, dass es auch reine Kombinatorik optimal verteilt.

[Michael W. (Gast)]

my 50 Cents schrieb:
> Die Vivado-Synthese scheint nicht der Weißheit letzter Schluss.
Vor allem scheint es so zu sein, daß die Zwischenergebnisse, die er 
unterwegs oder aus voran gegangenen Syntheseläufen beibehalten hat, eine 
Rolle spielen und nicht unter einen Hut bekommt.

> Wahrscheinlich ist das "timing driven placement" noch nicht so
> ausgereift, dass es auch reine Kombinatorik optimal verteilt.
Wie könnte man das einstellen, um ihm mehr Freiheiten zu geben?

Im Explorer-Modus wird es teilweise besser, komischerweise aber auch 
schlechter.

[VHDL hotline (Gast)]

Markus W. schrieb:
> Wie könnte man das einstellen, um ihm mehr Freiheiten zu geben?

Was hast du denn jetzt eingestellt? Ist post_place_opt beim placer an? 
Machst du phys_opt_design zwischen placement und routing? Bzw. kannst du 
das auch iterativ aufrufen.

[Michael W. (Gast)]

VHDL hotline schrieb im Beitrag #6735688:
> phys_opt_design zwischen placement und routing?
möglicherweise ... (oder auch nicht)

Ich habe es auf maximale Timing-Performace (SYN + IMPL) stehen, nachdem 
ich alles gelöscht und zwischenzeitlich wieder alles auf default hatte.