VHDL Grundlagen : Rechnen

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.

1

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.

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"

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 :-)

Arghh .. eigentlich wollte ich diesen Thread für die Rechengrundlagen 
nehmen ...

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.

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

Während Diamond diesen Ausdruck compiliert

1

table: for i in 0 to 255 generate

2

 Sinus_Rom(i) <= to_signed(integer( sin(2.0*MATH_PI*(real(i)+0.5)/1024.0) *32767.0),16);

3

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"...

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?

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

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.

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.

:)

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)

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.

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.

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!

>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

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:
> 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.

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?

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.

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"

1

                 _

2

  |             / /-\/

3

  |       ->   |_/\_/\

4

 / \           |/  \/\

5

/\  \

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.

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:
> 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:
> 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.

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

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.

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.

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

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

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

1

entity simple is

2

    Port (

3

   data : inout  STD_LOGIC;

4

   o : out STD_LOGIC;

5

   clk : in STD_LOGIC );

6

end simple;

7

8

architecture Behavioral of simple is

9

10

begin

11

12

process (clk)

13

  variable x: std_logic;

14

begin

15

  if(rising_edge(clk)) then  

16

    x := data;

17

  end if;

18

  o <= x;

19

end process;

20

21

end Behavioral;

1

.....

2

3

  -- Instantiate the Unit Under Test (UUT)

4

   uut: simple PORT MAP (

5

          data => data,

6

          o => o,

7

          clk => clk

8

        );

9

10

  data <= '1';

11

12

   -- Clock process definitions

13

   clk_process :process

14

15

.....

@chris
Eben. Man lebt und lernt.

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

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:
> 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?

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

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?

"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"?

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.

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

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.

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.

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.

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

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

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.

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.

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.