mikrocontroller.net

Forum: FPGA, VHDL & Co. Multiplizierer, Addierer kombinatorisch beschreiben


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Christian Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte gerne einen 12bit Vektor erst mit einem 12bit-Faktor 
multiplizieren und dann einen 12bit signed-Wert addieren.

Leider habe ich dazu nicht viel Zeit und jeder Takt tut weh, den es 
länger dauert.

Gibt es die Möglichkeit die Multiplikation und dann auch die Addition so 
zu beschreiben, dass es sich um einen rein kombinatorischen Prozess 
handelt und das Ergebnis quasi nach der Gatterlaufzeit X zur Verfügung 
steht?

Die Multiplikation dürfte durch die seriell geschalteten Addierer 
limitiert sein...

Leider habe ich keine fertigen Multiplikationsblöcke, wie sonst im FPGA 
üblich.
Ob das vom Timing mit der Taktfrequenz (20-30MHz) machbar ist, muss ich 
dann nach der Synthese sehen. Jetzt geht es mir erstmal nur darum, wie 
ein solches "Rechenwerk" kombinatorisch beschrieben werden könnte.

Vielen Dank!
Chris

: Gesperrt durch Moderator
Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du mal versucht es einfach hinzuschreiben?
d = a * b + c;
Duke

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ob das vom Timing mit der Taktfrequenz (20-30MHz) machbar ist, muss ich
> dann nach der Synthese sehen. Jetzt geht es mir erstmal nur darum, wie
> ein solches "Rechenwerk" kombinatorisch beschrieben werden könnte.

Die gesamt Durchlaufzeit wird mit einer Zweittaktvariante besser sein.

1. Takt Multiplikation
2. Addtion

if rising_edge(clk) then
   k<=a*b;
   d<=k+c;

end if;

Der Code erzeugt ein Latch und das Ergebnis ist ist im zweiten Takt 
gültig.
Vorteil, es sind höhere Taktraten möglich.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René D. schrieb:
> Der Code erzeugt ein Latch und das Ergebnis ist ist im zweiten Takt
> gültig.

Ein Flip-Flop, kein Latch.

Autor: Christian Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank für die Antworten.

René D. schrieb:
> Die gesamt Durchlaufzeit wird mit einer Zweittaktvariante besser sein.
>
> Der Code erzeugt ein Latch und das Ergebnis ist ist im zweiten Takt
> gültig.
> Vorteil, es sind höhere Taktraten möglich.
Mein Ziel ist es nicht, eine möglichst hohe Taktrate zu erreichen.
Es geht mir darum die gesamte Rechnung bei ca. 25MHz kombinatorisch zu 
lösen.
Zwei Takte sind 80ns, die Gatterlaufzeiten sollten doch um ein 
Vielfaches kleiner sein?
if rising_edge(clk) then
   k<=a*b;
   d<=k+c;
end if;
Im ersten Takt wird k umgesetzt und im zweiten Takt ist das Ergebnis 
dann auf d gültig - zwei klassische Flip-Flops in meinem Weltbild. Aber 
genau die wollte ich vermeiden...

Mir geht es erstmal nur darum, die beiden Rechnungen in einem 
kombinatorischen Prozess zu beschreiben. Dann kann ich schauen, welche 
Taktraten ich erreichen kann.
Nur zur Beschreibung fehlen mit aktuell noch die Ideen.

Vielen Dank!
Chris

Autor: Bronco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Z. schrieb:
> Es geht mir darum die gesamte Rechnung bei ca. 25MHz kombinatorisch zu
> lösen.

Ich bin mir nicht sicher, ob ich Dich richtig verstehe.
Nehmen wir mal die Addition: Der eigentliche Addierer ist immer eine 
rein kombinatorische Logik, also ungetaktet. Es sind keine Flipflop 
darin vorhanden, sondern der Ausgang reagiert "direkt" auf die Eingänge.
Zwischen dem Zeitpunkt, wo man die Eingänge ändert und dem Zeitpunkt, wo 
die Ausgänge ein stabiles und korrektes Ergebnis annehmen, liegt eine 
Zeit t(x), die unabhängig von irgendwelchen Takten ist.
Wenn Du diesen Addierer in einem getakteten Prozeß verwendest, änderst 
Du die Eingänge mit dem Takt und Du liest den Ausgang mit dem Takt. Die 
Synthese muß nun versuchen, das ganze so aufzubauen, daß die genannte 
Zeit t(x) in einen Taktzyklus' hineinpaßt, d.h. das Ergebnis muß einen 
Takt später stabil und korrekt anliegen.
Es ist also für den Addierer egal, ob Du
c <= a + b;
in einen getakteten Prozeß hinsetzt oder nicht, der erzeugte Addierer 
wird immer nur kombinatorische Logik enthalten.

Autor: Christian Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und vielen Dank für die Antwort.

Genau das ist der Punkt.
Die Sache mit dem Addierer hätte man nicht besser auf den Punkt bringen 
können. So ist auch mein Verständnis. Nur in Verbindung mit der 
Multiplikation habe ich noch Probleme.
Eine Multiplikation sind ja auch nur ein paar Addierer in Reihe 
geschaltet, so dass hier das gleiche zutrifft wie für den Addierer mit 
seiner kombinatorischen Logik alleine.

Aber wie beschreibe ich die Geschichte nun mit Multiplikation und dann 
Addition, ohne das mit die Synthese dann ein FlipFlop dazwischen baut?

Dieses Bsp. hier, nur ohne getakteten Process, wird nicht reichen...
C = A * B;
E = C + D;
Vielen Dank!
Chris

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du schreibst einfach
y <= a * b + k;

fertig. (Evtl. noch die bitbreiten anpassen)

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hier:
y <= a * b + k;
ist genau das selbe wie das hier:
C = A * B;
E = C + D;
(eventuelle Tools-Schwaechen nicht beachtet...)

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Z. schrieb:
> Aber wie beschreibe ich die Geschichte nun mit Multiplikation und dann
> Addition, ohne das mit die Synthese dann ein FlipFlop dazwischen baut?

Hm. Ich bin kein Experte, aber ich kann mir schwer vorstellen, dass dir 
eine Multiplikation ohne Schieberegister so einfach gelingen wird. Der 
ein Multiplikant wird immer um eins geshiftet (so oft wie die (Breite-1) 
). Dann wird über alle Schieberegister und dem 2.ten Multiplikant 
bitweise addiert. Ohne Schieberegister könnte ich mich höchstens 
vorstellen, dass Du wirklich den Schaltplan von Hand zeichnen müsstes 
und über Logiken die Verschiebung des 1.ten Multiplikanten darstellst. 
Wird schon bei 4-Bit komplex. Volladdierer in kombinatorischer Logik 
sollte kein Problem sein. Das kriegt man mit Equivalenz-, UND- und 
ODER-Gliedern auch hin.

Warum willst Du keine FFs. Hast Du ein CPLD?

Autor: Christian Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hans schrieb:
> Warum willst Du keine FFs

Weil ein FF immer einen Takt Verzögerung bringt und genau das möchte ich 
gerne verhindern :)

Vielen Dank!
Chris

Autor: Auch Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Z. schrieb:
> Dieses Bsp. hier, nur ohne getakteten Process, wird nicht reichen...C = A * B;
> E = C + D;

Warum sollte das nicht reichen? "Schneller" geht halt nicht. Schreibst 
einfach sowas:
process (A, B, D) begin
  E <= A * B + D;
end process;
oder auch einfach nur
E <= A * B + D;
Ist ein nicht getakteter Prozess. Kein Flip Flop drin.
Was willst du denn noch mehr?

Autor: Bronco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
>> Aber wie beschreibe ich die Geschichte nun mit Multiplikation und dann
>> Addition, ohne das mit die Synthese dann ein FlipFlop dazwischen baut?
>
> Hm. Ich bin kein Experte, aber ich kann mir schwer vorstellen, dass dir
> eine Multiplikation ohne Schieberegister so einfach gelingen wird.

Beim Spartan3 gibt es tatsächlich einen "Embedded Multiplier", der ohne 
Takt auskommt, also rein kombinatorisch läuft.
www.xilinx.com/support/documentation/application_notes/xapp467.pdf
Allerdings wird ausdrücklich darauf hingeweisen, daß die Ergebnisbits 
unterschiedliche Laufzeiten haben, bis sie gültig werden.

Allerdings glaube ich, daß Du (OT) zu kompliziert denkst:
Wenn Du in einen getakteten Prozeß schreibst:
E <= A * B + D;
dann wird eine gute (!) Synthese alles daran setzen, daß die Berechnung 
in einem Takt fertiggestellt wird. Falls sie das nicht schafft, wird sie 
einen entsprechenden Fehler melden. Sie wird keine unnötigen FlipFlops 
einbauen, die die Berechnung verzögern.

Mit der Anweisung
E <= A * B + D;
beschreibst Du, was Du haben willst, nämlich das Ergebnis in einem Takt, 
und die Synthese muß gucken, wie sie das hinkriegt.

Autor: Klaus F. (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bronco schrieb:
> Allerdings glaube ich, daß Du (OT) zu kompliziert denkst:
> Wenn Du in einen getakteten Prozeß schreibst:E <= A * B + D;
> dann wird eine gute (!) Synthese alles daran setzen, daß die Berechnung
> in einem Takt fertiggestellt wird. Falls sie das nicht schafft, wird sie
> einen entsprechenden Fehler melden. Sie wird keine unnötigen FlipFlops
> einbauen, die die Berechnung verzögern.
>
> Mit der AnweisungE <= A * B + D;
> beschreibst Du, was Du haben willst, nämlich das Ergebnis in einem Takt,
> und die Synthese muß gucken, wie sie das hinkriegt.

Leute,
hier wird ziemlich viel Blödsinn geschrieben:
a) Die Synthese setzt das um, das in VHDL beschrieben wird.
Keine Synthese der Welt wird von sich aus zusätzliche Takte einfügen, 
wenn sie mit dem Timing nicht hinkommt.

Christian Z, bitte lies nochmals in deinem VHDL Buch das Verhalten von 
Signalen durch. Hier nochmals kurz (A,B,C,D,E sind Signale) :

a) Außerhalb eines Prozesses :
E <= A * B + C;
und
D <= A * B;
E <= D + C;

sind äquivalent und bilden keinerlei Latch und kein FFs, weil weit und 
breit kein Takt im Spiel ist. Bei der WEITERVERARBEITUNG von D oder E in 
einem getaktetem Prozess kann es zu FFs kommen.

b) Innerhelb eines GETAKTETEN Prozesses:
 
process(clk) 
begin
  if rising_edge(clk) then 
     E <= A * B + C;
  end if;
end process;
und
 
process(clk) 
begin
  if rising_edge(clk) then 
     D <= A * B;
     E <= D + C; 
  end if;
end process;

sind nicht äquivalent, da im Prozess die Zuweisung and D und E erst am 
Ende erfolgt und deshalb
E <= D + C;
noch mit dem "veralteten" Wert von D erfolgt.
E und D sind in diesem Falle FF's und E ist zu D nochmals um einen Takt 
verzögert.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans schrieb:
> Ich bin kein Experte, aber ich kann mir schwer vorstellen, dass dir
> eine Multiplikation ohne Schieberegister so einfach gelingen wird.
Eine Multiplikation ist einfach ein fortgesetzte und um ein Bit 
versetzte Addition. Natürlich geht das ohne Schieberegister.

Bronco schrieb:
> Beim Spartan3 gibt es tatsächlich einen "Embedded Multiplier", der ohne
> Takt auskommt, also rein kombinatorisch läuft.
In allen halbwegs zeitgemäßen FPGAs sind jeweils mehrere solcher 
Multiplizierer inzwischen Standard.

> Wenn Du in einen getakteten Prozeß schreibst:E <= A * B + D;
> dann wird eine gute (!) Synthese alles daran setzen, daß die Berechnung
> in einem Takt fertiggestellt wird. Falls sie das nicht schafft, wird sie
> einen entsprechenden Fehler melden.
Falls sie das nicht schafft, dann ist das der Synthese an sich erst mal 
komplett egal, denn ob Timing-Vorgaben (Constraints) eingehalten werden 
(können), das prüft erst Place&Route...

Autor: Korrektor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die MULS kombinatorisch aufzuziehen, macht meistens keinen Sinn mehr, da 
die Vereinfachungen durch das Zusammenfassen von Partialtermen nur dann 
richtig Flächenersparnis bringt, wenn mehrere MULS mit einfachen 
Bitkombis benutzt werden und statisch sind - dies aber zu sehr langen 
Pfade mit geringer fmax führt.

Einfach einen embedded MUL rein und fertig.

Autor: Bronco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Falls sie das nicht schafft, dann ist das der Synthese an sich erst mal
> komplett egal, denn ob Timing-Vorgaben (Constraints) eingehalten werden
> (können), das prüft erst Place&Route...
Erwischt! Ich neige dazu, die gesamte Toolchain als "Synthese" zu 
bezeichnen, obwohl sie ja nur ein Teile davon ist. Sorry.

Autor: Dani (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo zusammen,
ist ein Multiplikationblock stabil?

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dani schrieb:
> ist ein Multiplikationblock stabil?
NEUE Fragen bitte in einem NEUEN Thread stellen!

Und dann definierst du am besten gleich "stabil" in diesem 
Zusammenhang...

: Bearbeitet durch Moderator
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.