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 M. (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/packages/numeric_std.vhd
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 M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
-1 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. (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 M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 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 M. (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. (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
-3 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 M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 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. (elektromeister)
Datum:

Bewertung
-1 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
-3 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. (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
-4 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
-2 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 M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
3 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-arithmetics-verilog/

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 B. (-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.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
berndl schrieb:
> 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)

Soweit die Theorie. Leider kommen viele VHDL-Beschreibungen aus 
Code-Generatoren, die sich noch an alten Libs orientieren, numeric 
umgehen oder andere Klauseln drinne haben. Solange man die irgendwie 
wrappen kann, um sie in die eigenen Projekte einzubinden, ist das ok.

Oft ist es aber umgekehrt und man bringt seine eigenen 10% in ein 
solches System ein und dort kommen die Werte über Vektoren rein. Dann 
muss man konvertieren, um sich anzupassen oder man hat Schreibarbeit. 
Wehe man muss einen solchen Code benutzen und ihn umschreiben.

Weil heissen: Man muss alle Arten der Formulierung von Rechnungen 
beherrschen. Das ist beim VHDL eben nun mal so.

Autor: chris (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hat jemand ein VHDL-Beispiel für einen Binärmultiplizierer?
Wenn ich es richtig sehe, ist diese Art eine Multiplzieres zwar langsam, 
braucht aber wenig LUTs.
Hier ist ein Beispiel für 4x4
https://www.allsyllabus.com/aj/note/ECE/Digital_System_Design_Using_VHDL/Unit4

Ich finde es aus Codesicht aber nicht besonders schön.

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

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Ich finde es aus Codesicht aber nicht besonders schön.
Ich finde es umständlich, das Schieben vom Addieren zu trennen. Denn 
prinzipiell ist die Addition vom Schieben sowieso schon durch den Takt 
getrennt. Für mein Verständnis hat da einer ein Verständnisproblem beim 
Thema "synchrones Design"...

Autor: chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal mein Übungsbeispiel einer 16x8 Multiplikation in 10 Takten 
welches ich gerade erstellt habe.

Ich überlege, ob man vielleicht den Startpulse weglassen könnte ...

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

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Übungsbeispiel einer 16x8 Multiplikation
Deren Ergebnis ist aber 24 Bit breit...

Autor: -gb- (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier im Anhang zwei Aufgaben zum Thema. Lösungen kann ich auch posten, 
aber lieber erstmal selber probieren. Leere Projekte sind auch dabei 
(zwecks Testbench).

Aufgabentext zu a4:

Es soll dividiert werden. Die Eingänge sind Takt, a (Dividend), b 
(Divisor), q (Quotient) und start und busy.
Es gibt zwei unterschiedliche Varianten:
1. Nacheinander in mehreren Takten mit Handshake. Dabei wird das Signal 
busy auf '1' gelegt sobald gerechnet wird. busy muss dazu kombinatorisch 
ungetaktet erzeugt werden. start gibt an wenn neue Werte a und b 
vorliegen, die Rechnung wird in beliebig vielen Takten durchgeführt, und 
das Ergebnis wird auf q gelegt und gleichzeitig busy auf '0' gesetzt.
2. Ohne Handshake mit einer Pipeline. Dafür wird busy dauerhaft auf '0' 
gelegt und start kann ignoriert werden. Es wird jetzt davon ausgegangen, 
dass mit jedem Takt neue Werte a und b angelegt werden. Diese 
durchlaufen eine Rechenpipeline und nach einer festen Anzahl von Takten 
wird das jeweilige Ergebnis auf den Aufgang q gelegt.
Die Testbench stellt sicher, dass b nie Null ist. Diese Aufgabe soll wie 
die schriftliche Division, also durch Vergleiche und Subtraktionen 
gelöst werden. Abzugeben ist wie immer nur die entsprechende VHDL Datei. 
Für die beiden Lösungsvarianten könnt ihr also diese Datei kopieren oder 
auch beide Varianten in eine Datei schreiben und jeweils eine 
auskommentieren.

Autor: nada (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Vancouver schrieb:
> Erst allmählich lernen Sie, dass das Ziel eine RTL-Architektur
> ist und kein Maschinenprogramm.

Ja? Ist VHDL nicht eher so gedacht, dass man dort einfach ein Programm 
schreibt, aus dem der Compiler dann eine Schaltung herzuleiten hat, die 
sich genau so verhält, wie das Programm es täte? Immerhin gibt's da 
schon extra "if", "for" und nicht nur "AND" usw. usf.
Beschreibung ist Beschreibung - ganz abgesehen davon, dass das (so) 
derzeit nicht funktioniert.

--

Mögen die Spiele beginnen!

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

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Ist VHDL nicht eher so gedacht, dass man dort einfach ein Programm schreibt
Nein, im Grunde nicht.
VHDL ist eine Alternative zur Schaltungsbeschreibung mit einem 
Schaltplan. Aus diesem Grund sollte man sich eigentlich eher eine 
Schaltung vorstellen und diese dann mit herstellerübergreifendem VHDL 
beschreiben, als sie mit einem herstellerspezifischen Zeichenprogramm am 
Bildschirm zu malen.
VHDL-Code kann man mit einem Compare-Tool auf Änderungen vergleichen. 
Bei Schaltplänen ist das nur umständlich möglich.
Die einfachere Portierbarkeit und Wartbarkeit war dann letztlich die 
eigentliche Absicht bei der Einführung von Beschreibungssprachen.

> Immerhin gibt's da schon extra "if", "for" und nicht nur "AND" usw. usf.
Ein "if" ist ja nur die Umschreibung für einen Multiplexer. Statt den 
selber in Logik aufzulösen überlässt man das dem Synthesizer.
Und dass ein "for" keine Schleife ist, sondern parallele Hardware 
erzeugt (und die "Schleife" quasi sofort "ausgerollt" wird), das 
entspricht ja überhaupt nicht dem, was man von einer Programmiersprache 
kennt...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>chris schrieb:
>> Übungsbeispiel einer 16x8 Multiplikation
Lothar Miller
>Deren Ergebnis ist aber 24 Bit breit...

Da ist meine Dokumentation wahrscheinlich etwas ungenügend.
Da ich die Notation für die Fixpunktarithmetik

Zahl = Vorkomma.Nachkomma

gerade nicht im Kopf hatte, habe ich folgendes darüber geschrieben:

-- u16.u0 = u16.u0 * u0.u8

wahrscheinlich wäre

u16.0 = u16.0 * u0.8

besser.

Im Blick hatte ich die die Dämpfung eines Audiosignals:

audioOut_u16 = audiIn_u16 * amplification_u8

Das Ergebnis einer u16*u8 Multiplikation wäre eigentlich u24, aber für 
das Audiosignal können die unteren 8 Bit verworfen werden. Das 
verringert die Anzahl der LUTs und erhöht die Geschwindigkeit, die für 
den Multiplizierer benötigt werden.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl, Du hast in Deinen Templates ein Busy-Ausgangssignal. Das hatte 
ich mir auch schon überlegt, war aber unsicher, ob ich das brauchen 
werden, da man ja weiß, dass der Multiplizierer nach einer bestimmten 
Anzahl Takte fertig ist.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir sogar extra Datentypen mit 'enable'-Signal angelegt.

Das enable propagiert sich dann durch die ganze Rechnung und man muß 
nicht immer die Takte mitzählen. Ein Rechen-FSM rennt erst los, wenn 
alle Eingangsdaten da sind. Das Ergebnis wird wieder mit einem enable 
versehen und alles ist gut.

Ein busy kann man trotzdem gebrauchen. Z.B.: um in der Simulation einen 
Fehler zu werfen, wenn doch ein neues Datum mit enable kommt, während 
die FSM noch beschäftigt ist.

Duke

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

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> da man ja weiß, dass der Multiplizierer nach einer bestimmten Anzahl
> Takte fertig ist.
Dann machst du dieses Busy-Signal eben implizit ausserhalb. Brauchen 
tust du es trotzdem...

Ich mach solche Busy-Signale immmer im Modul, denn dann kann ich dort 
auch mal was ändern und/oder optimieren, ohne mir jede Instanz des 
Moduls einzeln anschauen und die Latenzen kontrollieren zu müssen...

: Bearbeitet durch Moderator
Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Ein "if" ist ja nur die Umschreibung für einen Multiplexer.
Oder ein output-enable oder eine Verundung oder sonstwas...
Punkt ist: Man kann das abstrakt schon da nicht mehr ohne weiteres 
sagen. Die Schaltung verhält sich nachher nur so, als ob die Codezeilen 
im "if" nur dann ausgeführt/beachtet/aktiv würden, wenn die Bedingung 
zutrifft. Das hat mit Logik nichts mehr zu tun - das ist imperativ! Am 
besten sind noch ":="-Zuweisungen...
Fazit: Mit solchen Features hat VHDL sich bereits vollständig davon 
verabschiedet, die Hardware qua ihres Seins beschreiben zu wollen und 
beschreibt nur noch deren Verhalten. Der Compiler ist frei alles zu tun, 
solange die Schaltung als IO-Blackbox begriffen, sich noch genau so 
verhält, wie das Programm.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> sondern parallele Hardware
> erzeugt (und die "Schleife" quasi sofort "ausgerollt" wird), das
> entspricht ja überhaupt nicht dem, was man von einer Programmiersprache
> kennt...

Das war vielleicht mal richtig, stimmt so aber längst nicht mehr.

Auch bei "echten" Programmiersprachen ist so mancher Anfänger 
überrascht, wo denn nach dem Compilieren wohl seine Schleife geblieben 
ist.
i = 3 * 5 / 2;

oder
for (i = 0; i < 1000; i++);

oder gar
#include <iostream>

template <int N> struct Fib_t {
        enum { value = Fib_t<N-1>::value + Fib_t<N-2>::value };
        Fib_t() { std::cout << N << ": " << value << std::endl; }
};

template <> struct Fib_t<2> {
        enum { value = 1 };
        Fib_t() { std::cout << 2 << ": " << value << std::endl; }
};

template <> struct Fib_t<1> {
        enum { value = 1 };
        Fib_t() { std::cout << 1 << ": " << value << std::endl; }
};

int main(void)
{
       Fib_t<30> f;
}
 (das fib(30) in "Nullzeit" ausrechnet)

produzieren längst nicht mehr (genau) das als Code, was man 
hingeschrieben hat, sondern "nur" das "funktionale Äquivalent". Insofern 
sind C und C++ nach der strengen "LM-Definition" auch keine 
Programmiersprachen, sondern "Programm-Beschreibungssprachen" ;)

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

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Auch bei "echten" Programmiersprachen ist so mancher Anfänger
> überrascht, wo denn nach dem Compilieren wohl seine Schleife geblieben ist.
Ja, eh' klar. Aber es wird trotzdem keine "parallele Schleife" daraus. 
Der Code vom Durchlauf 20 wird sicher nach dem Code von Durchlauf 10 
ausgeführt.

> (das fib(30) in "Nullzeit" ausrechnet)
Naja, diese Beispiele sind ja "nur" Beispiele für einen schlauen 
Präprozessor.

nada schrieb:
> Lothar M. schrieb:
>> Ein "if" ist ja nur die Umschreibung für einen Multiplexer.
> Oder ein output-enable oder eine Verundung oder sonstwas...
Sowieso, ein Multiplexer ist letztlich eine Verundung. Und hinter einem 
output-enable sitzt mit allerhöchster Wahrscheinlichkeit ein 
Multiplexer.

> Fazit: Mit solchen Features hat VHDL sich bereits vollständig davon
> verabschiedet, die Hardware qua ihres Seins beschreiben zu wollen und
> beschreibt nur noch deren Verhalten. Der Compiler ist frei alles zu tun,
> solange die Schaltung als IO-Blackbox begriffen, sich noch genau so
> verhält, wie das Programm.
Tut er aber nicht. Er ist im Gegenteil sehr berechenbar und 
deterministisch. Du musst ihm nur ab&zu auf die Finger schauen. Denn für 
die Lösung der Aufgaben bleiben ihm nur LUTs und Flipflops.

Und weil ich das weiß, kann ich mit der "Programmiersprache VHDL" 
tatsächlich eine gute Hardware erzeugen.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Denn für die Lösung der Aufgaben bleiben ihm nur LUTs und Flipflops.

Auf einer gewissen Abstraktionsebene mag das unter bestimmten 
Bedingungen zutreffen. Er könnte aber auch einfach einen CPU-Kern 
synthetisieren und das Programm ausführen ;)
"Auf die Finger schauen", muss man ihm nur wegen seiner Unfähigkeit, 
logisch äquivalente Programme zur selben Schaltung zu synthetisieren 
(schönes Wort!). Am Ende des Tages ist die Leitung H oder L. Alles, wo 
das raus kommt, ist der selbe Topf und unterschiedliche 
Schaltungsimplementierungen nurmehr eine versäumte Compileroptimierung. 
DANN würde der Quelltext an sich überhaupt erst interessant - vorher ist 
er doch nur als plumper und irreführender Versuch zu verstehen, den 
Synthesizer bestimmte Baugruppen erzeugen zu lassen, die man, wenn man 
das wirklich wollte, doch besser explizit angäbe.

VHDL ist noch nicht einmal das QBASIC der Harwareentwicklung.


Ausgetrollt. Ich hatte nicht den Eindruck, dass bei der Definition von 
VHDL der nachvollziehbare Bezug zur Hardware im Vordergrund stand. Schon 
der Begriff der Synthese unterstreicht das.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>VHDL ist noch nicht einmal das QBASIC der Harwareentwicklung.

Ich würde sagen, es soll gar kein Basic sein. VHDL ist ein Schaltplan in 
Textform. Kann ein Schaltplan ein Programm sein? Eher nicht.
Man kann aber eine Schaltung entwerfen, die ein Programm ausführt.

Wie war das noch gleich mit dem Programmieren?
Beitrag "Programmierung von FPGAs"

Ich bin ja der Meinung, dass man die Fuses im FPGA programmieren kann.

Autor: chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Man kann es mit diesem Bildchen hier verdeutlichen: Ich habe den 
Multiplizierer von oben genommen und in der Entwicklungsgebung einfach 
mal auf "View RTL Source" gedrückt und siehe da, der Code ist ein 
Schaltplan und kein Programm.

BinaryMultiplier2 ist der "RTL post mapping view". Ich bekomme da 
irgendwie das Gefühl, wenn man das jetzt auf eine Lochrasterplatine 
löten sollte, man doch einiges anstellen würde, um den Aufwand zu 
reduzieren.

Wer weis, vielleicht wäre die Schaltplaneingabe doch effizienter.

Autor: nada (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
chris schrieb:
> Kann ein Schaltplan ein Programm sein? Eher nicht.
> Man kann aber eine Schaltung entwerfen, die ein Programm ausführt.

Sein ist Sein von Seiendem. Was einmal so ganz offensichtlich 
unterschiedliche Dinge war kann nur ein synthetisches Konstrukt sein. 
Und das ist eben das Argument. Vom prinzipiellen Standpunkt macht es 
ebensowenig Sinn, aus den Eigenschaften des Endprodukts - des 
Schaltplans oder - Anekdotenhaft: des Salzes -, auf die Eigenschaften 
der Zutaten - Natrium und Chlor - schließen zu wollen, wie umgekehrt.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sein ist Sein von Seiendem.

So gesehen: Mathematik und damit die Informatik als eine der darauf 
aufbauenden Wissenschaften gehört so weit ich weiß, zu den 
Geisteswissenschaften. Und vielleicht kann man fragen, ob die Konstrukte 
des Geistes überhaupt wirklich "sind".
Die Philosophie befasst sich gerne mit den Frage ob wir die Welt, wie 
sie wirklich ist, wirklich erkennen können.
Aber auch dort gab's in einem der Philosophiebücher einen recht 
praktischen Hinweis: Um die Wirklichkeit zu erkennen solle man sich mit 
dem nackten Arsch auf eine Herdplatte setzen, das würde unmittelbar zur 
Erkenntnis führen.

Und deshalb halte ich es mit der Phänomenologie und betrachte die Dinge 
gerne, wie sie sich in der Welt verhalten.

Meine Vorstellung eines Programms war immer eine Vorstellung eines 
dynamischen Vorgangs. Ein Programm wird abgearbeitet, es lebt sozusagen.
Aber ich liege offensichtlich falsch: Ein Programm auf dem Papier ist 
tot, so lange es nicht aufgeführt wird. Das Gleiche gilt für den 
Schaltplan oder die Schaltung ohne Strom. Da der Multiplizierer unter 
Strom und mit Takt versorgt zu "leben" beginnt, kann man die Grundlage 
des Multiplizierers ( nämlich den VHDL-Code oder den graphischen 
Schaltplan ) vielleicht doch als Programm bezeichnen.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
chris schrieb:
> VHDL ist ein Schaltplan in
> Textform. Kann ein Schaltplan ein Programm sein? Eher nicht.

Das ist jetzt DEINE persönliche Argumentatinskette. Und die ist falsch, 
denn:

Ein Ei ist ein Bauplan für ein Huhn in Gen-form. Kann eine Gen-Form ein 
Ablauf sein? - Nein, folglich ist ein Ei kein Programm.

Doch, es IST ein Programm, weil das Ei eben mehr ist, als nur ein 
Bauplan. Die Funktion "Bauplan" ist ein Teilaspekt des Programms "Ei", 
denn das Ei ist nicht nur ein Gen-Pool sondern auch ein Chemiecocktail 
und enthält zumindest Reste von Gamonen.

Du darfst dies nun aufs VHDL-übertragen.

Es gibt heute eine Reihe von VHDL-Programmen die völlig ohne einen 
Schaltplan auskommen. Oft auch, weil man das Meiste mit Schaltsymbolen 
der HW-ler nicht beschreiben KANN.

Schaltplan als Ersatz und tool für VHDL ist die alte Welt der 90er und 
2000er. Wir haben 2017! Ich baue gerade für ein Produkt das in 2020 in 
den Markt kommt.

Autor: nada (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
chris schrieb:
> Aber auch dort gab's in einem der Philosophiebücher einen recht
> praktischen Hinweis: Um die Wirklichkeit zu erkennen solle man sich mit
> dem nackten Arsch auf eine Herdplatte setzen, das würde unmittelbar zur
> Erkenntnis führen.

Oh - abgesehen davon, dass es keiner versteht, hatte Heidegger einen 
ziemlich konsequenten und daher auch realistischen Bezug auf das 
Problem: Eine Wischi-Waschi Durcheinanderbringung grundverschiedener 
Begriffe wie "Programm" und "Schaltplan" wäre da nur ein gefundenes 
Fressen.
Ganz einfach: "Das eine ist das eine und das andere is' das and're."

Es liegt in der begrifflichen Bestimmung des "Programms" abzulaufen oder 
dazu bestimmt zu sein. Und das ist schon einmal etwas von einer 
Schaltung grundverschiedenes. Logik und Mathematik haben keine zeitliche 
Dimension. Da gilt jedes Axoim jeder Zeit. In einer Schaltung sind alle 
Bestandteile immer vorhanden. Ein "if" im Quelltext führt 
schlechterdings nicht zu einem temporären Loch in der Platine. Die ganze 
VHDL-Beschreibung findet nur auf Ebene eines "so, wie" statt. Ein "als 
ob", wegen dem so getan wird, als wäre damit irgend etwas substantielles 
ausgesagt. Ist aber nicht so - das Ergebnis der Synthese kennt man immer 
erst hinterher. Das eine Tool kann das so machen, das andere so. Der 
eine Chip hat mehr LUTs als der andere usw. usf.
Alles das hat man in VHDL explizit ausgeblendet. Die Sprache ist dazu 
[i]bestimmt[/i], die Umsetzung in Hardware auszublenden. Sie beschreibt 
"behavioural".
Überspitzt: Wenn die Tools zur Umsetzung also aus einem im Grunde in 
einer simplen Schaltung zu realisierendem "behaviour" irgendeine 4k-LUT 
Monster-Schaltung machen, ist nicht das "behaviour" Schuld - kann es 
per-se nicht sein: Es definiert ja nur die Ausgangswerte. :D

Autor: chris (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>Oh -

Ganz vorweg: Ich in begeistert ob Deiner Formulierungen. Meine etwas 
"harsche" Formulierung nutze ich öfters auch als Mahnung für mich 
selbst.

Markus F. hatte es oben schon angedeutet und deshalb hier der Spiegel:

Frei aus der Vorlage:
Logik und Mathematik haben keine zeitliche Dimension. Da gilt jedes 
Axiom jeder Zeit. In einem Programmtext sind alle Bestandteile immer 
vorhanden. Ein "if" im Quelltext führt schlechterdings nicht zu einem 
temporären Loch im Papier oder Speicher für den nicht ausgeführten 
Codeteil.
Die ganze Programmtextbeschreibung in 'C' findet nur auf Ebene eines 
"so, wie" statt. Ein "als ob", wegen dem so getan wird, als wäre damit 
irgend etwas substantielles ausgesagt. Ist aber nicht so - das Ergebnis 
des Compilers kennt man immer erst hinterher. Der eine Compiler kann das 
so machen, das andere so. Die eine CPU hat mehr Maschinenbefehle als die 
andere usw. usf.
Alles das hat man in der Hochsprache explizit ausgeblendet. Die Sprache 
ist dazu [i]bestimmt[/i], die Umsetzung in Maschinencode auszublenden. 
Sie beschreibt "behavioural".
Überspitzt: Wenn die Compiler zur Umsetzung also aus einem im Grunde in
einem simplen Programm zu realisierendem "behaviour" irgendeine 
4k-Maschinencode Monster macht, ist nicht das "behaviour" Schuld - kann 
es
per-se nicht sein: Es definiert ja nur die Ausgangswerte. :D

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö. VHDL ist nicht dazu bestimmt Hardware auszublenden. Sondern sie 
ermöglicht es überhaupt erst Hardware zu beschreiben.

Bei einer Programmiersprache wie C stimmt es, die abstrahiert einem das 
ASM weg. Aber man könnte den Code eben auch stattdessen in ASM 
schreiben. Aber was könnte man statt VHDL schreiben? Man könnte die 
Bauteile zeichnen, oder sie direkt verlöten, aber beschreiben? Dazu 
braucht man zwingend VHDL oder eine andere HDL. Klar manche Sachen an 
VHDL sind dann auch abstrakt und eine Ebene höher, z. B. wenn man 
einfach Rechenzeichen hinschreibt aber keinen Addierer zu Fuß aufbaut, 
aber das ist dann der persönliche Umgang, das müsste man nicht machen.
VHDL ermöglicht einfach nur textuell Hardware zu beschreiben, und zwar 
beschreibt man das gewünschte Verhalten, also das wie die Hardware am 
Ende funktionieren soll und die Toolchain verwendet dann 
Hardwarebausteine so passend, dass das mit der Beschreibung 
übereinstimmt.
Man kann aber natürlich auch auf unterster Ebene die einzelnen Gatter 
beschreiben und deren Verbindungen untereinander. Da ist dann die Frage 
ob man noch Verhalten oder Hardware beschreibt. Eigentlich ist es immer 
gewünschtes Verhalten das die Toolchain dann auf die verfügbare Hardware 
abbildet.

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

Bewertung
0 lesenswert
nicht lesenswert
Ich kann mir VHDL natürlich auch ganz normal prozedural "programmieren" 
mit Textein- und -ausgabe, mit Zeiten und Dateizugriffen, 
Bildschirmausgabe und zeitlich vollkommen abstrakten Funktionen, bei 
denen eine Dauer nicht definiert oder relevant ist.

Nur bekommt der Synthesizer so ein "Programm" eben nicht mehr auf die 
Hardware abgebildet. Und genau das ist das Problem der 
"VHDL-Programmierer": in der Simulation läuft das Programm, aber es kann 
nicht oder nur schlecht in Hardware umgesetzt werden...

: Bearbeitet durch Moderator
Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> In einem Programmtext sind alle Bestandteile immer vorhanden.

Du hast den Unterschied der Begriffsbestimmung - ein Programm ist da, um 
ausgeführt zu werden, eine Schaltung nicht - keine Beachtung geschenkt. 
Wenn man schon meint, der beste Weg Äpfel zu beschreiben, seien Birnen, 
und dann noch meint, deren Verhältnis sei selbstverständlich "Apfel = 
2pi^Birne", muss man sich nicht wundern, wenn andere widersprechen.

chris schrieb:
> Wenn die Compiler zur Umsetzung also aus einem im Grunde in
> einem simplen Programm zu realisierendem "behaviour" irgendeine
> 4k-Maschinencode Monster macht, ist nicht das "behaviour" Schuld - kann
> es
> per-se nicht sein: Es definiert ja nur die Ausgangswerte.

Es gibt genug Sprachen, wo ich das nachvollziehen könnte. Wenn man 
schreibt "Fahre eine Linkskurve, dann eine Rechtkurve!" statt "Fahre 
geradeaus!" heißt die Antwort in imperativen Sprachen prinzipiell "Okay 
- Du bist der Boss!".
Eine Komponente in VHDL bestimmt sich über ihre Ein- und Ausgänge. Das 
Behaviour definiert also der Sprachlogik folgend nur welche Ausgaben bei 
welchen Eigaben vorzuliegen haben.
Der Logik der imperativen Sprachen folgend soll dort immer das getan 
werden, was befohlen wird. Soweit hat man dort eine konzeptionelle 
Übereinstimmung dessen, was die Hardware erwartet (sie hat einen 
Instruction-Pointer) und dem, was man schreibt. Und die ist bei VHDL so 
nicht gegeben.
VHDL ist deshalb noch nicht einmal das QBASIC der Hardwareentwicklung, 
weil in Anbetracht dessen, das dort die Übereinstimmung zur Harware 
sowieso kein Argument sein kann, der imperative Sprachteil einfach nur 
plump, umständlich, spitzfinnig und jedenfalls alles andere als eines 
modernen Softwareentwicklers würdig ist.

Autor: Ordner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> jedenfalls alles andere als eines
> modernen Softwareentwicklers würdig ist.

Wie müsste eine Hardwaresprache organisiert sein, damit sie "eines 
Software-Entwicklers würdig ist"?

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verstehe ich auch nicht. Man kann mit VHDL einzelne Gatter beschreiben 
aber auch ganz abstrakt Rechnungen hinschreiben, da ist doch alles bei 
was man möchte?

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

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> VHDL ist deshalb noch nicht einmal das QBASIC der Hardwareentwicklung
Und was wäre dann das C/C++/Java oder wasweißich der 
Hardwareentwicklung?

Ich finde es übrigens interessant, dass die imperative Sprache eben 
genau den sequentiellen Befehlszeiger braucht, den es in der parallelen 
Hardware nicht gibt. Aus diesem Grund haben imperative Programmierer 
dann auch gern mal Probleme mit "wirklich gleichzeitig"...

: Bearbeitet durch Moderator
Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: -gb- (Gast)
>Verstehe ich auch nicht. Man kann mit VHDL einzelne Gatter beschreiben
>aber auch ganz abstrakt Rechnungen hinschreiben, da ist doch alles bei
>was man möchte?

Da kann ich eventuell mit einem Beispiel dienen, welches mir von ein 
paar Tagen widerfahren ist:
Ich wollte einen einfachen RC-Oszialltor mit dem FPGA bauen ( also eine 
Schmittrigger-Inverter ins FPGA programmieren, den Ausgang an den 
Widerstand und den Eingang an den Kondensator).
Aber es hat nicht funktioniert. Ich hatte die mystischen metastabilen 
Zustände im Verdacht
Beitrag "Re: VHDL Grundlagen Pin Zustand lesen, Flankenerkennung"
und wollte deshalb 3 Inverter hintereinander schalten.
Aber immer wenn das Ergebnis des Synthesizers betrachtet habe, waren 
zwei der 3 Inverter aus der Kette verschwunden, weil der Synthesizer 
diese für unnötig hielt.
Ich habe es dann aufgegeben und das Ganze in den Ordner: "erfolglose 
Experimente" verbannt.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das ist das Problem Vieler:

Sie verstehen nicht, dass VHDL ein LOGIKDESIGN beschreibt und eben keine 
Hardware. Es beschreibt abstrakte Handlungsabläufe wie UND, NICHT, MUL, 
AND aber eben nicht! Logikgatter oder Physik.

Wenn Ich dem "virtuellen Layouter" sage, er solle eine Logikschaltung so 
und so und so bauen, und am Ende bleibt in einem Zweig eine Inversion 
über, dann baut er folgerichtig einen einzigen Inverter ein.

Es handelt sich eben um logische Inversionen und nicht etwa 
Pegeldrehungen oder funktionelle Drehungen. Daher sollte man diese drei 
Ebenen:

Funktion : TRUE / FALSE
Logik :    0 / 1
Physik :   LO / HI

sauber auseinander halten!  Ein Inverter, ein OR oder AND-Gatter in VHDL 
ist eben nur die logische Verknüpfung und nicht etwa der 4000er 
Baustein. VHDL beschreibt nicht direkt eine Hardware, sondern die 
Funktion einer Hardware. Was von all den vielen ANDs und ORs oder 
übergeordneten Bedingungen wie WHEN und OF dann am Ende über bleibt, ist 
nicht direkt zu kontrollieren.

Daher werden diese Mehrfach-Inverter völlig zurecht weggeworfen!

Weil man Physik beschreiben, muss man das entweder speziell kommandieren 
oder ausdrücklich einbauen indem man dem virtuellen Layout das fertig 
Invertermakro übergibt und ihn untersagt, es zu optimieren.

Eigentlich ist es eine einfache Sache. Und so weit Ich es überschaue, 
wird es auch richtig gelehrt. Aber irgendwie wird am Ende alles in einen 
Topf geworfen und ein eigenes Weltbild generiert.

: Bearbeitet durch User
Autor: Bernhard K. (bkom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> und wollte deshalb 3 Inverter hintereinander schalten.
> Aber immer wenn das Ergebnis des Synthesizers betrachtet habe, waren
> zwei der 3 Inverter aus der Kette verschwunden, weil der Synthesizer
> diese für unnötig hielt.
> Ich habe es dann aufgegeben und das Ganze in den Ordner: "erfolglose
> Experimente" verbannt.

Beim Xilinx-ISE könnte da "keep" helfen:

http://www.lothar-miller.de/s9y/categories/29-Ringoszillator

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Und was wäre dann das C/C++/Java oder wasweißich der
> Hardwareentwicklung?

Keine Ahnung. VHDL lässt jedenfalls an Umständlichkeit Pascal im 
Vergleich zu Java und C++ weit hinter sich, ist aber trotzdem viel 
verschleiernder als BASIC in Vergleich zu Assembler. Verilog glänzt zwar 
mit einer annährend annehmbaren Syntax, hat aber noch nicht einmal 
strukturierte Datentypen! VHDL definiert zwar ein paar 
"High-Level"-Features wie Configurationen usw. - richtig verwenden kann 
man die allerdings zumeist nicht, weil der COmpiler die nur so 
"pro-forma" unterstützt. SystemVerilog liefert zwar immerhin schon 
einmal structs (jaaaa!), gilt aber momentan anscheinend als das 
Gottesgeschenk schlechthin und kostet deswegen gleich ein paar tausend 
Dollar >:|
KR-C muss echt der Hammer gewesen sein...

Lothar M. schrieb:
> Ich finde es übrigens interessant, dass die imperative Sprache eben
> genau den sequentiellen Befehlszeiger braucht, den es in der parallelen
> Hardware nicht gibt. Aus diesem Grund haben imperative Programmierer
> dann auch gern mal Probleme mit "wirklich gleichzeitig"...
Ich glaube, Imperatoren haben prinzipiell Probleme mit geteilten 
Resourcen :D
Ein "neben mir" verträgt sich so ganz prinzipiell nicht gut mit 
Konzepten wie "Befehl", "Kommando", "Herrschaft" - es muss also 
tendenziell inhaltlich geregelt werden, wenn es zu territorialen 
Streitigkeiten um Speicherlocations kommt. haha

Da könnte man ein Buch drüber schreiben: "Warum der Prozess dem Thread 
vorzuziehen ist" oder eine kritische Betrachtung "Vom Baum zum Gestrüpp 
mit modernem Design-Patterns"
                 _
  |             / /-\/
  |       ->   |_/\_/\
 / \           |/  \/\
/\  \  

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dir ist die Sprache also zu geschwätzig und am liebsten wäre dir eine 
Sprache wie C mit massig {} Klammern.

Ganz ehrlich, wieviel Zeit verwendet man für das Hinschreiben und wie 
viel für das Überlegen davor? Ich finde die Syntax wirklich 
nebensächlich.

nada schrieb:
> VHDL definiert zwar ein paar
> "High-Level"-Features wie Configurationen usw. - richtig verwenden kann
> man die allerdings zumeist nicht, weil der COmpiler die nur so
> "pro-forma" unterstützt.

Du meinst man kann sie nicht verwenden weil man die nicht in Hardware 
übersetzen kann? So wie das TextIO?

nada schrieb:
> "Warum der Prozess dem Thread
> vorzuziehen ist"

Wenn du das VHDL Process meinst, das ist einfach was komplett anderes 
wie ein Thread in Software. Hat damit genau nichts zu tun. Wenn man im 
VHDL z. B. eine if Bedingung hinschreibt und die trifft nur selten zu, 
dann belegt diese trotzdem die Hardware für alle Zweige die eintreten 
könnten. Nicht wie bei einem Thread der dann eben weniger CPU Zeit 
frisst. Es ist eben eine andere Denkweise.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Ganz ehrlich, wieviel Zeit verwendet man für das Hinschreiben und wie
> viel für das Überlegen davor?
> Ich finde die Syntax wirklich
> nebensächlich.

Absolut nicht. Quelltext wird sehr oft gelesen. Gelesen von Leuten, die 
ihn nicht geschrieben haben. Das Hinschreiben ist wirklich das kleinste 
Problem.
VHDL-Code, der nicht gerade vom Militär veröffentlicht wurde, sieht zu 
80% selbst im Vergleich zu Java aus wie Kraut und Rüben.
Das Auge sollte entlastet werden. "then", "downto" usw. fügen dem 
Sachverhalt wirklich nichts hinzu, müssen aber geparsed werden. ;)
Nun gut, bin ja kein Hardwareentwickler. Wenn dann die Komponente nur 
noch gemäß des umfassenden Design-Documents aufgeschrieben werden muss 
und dann Jahre lang als BlackBox nur noch eingebunden wird, ist das 
vielleicht okay.
Einem Softwareentwickler wäre das nicht zuzumuten.


Zum Rest: Um Verstehensschwierigkeiten kümmere ich mich grundsätzlich 
nicht. Ich versuche, möglichst wenig zu verstehen.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Wenn du das VHDL Process meinst, das ist einfach was komplett anderes
> wie ein Thread in Software. Hat damit genau nichts zu tun.
Doch durchaus.

> Wenn man im VHDL z. B. eine if Bedingung hinschreibt und die trifft nur
> selten zu,
Da steckt schon der Interpretationsfehler:

Wenn der Code simuliert wird, also per Software ausgeführt wird, dann 
verhält der sich ganz genau so. Er braucht Rechenzeit, je nach 
Sensitivity-liste. Nicht nur - aber auch deshalb, steckt man die Sachen 
ja in Prozesse, die man von Signalen abhängig macht, statt einfach nur 
alles parallel hinzuknallen. Rechenzeitersparnis! Da gibt es noch ganz 
andere Aspekte.

> dann belegt diese trotzdem die Hardware für alle Zweige die eintreten
> könnten. Nicht wie bei einem Thread der dann eben weniger CPU Zeit
> frisst.
Das darf man nicht vergleichen, oder es gilt der Satz eins drüber, dass 
es Dasselbe ist.

Nochmal:

Bei VHDL gibt es 2 Geschichten:

Die Simulation durch eine Software durch Ausführen des Codes und die 
Erzeugung der Hardware durch sinngemässes Ausführen, also Interpretieren 
des Codes.


Der Code läuft eben nicht auf dem FPGA, sondern auf der 
Synthesesoftware. Daher sehen es Leute wie Lothar ja auch kritisch, wenn 
behauptet wird, daß FPGAs "programmiert" werden, weil die Software VHDL 
nicht dort unten abgearbeitet wird.

> Es ist eben eine andere Denkweise.
Nicht wirklich. Nach meiner Auffassung ist das nur Folge eines ungenauen 
Denkens. Wenn man sich bei jeder VHDL-Zeile immer wieder sagt, daß VHDL 
eine Funktion einer virtuellen Hardware, also Ablauf und Struktur, 
beschreibt, also eine Anweisung an einen Erbauer ist, dann gibt es da 
keinerlei Verständnisproblem.

Es gibt eben zwei Arten von Anweisungen, nämlich explizite "Tue das und 
das" (Schleifen z.B.) und "baue mir was, was so funktioniert, wie das 
was da steht" (FSMs) z.B.

Der Fehler ist die falsche Erwartungshaltung.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Das Auge sollte entlastet werden. "then", "downto" usw. fügen dem
> Sachverhalt wirklich nichts hinzu,

Wie würdest Du das "then" als Ende der Bedingungskette einsparen wollen?

Das downto ist durchaus variant  wenn es um die Arbeit mit Vektoren 
geht.

Es ist nur so, daß viel damit gerechnet wird, was nicht sein muss und 
gfs auch nicht gut ist und beim Rechnen mit vollen Vektoren der gesamte 
Konstrukt mitgeschleppt wird / werden muss

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

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Das ist das Problem Vieler: Sie verstehen nicht,
> dass VHDL ein LOGIKDESIGN beschreibt und eben keine Hardware.
Mhmmmm, interessant...
Das ist für mich im Grunde das selbe, denn ich sehe im entsprechendem 
VHDL-Code zwar virtuell sofort einen Multiplexer, mich interessiert im 
Normalfall nicht die Bohne, wie der im FPGA dann realisiert wird.

Aber es stimmt, man sollte das mental und verbal trennen, dann wird das 
einfacher. Wenn ich meinen Praktikanten sage: "du musst dir die 
Schaltung vorstellen und die dann beschreiben", dann meine ich 
eigentlich implizit das Verhalten, die Funktion, die Logik. Das bedeutet 
für mich in diesem Zusammenhang die Begriffe "Hardware" und "Schaltung". 
Und eben nicht einzelne Gatter oder atomare logische Bauteile.

Insofern sehen wir die Sache gleich und verwenden nur andere Termini...

nada schrieb:
> Keine Ahnung. VHDL lässt jedenfalls an Umständlichkeit Pascal im
> Vergleich zu Java und C++ weit hinter sich, ist aber trotzdem viel
> verschleiernder als BASIC in Vergleich zu Assembler.
Dass einem VHDL vom Syntax her nicht passt, das ist ein anderes Thema. 
Es gibt eben nicht viele andere Hardwarebeschreibungssprachen zur 
Auswahl. Und sobald es um die Umsetzung in reale Hardware geht, wird die 
Luft ganz, ganz dünn.

Schon das einfachste "Programm", die einfachste Beschreibung in VHDL 
lässt sich tadellos simulieren, kann aber (von den heutigen Tools noch) 
nicht in einem FPGA umgesetzt werden:
LED <= not LED after 500 ms;
Da fragt sich einer ganz berechtigt:
"Warum nicht? Ich gebe einem Takt vor und möchte eine blinkende LED. Das 
könnte ein halbwegs schlauer Synthesizer doch selber zu einem Zähler 
umrechnen..."

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird das noch kommen? Also ich hätte sowas auch gerne für normale 
Programme, man beschreibt irgendwie den Zusammenhang von Eingabe und 
Ausgabe und den Rest macht irgendeine Software ohne dass man sich selber 
drum kümmern muss.

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

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Wird das noch kommen?
Bei den mickrigen Schritten, die die Synthesesoftware macht, glaube ich 
nicht, dass das im nächstenJahrzehnt passiert. Wenn dann gibt es eine 
"neue" Sprache, die sowas "von vorn herein kann". Aber ich sehe auch 
eine solche noch nicht... ;-)

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> irgendwie

Irgendwies gibt's wie Sand am Meer... ;)


Lothar M. schrieb:
> Schon das einfachste "Programm", die einfachste Beschreibung in VHDL
> lässt sich tadellos simulieren, kann aber (von den heutigen Tools noch)
> nicht in einem FPGA umgesetzt werden

Und schon das einfachste signal, das "inout"(was soll das sein?) 
deklariert ist, ist laut Simulation in "undefiniertem Zustand", wenn 
nur die Testbench da einen Treiber ranhängt, weil (sic!) die Leitung 
ist ja "inout" und wenn die Komponente da intern nicht noch einen 
Treiber ranhängt, ist nicht definiert, wie die Komponente die Leitung 
unter Strom setzt.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Irgendwies gibt's wie Sand am Meer... ;)

In VHDL ist das irgendwie eben definiert. Da gibt es Regeln an die man 
sich halten muss.

nada schrieb:
> inout

Das ist eben ein Anschluss an den ein Pegel angelegt werden kann, der 
aber auch hochohmig geschaltet werden kann um einen extern angelegten 
Pegel nicht zu verfälschen (auf Masse oder High zu ziehen). Braucht men 
z. B. bei RAM.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Das ist eben ein Anschluss an den ein Pegel angelegt werden kann, der
> aber auch hochohmig geschaltet werden kann um einen extern angelegten
> Pegel nicht zu verfälschen (auf Masse oder High zu ziehen).

Jetzt so theoretisch oder auch echt?

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> -gb- schrieb:
>> Das ist eben ein Anschluss an den ein Pegel angelegt werden kann, der
>> aber auch hochohmig geschaltet werden kann um einen extern angelegten
>> Pegel nicht zu verfälschen (auf Masse oder High zu ziehen).
>
> Jetzt so theoretisch oder auch echt?

Ich sehe da nämlich einen Multiplexer...

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

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Und schon das einfachste signal, das "inout"(was soll das sein?)
> deklariert ist, ist laut Simulation in "undefiniertem Zustand", wenn nur
> die Testbench da einen Treiber ranhängt, weil (sic!) die Leitung ist ja
> "inout" und wenn die Komponente da intern nicht noch einen Treiber
> ranhängt, ist nicht definiert, wie die Komponente die Leitung unter
> Strom setzt.
Du verwechselst da mit an Sicherheit grenzender Wahrscheinlichkeit was:
'U' ist nicht 'undefiniert' sondern 'uninitialisiert'. Ein 
undefinierter bzw. unbekannter Zustand wird mit einem 'X' angezeigt.
https://www.cs.sfu.ca/~ggbaker/reference/std_logic/1164/std_logic.html

Und natürlich ist es problemlos möglich, einen inout-Port nur zu lesen. 
Und wenn der von Anfang an von beiden Seiten nur gelesen wird, dann 
kommt halt ein 'U' dabei heraus...

> das "inout"(was soll das sein?)
Es ist ein Port, der als Eingang und als Ausgang funktionieren kann. 
Manchmal ist das praktisch. Manchmal wäre sowas z.B. auch in C 
praktisch. Aber nein, da muss man dann gleich "eine Ebene höher" mit 
Zeigern herumhampeln...

: Bearbeitet durch Moderator
Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Ich sehe da nämlich einen Multiplexer...

Den kann man sehen wenn man möchte, ja. Wenn man auf einen Ausgang ein 
High oder Low oder Z legen kann, dann ist irgendwie auch eine Art 
Multiplexer.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> nada schrieb:
>> Und schon das einfachste signal, das "inout"(was soll das sein?)
>> deklariert ist, ist laut Simulation in "undefiniertem Zustand", wenn nur
>> die Testbench da einen Treiber ranhängt, weil (sic!) die Leitung ist ja
>> "inout" und wenn die Komponente da intern nicht noch einen Treiber
>> ranhängt, ist nicht definiert, wie die Komponente die Leitung unter
>> Strom setzt.
> Du verwechselst da mit an Sicherheit grenzender Wahrscheinlichkeit was:
> 'U' ist nicht 'undefiniert' sondern ' uninitialisiert'. Ein
> undefinierter bzw. unbekannter Zustand wird mit einem 'X' angezeigt.
> https://www.cs.sfu.ca/~ggbaker/reference/std_logic...

Nein. Ist der Xilinx-Simulator und wurde da vom Support so beantwortet. 
Das das ein "Fehler" sei, wurde wohlgemerkt nicht gesagt. Der Simulator 
schaut, weil die Leitung ja "inout" ist, welchen Output die Komponente 
da ranhängt. Wenn das keiner ist, wird's U. Weil '1'+'U'='U'. Wenn die 
Leitung auch "out" ist, und kein Ouput definiert ist, ist der 'U'. Ist 
doch logisch, oder?

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Den kann man sehen wenn man möchte, ja. Wenn man auf einen Ausgang ein
> High oder Low oder Z legen kann, dann ist irgendwie auch eine Art
> Multiplexer.

Ja. Und eine Leitung die zu einer anderen Komponente führt ist ein 
Kabel. Auch wenn da "inout" dransteht...

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Wenn die
> Leitung auch "out" ist, und kein Ouput definiert ist, ist der 'U'. Ist
> doch logisch, oder?

Ja, ist logisch. Könnte ja intern auch was anders als Z sein und so das 
aussen angelegte Signal nach high oder low ziehen. Wobei U eben kein X 
ist, da ist einfach unebkannt was noch dran hängt weil nicht 
beschrieben. Da feht dem Simulator eine Angabe.

nada schrieb:
> Und eine Leitung die zu einer anderen Komponente führt ist ein
> Kabel.

Natürlich! An einen Draht kann man doch auch von beiden Enden Spannung 
anlegen.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Natürlich! An einen Draht kann man doch auch von beiden Enden Spannung
> anlegen.
Eine wertvolle Bereicherung zum Simulationsbegriff.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ein in oder out hat immer nur einen Treiber zu einem Zeitpunkt. Ein 
inout hat zwei. Gut, einer der Beiden sollte ein 'Z' anlegen, aber es 
wird in Hardware so umgesetzt, dass man aus beiden Richtungen treiben 
kann.

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

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Ist doch logisch, oder?
Eigentlich schon. Es ist auf jeden Fall (wie bei VHDL üblich) nichts dem 
"Zufall" oder irgendwelchen impliziten Mechanismen überlassen. Mir 
gefällt das...  ;-)

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> nada schrieb:
>> Ist doch logisch, oder?
> Eigentlich schon. Es ist auf jeden Fall (wie bei VHDL üblich) nichts dem
> "Zufall" oder irgendwelchen impliziten Mechanismen überlassen. Mir
> gefällt das...  ;-)

Hatte nur leider nichts mit der Schaltung im Schaltplan zu tun.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit welcher Schaltung? Her damit! Ich mag das auch so wie es ist.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Mit welcher Schaltung?
Keine Ahnung. Wie gesagt: Eine Leitung zwischen 2 Komponenten ist ein 
Kabel.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kabel hin oder her, wenn du dem Simulator nicht mitteilst was 
angeschlossen ist an das Kabel oder ihm nur mitteilst was an einem der 
Enden angeschlossen ist, dann kann der dir auch nicht sagen ob das Kabel 
high oder low ist.

Bei einem "in" genügt es nur die eine Seite des Kabels anzugeben weil 
das andere Ende automatisch als hochohmig angenommen wird.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: nada (Gast)
>Keine Ahnung. Wie gesagt: Eine Leitung zwischen 2 Komponenten ist ein
>Kabel.

Da möchte ich zitieren:

>.. hatte Heidegger einen
>ziemlich konsequenten und daher auch realistischen Bezug auf das
>Problem: Eine Wischi-Waschi Durcheinanderbringung grundverschiedener
>Begriffe wie "Programm" und "Schaltplan" wäre da nur ein gefundenes
>Fressen.
>Ganz einfach: "Das eine ist das eine und das andere is' das and're."

:-P

Autor: nada (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert

entity simple is
    Port (
   data : inout  STD_LOGIC;
   o : out STD_LOGIC;
   clk : in STD_LOGIC );
end simple;

architecture Behavioral of simple is

begin

process (clk)
  variable x: std_logic;
begin
  if(rising_edge(clk)) then  
    x := data;
  end if;
  o <= x;
end process;

end Behavioral;

.....

  -- Instantiate the Unit Under Test (UUT)
   uut: simple PORT MAP (
          data => data,
          o => o,
          clk => clk
        );
  
  data <= '1';

   -- Clock process definitions
   clk_process :process

.....


@chris
Eben. Man lebt und lernt.

'1' + 'U' = 'U'. Das leuchtet ein. ;)

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hättest du noch ein

data <= 'Z';

geschrieben wäre alles gut. So wird data nämlich intern nur gelesen, 
damit ist das "in" vom inout abgedeckt, das "out" aber noch nicht.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Hättest du noch ein
>
> data <= 'Z';
>
> geschrieben wäre alles gut. So wird data nämlich intern nur gelesen,
> damit ist das "in" vom inout abgedeckt, das "out" aber noch nicht.

Und jetzt erkläre mir, was das mit der Schaltung da zu tun hat? Nichts?
Ach - das war ja mein Punkt....

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

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> '1' + 'U' = 'U'. Das leuchtet ein.
Bei einem std_logic sicher. Dessen Auflösungstabelle ist genau so 
definiert.
Und du hast doch extra und sehenden Auges den std_logic genommen.
Wenn du ein solches Verhalten nicht brauchen kannst, definiere doch 
einfach einem nada_logic Typ, der diesen "Konflikt" nach '1' auflöst...

: Bearbeitet durch Moderator
Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Und jetzt erkläre mir, was das mit der Schaltung da zu tun hat? Nichts?
> Ach - das war ja mein Punkt....

Der Simulator weiß halt nicht ob das jetzt in oder out ist. Und daher 
findet der Simulator auch zwei Treiber für data:

Drivers for /simple_bench/data
  U : Net /simple_bench/data
    U : Driver Implicit process at 
D:/vhdl/inout_sim/inout_sim.srcs/sources_1/new/simple.vhd:6
    1 : Driver /simple_bench/line__23 at 
D:/vhdl/inout_sim/inout_sim.srcs/sim_1/new/simple_bench.vhd:23

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der eine Treibe ist in der Testbench, da wird dem Data eine '1' 
zugewiesen, und der andere Treiber ist der "out"-Teil vom "inout", der 
ist nicht beschrieben und daher 'U'.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Der Simulator weiß halt nicht ob das jetzt in oder out ist. Und daher
> findet der Simulator auch zwei Treiber für data:

Interessantere Frage: Ist das das korrekte Ergebnis?

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hatte ich unglücklich formuliert. Also der Simulator sieht inout und 
erwartet dann einen Treiber für in und einen für out. Hier wurde der für 
out nicht beschrieben, das ist also U. Und weil es U ist könnte es auch 
0 sind. Der andere Treiber für in legt eine 1 an, wäre der Treiber für 
out aber 0 wäre das ein Konflikt. Und weil das eben passieren kann muss 
da auch U stehen und es darf nicht irgendwie wegoptimiert werden.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Das hatte ich unglücklich formuliert. Also der Simulator sieht
> inout und
> erwartet dann einen Treiber für in und einen für out. Hier wurde der für
> out nicht beschrieben, das ist also U. Und weil es U ist könnte es auch
> 0 sind. Der andere Treiber für in legt eine 1 an, wäre der Treiber für
> out aber 0 wäre das ein Konflikt. Und weil das eben passieren kann muss
> da auch U stehen und es darf nicht irgendwie wegoptimiert werden.

Meine Auffassung wäre ja, dass das eine Leitung ist, die genau einen 
Treiber hat...

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da steht aber inout, also kann sie zwei Treiber haben. Der Simulator 
könnte erkennen dass out nicht verwendet wird und das wie ein in 
behandeln. Das macht der aber nicht. Ich finde das auch richtig so, denn 
der Schreiber hat sich ja was gedacht wieso er inout verwendet. Dann 
soll er auch sehen dass das hier keinen Sinn ergibt.

Autor: Beispiel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Meine Auffassung wäre ja, dass das eine Leitung ist,
> die genau einen Treiber hat...

Beispiel: RAM-Baustein am FPGA, mit bidirektionalem Datenbus.
Beim Schreiben treibt das FPGA, beim Lesen treibt der RAM-Baustein.

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Da steht aber inout, also kann sie zwei Treiber haben.

Mag sein - hat sie aber nicht.
Da sehe ich also tendenziell ein Problem mit dem Simulator ODER ABER ein 
mehr oder weniger verbindlicher Standard (gibt's da überhaupt so etwas?) 
definiert, dass "inout" einen Treiber deklariert.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"inout" ist eine Abstraktion.
An den FPGA Ausgängen wird ein echter Tristate-Treiber synthetisiert.
Innerhalb des FPGAs gibt es keine Tristate-Treiber, deshalb werden dort 
getrennte Ein- und Ausgänge synthetisiert und damit die abstrakt 
beschriebene Funktionsweise realisieren.

P.s.: Könntest Du für VHDL-Code die VHDL-Formatierungsanweisung 
benutzten? Dann lässt sich der Code besser lesen.

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> process (clk)
>   variable x: std_logic;
> begin
>   if(rising_edge(clk)) then
>     x := data;
>   end if;
>   o <= x;
> end process;

wenn ich das sehe, rollen sich meine Fussnaegel auf...
Was bitte soll denn dabei rauskommen? Und wie soll ein SImulator damit 
das gleiche veranstalten wie ein Synthesetool?

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

Bewertung
1 lesenswert
nicht lesenswert
berndl schrieb:
> wenn ich das sehe, rollen sich meine Fussnaegel auf...
Ja, ein von einem Programmierer geschriebenen "VHDL Programm" eben. 
Natürlich hat in einem getakteten Prozess außerhalb der if-Takt Abfrage 
nichts stattzufinden oder zugewiesen zu werden. Aber lustigerweise 
"funktioniert" dieser Code zufällig sowohl in Simulation wie auch nach 
der Synthese gleich, weil x eine Variable ist...

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"stattfinden", "zuweisen" - so funktioniert das doch nicht!
Die Zeile verbindet x als Treiber mit dem Ausgang.
Wenn wir hier mit "Zuweisungen" zu tun hätten, hätte es das obige 
Problem gar nicht gegeben.

Was ich da im Standard finde ist
A process statement contains a driver for each actual signal associated with a formal signal parameter of mode out or inout in a subprogram call. Similarly, a subprogram contains a driver for each formal signal parameter of mode out or inout declared in its subprogram specification
Eine Zuweisung auf 'U' wird man im obigen Beispiel lange suchen können. 
Ich habe auch nicht gefunden, dass das inout dort überhaupt einen 
Treiber deklarieren würde.

Und noch prinzipieller: Ich kann mir echt absolut nicht erklären, 
welchen Sinn es haben sollte, da zu schreiben, das das ein Treiber sei. 
Welchen positiven Nutzen hat so ein Treiber ohne "Zuweisung"?

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Das ist für mich im Grunde das selbe,
Für mich ist das glasklar nicht dasselbe, denn es löst genau den 
Konflikt auf zwischen dem scheinbaren Unterschied von behaviour und 
structure:

Wenn man mit meinem Denkansatz herangeht, dann wird klar, warum manche 
Dinge (egal, wie man sie formal nennt) eben nachgebildet werden, indem 
man sie schnappt und einbaut, während man sie im andern Fall ausführt.

Ehrlich gesagt ist mir nicht klar, warum anderen das nicht klar ist:-)

Es liegt in Vorlesungen und Büchern allerdings manchmal auch an der 
miesen Didaktik und dem Umstand, dass scheinbar logische Sachen 
kurzerhand nicht direkt erklärt werden.

Für die Studies ist es z.B. mit der wichtigste Satz, dass eine Schleife 
immer zu einer Mehrfachhandlung des FPGA-Erbauers "XST" führt.

Der zweite Hinweis ist eben jene strikte Trennung von Logik und Physik:

Signale sind keine Leitungen, sondern Gleichheitszeichen, also 
Zuweisungen, die besagten, woher ein Punkt in der Logikschaltung seine 
Info bezieht.

Wenn man den Leuten das erklärt, dann kommt keiner mehr auf 
bidirektionale Leitungen, "wired or" oder tristates oder die oft 
verwendeten- aber real nicht existierenden "low aktiven Signale".

chris schrieb:
> "inout" ist eine Abstraktion.
Eigentlich ist es eine sehr konkrete Beschreibung, aber eben eine 
physikalische. Und damit ist es eine, die hilfsweise im VHDL steht um 
Porteigenschaften zu definieren und auf das Toplevel gehört, denn nur 
dort gibt es Ein- und Ausgänge.

> An den FPGA Ausgängen wird ein echter Tristate-Treiber synthetisiert.
Der ist bereits da und wird benutzt.

> Innerhalb des FPGAs gibt es keine Tristate-Treiber, deshalb werden
> dort getrennte Ein- und Ausgänge synthetisiert
Die sind bereits da (wenn sie da sind - einige FPGAs / Typen haben nicht 
an jedem Pin einen Out, wie z.B. der alte Spartan 3A) und sie werden 
genau so verschaltet, wie man tristate auch in jedem andere Chip hat und 
einbauen würde.  Innerhalb eines FPGAs gibt es genau genommen gar keine 
Ein- Ausgänge sondern nur Informationsgeber und -empfänger.


> und damit die abstrakt
> beschriebene Funktionsweise realisieren.
In dem Fall ist die Beschreibung durchaus sehr real.

Die Crux beim VHDL ist eben, dass sie Logik und Physik mischt. Man hätte 
das strenger trennen müssen und einen "physical" tag definieren müssen, 
mit dem tatsächlich vorhandene HW konkret angepeilt wird.

Dies wäre z.B. bei den Themen "IO-FF auch wirklich im IO" und 
"Reset-Synch-FF nicht ins Design verteilen" wichtig.

In manchen FPGA-Design-Guides von Firmen findet man daher auch die 
Vorgabe, solche Strukturen ausdrücklich einzubauen und nicht etwa zu 
inferieren.

Einige Tools unterstützen das auch: Ein Equivalent dazu findet sich z.B. 
in Simulink, welches ein ausdrückliches Delay vorsieht, welches - im Ggs 
zu einem echten FF - wegoptimiert werden darf. Allerdings bringt es nix, 
weil die dahinter kommende Synthese, es durchaus wieder wegwirft, wenn 
man es ihr nicht verbietet.

Wie Ich schon an mehreren Stellen empfohlen habe, plädiere Ich daher für 
eine ausdrückliche Trennung von FPGA-Toplevel-Physik und Logikdesign. 
Nur auf der ersten Ebene braucht man dann auch die ganze Mechanik der 
Simulation mit Delays, Timing und realem Verhalten wie Tristates. Der 
Rest geht mit clean clocks, synchronen Takten zu Signalen ohne waits, 
delays etc.



Allerdings hat das

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Schuhmacher (engineer) Benutzerseite
>chris schrieb:
>> "inout" ist eine Abstraktion.
>Eigentlich ist es eine sehr konkrete Beschreibung, aber eben eine
>physikalische. Und damit ist es eine, die hilfsweise im VHDL steht um
>Porteigenschaften zu definieren und auf das Toplevel gehört, denn nur
>dort gibt es Ein- und Ausgänge.

Ursprünglich habe ich aus so gedacht, aber dann habe ich folgendes 
ausprobiert, in dem ich ein paar Module erzeugt habe.

MACHX02_topLevelChipAdapter.vhd <=> main.vhd <=> onePinAdc.vhd

Das "inout"-Signal vom onePinAdc ziehe ich bis zum topLevelChipAdapter 
durch, der die zentrale Pin-Routingstelle ist.
Da ja der Übergang zwischen den Modulen innerhalb des FPGAs keine 
Tristate Signale erlaubt, bin ich davon ausgegangen, dass der 
Syntheszier das Ganze auf getrennte Signale abbildet und also die 
Signaldefinition "inout" auch innerhalb des FPGAs funktioniert.

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

Bewertung
1 lesenswert
nicht lesenswert
chris schrieb:
> Das "inout"-Signal vom onePinAdc ziehe ich bis zum topLevelChipAdapter
> durch, der die zentrale Pin-Routingstelle ist.
> Da ja der Übergang zwischen den Modulen innerhalb des FPGAs keine
> Tristate Signale erlaubt, bin ich davon ausgegangen, dass der
> Syntheszier das Ganze auf getrennte Signale abbildet und also die
> Signaldefinition "inout" auch innerhalb des FPGAs funktioniert.
Du kannst ein (z.B. inout-)Signal vom Top-Level über 100 Module und über 
100 verschiedene Namen nach "unten durchziehen", es wird immmer das 
selbe Signal sein. Mitnichten wird der Synthesizer dieses Signal ab der 
zweiten Entity in getrennte Pfade aufteilen und automatisch die 
Steuersignale dafür generieren. Ergo: du kannst jederzeit auch im 
"tiefsten Inneren" deines Designs direkt den IO-Pin und seine (z.B. 
Tristate-)Fähigkeiten verwenden.

chris schrieb:
> Da ja der Übergang zwischen den Modulen innerhalb des FPGAs keine
> Tristate Signale erlaubt
Natürlich kannst du in deinem Design an jeder Stelle auch von 
"Unterebene 99" zu "Unterebene 100" ein Tristate-Signal verwenden. Wenn 
dieser Datenstrom innerhalb des FPGAs implementiert werden soll, dann 
muss einfach der Zugriff auf diesen Bus exklusiv sein, es muss also für 
den Synthesizer erkennbar sein, dass immer nur 1 Teilnehmer aktiv auf 
dem Bus ist.
Dann kann er den (Tristate oder Bidirektionalen) Bus in getrennte 
Pfade und Multiplexer auflösen und umwandeln.

> bin ich davon ausgegangen
Es ist immer ein schlechtes Vorankommen, wenn man von etwas ausgeht, 
dort aber dann einfach stehen bleibt. Fazit: wenn du "von etwas 
ausgehst", dann musst du dich offensichtlich noch etwas bewegen, um 
irgendwo hin zu kommen...

: Bearbeitet durch Moderator
Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gehen tut vieles. Manchmal hilft's, mal ein Handbuch zu lesen. Aus: 
Recommended HDL Coding Styles, Quartus Handbook:

When you target Altera devices, you should use tri-state signals only 
when they are attached to top-level bidirectional or output pins. Avoid 
lower-level bidirectional pins, and avoid using the Z logic value unless 
it is driving an output or bidirectional

Synthesis tools implement designs with internal tri-state signals 
correctly in Altera devices using multiplexer logic, but Altera does not 
recommend this coding practice.
In hierarchical block-based or incremental design flows, a hierarchical 
boundary cannot contain any bidirectional ports, unless the lower-level 
bidirectional port is connected directly through the hierarchy to a 
top-level output pin without connecting to any other design logic. If 
you use boundary tri-states in a lower-level block, synthesis software 
must push the tri-states through the hierarchy to the top level to make 
use of the tri-state drivers on output pins of Altera devices. Because 
pushing tri-states requires optimizing through hierarchies, lower-level 
tri-states are restricted with block-based design methodologies.

Für mich heisst das: gegen Tristates ist nichts einzuwenden, wenn sie 
direkt auf dem Toplevel angelegt werden (entweder weil sie eben dort 
definiert oder "von unten durchgereicht" werden, ohne dass auf dem Weg 
nach oben dran gefummelt wird). Tristates "innerhalb" des Designs führen 
zu "Multiplexer-Ersatzschaltungen", die man besser vermeiden sollte.

Ich gehe damit (VHDL 2008) so um, dass ich std_logic_vector nur für 
"die guten" Tristates verwende. Alles andere ist std_ulogic.
So kann der Compiler mithelfen, versehentliche Schlampereien aufzudecken 
und Busstrukturen, die wirklich echte Tristates brauchen, sind viel 
einfacher zu lesen. Das funktioniert allerdings nur in VHDL 2008 
"richtig schön" (std_logic_vector ist ein subtype von 
std_ulogic_vector).

Autor: nada (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallelujah!
Komponentenbasierte Entwicklung muss sich ein für alle mal entscheiden, 
auf welcher Ebene ein Block sitzt, sonst wirds durchgerouted bis zu den 
Tristate-Pins von Altera(tm) devices.

Brille wechsel
Ist natürlich richtig - unterstreicht aber wieder einmal nur die These: 
VHDL ist einfach nichts Ganzes und nichts Halbes.
Und das nicht nur in Punkten, die eine derart eindeutige Konzession an 
die Praxis in sich tragen ( - der Optimizer bekommt's nicht gebacken, 
die inout-Leitung eigenständig in eine In- und eine Outputleitung zu 
zerlegen).
Versuche zB mal einer mit VHDL darüber zu streiten, was "TopLevel" 
bedeutet

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

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Versuche zB mal einer mit VHDL darüber zu streiten, was "TopLevel" bedeutet
Wozu streiten? Das ist lediglich Nomenklatur.

Der Toplevel ist meist die Komponente, für die ein Pinout Constrait File 
angelegt wird.

Du kannst aber auch eine Subkomponente (z.B. einen Divider oder einen 
Decoder) entwickeln, für die du dann einen "Toplevel" definierst, der 
aber nie an Pins kommt...

: Bearbeitet durch Moderator
Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nada schrieb:
> Versuche zB mal einer mit VHDL darüber zu streiten, was "TopLevel"
> bedeutet

"Streiten" mit sturer Software führt zu nix. Wenn Du's nicht ändern 
kannst, arrangiere dich damit (der Klügere gibt nach) oder mach' was 
anderes. Gärtner ist auch ein schöner Beruf ;)

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Jürgen Schuhmacher (engineer) Benutzerseite
>>Eigentlich ist es eine sehr konkrete Beschreibung, aber eben eine
>>physikalische. Und damit ist es eine, die hilfsweise im VHDL steht um
>>Porteigenschaften zu definieren und auf das Toplevel gehört, denn nur
>>dort gibt es Ein- und Ausgänge.
> Ursprünglich habe ich aus so gedacht, aber dann habe ich folgendes
> ausprobiert, in dem ich ein paar Module erzeugt habe.

Das haben schon andere ausprobiert und sind auf die Nase gefallen. Es 
mag sein, daß die design suite das toleriert und richtig fortpflanzt, 
aber für diesen Zweck gibt es in VHDL eigentlich den buffer-Konstrukt. 
Damit wird auf der obersten Ebene ein IO gemacht und weiter unten wird 
es ignoriert.

Das lehnen aber viele VHDL-Entwickler kategorisch ab.

> Da ja der Übergang zwischen den Modulen innerhalb des FPGAs keine
> Tristate Signale erlaubt, bin ich davon ausgegangen, dass der
> Syntheszier das Ganze auf getrennte Signale abbildet und also die
> Signaldefinition "inout" auch innerhalb des FPGAs funktioniert.
Das schon einmal garnicht, weil das weder von der Logik noch der 
gewollten Wirkung her das wäre, was gebraucht wird.

Ich würde Dir angesichts Deines Wissensstandes dringlichst empfehlen, 
Dich auf einfache Formulierungen zu beschränken und nicht auszureizen 
was die Software hergibt. Da gibt es nämlich böse Überraschungen.

Ach nebenbei: Wir sind OT, da es eigentlich ums Rechnen ging, oder?

Vielleicht möchte chris ja aber auch anfangen, mit Tristates zu rechnen. 
Ich bin sicher, dass es spannende Ergebnisse liefert.

Du könntest ja versuchen, einem IO-Port nach einem Takt ein 
Rechenergebnis zuzuweisen, dass das Quadrat seines Inputs ist.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: Markus F. (mfro)
>Für mich heisst das: gegen Tristates ist nichts einzuwenden, wenn sie
>direkt auf dem Toplevel angelegt werden (entweder weil sie eben dort
>definiert oder "von unten durchgereicht" werden, ohne dass auf dem Weg
>nach oben dran gefummelt wird). Tristates "innerhalb" des Designs führen
>zu "Multiplexer-Ersatzschaltungen", die man besser vermeiden sollte.

Das sehe ich genau so. Und für die Strukturierung meines Projektes ist 
es genauso ideal. Es funktioniert ganz wunderbar und wird deshalb auch 
so von mir verwendet. Basta.

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

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5208363:
> aber für diesen Zweck gibt es in VHDL eigentlich den buffer-Konstrukt.
> Damit wird auf der obersten Ebene ein IO gemacht und weiter unten wird
> es ignoriert.
Das ist aber nicht so ganz das, was der VHDL-Standard dazu sagt.

Ein buffer ist lediglich ein out Port einer Entity, der auch 
zurückgelesen werden kann, so dass sich schreibfaule Zeitgenossen lokale 
Signale sparen können.
Ein buffer, der an einen Pin angeschlossen ist, wird in der Hardware 
wie ein out Port umgesetzt: wenn ihm ein 'Z' zugewiesen wird, dann 
wird ein hochohmiger Treiber eingebaut.
Innerhalb des FPGAs wird bei einem multiplen "Buszugriff" versucht, das 
Ganze auf unidirektionale Signale und Multiplexer abzubilden.

: Bearbeitet durch Moderator
Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Ein buffer ist lediglich ein out Port einer Entity, der auch
> zurückgelesen werden kann
was für den Zweck der einfachen Beschreibung ja reicht.

> so dass sich schreibfaule Zeitgenossen lokale
> Signale sparen können.
was sie ja offensichtlich tun wollen

> Ein buffer, der an einen Pin angeschlossen ist, wird in der Hardware
> wie ein out Port umgesetzt: wenn ihm ein 'Z' zugewiesen wird, dann
> wird ein hochohmiger Treiber eingebaut.
was nicht falsch wäre

> Innerhalb des FPGAs wird bei einem multiplen "Buszugriff" versucht, das
> Ganze auf unidirektionale Signale und Multiplexer abzubilden.
da haben wir es doch

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Das sehe ich genau so. Und für die Strukturierung meines Projektes ist
> es genauso ideal. Es funktioniert ganz wunderbar und wird deshalb auch
> so von mir verwendet. Basta.

Das sollst Du doch auch genau so machen. Die buffer-Geschichte war nur 
die Ersatzlösung für die, welche unbedingt Schreibarbeit sparen wollen 
und tristates tief im Design hätten.

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

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5208773:
> Die buffer-Geschichte war nur die Ersatzlösung für die, welche unbedingt
> Schreibarbeit sparen wollen und tristates tief im Design hätten.
Das "und" ist an dieser Stelle eigentlich falsch.
Ich kann jederzeit auch einem "ganz normalen" out Port ein 'Z' 
zuweisen. Wenn dieser Port es bis an einen Pin schafft, dann wird das 
ein Tristate Ausgangspin.

Das "Hochreichen" eines tief vergrabenen buffer an einen höher 
liegenden out Port geht schon 15 Jahre und seit VHDL 2008 kann man 
auch einen out-Port ganz einfach "zurücklesen":
https://books.google.de/books?id=ETxLguPMEY0C&printsec=frontcover

: Bearbeitet durch Moderator
Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Lothar M. schrieb:

> Ich kann jederzeit auch einem "ganz normalen" out Port ein 'Z'
> zuweisen.
Aber damit machst Du ihn doch zum Tristate! Und Du kommandierst etwas, 
was es da unten nicht gibt. Wozu?

> Wenn dieser Port es bis an einen Pin schafft, dann wird das
> ein Tristate Ausgangspin.
Ja klar, ein Try and Error Spielchen, denn was passiert denn, wenn 
weiter oben in der Hierarchie weitere Zugriffe auf dem Signal laufen, 
die sich dann so nicht realisieren lassen?

Der Grund, Tritstates im Design zu belassen, wäre einzig, dass man das 
getrost überall reinwerfen kann, ohne es umzuverzeigern. Was passiert 
wenn mehrere Module auf unterschiedlichen Ebenen "reingeworfen" werden? 
Das müsste man erst allen durchspielen, oder man denkt strategisch und 
macht es so, wie es sein soll.

Letztlich müsste man bei der Verwendung solcher Module IM FPGA ja 
irgendwie eine Bussystem aufziehen, damit die miteinander reden können.

Mit solchen Gesichten werden nur Fallstricke erzeugt, über die man dann 
stolpert! Das macht für mich keinen Sinn.

Überall in der Softwareentwicklung und auch HW-Entwicklung versucht man 
doch, sowas zu vermeiden, Probleme schon im design zu verhindern, damit 
man die designs sicherer kriegt und schließt die Hintertürchen des 
unasauberen Programmierens.

Lieber etwas mehr Aufwand und dafür durchsichtig. In C für Automotive 
(MISRA) kannst Du schon lange nicht mehr das machen, was in C alles 
geht.


> Das "Hochreichen" eines tief vergrabenen buffer an einen höher
> liegenden out Port geht schon 15 Jahre

Ja, historisch gesehen gibt es in allen Programmiersprachen sehr viel 
Schwachsinn, der sich gehalten hat.

Das Rücklesen eines Signals nach dem Buffer ist technisch unmöglich und 
muss dann auch erst wieder umgestaltet werden, um dahin zu kommen, wie 
es richtig läuft, nämlich mit 2 Signalen, einem rücklesbaren vor dem 
buffer und einem echten nach draussen.

Bei einem PortPin ist das sicher sinnvoll, weil das, was im VHDL 
passiert real letztlich auch stattfinden kann.

Bei hierarchierten Modulen ist das aber überflüssig und falsch.

Wozu soll man sowas zulassen? Die Funktion macht keinen richtigen Sinn 
sondern was letztlich rasukommt, hängt davon ab, wie der Compiler es 
kann, was sonst drum herum passiert. Am Ende ist irgendwo ein 
wegoptimiertes Signal infolge einer Deaktivierung eines Funktion bei 
einer bestimmten Konfiguration dann dafür verantwortlich, dass es "der 
Pin nach oben schafft". Beim TEst geht alles gut.

Der nächste Designer macht eine Änderung und übersieht die Auswirkungen 
nicht.

Wir beide wissen doch sehr gut, wie genau designs von den 
Hacker-FPGA-lern dokumentiert sind, oder?

Das ist alles grosser Schwachsinn und in seriösen Anwendungen untragbar!

Bei keinem Codereview in der Automotive bekommst Du das durch. Bei 
keinem! Und das zurecht.

Und letztlich sind solche Sauereien mit der Grund, warum viele VHDL und 
FPGAs in der Automotive ablehnen.

Autor: Bernhard K. (bkom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5214212:
> Und letztlich sind solche Sauereien mit der Grund, warum viele VHDL und
> FPGAs in der Automotive ablehnen.

Mhh: jetzt würde ich doch gerne wissen was bei Automotive so verwendet 
wird:
 doch nicht etwa verilog?

: Bearbeitet durch User
Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5214212:
> Lothar M. schrieb:
>> Ich kann jederzeit auch einem "ganz normalen" out Port ein 'Z' zuweisen.
> Aber damit machst Du ihn doch zum Tristate! Und Du kommandierst etwas,
> was es da unten nicht gibt. Wozu?
Mach ich doch nicht. Ich schrieb nur, dass ich es könnte:
    process (...,sel,eingang1,...) begin
       ...
       ausgang <= eingang1 when sel='0' else 'Z';
    end process;
    ...
    ... viel Code und andere Prozesse
    ...
    process (...,eingang2,sel,...) begin
       ausgang <= eingang2 when sel='1' else 'Z';
    end process;
Dieser "Tristate-Bus" wird in der Realität niemals hochohmig, weil sel 
da nur '1' oder '0' sein kann. Deshalb macht der Synthesizer einen 
Multiplexer daraus. In der Simulation erscheint der Bus aber nach dem 
Start 'Z', weil sel dann 'U' ist und damit weder eingang1 noch eingang2 
auf den ausgang getrieben werden...

> Wozu soll man sowas zulassen?
Gar nicht sollte man es zulassen.

: Bearbeitet durch Moderator
Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5214212:
>> Ich kann jederzeit auch einem "ganz normalen" out Port ein 'Z'
>> zuweisen.
> Aber damit machst Du ihn doch zum Tristate! Und Du kommandierst etwas,
> was es da unten nicht gibt. Wozu?
>
>> Wenn dieser Port es bis an einen Pin schafft, dann wird das
>> ein Tristate Ausgangspin.
> Ja klar, ein Try and Error Spielchen, denn was passiert denn, wenn
> weiter oben in der Hierarchie weitere Zugriffe auf dem Signal laufen,
> die sich dann so nicht realisieren lassen?

Konsequenterweise müsstest Du "unten/innen" ausschliesslich std_ulogic 
oder gar bit-Typen verwenden, dann würden solche Fehler schon bei der 
Analyse/Synthese oder spätestens bei der Simulation deutlich auffallen 
und das strenge Typsystem wäre auch mal zu was nütze, anstatt immer nur 
hinderlich zu sein.

Machst Du das?

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Konsequenterweise müsstest Du "unten/innen" ausschliesslich std_ulogic
> oder gar bit-Typen verwenden
Endlich mal jemand, der mich versteht :-)
Ich verwende std_ulogic. Das hört leider da auf, wo man IP-Cores oder 
anderen Fremdcode andocken muß.

Duke

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Ich verwende std_ulogic.

ich auch.

> Das hört leider da auf, wo man IP-Cores oder
> anderen Fremdcode andocken muß.

und auch das ist kein Problem, wenn man sich vor der extra Schreibarbeit 
nicht scheut, die Fremd-IP in eigene, typsichere Components einzupacken.

Man kann ja durchaus Entities mit std_logic-Ports in std_ulogic... 
"Component-Sockel" stecken.

Autor: carlo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie aufwändig wäre es einen Gauss-Algorithmus in einen solchen FPGA zu 
packen? Wie schnell könnte der Rechnen um z.B. eine Kurze in Echtzeit 
anzuzeigen?  Nötig wären Spline-Interpolationen etc.

Autor: Edi M. (elektromeister)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Deshalb formuluere ich das mal so: VHDL ist hakelig und VHDL ist eben
> nicht wirklich gut, weswegen genau dieser Thread zustande gekommen
> ist.
was ist jetzt hierbei die Aussage? VHDL ist wofür nicht gut? Nicht gut 
zum Formulieren von Problemen? Oder nicht gut um generell Lösungen für 
FPGAs zu formulieren?

carlo schrieb:
> wie aufwändig wäre es einen Gauss-Algorithmus in einen solchen FPGA zu
> packen?
Vermutlich 10mal aufwändiger, weil es Implementierungen desselben in C 
zuhauf gibt, die es nur reinzuwerfen gilt.

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

Bewertung
0 lesenswert
nicht lesenswert
carlo schrieb:
> Wie schnell könnte der Rechnen um z.B. eine Kurze in Echtzeit anzuzeigen?
"In Echtzeit anzeigen" sind ja bestenfalls 10 pro Sekunde. Schneller 
kannst du nicht gucken, dann wird ein Film daraus.
Oder was ist deine Definition von "in Echtzeit anzeigen"?

Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
carlo schrieb:
> wie aufwändig wäre es einen Gauss-Algorithmus in einen solchen FPGA zu
> packen?

Schau dir den Algorithmus an, welche Schritte gemacht
werden müssen, welche davon parallel znd welche seriell,
daraus ergibt sich dann ein Zustandautomat und ein
Speicherlayout. (knifflig wird's evtl. falls das LG
nicht eindeutig oder nicht lösbar ist)

Abgesehen davon verwendet man beim LG-Lösen besser
numerische Verfahren (siehe das Buch "Numerical Recipies").
Und bei Spline-Interpolation lassen sich mit
Bernsteinpolynomen LG-Verfahren grösstenteils vermeiden,
je nach Glattheitsvoraussetzung lassen sich Kurven
im MHz-Bereich locker berechnen.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Edi M. schrieb:
> carlo schrieb:
>> wie aufwändig wäre es einen Gauss-Algorithmus in einen solchen FPGA zu
>> packen?
> Vermutlich 10mal aufwändiger, weil es Implementierungen desselben in C
> zuhauf gibt, die es nur reinzuwerfen gilt.

Das ist doch gar nicht die Frage. Jeden Algorithmus, den man in C 
formulieren kann, kann man auch in VHDL schreiben.

Die Frage war ja

carlo schrieb:
> Wie schnell könnte der Rechnen

und das finde ich viel interessanter.

Das FPGA ist einer CPU zunächst mal unterlegen, weil es mit Abstand 
nicht deren Taktfrequenz erreicht.

Schneller kann es nur sein, wenn sich das Problem ausreichend 
parallelisieren lässt, um diesen Nachteil mit möglichst vielen 
gleichzeitigen Berechnungen auszugleichen. Weil CPUs heutzutage auch 
gleich im Zehner- oder Dutzend- (oder bei HPCs/GPUs gar im 100er+ -) 
Pack daherkommen, die für Schnelligkeit alle beschäftigt sein wollen, 
stellt sich da im Grunde genau dasselbe Problem.

Ein zweiter Stärke des FPGA ist Pipelining, also auch bei komplexen 
Berechnungen bei jedem Takt ein neues Ergebnis auszuwerfen. 
Möglicherweise lohnt sich das beim Wiedereinsetzen beim Gauß. Natürlich 
nur, wenn die Problemstellung das auch erfordert.

Autor: Carlo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> carlo schrieb:
>> Wie schnell könnte der Rechnen um z.B. eine Kurze in Echtzeit anzuzeigen?
> "In Echtzeit anzeigen" sind ja bestenfalls 10 pro Sekunde. Schneller
> kannst du nicht gucken, dann wird ein Film daraus.

Das ist ganz genau der Hintergedanke! :-)
Ich hätte gern 60 Kurven die Sekunde.

Autor: Duke Scarring (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Im Moment will ich eine 24Bit Zahl mit einer 8 Bit Zahl multiplizieren.
Ich hab das mal eben simuliert/synthetisiert:
Ein Multiplikation benötigt ca. 100 Slices. Theoretisch passen 34 davon 
in einen MachXO2 (parallel).

Carlo schrieb:
> Ich hätte gern 60 Kurven die Sekunde.
Der Router von Lattice behauptet, das die Multiplikationen von chris 
(24x8) mit 50 MHz rennen können. Das wären 800k Multiplikationen in 16.6 
ms.

Wieviele Operationen/Multiplikationen/Additionen/Speichervorgänge 
braucht Dein Gauß?
Erst muß der Algorithmus stehen (inkl. benötigter Bitbreiten). Dann kann 
man verlässliche Aussagen treffen.

Duke

Autor: Thomas U. (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Das FPGA ist einer CPU zunächst mal unterlegen, weil es mit Abstand
> nicht deren Taktfrequenz erreicht.
Welche CPU vergleichst Du mit welchem FPGA?

Duke Scarring schrieb:
> Wieviele Operationen/Multiplikationen/Additionen/Speichervorgänge
> braucht Dein Gauß?

Die Frage hierbei wiederum ist: "Braucht er mehrere Berechnungen" dass 
sich das Parallele lohnt.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas U. schrieb:
> Markus F. schrieb:
>> Das FPGA ist einer CPU zunächst mal unterlegen, weil es mit Abstand
>> nicht deren Taktfrequenz erreicht.
> Welche CPU vergleichst Du mit welchem FPGA?

High-End mit High-End. Alles andere ist m.E. reichlich witzlos.

Autor: Edi M. (elektromeister)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Das ist doch gar nicht die Frage. Jeden Algorithmus, den man in C
> formulieren kann, kann man auch in VHDL schreiben.

Grundsätzlich ja, aber schreibe doch mal schnell reine Rekursions oder 
eine auf sich selbst zeigende Pointerstruktur in Listenform.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Edi M. schrieb:
> Markus F. schrieb:
>> Das ist doch gar nicht die Frage. Jeden Algorithmus, den man in C
>> formulieren kann, kann man auch in VHDL schreiben.
>
> Grundsätzlich ja, aber schreibe doch mal schnell reine Rekursions oder
> eine auf sich selbst zeigende Pointerstruktur in Listenform.

Mal ganz abgesehen von der Frage, ob das wohl die richtigen 
Designpatterns für Hardware sind (und der noch grundsätzlicheren Frage, 
ob sie überhaupt etwas in einem Lowlevel-Design - also beispielsweise 
auch in einem µC-Programm - was zu suchen haben): nicht unbedingt 
simpel, aber auch keine Raketentechnik, also durchaus machbar.

Autor: Edi M. (elektromeister)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Machbar ja, aber zu welchen Kosten? Gerade solche rechenintensiven 
Anwendungen bewegen sich oft auf Prototypen und da sind die 
Entwicklungskosten relevant. In VHDL wird da nichts unterstütz, soweit 
mir die Sprache geläufig.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Ich hab das mal eben simuliert/synthetisiert:
> Ein Multiplikation benötigt ca. 100 Slices. Theoretisch passen 34 davon
> in einen MachXO2 (parallel).

Bei nur 8 Bit sollte man überlegen, die Multiplikation durch Additionen 
zu ersetzen. Bei 8 Bit ergeben sich bei jedem erdenklichen Koeffizienten 
maximal Additionen + in der Hälfte der Fälle eine weitere Subtraktion. 
Das schafft man meistens über die Zeit.

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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