mikrocontroller.net

Forum: FPGA, VHDL & Co. VHDL Grundlagen : Rechnen


Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VHDL scheint etwas umständlich zu sein, wenn man etwas berechnen will.
Im Moment will ich eine 24Bit Zahl mit einer 8 Bit Zahl multiplizieren.
signal sineWaveSignal  :  std_logic_vector(15 downto 0);
signal mixerSum : std_logic_vector(23 downto 0)  ;
signal amplitude : std_logic_vector(7 downto 0)  ;
...
mixerSum <= std_logic_vector(to_signed( to_integer(signed(sineWaveSignal)) * to_integer(unsigned(amplitude)) )) ;

So weit ich aus dem Datenblatt meines FPGAs ( MACHX02 ) erkennen kann, 
hat es keine Hardwaremultiplizierer. Deshalb frage ich mich, ob die 
Multipliktion oben nicht zu viele Resourcen verbraucht.

Ausserdem gibt es noch ein Problem:
Obwohl die obige Multiplikation mit Lattice Diamond compiliert werden 
kann, wirft Symplyfy Pro diesen Fehler:
E  CD371  No matching overload for to_signed  error

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> VHDL scheint etwas umständlich zu sein, wenn man etwas berechnen will.
Wenn man nicht die richtigen Typen verwendet, dann stimmt das. Ansosnten 
ist VHDL eben sehr restriktiv, was die Typumwandlung angeht, einfach so 
implizit von z.B. float nach integer wie in C gaht das nicht:
i = f;
Sondern da braucht man schon die passenden Routinen und Umwandlungen.

> Im Moment will ich eine 24Bit Zahl mit einer 8 Bit Zahl multiplizieren.
Sieh dir numeric_std an: die Multiplikation ist auch für Vektoren 
definiert:
https://www.csee.umbc.edu/portal/help/VHDL/package...
Dmit könntest du also schon mal so rechnen:
mixerSum <= std_logic_vector(signed(sineWaveSignal) * unsigned(amplitude));
Allein das signed*unsigned könnte noch Probleme bereiten. Aber probiers 
einfach aus...

> So weit ich aus dem Datenblatt meines FPGAs ( MACHX02 ) erkennen kann,
> hat es keine Hardwaremultiplizierer. Deshalb frage ich mich, ob die
> Multipliktion oben nicht zu viele Resourcen verbraucht.
Ausprobieren.

chris schrieb:
> Obwohl die obige Multiplikation mit Lattice Diamond compiliert werden
> kann
Überraschend.
> wirft Symplyfy Pro diesen Fehler
Klar. Sieh dir mal in der numeric_std an, wie to_signed() definiert ist. 
Oder suche
http://www.lothar-miller.de/s9y/categories/16-Numeric_Std

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Deshalb frage ich mich, ob die
> Multipliktion oben nicht zu viele Resourcen verbraucht.

Das wird sie vermutlich, das hat aber nichts mit den ganzen 
Typumwandlungen zu tun, sondern, weil ein großes Netz aus 
kombinatorischer Logik erzeugt wird, welches dann auch recht langsam 
sein wird (bzgl. der maximalen Taktfrequenz).
Wobei 8x16 noch gemäßigt ist, aber es hängt natürlich vom restlichen 
Design ab, ob der Ressourcenverbrauch angemessen ist.

Wenn der Ressourcenverbrauch ein Problem ist, wirst Du einen 
sequenziellen Muliplizierer verwenden müssen (entweder selbstgeschrieben 
oder einen Core), der ist dann kleiner, aber braucht natürlich mehr als 
einen Taktzyklus für eine Multiplikation. Und lässt sich nicht mehr in 
einer Zeile beschreiben.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Antworten.

>Obwohl die obige Multiplikation mit Lattice Diamond compiliert werden
>kann, wirft Symplyfy Pro diesen Fehler:

Mittlerweile habe ich den Fehler gefunden: Für "to_signed" braucht man 
die Längenangabe in bits.
mixerSum <= std_logic_vector(to_signed( to_integer(signed(sineWaveSignal)) * to_integer(unsigned(amplitude)),24 )) ;

Intersssant ist, dass Dyamond compiliert ( Das Programm dann aber nicht 
läuft ), während Symplify Pro den Fehler gleich zeigt.

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Das Programm

Tststs. Das haben wir jetzt aber nicht gelesen :-)

Nimmt Diamond vllt eine Standard-Wortbreite an (z.B. 32Bit), wenn nichts 
anderes angegeben ist? Die Frage ist dennoch, warum es nicht 
funktioniert.

Autor: chris (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>Nimmt Diamond vllt eine Standard-Wortbreite an (z.B. 32Bit), wenn nichts
>anderes angegeben ist? Die Frage ist dennoch, warum es nicht
>funktioniert.
Keine Ahnung, aber egal, das Problem ist ja gefunden und wird fürderhin 
ignoriert. Ich hatte bei Diamond auch schon den Fall, das irgendwo im 
"!Programm!" ein Semikolon statt ein Komma war und dann einfach nur ein 
Fehler in der linken oberen Position des "!Programms!" angezeigt wurde 
und die einzige Möglichkeit der Fehlersuchen war, den gesammten Text 
Schritt für Schritt zurück zu bauen und irgendwann da Problem zu finden.

>Tststs. Das haben wir jetzt aber nicht gelesen :-)
War''s nicht unentschieden?
Beitrag "Re: Programmierung von FPGAs"

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> War''s nicht unentschieden?
Anfänger haben in einem FPGA mit einer Hardwarebeschreibungssprache 
nichts zu programmieren. Denn sonst programmieren sie genauso wie auf 
einem uC auch auf einem FPGA nach dem Try-and-Error Verfahren vor sich 
hin.

> das irgendwo im "!Programm!" ein Semikolon statt ein Komma war
Kurios. Mit welcher Fehlermeldung? Und weißt du noch, wo "irgendwo" 
genau war? Denn normalerweise schafft es der Parser durchaus, die 
Beschreibung in einzelne Blöcke zu zerlegen.

Autor: Edi. M. (Firma: Industrie 1.0) (elektromeister)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vancouver schrieb:
> Nimmt Diamond vllt eine Standard-Wortbreite an (z.B. 32Bit), wenn nichts
> anderes angegeben ist?

Ich glaube eher, er überträgt die Wortbreite des Eingangsvektors und 
durch die Multiplikation stimmt das Ergebnis nicht. Bei zweimal signed 
kommt nämlich weniger raus.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Ich hatte bei Diamond auch schon den Fall, das irgendwo im
> "!Programm!" ein Semikolon statt ein Komma war
U.a. deswegen entwickele ich die Designs erstmal im Simulator.
Gefühlt mehr als 90% der Fehler lassen sich dort finden (und 
eliminieren)...

Duke

Autor: Vancouver (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
chris schrieb:
> War''s nicht unentschieden?

Was mich betrifft, ist es längst entschieden. Meine Studenten 
"programmieren" auch am Anfang, und da kommt allerley lustig' Ding 
heraus. Erst allmählich lernen Sie, dass das Ziel eine RTL-Architektur 
ist und kein Maschinenprogramm. Dann fangen sie an zu modellieren und ab 
da nähern wir uns schrittweise der Spezifikation. Der selbe Weg, den ich 
vor 20 Jahren auch gegangen bin. Aber diese Diskussion ist so fruchtbar 
wie die um Windows/Linux, Perl/Python oder Spiegelreflex/Smartphone und 
es tut mir schon wieder leid, dass ich überhaupt damit angefangen habe.


@Duke Scarring (Gast)
> U.a. deswegen entwickele ich die Designs erstmal im Simulator.

Ich kenne ein paar Masochisten, in deren Augen die Simulation etwas für 
Weicheier ist. Wenn's nicht läuft, wird ein ILA-Core reindesigned, der 
60% der Blockrams auffrist (da muss man dann eben Teile des Designs 
erstmal weglassen, damit es passt) und dann auf dem blanken Silizium 
debuggt. Das sind noch echte Männer :-)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vancouver schrieb:
> Ich kenne ein paar Masochisten, in deren Augen die Simulation etwas für
> Weicheier ist.
Und ich kenne ein paar Weicheier, in deren Augen die Simulation etwas 
für Masochisten ist...  ;-)

Ich bringe meinen Praktikanten und angehenden Ingenieuren die Simulation 
schon an der blinkenden LED und am Lauflicht bei (das dürfen die auch 
machen, wenn sie schon "fit in VHDL" sind, denn man lernt nie aus). Die 
begreifen den Vorteil des Simulators dann recht schnell, wenn sie zur 
seriellen Schnittstelle kommen.

Autor: chris (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Arghh .. eigentlich wollte ich diesen Thread für die Rechengrundlagen 
nehmen ...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Arghh .. eigentlich wollte ich diesen Thread für die Rechengrundlagen
> nehmen ...
Damit waren wir doch schon durch... oder kommt noch was?

Aber mal zurück zum Anfang. Ich habe das ausprobiert und bekomme mit der 
fraglichen Zeile in der angehängten Beschreibung durchaus einen Fehler 
und vorneweg zwei Infos, die das Fehlen der Breite anmeckern:
INFO - c:/.../multiplier.vhd(22): input pin size has no actual or default value. VHDL-9000
INFO - C:/lscc/diamond/3.8_x64/ispfpga/vhdl_packages/numeric_std.vhd(718): size is declared here. VHDL-1259

ERROR - c:/projekte/fpga/lattice/mul_test/multiplier.vhd(22): expression has 25 elements  expected 24. VHDL-1077
Done: error code 2
Zielplattform war ebenfalls MachXO2. Der Synthesizer war der von 
Lattice.

Die Synplify Lattice Version sagt dazu:
E  CD371  No matching overload for to_signed  multiplier.vhd (22)  multiplier.srr (22)  error

: Bearbeitet durch Moderator
Autor: Edi. M. (Firma: Industrie 1.0) (elektromeister)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hier scheint eine Ansammlung von Lehrtätigen zu sein, wenn man euch 
dreien so zuhört. Ich finde es nett, wenn hier eine Grundlagenserie 
aufgelegt wird, allerdings sollte das nicht von einem "chris" anonymous 
geschehen, der von VHDL noch weniger Ahnung hat, als Ich.

Ich kann mal beisteuern wie Ich das gemacht habe:

Studium ohne VHDL
2 Jahre Analogdesign
3 Jahre Digitaldesign
dann mit 5 Jahren Berufserfahrung die ersten PLDs und FPGAs
erst Eingabe mit Xilinx auf Gatterebene, dann VHDL
nie einen VHDL-Kurs gehabt, aber auch nie ein grösseres Problem
Studenten, die Ich treffe, können zwar alle VHDL, kennen aber keine 
Schaltungstechnik.

Ob das gut geht?

Autor: Ale (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hei Chris, 'ne Frage:

Kann es sein daß du den "Lattice LSE" anstatt Synplify Pro ausgewählt 
hast ?... mir kommt komisch vor daß Diamond, das Synplify direkt nutzen 
kann gibt andere Fehlermeldungen als Synplify.

Rechte Maustaste auf "impl1" und dann Systhesis Tool "Synplify Pro" :D

(Btw, Der Synplify chokes mit Bestimmte Syntax Fehlern... machmals 
stürzt einfach ab... nicht immer lustig :(


Noch eine Sache:

> implizit von z.B. float nach integer wie in C gaht das nicht:
> i = f;


Das ist eine abomination ! Und die vielen Typen in VHDL auch. Reg und 
wire ist alles was Man(n) braucht :).

Weiß du, der Diamond kann dir ein Multiplizierer bauen :) :

IPExpress und dann Arithmetic_Modules, gibt es alles: mul, mul+add, 
mul+add+sub. Ja, es wird nicht "Portabel"... noch ein Märchen :)

Autor: chris (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Edi. M. Altingenieur (Firma: Solide Industriebude) (elektromeister)
>Hier scheint eine Ansammlung von Lehrtätigen zu sein, wenn man euch
>dreien so zuhört. Ich finde es nett, wenn hier eine Grundlagenserie
>aufgelegt wird, allerdings sollte das nicht von einem "chris" anonymous
>geschehen, der von VHDL noch weniger Ahnung hat, als Ich.

Wie stellst Du Dir das vor? Ich arbeite mich gerade in das Thema ein und 
stelle dazu Fragen. Die Fragen werden von erfahrenen Leuten beantwortet 
und jeder der mit liest, kann daraus lernen.
Gleichzeitig versuche ich immer irgendwo im Thread ein letztlich 
funktionierendes Code-Beispiel zu posten, damit der Thread auch am Ende 
ein nützliches Ergebnis liefert und für mich zu einem späteren Zeitpunkt 
als Nachschlagewerk dienen kann.

Ich habe mir sehr viele Dinge autodidaktisch beigebracht. Tatsächlich 
muss man das wohl, weil sich die Softwarewelt so rasant ändert.
Bei vielen anderen Leuten habe ich aber festgestellt, dass sie sich auf 
bestimmte Vorgehensweisen und Programmierstile "einschießen" die 
eigentlich umständlich und ineffizient sind.
Das kann man bis zur Realisierung von sehr komplexen Projekten 
durchziehen. Da habe ich schon einige Leute kennen gelernt.
Aus diesen Grund schreibe ich die Grundlagenthreads, um zu lernen, wie 
etwas effizient geht, und eventuell auch ein Experte von einem zweiten 
mit einer besseren Lösung korrigiert werden kann.

Ich denke, dieses Vorgehen ist genau das Richtige für einen Lern-Thread. 
Es hat eine ganz anderen Nutzen als das Lesen von Büchern, weil es nur 
sehr wenige "Bestseller" gibt und die meisten Autoren nun mal keine 
"Bestsellerautoren" sind. Gute Lehrbücher entstehen durch Interaktion 
der Lehrenden und Lernenden und nicht jeder Lehrer passt zu einem 
bestimmten Schüler.

 Edi. M. Altingenieur (Firma: Solide Industriebude) (elektromeister)
>der von VHDL noch weniger Ahnung hat, als Ich.
Darf ich fragen, welche Erfahrungen Du in VHDL hast?

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ale schrieb
>Kann es sein daß du den "Lattice LSE" anstatt Synplify Pro ausgewählt
>hast ?... mir kommt komisch vor daß Diamond, das Synplify direkt nutzen
>kann gibt andere Fehlermeldungen als Synplify.

Das stellst Du eine sehr spezifische Frage. Ich wusste gar nicht, dass 
man beides einstellen kann. Mal schauen, ob das noch irgendwie 
reproduzierbar ist ...
Andererseits: Das Syntaxproblem ist ja gefunden und ich mach's einfach 
in Zukunft richtig ... vielleicht ;-)

Autor: Steini (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Chris, viele Deiner Fragen werden in Grundlagenbüchern exzessiv 
behandelt und abgewickelt. Statt Dich selber mit Probieren 
einzuarbeiten, wäre wirklich empfehlenswert, ein Fachbuch zu holen. Dann 
bist Du auch nicht auf dubiose Redner mit Halbwissen angewiesen, deren 
Wissen Du nicht überprüfen kannst.

Rechnen in VHDL ist eigentlich einfach, du musst nur die richtige 
Library verwenden:

Du hast die Möglichkeit, direkt auf den Bits zu rechnen, was am Besten 
zu kontrollieren und nachzuvollziehen ist, besonders später in Hardware. 
Dies empfiehlt sich bei einfachen Operationen wie Zählen und dem Rechnen 
mit direkt von Eingang kommenden Daten, die eh wieder als Vektor raus 
müssen. Der Aufwand ist dann überschaubar und nur die Formulierung 
aufwändiger.

Für komplizierte mathematische Operationen lohnt die Konvertierung in 
signed integer und das Rechnen mit echten Integerdatentypen, die dann 
erst vom Compiler auf Bits umgesetzt werden. Da ist die Formulierung 
nicht komplizierter, als in C, es geht nur der direkte Zusammenhang zu 
den Bits verloren, die Du irgendwann mal kontrollieren möchtest.

Für beide Anwendungsfälle gibt es genügend Beispiele und Begründungen.

Autor: chris (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
>Für beide Anwendungsfälle gibt es genügend Beispiele und Begründungen.

Ja, aber Foren sind für Diskussion da. Wenn jemand keine Lust darauf 
hat, einfach weg bleiben.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es scheint tatsächlich einen Unterschied zwischen der Compilierung mit 
SympliFy und Diamond zu geben.

Während Diamond diesen Ausdruck compiliert
table: for i in 0 to 255 generate
 Sinus_Rom(i) <= to_signed(integer( sin(2.0*MATH_PI*(real(i)+0.5)/1024.0) *32767.0),16);
end generate;

Wirf Symplify diese Meldung:
E  CD351  Can't implement expression type E128 yet  (57)  13:55:16 Fri 
Oct 13  error

Mit dem expression type meint er den "sin"...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
chris schrieb:
> Symplify
Sy-n-plify, das kommt von grundlegend "Synthese" und erst nachrangig vom 
englischen "vereinfachen".

> Wirf Symplify diese Meldung
Nur diese, sonst nichts? Keine Warnung, keine Info?

> E  CD351  Can't implement expression type E128 yet  (57)
> Mit dem expression type meint er den "sin"...
Wie kommst du darauf?
Dort steht "expression type E128". Mich würde das E128 interessieren...

Lass doch mal den ganzen Code sehen...

: Bearbeitet durch Moderator
Autor: Edi. M. (Firma: Industrie 1.0) (elektromeister)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
>>der von VHDL noch weniger Ahnung hat, als Ich.
> Darf ich fragen, welche Erfahrungen Du in VHDL hast?

Darf Ich fragen, wieviel Erfahrung Du im Lesen hast? Ich habe es in dem 
Beitrag, auf den Du antwortest, indirekt geschrieben. Ich gebe dir aber 
noch einen Tipp: Das Studium wurde in den 80ern aufgenommen. Du darfst 
jetzt rechnen.

Autor: chris (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
>dann mit 5 Jahren Berufserfahrung die ersten PLDs und FPGAs
>erst Eingabe mit Xilinx auf Gatterebene, dann VHDL

Da steht nicht, ab wann Du VHDL gemacht hast und welche Projekte.
Also: ab wann und welche Projekte?

Autor: Edi. M. (Firma: Industrie 1.0) (elektromeister)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da es mit dem Rechnen oder Schätzen so schwierig wird: Seit etwa 20 
Jahren immer mal wieder. Auch "Rechnen".

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Dort steht "expression type E128". Mich würde das E128 interessieren...
> Lass doch mal den ganzen Code sehen...

Da scheint irgendein Exponent im Spiel, falsch deklrairert oder was auch 
immer. Richtig?

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Edi. M. schrieb:
> Hier scheint eine Ansammlung von Lehrtätigen zu sein,

Ja, das ist wohl so. Man merkt es, daß die Jungs nen Abstand zur Praxis 
haben. Aber das Problem ist ubiquitär, beim Thema digitale 
Signalverarbeitung ist es exakt das Gleiche.

Ich sag's mal so: Um eine Plastikkiste mit nem FPGA drin herzustellen, 
die man dann im Mediamarkt für 199€ verkaufen kann (und mit den Steuern 
dann auch unsere akademischen Gefilde zu ernähren), braucht man ne 
Programmiersprache, in welcher man das, was man im FPGA an 
Funktionalität drin haben will, auch formulieren kann. Und das möglichst 
komfortabel und ohne elende Einarbeitungszeit, weil die in den 199€ 
nicht darstellbar ist.

Entweder geht das in einer Sprache gut, dann ist diese Sprache auch gut 
geeignet oder es geht schlecht, hakelig oder garnicht, dann ist diese 
Sprache eben schlecht, hakelig oder gar ungeeignet.

Lothar M. schrieb:
>> VHDL scheint etwas umständlich zu sein, wenn man etwas berechnen will.
> Wenn man nicht die richtigen Typen verwendet, dann stimmt das. Ansonsten
> ist VHDL eben sehr restriktiv, was die Typumwandlung angeht

Hier geht es doch gar nicht um Typumwandlungen, sondern um den gleichen 
Typ:
signal sineWaveSignal  : std_logic_vector(15 downto 0);
signal amplitude       : std_logic_vector(7 downto 0)  ;

Beide Operanden sind vom exakt gleichen Typ "std_logic_vector" und die 
Bitwertigkeiten sind auch genannt (15..0 und 7..0). Chris hat an keiner 
Stelle ne Umwandlung float<--->integer erwähnt.

Soviel zum Verständnis der praktischen Anwendung.

Deshalb formuluere ich das mal so: VHDL ist hakelig und VHDL ist eben 
nicht wirklich gut, weswegen genau dieser Thread zustande gekommen 
ist.

Schönen Abend noch

W.S.

Autor: Markus F. (mfro)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Beide Operanden sind vom exakt gleichen Typ "std_logic_vector" und die
> Bitwertigkeiten sind auch genannt (15..0 und 7..0). Chris hat an keiner
> Stelle ne Umwandlung float<--->integer erwähnt.

Ein std_logic_vector ist kein integer.

Ein std_logic_vector ist ein Bus und mit Bussen kann man nun mal nicht 
rechnen.

Wenn man rechnen will, nimmt man entweder integer, unsigned oder signed.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grundlagen - Namensgebung

Diamond ist der Name der IDE von Lattice.
Synplify mit n ist der Name des einen, unterstützten Synthese Tools
LSE ist der Name des anderen Synthesetools

Autor: Ale (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Ein std_logic_vector ist ein Bus und mit Bussen kann man nun mal nicht
> rechnen.

hahaha

wire [3:0] a, b, c;
wire [7:0] d;

assign a = b + c;
assign d = a * b;

a, b, c und d sind Bussen, und mit Bussen kann man ganz gut rechnen, 
aber nicht in VHDL.

:)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ale schrieb:
> und mit Bussen kann man ganz gut rechnen, aber nicht in VHDL.
Kann man mit den obsoleten std_arith Libs auch in VHDL. Ist aber 
prinzipiell keine gute Idee, weil über einen Bus generell jede Art von 
Daten kommen kann. Auch solche, die nicht sinnvoll miteinander 
verrechnet werden können...

> a, b, c und d sind Bussen, und mit Bussen kann man ganz gut rechnen
Signed oder Unsigned?

Autor: berndl (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Lothar M. schrieb:
>> a, b, c und d sind Bussen, und mit Bussen kann man ganz gut rechnen
> Signed oder Unsigned?

Bingo! Treffer, versenkt :o)

Autor: Bernhard K. (bkom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
reg         [15:0] a; // Unsigned
reg signed  [15:0] b;
wire signed [16:0] signed_a;
wire signed [31:0] a_mult_b;

assign signed_a = a; // Convert to signed
assign a_mult_b = signed_a * b

dort gefunden:
http://billauer.co.il/blog/2012/10/signed-arithmet...

Autor: Andi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Lothar M. schrieb:
>> a, b, c und d sind Bussen, und mit Bussen kann man ganz gut rechnen
> Signed oder Unsigned?

Alles ist möglich:

assign d = a * b;
assign d = $signed(a) * b;
assign d = $unsigned(a) * $signed(b);
assign d = $signed(a) * $signed(b);

Wie die Daten auf einem Bus interpretiert werden bestimmt doch das 
Rechenwerk und nicht der Bus.

Andi

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Mit VHDL kann man gar nicht rechnen, höchstens ein Rechenwerk 
beschreiben.

Autor: Thomas U. (thomasu)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Andi schrieb:
> Wie die Daten auf einem Bus interpretiert werden bestimmt doch das
> Rechenwerk und nicht der Bus.
Das ist richtig, aber nicht unbedingt ein Vorteil, alles quer durch den 
Garten zu formulieren, bzw es tun zu können, weil dann ein Wildwuchs 
entsteht. Das kann man sehr gut an Verilog erkennen, der aus dem 
angloamerikanischen Raum zu uns kommt.

Gustl B. schrieb:
> Mit VHDL kann man gar nicht rechnen, höchstens ein Rechenwerk
> beschreiben.
Nein, man kann durchaus rechnen. VHDL kann sehr viel mehr, als man im 
FPGA letztlich herstellen kann. Gerade dei Verifikation mit VHDL kann 
sehr effektiv werden. Man kann sich Sinus, FTT, DFT und Vieles mehr als 
in REAL fromulieren und schneller berechnen, als in MATLAB.


Andi schrieb:
> Grundlagen - Namensgebung

Etwas zum erweiterten Horizont:

> Diamond ist der Name der IDE von Lattice.
Diamond ist auch der Name einer IDE von 3P für Sundance FPGA-Systeme. 
Diese ist allerding 2013 von uns gegangen

> Synplify mit n ist der Name des einen, unterstützten Synthese Tools
Symplify  ist auch der Name eine GitHub Projects

> LSE ist der Name des anderen Synthesetools
LSI ist der Name eines Halbleiterherstellers
Die IDE heisst "ISE". Diese ist allerdings 2012 von uns gegangen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.