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:
1
libraryieee;
2
useieee.std_logic_1164.all;
3
4
entitysubtractionis
5
port(clk:instd_logic;
6
output:outstd_logic;
7
minuend,subtrahend:inintegerrange0to4095;
8
differenz:outintegerrange0to4095;
9
compare:inintegerrange0to4095);
10
endentitysubtraction;
11
12
architecturearchofsubtractionis
13
14
signalergebnis:integerrange0to4095:=0;
15
16
begin
17
18
differenz<=ergebnis;
19
20
process(clk)is
21
begin
22
if(clk'eventandclk='1')then
23
ergebnis<=minuend-subtrahend;
24
if(compare<ergebnis)then
25
output<='1';
26
else
27
output<='0';
28
endif;
29
endif;
30
endprocess;
31
endarchitecture;
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
@ 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
>>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
@ 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
>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
@ 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
>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)
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
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.
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
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)
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 . . .
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).
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.
@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
@ 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