(VHDL) schlechtes Design, oder nicht?!

[Maik R. (kiamur)]

Hallo!

Ich hoffe es geht jetzt kein Aufschrei durch die (VHDL-)Nation, aber ich 
versuche mir jetzt seit einiger Zeit VHDL beizubringen, weiß aber eben 
manchmal nicht, ob das, was funktioniert auch gut ist.

Ich habe hier mal ein kleines Codeexperiment vorbereitet:

library ieee;
use ieee.std_logic_1164.all;

entity subtraction is
  port(  clk : in std_logic;
      output : out std_logic;
      minuend, subtrahend : in integer range 0 to 4095;
      differenz : out integer range 0 to 4095;
      compare : in integer range 0 to 4095);
end entity subtraction;

architecture arch of subtraction is

signal ergebnis : integer range 0 to 4095 := 0;

begin
  
  differenz <= ergebnis;
  
  process (clk) is
  begin
    if(clk'event and clk = '1') then
      ergebnis <= minuend - subtrahend;
      if (compare < ergebnis) then
        output <= '1';
      else
        output <= '0';
      end if; 
    end if;
  end process;
end architecture;

Quartus II schluckt das ganze ohne Probleme, und auch eine kleine 
Simulation mit den Werten

minuend = 1350, subtrahend = 555, compare = 344 und einem clk von 25MHz

läuft straight und "richtig" durch.

Allerdings kann ich im Simulator beobachten, wie z.B. das ermitteln der 
Differenz "langsam" von statten geht. D.h. das Ergebnis ist nicht sofort 
da, sondern es baut sich während des clk Signals auf.
Wenn dann die negative Flanke des clk Signals kommt. stehen beide 
Ergebnisse (differenz und output). Bei der nächsten steigenden Flanke 
könnte man diese also weiterverarbeiten.

Nun ist dieses Design ja nicht 100%ig "synchron", sondern auch 
"kombinatorisch", aber laut Simulator bei diesen Rahmenbedingungen doch 
hinreichend. Nun weiß ich aber durch eifriges lesen der Forumsbeiträtge 
hier, dass einige Mitglieder bei nicht synchronem Design die Hände über 
dem Kopf zusammeschlagen (Schönen Gruß an Falk ;-) ) . . .

Ist das nun ein aktzeptables Design, oder sollte man das Ganze doch 
total anders realisieren?

Das soll hier keine weiterführende Anwendung werden, sondern ist nur für 
mich zum Verstehen von "VHDL + Synthese = aktzeptables Ergebnis" . . .

Gruß
Maik

[Falk B. (falk)]

@ Maik Ritter

>Ich hoffe es geht jetzt kein Aufschrei durch die (VHDL-)Nation, aber ich

So schnell schreit die Nation nicht. ;-)

>Ich habe hier mal ein kleines Codeexperiment vorbereitet:

>Allerdings kann ich im Simulator beobachten, wie z.B. das ermitteln der
>Differenz "langsam" von statten geht. D.h. das Ergebnis ist nicht sofort
>da, sondern es baut sich während des clk Signals auf.

???
Je nach Simulationsmodus siehst du wahrscheinlich die 
Laufzeitverzögerungen der Signale. Das ist aber normal.

>Wenn dann die negative Flanke des clk Signals kommt. stehen beide
>Ergebnisse (differenz und output). Bei der nächsten steigenden Flanke
>könnte man diese also weiterverarbeiten.

Genauso funktioniert sequentielle Logik. Alles zu 100% im grünen 
Bereich.

>Nun ist dieses Design ja nicht 100%ig "synchron", sondern auch

???
Das ist ein ganz sauberes, synchrones Design. Warum denkst du, dass es 
nicht so ist?
Passt wunderbar.

MFG
Falk

[Maik R. (kiamur)]

>>Nun ist dieses Design ja nicht 100%ig "synchron", sondern auch

>???
>Das ist ein ganz sauberes, synchrones Design. Warum denkst du, dass es
>nicht so ist?
>Passt wunderbar.

Naja, ich dachte das halt, weil die Signallaufzeitverzögerung ja dieses 
"langsame" aufbauen des Ergebnisses bewirkt, wo ja eben nicht alles auf 
einen Schlag da ist.

Wenn das Design aber so gut aussieht, dann bin ich beruhigt.

Das mit den Integers in der Entity Deklaration ist aber sicher nicht so 
doll, oder ist das auch okay?

Gruß
Maik

[Falk B. (falk)]

@ Maik Ritter

>Naja, ich dachte das halt, weil die Signallaufzeitverzögerung ja dieses
>"langsame" aufbauen des Ergebnisses bewirkt, wo ja eben nicht alles auf
>einen Schlag da ist.

Auch die Lichtgeschwindigkeit ist endlich. Ausserdem, asynchrone 
Schaltungen sehen anders aus.

>Das mit den Integers in der Entity Deklaration ist aber sicher nicht so
>doll, oder ist das auch okay?

Naja, ich würde für die IO-Signale immer nur std_logic bzw 
std_logic_vector nehmen. Integers nur für Generics.

MFG
Falk

[Maik R. (kiamur)]

>Naja, ich würde für die IO-Signale immer nur std_logic bzw
>std_logic_vector nehmen. Integers nur für Generics.

Das dachte ich mir. Nuuur, dann kann ich ja nicht mehr so schöne 
arithmetische Berechnungen durchführen. Ich muss erst alles hin und her 
Casten. Hat das auch Einfluss auf mein Syntheseergebnis? Ich denke zwar 
nicht, denn der Hardware ist es doch egal, ob diese 12 Bit nun ein 
Integer oder ein std_logic_vector sind. Aber zur Sicherheit frage ich 
halt noch mal nach.

Gruß
Maik

[Falk B. (falk)]

@ Maik Ritter

>>Naja, ich würde für die IO-Signale immer nur std_logic bzw
>>std_logic_vector nehmen. Integers nur für Generics.

>Das dachte ich mir. Nuuur, dann kann ich ja nicht mehr so schöne
>arithmetische Berechnungen durchführen. Ich muss erst alles hin und her
>Casten.

Wieso das? Du kannst auch mit std_logic_vector wunderbar rechnen.

> Hat das auch Einfluss auf mein Syntheseergebnis?

Nein.

MfG
Falk

[TheMason (Gast)]

>Nuuur, dann kann ich ja nicht mehr so schöne arithmetische Berechnungen 
>durchführen.

sicher ?! probiers mal aus. :-)) std_logic_vector ist zwar nur eine 
ansammlung von bits, aber damit kann man ebenfalls rechnen (addieren, 
subtrahieren und multiplizieren), oder diese in integer umwandeln (wenn 
du lieber mit integern arbeitest). ich persönlich verwende (um 
synthese-fehler auszuschließen) die datentypen signed und unsigned (ist 
dann nichts anderes als ein std_logic_vector mit dem hinweis für den 
synthesizer das dieser vektor eben signed oder unsigned ist)

[Maik R. (kiamur)]

Okay, habe es mal ausprobiert. Ich habe jetzt einfach aus allen

integer range 0 to 4095

ein

std_logic_vector (11 downto 0)

gemacht.

Das frisst Quartus nicht. Fehlermeldung in der Zeile "ergebnis <= 
Minuend - subtrahend":

VHDL error at ....: can't determine definition of operator ""-"" -- 
found 0 possible definitions

Für mich hört sich das so an, dass der Minus Operator für 
std_logic_vector nicht definiert ist.

Habt ihr mal ein Beispiel parat, wo es doch funktioniert?

Gruß
Maik

[TheMason (Gast)]

versuchs mal mit unsigned

da std_logic_vector eine ansammlung von bits ist dürfte ein unsigned 
eventuell funktionieren.
dürfte aber eventuell eine eigenheit des quartus sein. bei ise (xilinx) 
geht das.

[T.M. (Gast)]

use ieee.numeric_std.all;

fehlt dafür noch in deinem Beispiel. Dann kannst du mit (un)signed 
rechnen wie mit integern.

[Maik R. (kiamur)]

Ja, jetzt haut es hin.

Ich verstehe nur eins nicht: Was sollen alle diese unterschiedlichen 
Typen, die ja doch nichts anderes sind, als (in diesem Fall) 12 Bits?

Wo ist jetzt für mich der Vorteil, wenn ich nun unsigned statt integer 
nehme? Ist das nur eine ästhetische Frage? Wohl kaum . . .

Gruß
Maik

[TheMason (Gast)]

durch std_logic_vector/unsigned/signed arbeitest du direkt mit den bits 
(du kannst dabei immer noch direkt auf die bits zugreifen, auch bei 
signed und unsigned). bei integer muß sich der synthesizer drum kümmern 
was du "meinst". (denk mal an die range eines integers die nicht 
zwangsweise auf einer potenz-grenze liegen muß, da muß der synthesizer 
erst mal ermitteln was du genau mit dem integer machen willst).
das verhalten bei den bit vektoren ist für den synthesizer klarer 
definiert, und somit auch "unmissverständlicher" (selbst wenn man das 
nicht so stehen lassen kann, da man immer noch genug fehlerquellen 
einbauen kann, obwohl die dann nicht direkt den bit-vektor betreffen 
müssen)

[Maik R. (kiamur)]

Auch wenn das jetzt hier etwas "off toppic" wird, aber warum gibt es 
denn überhaupt integers in einer Hardware Definition Language?
Genau diese Sache mit den Potenz-Grenzen wäre doch ein Grund solche 
Datentypen aussen vor zu lassen, da sie in der Hardware doch eh wieder 
von einem "Bitvektor" egal welcher Art repräsentiert werden müssen.

Dieses ganze VHDL konzept hat sich mir noch nicht so richtig 
erschlossen, da es einfach zu viele Dinge gibt, deren Sinn ich (noch) 
nicht sehe . . .

[TheMason (Gast)]

vhdl ist zwar eigentlich eine hardwarebeschreibungssprache bei der man 
meinen sollte das man sich auf low-level hardware-ebene befindet.
aber wenn es um die simulation geht braucht man eben solche konstrukte. 
selbst dateien kann man mit vhdl lesen. das das aber nur für die 
simulation sinnvoll (und auch machbar ist) steht auf einem anderen 
blatt, und darüber stolpern anfänger gerne (nach dem motto : ich warte 
10ns mit "wait for 10ns" und dann mache ich eine division, warum meckert 
ise/quartus denn dann).

[Haubndaucher (Gast)]

      ergebnis <= minuend - subtrahend;
      if (compare < ergebnis) then
        output <= '1';
      else
        output <= '0';
      end if;

Du weißt aber, dass der Vergleich ob compare < ergebnis ist, für die 
Zuweisung ergebnis <= minuend - subtrahend; erst einen Taktzyklus später 
ausgewertet wird?

Da hat bisher noch keiner was dazu gesagt und das wundert mich etwas.

[Maik R. (kiamur)]

@Haubndaucher:

Du hast Recht. Ist mir nach meinem ersten Post auch gleich aufgefallen. 
Ich dachte, es merkt keiner ;-)

>vhdl ist zwar eigentlich eine hardwarebeschreibungssprache

Mir kommt es so vor, als ob VHDL eigentlich eine Hardware 
Simulationssprache ist, und nur zweitrangig Hardware Beschreibung.

Auf alle Fälle würde ich gerne mal etwas finden, was auf beide Aspekte 
getrennt eingeht, bzw. die Unterschiede deutlich hervorhebt, damit man 
als Anfänger nicht solche blöden Fargen stellen muss. . . .

Gruß
Maik

[Falk B. (falk)]

@ Haubndaucher

>Du weißt aber, dass der Vergleich ob compare < ergebnis ist, für die
>Zuweisung ergebnis <= minuend - subtrahend; erst einen Taktzyklus später
>ausgewertet wird?

>Da hat bisher noch keiner was dazu gesagt und das wundert mich etwas.

Warum sollte da jemand was sagen? Das ist ganz normale Logic. Das 
Ergebnis wird halt über FlipFlops gespeichert und gleichzietig nochmal 
Retimed (schreckliches Denglisch).

>Mir kommt es so vor, als ob VHDL eigentlich eine Hardware
>Simulationssprache ist, und nur zweitrangig Hardware Beschreibung.

So ist sie auch entstanden. Erst nur Simulation, dann Synthese.

MFG
Falk