Forum: FPGA, VHDL & Co. Latch bei Berechnung mittels FSM


von Martina M. (xaiven-be)


Angehängte Dateien:

Lesenswert?

Hallo,

ich muss eine recht komplexe Berechnung in HW realisieren. Hier als 
Lernbeispiel (num1*num2)+(num3*num4). Darf dafür nur einen 
Multiplizierer und einen Addierer verwenden. Habe jetzt mit der ISE 
10.1.03 einen IP-Core für die Multiplikation erstellt und den in mein 
Hauptfile (angehängt) eingebunden. Die sequentielle Berechnung erledige 
ich mit einer FSM, die nacheinander die Signale verteilt. Jetzt habe ich 
einige Fragen an die Profis.

1. Ist das eine gute und saubere Methode, diese Berechnung 
[(num1*num2)+(num3*num4)] durchzuführen?
2. Kann ich das dann so auch auf die Hardware bringen?
3. Werden mir die Latches zum Problem (Fehlerbericht hängt am nächsten 
Post)?

In der Simulation klappt das ja ganz gut... (Shot im nächsten Post)

Da ich heute schon einmal viel Hilfe erfahren habe, nochmals vielen 
Danke für die Antworten!

Viele Grüße
Martina

von Martina M. (xaiven-be)


Angehängte Dateien:

Lesenswert?

hier der Fehlerbericht.

von Martina M. (xaiven-be)


Angehängte Dateien:

Lesenswert?

... und hier die Sim-Ergebnisse.

von Gast (Gast)


Lesenswert?

Ich zitiere mal deinen output:
<One or more signals are missing in the process sensitivity list.
Daher würde ich auf deine SIM nichts geben.

Aber sag, was ist das für ein gigantisch schneller Core, der eine 
komplette ADDMUL-Operation in nur 6us schafft?

von Nephilim (Gast)


Lesenswert?

du hast irgendwie keinerlei rücksetzung der signale drin, durch nen 
reset oder so, dadurch könnten die latches entstehen.

obs inner handware so geht solltest rausfinden, wenne mal 
durchsynthetisierst und dann vielleicht nochmal simulierst.

von Martina M. (xaiven-be)


Angehängte Dateien:

Lesenswert?

Naja, ich bin für alle Vorschläge offen. Dachte, so kann ich das mit 
einer Art von FSM machen...

Später soll das auf einem Virtex4 laufen. Der hat diesen XtremeDSP48, 
aber wie schnell der das schafft, habe ich mir noch keine Gedanken 
gemacht. Habe einfach nur eine Testbench draufgelegt (im Anhang).

Martina

von Jan M. (mueschel)


Lesenswert?

Ganz einfach: In einem kombinatorischen Prozess (also ohne 
rising_edge(CLK)) muss jedes Signal in jedem Fall (hier: in jedem 
when-statement) zugewiesen werden, sonst -> Latches, timing-Probleme, 
Aerger.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Du hast keine Defaultwerte für mu1_a, mu1_b...
--> Latch, weil in kombinatorischem Prozess.

Vergiss die 2 Prozess-Schreibweise. Das geht viel übersichtlicher (und 
automatisch ohne Latches) in 1 Prozess (Anhang). Ich verwende (ohne 
jetzt irgendwelche Glaubenskriege hervorrufen zu wollen) nur noch 
1-Prozess SM, und das Leben ist einfacher und übersichtlicher geworden.

Ein Tipp:
Sieh dir mal die NUMERIC_STD Lib an. Die ist herstellerunabhängig und 
für Berechnungen viel besser geeignet.

EDIT:
Das mit der Simulation hatte ich schon im anderen Post erwähnt. Mein 
Verdacht hat sich bestätigt (dein kombinatorischer Prozess). Mit der 
1-Prozess SM Schreibweise passiert sowas nicht.

EDIT2:
Im angehängten File ist noch ein Typo. Die Startbedingung muß korrigiert 
werden. Richtig ist:
1
      :
2
      when st0_idle =>
3
        if (num1 /= (others=>'0') ) then
4
--           state <= st0_idle;     FALSCH
5
           state <= st0_calc1;
6
        end if;
7
      when st1_calc1 =>
8
      :
Aber diese Startbedingung ist sowieso etwas zwielichtig ;-)

von Martina M. (xaiven-be)


Lesenswert?

Vielen, vielen Dank!
Habs jetzt gleich mal versucht, bekomme aber zwei Fehlermeldungen:

Zeile:
if (num1 /= (others=>'0') ) then
Fehler:
Can not determine the "others" values in aggregate. (LRM 7.3.2.2)
mit num1/= "0" gehts.

Aber hier:
result <= result12 + result34;
Fehler:
+ can not have such operands in this context.
... das verstehe ich jetzt gar nicht.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> use IEEE.NUMERIC_STD.ALL;
Mea Culpa: stell das (vorübergehend) wieder auf deine "alten" Libs um.
NUMERIC_STD kann nicht mit STD_LOGIC_VECTOR rechnen.
Dafür gibts dann UNSIGNED und SIGNED.

von Martina M. (xaiven-be)


Lesenswert?

das mit den libs habe ich gerade auch gesehen. Mit den alten gehts. 
SUPER!!! Vielen, vielen Dank!!!!

Die Startbedingung hatte ich mir so überlegt, dass mit die SM nicht 
einfach "davonläuft", sondern erst anfängt, wenn ein Signal kommt. Jetzt 
muss ich bei deiner Version nur noch schnell einen Endstatus einbauen, 
sonst fängt die gleich wieder von vorne an und die Signal haben in 
meiner Testbench gar keine Zeit.

Demnach kann man solche solche Berechnungn in dieser Art machen, ohne 
dass Profis gleich die Hände über dem Kopf zusammenschlagen?

EDIT:
jetzt habe ich noch ein Problem, das
1
when st2_calc2 =>
2
        result12 <= mu1_product;  
3
        state <= st3_calc3;
wird nicht von result12 übernommen. Das Problem hatte ich bei meiner 
Version auch schon. Als ich dann clk in die Sensitiv-List übernommen 
habe, hats geklappt.

von Martina M. (xaiven-be)


Lesenswert?

mh.. jetzt kann ich meinen Post nicht mehr editieren...

habs jetzt hinbekommen. Das liegt wohl an dem DSP. Wenn ich
1
wait until falling_edge(clk);
verwende, dann klappt das alles!!

Mensch super. Kann euch gar nicht genug danken. Nach so einem 10h Tag 
ist das ein gutes Gefühl wenn alles (zumindest der erste Schritt) 
funktioniert. Und mit nur einer Warnung (Instantiating black box module 
<mult20x20>), die wohl nicht besonders wichtig ist.

Einen schönen Abend dem ganzen Board.

Martina

EDIT:
habs gerade hier im Forum gefunden.
Matthias wrote:
> Das eine Warnung, keine Fehlermeldung. Und sie sagt genau das richtige
> aus, nämlihc das die Komponenten nicht synthetisiert werden, weil sie
> eben schon fertig als Hardware vorliegen, und dann im späteren Map
> Schritt einfach verwendet werden.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> habs jetzt hinbekommen. Das liegt wohl an dem DSP. Wenn ich
>> wait until falling_edge(clk);
> verwende, dann klappt das alles!!
Naja, ein wenig riechen tut das schon noch... :-/
Wieviele Takte braucht dein Multiplier?

von Martina M. (xaiven-be)


Angehängte Dateien:

Lesenswert?

Hallo,

habe mich den ganzen Morgen mit den Timing beschäftigt. Falls ich das 
Datenblatt richtig verstanden habe (Anhang, copyright by Xilinx) braucht 
ein DSP 3 Takte. Allerdings werden für die 20x20 Bit Berechnung 4 DSPs 
benötigt, die hintereinander beschaltet sind.
Ich habe ja bis jetzt nur eine Behavioral-Simulation laufen lassen. Die 
sagt mir ja wenig darüber aus, wie lange das wirklicht dauert. Oder?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Warum verwendest du nicht einfach einen generischen Multiplizierer?
Sowas z.B.:
1
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
use IEEE.NUMERIC_STD.ALL;
4
5
entity Multiply20x20 is
6
    Port ( clk : in  STD_LOGIC;
7
           val1 : in  STD_LOGIC_VECTOR (19 downto 0);
8
           val2 : in  STD_LOGIC_VECTOR (19 downto 0);
9
           res : out  STD_LOGIC_VECTOR (39 downto 0));
10
end Multiply20x20;
11
12
architecture Behavioral of Multiply20x20 is
13
begin
14
   res <= std_logic_vector(unsigned(val1) * unsigned(val2));
15
end Behavioral;
> Maximum combinational path delay: 16.151ns
Damit ergibt sich eine rechnerische Taktfrequenz von 62MHz.


Mit ein paar Pipeline-Rgistern wird das Ganze schon schneller, 
allerdings auf Kosten von 2 Takten Latency.
1
library IEEE;
2
use IEEE.STD_LOGIC_1164.ALL;
3
use IEEE.NUMERIC_STD.ALL;
4
5
entity Multiply20x20 is
6
    Port ( clk : in  STD_LOGIC;
7
           val1 : in  STD_LOGIC_VECTOR (19 downto 0);
8
           val2 : in  STD_LOGIC_VECTOR (19 downto 0);
9
           res : out  STD_LOGIC_VECTOR (39 downto 0));
10
end Multiply20x20;
11
12
architecture Behavioral of Multiply20x20 is
13
signal resreg1, resreg2 : STD_LOGIC_VECTOR (39 downto 0);
14
begin
15
   process begin
16
      wait until rising_edge(clk);
17
      resreg1 <= std_logic_vector(unsigned(val1) * unsigned(val2));
18
      resreg2 <= resreg1;
19
      res     <= resreg2;
20
   end process;
21
end Behavioral;
> Minimum period: 4.844ns (Maximum Frequency: 206.447MHz)
Na, wer sagts denn ;-)

von Martina M. (xaiven-be)


Lesenswert?

Hallo

so langsam werde ich mit der ISE vertraut. Habe im Synthesis Report 
gefunden, wie schnell ich mit dem DSP-Core arbeiten kann:

>Minimum period: 2.675ns (Maximum Frequency: 373.825MHz)
>Minimum input arrival time before clock: 2.847ns
>Maximum output required time after clock: 3.753ns
>Maximum combinational path delay: No path found

Habe jetzt ein paar Mal eine Post-Route Sim laufen lassen (dauert leider 
immer 15 Minuten...), wobei ich aber mindestens eine clk-Periode von 5ns 
brauche.
Mit 4, 3 oder gar 2.675ns bekomme ich das Ergebnis nicht.
Werde jetzt das Design mal mit den generischen Multiplizierer testen, 
ist dann vielleicht "durchsichtiger".

Möchte mich an dieser Stelle noch einmal ausdrücklich für die super 
und ausdauernde Hilfe hier bedanken ! Macht den Einstieg erheblich 
einfacher und effizienter. Freut mich sehr, dass Anfänger hier so nett 
und kompetent geholfen wird!

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.