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:
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:
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
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.
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.
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.
>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"
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.
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.
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
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 :-)
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.
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:
1
INFO - c:/.../multiplier.vhd(22): input pin size has no actual or default value. VHDL-9000
2
INFO - C:/lscc/diamond/3.8_x64/ispfpga/vhdl_packages/numeric_std.vhd(718): size is declared here. VHDL-1259
3
4
ERROR - c:/projekte/fpga/lattice/mul_test/multiplier.vhd(22): expression has 25 elements expected 24. VHDL-1077
5
Done: error code 2
Zielplattform war ebenfalls MachXO2. Der Synthesizer war der von
Lattice.
Die Synplify Lattice Version sagt dazu:
1
E CD371 No matching overload for to_signed multiplier.vhd (22) multiplier.srr (22) error
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?
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 :)
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?
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 ;-)
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.
>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.
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"...
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...
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.
>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?
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?
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.
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.
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
> 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.
:)
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?
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/
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
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.
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.
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"...
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 ...
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.
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!
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...
>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.
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.
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
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...
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.
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.
1
i=3*5/2;
oder
1
for(i=0;i<1000;i++);
oder gar
1
#include<iostream>
2
3
template<intN>structFib_t{
4
enum{value=Fib_t<N-1>::value+Fib_t<N-2>::value};
5
Fib_t(){std::cout<<N<<": "<<value<<std::endl;}
6
};
7
8
template<>structFib_t<2>{
9
enum{value=1};
10
Fib_t(){std::cout<<2<<": "<<value<<std::endl;}
11
};
12
13
template<>structFib_t<1>{
14
enum{value=1};
15
Fib_t(){std::cout<<1<<": "<<value<<std::endl;}
16
};
17
18
intmain(void)
19
{
20
Fib_t<30>f;
21
}
(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" ;)
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.
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.
>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.
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.
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.
>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.
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.
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
>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
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.
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...
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.
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"?
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?
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"...
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.
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.
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
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"
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.
-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.
-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.
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
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..."
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.
-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... ;-)
-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.
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.
-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?
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...
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...
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.
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?
-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...
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.
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.
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... ;-)
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.
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: 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
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.
-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....
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...
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
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'.
-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?
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.
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...
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.
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.
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.
"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.
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?
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...
"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
1
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"?
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
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.
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...
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).
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
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...
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 ;)
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: 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.
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.
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
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.
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
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.
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?
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:
1
process(...,sel,eingang1,...)begin
2
...
3
ausgang<=eingang1whensel='0'else'Z';
4
endprocess;
5
...
6
...vielCodeundandereProzesse
7
...
8
process(...,eingang2,sel,...)begin
9
ausgang<=eingang2whensel='1'else'Z';
10
endprocess;
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.
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?
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
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.
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.
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.
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"?
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschalten