Schaltungsminimierung mit KV-Diagramm
Dirk Bossenz
ich habe hier einen Zähler bestehend aus
4 JK-FF. Dieser zählt von 0-7,15-8 (Dualcode)
Dies ganze ist nun in 4 KV-Diagramme ein
getragen, für jedes FF eins. J und K sind dabei
in die KV-Diagramme mit ein gegangen, es werden
auch zwei Funtkionsgleichungen(J,K) aus den Diagrammen
herausgelesen.
Ich habe leider bei sowas nie richtig aufgepasst,
und nun stehe ich vor dem Problem, das ich
1) aus der Wertertabelle die Werte in die KV-Diagramme
eintragen muß (was ich noch so hinbekomme)
2) nichts mit der Unterscheidung von J und K inerhalb
des KV-Diagramm anfangen kann (wie&wo?)
3) nicht weiß wie ich nun Zusammenfassen kann (wg. der
Unterscheidung von J und K)
Diverse zufindene Vorlesungsskripte im Netz sind entweder
zu knapp gehalten, beinhalten andere Verfahrensweisen (mit
J und K in getrennten KV-Diagrammen), sind zu kompliziert
erklärt(von den Informatikern halt).
Wer kennt's und kann helfen? Das ganze wird dann natürlich
auf dem Digitaltrainer-Board aufgebaut, dementsprechend wenige
Logikgatter sind vorhanden (8 AND/NAND mit 2 Input; 4 AND/NAND
mit 4 Input; 4 OR/NOR mit 2 Input; 4 AND/NAND mit 4 Input;
8XOR mit 2 Input und 4 Inverter).
Das heißt mit dem numerischen Verfahren kommt man nicht hin;
zumindest habe ich es nicht geschafft mit ABEL (womit ich bisher
immer sowas mache) mir Logik mit den nur vorhandenen Gattern
zusammenzusetzen.
thx
Dirk
Falk Brunner
"Dirk Bossenz" <tig...@lipsia.de> schrieb im Newsbeitrag
news:cs5om9$us3$1...@news.manner.de...
> ich habe hier einen Zähler bestehend aus
> 4 JK-FF. Dieser zählt von 0-7,15-8 (Dualcode)
>
> Dies ganze ist nun in 4 KV-Diagramme ein
> getragen, für jedes FF eins. J und K sind dabei
> in die KV-Diagramme mit ein gegangen, es werden
> auch zwei Funtkionsgleichungen(J,K) aus den Diagrammen
> herausgelesen.
>
> Ich habe leider bei sowas nie richtig aufgepasst,
> und nun stehe ich vor dem Problem, das ich
> 1) aus der Wertertabelle die Werte in die KV-Diagramme
> eintragen muß (was ich noch so hinbekomme)
Soweit, so gut.
> 2) nichts mit der Unterscheidung von J und K inerhalb
> des KV-Diagramm anfangen kann (wie&wo?)
J und K sind unabhängige Dateneingänge für die JK-FFs. Also muss für beide
eine unabhängige Funktionsgleichung her. Somit sind es quasi 8 KV-Diagramme.
> 3) nicht weiß wie ich nun Zusammenfassen kann (wg. der
> Unterscheidung von J und K)
Im Prinzip erstmal gar nicht. Allerdings besteht der Trick darin, die
Schaltung so aufzubauen, dass die JK-FF als sog. Toggle FFs laufen, will
sagen J und K sind verbunden, dadurch kann ich nur noch J=K=0 oder J=K=1
anlegen, d.h. bei 0. ändert sich der FF Ausgang nicht, bei 1 wird der
Ausgangspegel invertiert. Bei bestimmten Schaltungen kann man damit
Logikgatter einsparen, bei anderen braucht man mehr. Welche Version nun die
Beste ist, kannst du nur herausfinden, indem du für beide Varianten die
Wertetabellen aufschreibst, in KV-Diagrame einträgt und entsprechend
minimiert ausliest.
> Wer kennt's und kann helfen? Das ganze wird dann natürlich
Naja, JK-FFs sind heute in der Praxis eher selten. "Richtige"
Digitalschaltkreise (sprich CPLDs/FPGAs) haben eh nur D-FFs.
> auf dem Digitaltrainer-Board aufgebaut, dementsprechend wenige
> Logikgatter sind vorhanden (8 AND/NAND mit 2 Input; 4 AND/NAND
> mit 4 Input; 4 OR/NOR mit 2 Input; 4 AND/NAND mit 4 Input;
> 8XOR mit 2 Input und 4 Inverter).
> Das heißt mit dem numerischen Verfahren kommt man nicht hin;
??? Wieso?
> zumindest habe ich es nicht geschafft mit ABEL (womit ich bisher
> immer sowas mache) mir Logik mit den nur vorhandenen Gattern
> zusammenzusetzen.
ABEL kann das schon minimieren, allerdings kann es auch nicht zaubern. Wenn
man nur einfache logische Funktionen hat, braucht man eben mehr Gatter.
MfG
Falk
Thomas Reinemann
Dirk Bossenz wrote:
> hallo,
>
> ich habe hier einen Zähler bestehend aus
> 4 JK-FF. Dieser zählt von 0-7,15-8 (Dualcode)
>
> Dies ganze ist nun in 4 KV-Diagramme ein
> getragen, für jedes FF eins. J und K sind dabei
> in die KV-Diagramme mit ein gegangen, es werden
> auch zwei Funtkionsgleichungen(J,K) aus den Diagrammen
> herausgelesen.
anhand der ziemlich sinnlosen Aufgabenstellung gehe ich davon aus, dass dies
Teil einer Ausbildung ist. Um es mal drastisch auszudrücken, kein Mensch
braucht heute noch Minimierungsverfahren. Die paar die wirklich noch mit
TTL-Gräbern zu tun haben, können sich das so aneignen. Du kannst deinem
Prof/Ausbilder sagen, er soll mal seine Hausaufgaben machen und sich an der
Realität orientieren. Heutzutage ist es wichtig zu wissen, wie man den
Inhalt einer Schaltbelegungstabelle in VHDL, Verilog, C, Abel usw umsetzt.
Den Rest machen dann die Compiler/Synthese-Tools.
Dies hilft nun nicht mehr dir, aber vielleicht den folgenden Generationen
Bye Tom
--
Dr.-Ing. Thomas Reinemann www.uni-magdeburg.de/reineman
IMAT Public key available
Otto-von-Guericke-Universität Magdeburg
Universitätsplatz 2
39106 Magdeburg, Germany
Dirk Bossenz
> anhand der ziemlich sinnlosen Aufgabenstellung gehe ich davon aus, dass dies
> Teil einer Ausbildung ist. Um es mal drastisch auszudrücken, kein Mensch
> braucht heute noch Minimierungsverfahren. Die paar die wirklich noch mit
> TTL-Gräbern zu tun haben, können sich das so aneignen. Du kannst deinem
> Prof/Ausbilder sagen, er soll mal seine Hausaufgaben machen und sich an der
> Realität orientieren. Heutzutage ist es wichtig zu wissen, wie man den
> Inhalt einer Schaltbelegungstabelle in VHDL, Verilog, C, Abel usw umsetzt.
> Den Rest machen dann die Compiler/Synthese-Tools.
jo...das hab ich ihm schon gesagt...auch das VHDL und Abel sehr wichtig
sind und er dies doch bitte stattdessen vermitteln soll. Er seines
Zeichens Dozent an der Hochschule - ein Mann direkt aus der Wirtschaft,
mit kleiner Atmel-Programmier-Bude - meinte dazu nur: wenn sie das
begriffen haben, dann können sie auch alles andere...mein Problem:
ich kann zwar alles andere, aber das nicht.
Dirk
Falk Brunner
Newsbeitrag news:cs81gu$m28$1...@fuerst.cs.uni-magdeburg.de...
> anhand der ziemlich sinnlosen Aufgabenstellung gehe ich davon aus, dass
dies
> Teil einer Ausbildung ist. Um es mal drastisch auszudrücken, kein Mensch
> braucht heute noch Minimierungsverfahren. Die paar die wirklich noch mit
AUA. Und das bei DER Signatur??
> --
> Dr.-Ing. Thomas Reinemann www.uni-magdeburg.de/reineman
> IMAT Public key available
> Otto-von-Guericke-Universität Magdeburg
> Universitätsplatz 2
> 39106 Magdeburg, Germany
Wieso noch Kopfrechen wenn jeder (Depp) nen P4 zuhause hat.
Ich meine, für angehene Techniker (und erst recht Ingeniere!!!) ist das
Grundverständniss solcher Dinge unverzichtbar. Sonst hat man bald nur noch
"Spezialisten", die auf ihrer tollen GUI rumclicken und wenn eine Schaltung
zu gross/zu langsam ist sagen, tja, schlechter Chip.
Wenn auch der Grossteil der logischen Schaltungsminimierung heute
automatisch erledigt wird, ist doch das Hintergrundwissen von echten
Spezialisten(tm) nie verkehrt, oft unverzichtbar.
Bisher hat die Seuche der aufgeblasenen Software (Hello World nicht <100K
mit C++ & Co) die Hardwarewelt noch icht ganz erreicht. Aber es wird nur
eine Frage der Zeit sein, wenn alle nur noch auf bunte Fenster clicken und
sich von Wizards ihre Zeugs zusammenbauen lassen. 100k oder 200k Baustein??
Egabl, der Wizards wirds schon wissen. Dann haben die Marketingleute ihr
ultimatives Ziel erreicht. Fachkompetenz und Hintergrundwissen der Kunden
auf Null.
> TTL-Gräbern zu tun haben, können sich das so aneignen. Du kannst deinem
Tja, warum er wohl diese Aufgabe lösen will/muss?? Vielleicht wird er in
Zukunft mit Digitaltechnik zutun haben?? TTL Gräber wohl kaum, FPGAs/CPLDs
sehr wohl.
> Prof/Ausbilder sagen, er soll mal seine Hausaufgaben machen und sich an
der
> Realität orientieren. Heutzutage ist es wichtig zu wissen, wie man den
> Inhalt einer Schaltbelegungstabelle in VHDL, Verilog, C, Abel usw umsetzt.
;-)))
Wenn ich schon VHDL nehme, dann sicher nicht, um irgendwelche
"Schaltbelegungstabellen" umzusetzen. Das haben villeicht die Leute von 10
Jahren mit ihren GALs gemacht. VHDL entfaltet seine Möglichkeiten erst
richtig bei systematischem Schaltungsentwurf der mindestens eine Ebene über
"Schaltbelegungstabellen" liegt.
> Den Rest machen dann die Compiler/Synthese-Tools.
Aber auch die haben ihre Grenzen und sind manchmal bissel dämlich. Dort muss
ein Spzialist dann schon mal nachhelfen.
MfG
Falk, der auch noch KV-Diagramme durchexerziert hat.
Dirk Bossenz
> Aber auch die haben ihre Grenzen und sind manchmal bissel dämlich. Dort muss
> ein Spzialist dann schon mal nachhelfen.
ja...und bei dieser Aufgabe sind sie nämlich vorhanden...da ich an die
wenigen Bauteile des beliebten Digitalkoffers gebunden bin. Und mit
nummerischen QC-Verfahren muß ich bei den ersten beiden FF's zuviele
Gatter nutzen, bzw. noch weiter zusammenfassen. - Eine Lösung gibt es
auf alle Fälle, meint ER, ich soll
konsequent das KV-Diagramm anwenden und die Theoreme der Schaltalgebra.
Und zwar müßte ich - wenn jetzt alles stimmt - aus den 4x4
OR/NOR-Gattern UND-Gatter machen (durch Negieren des Ausganges)
und das schafft AFAIK keine Software...oder?
> MfG
> Falk, der auch noch KV-Diagramme durchexerziert hat.
ich habe jetzt 8 KV-Tafeln aufgestellt. Und
konkrete Unsicherheit habe ich bei FF0:
J0
1 0 0 1
1 0 0 1
1*0 0 1
0 0 0 1
K0
0 1 1 0
0 1*0 0
0 1 1 0
0 1 1 0
Die mit dem * gekennzeichneten 1 (welche Minterme representieren)
würden übrig bleiben (die anderen 2 und 4 Päckchen fallen weg), oder?
Ein weiterer Extremfall ist der J1 von FF1:
1 0 1 0
0 0 0 0
0 0 0 0
0 0 1 0
J1=(Q3 Q2 -Q1 -Q0)+(-Q3 Q2 -Q1 Q0)+(-Q3 -Q2 -Q1 Q0)
Ist es möglich NUR für diese KV-Tafel durch anordnen der
"Minterme-Platzvergabe" so zu legen, das nur noch ein
Minterm übrig bleibt? Oder andersweitig zu minimieren?
THX
Dirk
Michael Schöberl
> begriffen haben, dann können sie auch alles andere...mein Problem:
> ich kann zwar alles andere, aber das nicht.
tjaa - und da muss ich ihm Recht geben! in
comp.arch.fpga kommt regelmäßig die Frage warum
ein WAIT FOR 10 us; nicht synthetisierbar ist ...
schon minimales Vorstellungsvermögen über die
Arbeit der eingesetzten Software kann das erklären!
nach 3 Jahren FPGA-Nebenjob merke ich immer
deutlicher, dass meine erstellte Logik nicht wirklich
optimal ist ...
ausgewogene Logiklevel erreiche ich, indem einfach
nach den ersten Syntheseversuchen irgendwo in den
kritischen Pfaden Register reingebaut werden ...
es funktioniert (super) - meint man kaum ...
wie lernt man, wie man das richtig macht?
bye,
Michael
Georg Acher
=?iso-8859-1?Q?Michael_Sch=F6berl?= <MScho...@ratnet.stw.uni-erlangen.de> writes:
|> > [...] meinte dazu nur: wenn sie das
|> > begriffen haben, dann können sie auch alles andere...mein Problem:
|> > ich kann zwar alles andere, aber das nicht.
|>
|> tjaa - und da muss ich ihm Recht geben! in
|> comp.arch.fpga kommt regelmäßig die Frage warum
|> ein WAIT FOR 10 us; nicht synthetisierbar ist ...
|> schon minimales Vorstellungsvermögen über die
|> Arbeit der eingesetzten Software kann das erklären!
Da hilft aber KV auch nicht ;-) Wo KV grad noch sinnvoll wären, wären CPLDs.
Spätenstens bei den meisten FPGAs ist das dann egal und es ist nur noch die
Anzahl der Eingangssignale wichtig...
Und wenn ich das Problem des OP richtig verstanden habe, ging es da noch um
JK-Flipflops, das ist ja eigentlich noch grösserer Blödsinn als die
KV-Spielereien. Die JKs gibts doch so gut wie nicht mehr, in CPLDs/FPGAs erst
recht nicht. Irgendwann muss man sich einfach mal von der 74er-Reihe lösen. Wenn
man sich seine Schaltungen nur in 74er-Logik vorstellen kann, geht einem viel
ab...
|> nach 3 Jahren FPGA-Nebenjob merke ich immer
|> deutlicher, dass meine erstellte Logik nicht wirklich
|> optimal ist ...
|> ausgewogene Logiklevel erreiche ich, indem einfach
|> nach den ersten Syntheseversuchen irgendwo in den
|> kritischen Pfaden Register reingebaut werden ...
|> es funktioniert (super) - meint man kaum ...
Das machen die Synthesetools mit Registerbalancing doch automatisch. Man haut
einfach vorne oder hinten (je nach Tool) eine Latte von Registern rein. Dumm
nur, wenn die Latenz zu gross wird, dann muss man leider nachdenken ;-)
|> wie lernt man, wie man das richtig macht?
Indem man es zuerst falsch macht.
--
Georg Acher, ac...@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Martin Laabs
> Wieso noch Kopfrechen wenn jeder (Depp) nen P4 zuhause hat.
> Ich meine, für angehene Techniker (und erst recht Ingeniere!!!) ist das
> Grundverständniss solcher Dinge unverzichtbar.
Das ist das Todschlagargument überhaupt. Ich bin zwar noch nicht so alt
aber mir wurde zugetragen das es bei der Einführung des Taschenrechners
wahnsinnige Diskusionen gab das eine Verdummung der Schüler droht.
Natürlich kann heute kaum mehr ein Schüler das große Ein mal Eins aber
ist es wirklich nötig?
Ich konnte ab der 10. Klasse einen programmierbaren Taschenrechner in
der Schule einsetzen der ein komplettes CAS enthält. Ich kann jetzt
nicht so schnell eine Taylorreihe aufschreiben wie es jemand könnte
der es 300 mal in der Schule machen musste. Ich muss bei ungewöhnlichen
Integralen evt. auch mal in die Formelsammlung schauen was ein "normaler"
Abiturient auswendig weis.
Aber ich habe freude an der Mathematik weil mir ein großer Teil der
Knechtsarbeit erspart bleibt und ich behaupte einen viel besseren Überblick
über die Mathematik bekommen zu haben als wenn ich das CAS nicht
zur Verfügung gehabt hätte.
Und dadurch das ich das Werkzeug nun perfekt behersche kann ich mal
Dinge ganz schnell ausprobieren zu denen ich mit Bleistift und Papier
viel zu lange bräuchte und demzufolge keine Lust hätte.
Es ist ja auch so das du nicht das Geschirrspülen verlernst nur
weil du eine Geschirrspülmaschine hast, du aber eher ein aufwändiges
Gericht kochst weil du weist das du nacher den Abwasch nicht per
Hand machen musst.
Und wir lernen jetzt im 3. Semester die Zweitortheorie auch nur noch
in 3 Doppelstunden weil es durch die Schaltungssimulation an Bedeutung
verlohren hat.
Tschüss
Martin L.
Matthias Eckel-Binder
> Diverse zufindene Vorlesungsskripte im Netz sind entweder
> zu knapp gehalten, beinhalten andere Verfahrensweisen (mit
> J und K in getrennten KV-Diagrammen), sind zu kompliziert
> erklärt(von den Informatikern halt).
>
zum Thema "Script" KV-Diagramme:
ist zwar kein Script, aber eine Vorlesung auf Video. Man kann sich also
die Grundlagen so oft ansehen, wie man möchte. Tolle Idee der Uni
Tübingen:
Besonders die Vorlesungen Technische Informatik I & II (einfach über die
Suche zu finden) sind wirklich sehenswert. Half mir sehr bei meiner
Digitaltechnik-Prüfung.
Gruß
Matthias
Dirk Bossenz
> Falk, der auch noch KV-Diagramme durchexerziert hat.
kann ein FF auch seinen eigenen Ausgang mit als Bestandteil
seiner charakteristischen Eingangsgleichung für J oder K haben??
Also ich würde bei solchen Sachen auch meine Mitstudenten
oder besser noch den Dozenten fragen - meine Mitstudenten
hatte ich schon gefragt, wissen es aber auch nicht richtig
und der Dozent erklärt und verliert sich in seinen ver-
schachtelten Nebensätzen.
Dirk
Oliver Bartels
wrote:
>Also ich würde bei solchen Sachen auch meine Mitstudenten
>oder besser noch den Dozenten fragen - meine Mitstudenten
>hatte ich schon gefragt, wissen es aber auch nicht richtig
>und der Dozent erklärt und verliert sich in seinen ver-
>schachtelten Nebensätzen.
Die KV-Diagramme decken in handhabbarer Form wirklich
nur die allersimpelsten Fälle ab, nämlich jene, die ein halbwegs
intelligenter Mensch auch so in seinem Kopf oder auf einem
Blatt Papier durchspielen kann.
Ergo: Betrachte sie wirklich als simples Spielchen,
hier eine Schleife, da eine, oh, jetzt haben wir eine
Minimalform entdeckt, wär hätte es gedacht ;-/
Alles andere - nämlich das, was als Logiktabelle übliche
Speicherdimensionen sprengt - ist nicht trivial und - so es
in einen *guten* Logikcompiler implementiert werden soll -
echte Kunst. Eben so wie Integrieren, man oder
Compiler "sieht" die schöne Lösung oder eben nicht.
Demzufolge schauen die Ergebnisse vieler
marketinggetriebener (tm) VHDL Compiler auch sehr
traurig aus.
Gruß Oliver
--
Oliver Bartels + Erding, Germany + obar...@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
MaWin
>
> kann ein FF auch seinen eigenen Ausgang mit als Bestandteil
> seiner charakteristischen Eingangsgleichung für J oder K haben??
>
Ja, natuerlich,
genau deswegen gibt/gab es vorbereitende Eingaenge wie J und K.
Heute natuerlich J und K ersetzt durch D, erfordert mehr Logik
aber weniger PinCount.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Dirk Bossenz
> On Sun, 16 Jan 2005 13:06:08 +0100, Dirk Bossenz <tig...@lipsia.de>
> wrote:
>
>>Also ich würde bei solchen Sachen auch meine Mitstudenten
>>oder besser noch den Dozenten fragen - meine Mitstudenten
>>hatte ich schon gefragt, wissen es aber auch nicht richtig
>>und der Dozent erklärt und verliert sich in seinen ver-
>>schachtelten Nebensätzen.
>
> Logik-Optimierung ist ein NP-Problem.
gibt es ein Programm was einfach nur boolsche Ausdrücke
vereinfacht? (als Extra vielleicht, jeden Minimierungs-
schritt anzeigt?)
ich hab jetzt zwar im Netz gesucht, aber nix passendes gefunden.
bei ABEL oder ähnliches kommt nur Schnulli raus, da immer nur
auf konkrete Bausteine entwickelt wird - allgemein genommen ist
dieser Digitaltechnik-Übungskoffer auch nix anderes, aber um ihn
als Baustein zu definieren und bei easyABEL einzubinden bedarf
es Zeit und noch mehr HowToDo, was ich nicht habe.
DAs würde mir jetzt helfen, um entweder meine Ergebnisse abzu-
gleichen bzw. besser zu minimieren.
thx
Dirk
PS: ich bin jetzt im 11Sem. ET an zwei unterschiedlichen FH's
gewesen, an beiden wurde VHDL-Entwurf als was spezielles Seltenes
abgetan - sprich nicht Bestandteil der regulären Vorlesungen -
irgendwie ärgerlich. An der einen FH haben wir stattdessen alles
mit dem mC gemacht bzw. fertige IC's aus dem Katalog gesucht und
an der jetzigen dienen die Ing.s nur als Teamleader/Verantwortungs-
träger, und bilden die Schnittstelle zwischen Facharbeitern und
Managment.(alles beides ist Nachrichtentechnik/Informationstechnik
bzw. Kommunikations- und Informationstechnologie)
Georg Acher
>> Logik-Optimierung ist ein NP-Problem.
>
>
>gibt es ein Programm was einfach nur boolsche Ausdrücke
>vereinfacht? (als Extra vielleicht, jeden Minimierungs-
>schritt anzeigt?)
http://diamond.gem.valpo.edu/~dhart/ece110/espresso/tutorial.html
Das mit den Schritten wird schwierig, weil es nicht auf der Gleichungsebene
optimiert wird... Oft wird dabei das Verfahren von Quine-McCluskey benutzt. Such
mal in google, da gibt's viel dazu, zB.:
http://maui.theoinf.tu-ilmenau.de/~sane/skript_new/node28.html
<...>
>PS: ich bin jetzt im 11Sem. ET an zwei unterschiedlichen FH's
>gewesen, an beiden wurde VHDL-Entwurf als was spezielles Seltenes
>abgetan - sprich nicht Bestandteil der regulären Vorlesungen -
Eben, wozu Chips entwickeln, die kommen doch schon alle aus Taiwan oder USA...
>irgendwie ärgerlich. An der einen FH haben wir stattdessen alles
>mit dem mC gemacht bzw. fertige IC's aus dem Katalog gesucht und
>an der jetzigen dienen die Ing.s nur als Teamleader/Verantwortungs-
>träger, und bilden die Schnittstelle zwischen Facharbeitern und
>Managment.(alles beides ist Nachrichtentechnik/Informationstechnik
>bzw. Kommunikations- und Informationstechnologie)
Gute Nacht, Deutschland...
Willi Marquart
>kann ein FF auch seinen eigenen Ausgang mit als Bestandteil
>seiner charakteristischen Eingangsgleichung für J oder K haben??
_ _
Qn+1 = KQn + JQn
Dabei ist Qn der Zustand vor und Qn+1 der nach dem Clock-Impuls.
Wenn Du jetzt ein KV-Diagramm für Qn+1 aufstellst, darfst Du keine
Zusammenfassungen machen, bei denen Qn eliminiert wird. Dann lässt
sich das Ergebnis durch Ausklammern von Qn bzw. Qn-Nicht in die obige
Form bringen. Der Rest wird durch Koeffizientenvergleich erledigt. Der
Term bei Qn invertiert ist dann die Beschaltung von K, der Term bei
Qn-Nicht die Beschaltung von J.
Gruß Willi
Willi Marquart
>
>>kann ein FF auch seinen eigenen Ausgang mit als Bestandteil
>>seiner charakteristischen Eingangsgleichung für J oder K haben??
> _ _
>Qn+1 = KQn + JQn
>
>Dabei ist Qn der Zustand vor und Qn+1 der nach dem Clock-Impuls.
Vielleicht sollte ich das mal an einem Beispiel erläutern, aber bitte
keine Proportionalschrift einstellen!
Ein dreistufiger Synchronzähler soll
0 1 2 3 7 6 5 4
zählen.
n | n+1
|
Q2 Q1 Q0|Q2 Q1 Q0
--------+--------
0 0 0 |0 0 1
0 0 1 |0 1 0
0 1 0 |0 1 1
0 1 1 |1 1 1
1 0 0 |0 0 0
1 0 1 |1 0 0
1 1 0 |1 0 1
1 1 1 |1 1 0
KV für Q0n+1
Q0 | /Q0
+-+-+-+-+
Q1|1| |1|1|
--+-+-+-+-+
/Q1| | | |1|
+-+-+-+-+
/Q2| Q2|/Q2
Das Einzelschicksal oben links wird nicht über den Rand mit der
1 oben rechts zu einem Zweierpaar zusammengefasst, da wir Q0 nicht
eliminieren wollen. Bleiben 2 Zweierpaare links.
__ __ __
Q0n+1 = Q1Q2Q0 + Q1Q0 + Q2Q0
__ __
Q0n+1 = Q1Q2Q0 + (Q1+ Q2)Q0
_ __
Q0n+1 = KQ0 + JQ0
Der Koeffizientenvergleich ergibt
_ __
K = Q1Q2
J = (Q1+Q2)
Das gleiche für Q1 und Q2 und fertig ist der Zähler.
Gruß Willi
Dirk Bossenz
> _ __
> K = Q1Q2
>
> J = (Q1+Q2)
>
> Das gleiche für Q1 und Q2 und fertig ist der Zähler.
>
ok kapiert...soweit bis auf:
_ __ __ __
K = Q1Q2 ist dann K = Q1Q2 oder K = Q1+Q2 ?
thx
Dirk
(kann mich nicht mehr richtig konzentrieren)
Willi Marquart
>ok kapiert...soweit bis auf:
>_ __ __ __
>K = Q1Q2 ist dann K = Q1Q2 oder K = Q1+Q2 ?
Nachdem beide Seiten invertiert wurden, wendest Du deMorgan auf die
linke Seite an:
__
K = Q1 + Q2
Gruß Willi
Willi Marquart
>Nachdem beide Seiten invertiert wurden, wendest Du deMorgan auf die
>linke Seite an:
> __
> K = Q1 + Q2
Ich meinte natürlich die rechte Seite.
Dirk Bossenz
> Ein dreistufiger Synchronzähler soll
> 0 1 2 3 7 6 5 4
> zählen.
>
> n | n+1
> |
> Q2 Q1 Q0|Q2 Q1 Q0
> --------+--------
> 0 0 0 |0 0 1
> 0 0 1 |0 1 0
> 0 1 0 |0 1 1
> 0 1 1 |1 1 1
> 1 0 0 |0 0 0
> 1 0 1 |1 0 0
> 1 1 0 |1 0 1
> 1 1 1 |1 1 0
>
ok ist hier nen Fehler drin?
wenn er 0 1 2 3 7 6 5 4 zählen soll.
Wertetabelle sollte doch so aussehen:
__n___ _n+1_
0 0 0 0 0 1
0 0 1 0 1 0
0 1 0 0 1 1
0 1 1 1 1 1
1 1 1 1 1 0
1 1 0 1 0 1
1 0 1 1 0 0
1 0 0 0 0 0
Oder nutze ich für die Koeffizentenvgl.methode
eine andere? (nach welcher Regel?)
Dirk
Willi Marquart
Die Reihenfolge der Zeilen in einer Wahrheitstabelle ist doch völlig
egal. Bei mir stehen die Eingangsvariablen immer so, wie man Dual
zählt. Beide Tabellen führen zum gleichen KV-Diagramm.
Gruß Willi
Dirk Bossenz
> Die Reihenfolge der Zeilen in einer Wahrheitstabelle ist doch völlig
> egal. Bei mir stehen die Eingangsvariablen immer so, wie man Dual
> zählt. Beide Tabellen führen zum gleichen KV-Diagramm.
ja stimmt auch wieder...ich bin fertig,
hätte nicht gedacht das dies so anstrengend wird.
Danke noch mal
Dirk
Falk Brunner
>
> > Falk, der auch noch KV-Diagramme durchexerziert hat.
>
> kann ein FF auch seinen eigenen Ausgang mit als Bestandteil
> seiner charakteristischen Eingangsgleichung für J oder K haben??
Ja. Denn alle Registerausgänge sind Speichervariablen. Aus dem IST-Zustand
wird durch Dekodiereung der Folgezustand berechnet. Grundprionzip eines
jeden Zustandsautomaten (FSM Finite State machine)
Jede Logikschaltung, egal ob Zähler, Schieberegister oder CPU basiert auf
diesem Prinzip.
> Also ich würde bei solchen Sachen auch meine Mitstudenten
> oder besser noch den Dozenten fragen - meine Mitstudenten
> hatte ich schon gefragt, wissen es aber auch nicht richtig
> und der Dozent erklärt und verliert sich in seinen ver-
> schachtelten Nebensätzen.
Fachwissen und Pädagogik sind zwei völlig unabhängige Dinge.
MfG
Falk
Falk Brunner
news:34ra84F...@individual.net...
> Das ist das Todschlagargument überhaupt. Ich bin zwar noch nicht so alt
> aber mir wurde zugetragen das es bei der Einführung des Taschenrechners
> wahnsinnige Diskusionen gab das eine Verdummung der Schüler droht.
> Natürlich kann heute kaum mehr ein Schüler das große Ein mal Eins aber
> ist es wirklich nötig?
Nochmal AUTSCH!
Ja, ich behaupte, das kleine einmaleins sollte jeder Schulabgänger
wenigstens leidlich beherrschen.
Alles andere ist Dünnbrettbohrerei und Volksverdummung.
Denn wozu brauche ich das kleine Einmaleins?? Um Dinge überschlägig
abschätzen und einordnen zu können.
Wie oft werden in Zeitungen/Nachrichten irgendwelche, meitst recht grossen
Zahlen genannt??
Oft. Und ich behaupte, es können sich immer weniger Leute eine reale
Vorstellung von diesen Zahlen machen. Da wird mit Milliaren in
Staatshaushalten hantiert etc. aber ich fürchte, nur die wenigstens sind
sich der Grössenordungen bewusst. Weil mathematische Grundkennnisse der
Grundstein dafür sind.
Aber Mathematik ist ja schwer, uncool und überhaupt nur was für wenige
Spezialisten. Otto-Normalbürger kauft eh nur bei Mediamarkt, un dort sind
die Preise klein, passend zum Konsumentenhirn.
> Ich konnte ab der 10. Klasse einen programmierbaren Taschenrechner in
> der Schule einsetzen der ein komplettes CAS enthält. Ich kann jetzt
> nicht so schnell eine Taylorreihe aufschreiben wie es jemand könnte
> der es 300 mal in der Schule machen musste. Ich muss bei ungewöhnlichen
> Integralen evt. auch mal in die Formelsammlung schauen was ein "normaler"
> Abiturient auswendig weis.
Man verwechsele nach Möglichkeit nicht Mathematik mit simplem Rechnen!!!
Mathematik heisst, logische zusammenhänge zu erkennen, Lösungsstrategien für
analytische Probleme zu erlernen.
Taschenrechner sind nur RECHENKNECHTE. Auch wenn die heute tiereisch
aufgebohrt sind, differenzieren und immer besser integrieren können, DENKEN
und analysiren können sie NICHT!!!
Nicht umsonst wird immer wieder betont (aber genausooft nicht verstanden)
warum GRUNDLAGENforschung wichtig ist. Und genauso ist es Grundlagen wissen,
auch im PC- und Internetzeitalter!!! Niemand verlangt mehr, dass Leute mit
dem Rechenschieber umgehen können, Logarithmentafeln und ähnliches hat auch
längst ausgedient. Aber das Grundlegende Prizip bleibt. DENKEN muss der
Mensch. Das unterscheidet ihn vom Tier (meistens . . ).
> Aber ich habe freude an der Mathematik weil mir ein großer Teil der
> Knechtsarbeit erspart bleibt und ich behaupte einen viel besseren
Überblick
Richtig, siehe oben.
> Es ist ja auch so das du nicht das Geschirrspülen verlernst nur
> weil du eine Geschirrspülmaschine hast, du aber eher ein aufwändiges
> Gericht kochst weil du weist das du nacher den Abwasch nicht per
> Hand machen musst.
Nicht alles was hinkt ist ein Vergleich ;-))
> Und wir lernen jetzt im 3. Semester die Zweitortheorie auch nur noch
> in 3 Doppelstunden weil es durch die Schaltungssimulation an Bedeutung
> verlohren hat.
Was das?
MfG
Falk
Falk Brunner
"Georg Acher" <ac...@in.tum.de> schrieb im Newsbeitrag
news:cs9q4d$fs8$1...@wsc10.lrz-muenchen.de...
> Und wenn ich das Problem des OP richtig verstanden habe, ging es da noch
um
> JK-Flipflops, das ist ja eigentlich noch grösserer Blödsinn als die
> KV-Spielereien. Die JKs gibts doch so gut wie nicht mehr, in CPLDs/FPGAs
erst
Naja, hab ich ja auch schon gesagt. ABER!!! Da der OP sich ja wohl gerade im
Studium befindet, ist es sicher nicht verkehrt, das Köpfchen mal mit ein
paar Denkaufgaben zu belasten. Dafür sind auch (vielleicht nicht mehr so
praxisrelevante) JK-FF brauchbar. Schliesslich sind auch nicht alles
Übungsaufgaben in Mathematik direkt praxisrelevant (aber das Prinzip sehr
wohl!!)
> recht nicht. Irgendwann muss man sich einfach mal von der 74er-Reihe
lösen. Wenn
> man sich seine Schaltungen nur in 74er-Logik vorstellen kann, geht einem
viel
> ab...
ACK.
MfG
Falk
Falk Brunner
news:34v4pdF...@individual.net...
> Heute natuerlich J und K ersetzt durch D, erfordert mehr Logik
> aber weniger PinCount.
Sicher?? Beweise?
Ich sag mal, ein FF hat nur ein Bit Speicherkapazität. Wozu sollte ich dann
2 Eingänge verwenden, ich kanns doch nur auf 1 oder 0 setzen.
Jaja, es gibt Ausnahmefälle, aber die Praxis zeigt, dass D-FF sinnvoller
sind.
MfG
Falk
Falk Brunner
news:unmku05v5qodflrr8...@4ax.com...
> Die KV-Diagramme decken in handhabbarer Form wirklich
> nur die allersimpelsten Fälle ab, nämlich jene, die ein halbwegs
> intelligenter Mensch auch so in seinem Kopf oder auf einem
> Blatt Papier durchspielen kann.
ACK. Aber was kommt denn raus, wenn selbst diese einfachen Dinge nicht
verstanden oder gar bekannt sind?? Mouseclick-Ingenieure!!
> Alles andere - nämlich das, was als Logiktabelle übliche
> Speicherdimensionen sprengt - ist nicht trivial und - so es
> in einen *guten* Logikcompiler implementiert werden soll -
> echte Kunst. Eben so wie Integrieren, man oder
> Compiler "sieht" die schöne Lösung oder eben nicht.
Womit wir wieder beim bein Spezialisten mit Hintergrundwissen wären.
Q.E.D.
MfG
Falk
Falk Brunner
> gibt es ein Programm was einfach nur boolsche Ausdrücke
> vereinfacht? (als Extra vielleicht, jeden Minimierungs-
> schritt anzeigt?)
Keine Ahnung. Aber. Sei ein MAnn, sei hart und versuch KV auf dem
klassischen Weg zu verstehen. Versuche mit Freunden das Problem
gemeinschaftlich zu lösen. ISt gleichzeitig ne teambildende Übung.
> PS: ich bin jetzt im 11Sem. ET an zwei unterschiedlichen FH's
> gewesen, an beiden wurde VHDL-Entwurf als was spezielles Seltenes
> abgetan - sprich nicht Bestandteil der regulären Vorlesungen -
Naja, wir haben rumgeABELt. Genauso wie wir noch Pascal programmiert haben.
Sicher wäre es sinnvoll hier bissel uptodate zu werden, aber die Grundlagen
kann man auch damit vermitteln. Die Welt ist selten perfekt.
MfG
Falk
MaWin
>
> Ich sag mal, ein FF hat nur ein Bit Speicherkapazität. Wozu sollte ich dann
> 2 Eingänge verwenden, ich kanns doch nur auf 1 oder 0 setzen.
>
Na, es spart(e) externe Gatter, weil sozusagen ein paar Gatter intern drin
sind. Man kann aus D leicht JK machen,
D --+------ J
|
+-|>|o- K
aber umgekehrt ist es aufwaendiger (left as an exercise to the reader).
Martin Laabs
> "Martin Laabs" <98ma...@gmx.de> schrieb im Newsbeitrag
> news:34ra84F...@individual.net...
> wenigstens leidlich beherrschen.
Ganz deiner Meinung. Ich schrieb über das große.
> Man verwechsele nach Möglichkeit nicht Mathematik mit simplem Rechnen!!!
> Mathematik heisst, logische zusammenhänge zu erkennen, Lösungsstrategien für
> analytische Probleme zu erlernen.
Das eine kannst du vom anderen nicht fern halten.
> Taschenrechner sind nur RECHENKNECHTE. Auch wenn die heute tiereisch
> aufgebohrt sind, differenzieren und immer besser integrieren können, DENKEN
> und analysiren können sie NICHT!!!
Du brauchst aber das eine um das andere zu machen. Natürlich musst du dir
erst Gedanken machen wie nun die Differntialgleichung ist. Aber ich finde
man muss sie nicht mehr Rechnen wenn es der Computer kann.
> warum GRUNDLAGENforschung wichtig ist. Und genauso ist es Grundlagen wissen,
> auch im PC- und Internetzeitalter!!!
Man. Wer kennt denn schon alle Grundlagen mit denen er arbeitet? Man muss
doch mal irgendwo einen Strich machen können und sagen: Das akzeptiere
ich jetzt so wie es ist. Das ist ein Werkzeug und muss nicht hinterfragt
werden.
Oder machst du dir jedes mal Gedanken wie es nun mit dem NNTP Protokoll
funktioniert wenn du deine Postings versendest? Überlegst du welche
Modulation nun auf den Übertragungsstecken eingesetzt wird?
> längst ausgedient. Aber das Grundlegende Prizip bleibt. DENKEN muss der
> Mensch. Das unterscheidet ihn vom Tier (meistens . . ).
Dagegen ist nichts einzuwenden. Aber warum willst du Technik verteufeln
die dir beim Denken hilft?
Tschüss
Martin L.
Thomas Reinemann
> "Thomas Reinemann" <thomas.r...@mb.uni-magdeburg.de> schrieb im
> Newsbeitrag news:cs81gu$m28$1...@fuerst.cs.uni-magdeburg.de...
>
>> anhand der ziemlich sinnlosen Aufgabenstellung gehe ich davon aus, dass
> dies
>> Teil einer Ausbildung ist. Um es mal drastisch auszudrücken, kein Mensch
>> braucht heute noch Minimierungsverfahren. Die paar die wirklich noch mit
>
> AUA. Und das bei DER Signatur??
>
>> --
>> Dr.-Ing. Thomas Reinemann www.uni-magdeburg.de/reineman
>> IMAT Public key available
>> Otto-von-Guericke-Universität Magdeburg
>> Universitätsplatz 2
>> 39106 Magdeburg, Germany
Nein, genau wegen der Signatur.-). Unsere Probleme hier, spezifizieren wir
in VHDL und implementieren in FPGAs, üblicherweise sage ich meinen
Studenten sie sollen nicht minimieren. Bei einem habe ich das mal
vergessen, der kam prompt mit einer minimierten Lösung. Bei einem etwas
aufwendigeren Problem ist die Wahrscheinlichkeit von Fehlern nicht gerade
gering, genau das ist ihm auch passiert.
Es ergibt sich noch ein anderes Problem. Üblicherweise überlebt nur der
Quellcode. Die Minimierung steht auf irgendeinem Blatt, das u.U. mal
abgeheftet wurde. Damit kann eine minimal implementierte Lösung nur schwer
ohne die zusätzlichen Infos nachvollzogen werden. Werden dagegen die Zeilen
aus der Tablle sturr in eine HDL übertragen, kann mann später einfach die
Tabelle wieder rekonstruieren.
>
> Wieso noch Kopfrechen wenn jeder (Depp) nen P4 zuhause hat.
> Ich meine, für angehene Techniker (und erst recht Ingeniere!!!) ist das
> Grundverständniss solcher Dinge unverzichtbar.
Richtig, Es stellt sich nur die Frage, auf welche Basis bezieht sich das
Grundverständnis? Eine 74er Reihe, FPGA, CPLD, ASIC? Dementsprechend ist
auszublden. Je mehr man manuell macht, umso mehr Fehler gibt es. Diese
sucht man dann aufwendig wieder raus.
> Falk, der auch noch KV-Diagramme durchexerziert hat.
Ich auch, trotzdem halte ich es für überflüssig.
Wie exerzieren, bei der Fahne haben wir stundenlang in der Grundausbildung
exerzieren geübt, nur um uns einmal bei der Vereidigung nicht in die Hacken
zu latschen.
Tom, der genau die Diskussion anstoßen wollte.
--
Dr.-Ing. Thomas Reinemann www.uni-magdeburg.de/reineman
IMAT Public key available
Otto-von-Guericke-Universität Magdeburg
Universitätsplatz 2
39106 Magdeburg, Germany
Falk Brunner
> > Man verwechsele nach Möglichkeit nicht Mathematik mit simplem Rechnen!!!
> > Mathematik heisst, logische zusammenhänge zu erkennen, Lösungsstrategien
für
> > analytische Probleme zu erlernen.
>
> Das eine kannst du vom anderen nicht fern halten.
Will ich auch nicht. Aber man braucht BEIDES und sollte sich nicht nur auf
die Zahlenhackerei mit der Elektronik beschränken.
> > warum GRUNDLAGENforschung wichtig ist. Und genauso ist es Grundlagen
wissen,
> > auch im PC- und Internetzeitalter!!!
>
> Man. Wer kennt denn schon alle Grundlagen mit denen er arbeitet? Man muss
> doch mal irgendwo einen Strich machen können und sagen: Das akzeptiere
> ich jetzt so wie es ist. Das ist ein Werkzeug und muss nicht hinterfragt
> werden.
Gelegentlich schon.
> Oder machst du dir jedes mal Gedanken wie es nun mit dem NNTP Protokoll
> funktioniert wenn du deine Postings versendest? Überlegst du welche
> Modulation nun auf den Übertragungsstecken eingesetzt wird?
Quark. Als Newsgroupteilnehmer bin ich User, nicht Ingenieur. Das ist was
vollkommen anderes.
> > längst ausgedient. Aber das Grundlegende Prizip bleibt. DENKEN muss der
> > Mensch. Das unterscheidet ihn vom Tier (meistens . . ).
> Dagegen ist nichts einzuwenden. Aber warum willst du Technik verteufeln
> die dir beim Denken hilft?
Ich verteufele nicht die Technik. Ich sage, dass man TROTZ Technik die
Grundlagen beherrschen muss und nicht dem Trugschluss verfallen sollte, in
der heutigen Zeit haben alle Grundlagen ausgedient.
MfG
Falk
Falk Brunner
> Nein, genau wegen der Signatur.-). Unsere Probleme hier, spezifizieren wir
> in VHDL und implementieren in FPGAs, üblicherweise sage ich meinen
> Studenten sie sollen nicht minimieren. Bei einem habe ich das mal
Minimieren und minimieren sind in VHDL zwei Paar Schuhe.
Man kann prinzipiell jeden (fast) Algorithmus in VHDL hinschreiben, wie der
dann in Hardware umgesetzt wird, ist ne andere Frage. Diese Art der
"Minimiereung" wird im allgemeinen synthesefähiges VHDL genannt.
Eine Boolsche Minimierung in VHDL macht niemand (der VHDL kapiert hat).
Denn dann schreibt man höchst selten in Gatterebene
xyz <= a and b or c and d;
sondern denkt auf Registerebene und schreibt Dinge wie
if zähler=55 then
ausgang <= '1';
end if;
Damit erreicht man auch schon ein gutes Stück Selbstdokumentation.
> vergessen, der kam prompt mit einer minimierten Lösung. Bei einem etwas
Dann hat er VHDL nicht verstanden. Oder derjenige, der ihm VHDL beigebracht
hat . . .*räusper* . .;-))
> aufwendigeren Problem ist die Wahrscheinlichkeit von Fehlern nicht gerade
> gering, genau das ist ihm auch passiert.
Siehe oben.
> Es ergibt sich noch ein anderes Problem. Üblicherweise überlebt nur der
> Quellcode. Die Minimierung steht auf irgendeinem Blatt, das u.U. mal
> abgeheftet wurde. Damit kann eine minimal implementierte Lösung nur schwer
> ohne die zusätzlichen Infos nachvollzogen werden. Werden dagegen die
Zeilen
> aus der Tablle sturr in eine HDL übertragen, kann mann später einfach die
> Tabelle wieder rekonstruieren.
OH Graus. Naja, VHDL im akademischen Bereich unterscheidet sich mal wieder
nicht wenig von VHDL in der (marktwirtschaflichen) Praxis.
So einen Quark würde ich nicht als Hardwareentwurf auf VHDL-Ebene bezeichen,
das ist VHDL als Netzliste missbraucht (und damit weit hinter den
Möglichkeiten ungenutzt liegen gelassen)
VHDL ist teilweise selbstkommentierend. Veriloger werden da jetzt ketzerisch
sagen, mit VHDL kann man Romane schreiben, naja, aber auch bei VHDL tippt
man sich nicht tot. Dazu noch sinnvolle Kommentare, und man braucht (fast)
keine externe Doku mehr (Bei kleinen bis mittelgrossen Sachen).
Das Tabellenrekonstruieren verrät einem auch nicht wichtige Details, ist nur
der rein logische Zusammenhang. Ecken und Kanten (oder Workarounds, bekannte
Beschränkungen) kann man daraus nicht ablesen.
> > Wieso noch Kopfrechen wenn jeder (Depp) nen P4 zuhause hat.
> > Ich meine, für angehene Techniker (und erst recht Ingeniere!!!) ist das
> > Grundverständniss solcher Dinge unverzichtbar.
> Richtig, Es stellt sich nur die Frage, auf welche Basis bezieht sich das
> Grundverständnis? Eine 74er Reihe, FPGA, CPLD, ASIC? Dementsprechend ist
> auszublden. Je mehr man manuell macht, umso mehr Fehler gibt es. Diese
> sucht man dann aufwendig wieder raus.
Hier werden wieder zwei Dinge in einen Topf geworfen.
1) Es geht um das unverzichtbare Grundverständnis. Ob man das mit nem reinen
FlipFlop auf dem Papier erklärt oder ein wenig in Richtung Praxis losgeht
und sie 74' Reihe verwendet, ist egal. Ich hätte auch nix dagagen wenn statt
der 74 Reihe (die fast nur noch historische Bedeutung hat) moderne
Technologien zumindest überblicksweise vermittelt würden. Aber die Welt geht
auch nicht unter, wenn Student von heute mit den Bausteinen von gestern die
Grundlagen übt. Und da hängt es ja schon bei dem OP. Und wenn er das
nichtmal gebacken bekommt, wie soll er da FPGA und ASICs verstehen??
2) Logische Optimierung in der Praxis. Klar sollte man sich dort auf die
Fälle beschränken, wo die automatische Generierung per Synthese zu langsam
oder zu gross ist. Ist genauso wie der Vergleich Assembler/C. Mit Assembler
plagt man sich nur rum, wenn das Ergebnis des C-Compilers zu gross/langsam
ist. Und das trifft meist nur auf kleine Kernroutinen, meist im
Embedded-Bereich zu. Wie eben die alte Programmierererkentnis. 90% der
Rechenzeit werden in 10% des Codes verbraucht. Diese 10% müssen optimiert
werden, der Rest "nur" solide hingeschrieben.
> > Falk, der auch noch KV-Diagramme durchexerziert hat.
> Ich auch, trotzdem halte ich es für überflüssig.
Ich nicht. Was willst du anstatt bezüglich Logikoptimierung vermittlen? Dass
es irgendeine schöne Software irgendwie schon machen wird? Ich hoffe nicht.
> Wie exerzieren, bei der Fahne haben wir stundenlang in der Grundausbildung
> exerzieren geübt, nur um uns einmal bei der Vereidigung nicht in die
Hacken
> zu latschen.
Nicht alles was hinkt, ist ein Vergleich.
MfG
Falk
Dirk Bossenz
hat den noch jemand praktische Tips oder Faustregeln
für das Minimieren mit Hilfe der Schaltalgebra?
Ich sitze jetzt (den ganzen Tag schon) vor solchen
Ausdrücken (es sind dann noch 2 mehr):
K=(Q3 Q2 -Q1 Q0)+(-Q3 -Q2 -Q1 Q0)+(-Q3 Q2 -Q1 -Q0)
und
J=(-Q3 Q2 Q1)+(Q2 Q1 Q0)+(-Q3 Q1 Q0)+(Q3 -Q2 Q1 -Q0)
zusammen mit 2 Büchern wo die Schaltalgebra auch mit
Beispielen erklärt ist, gehe ich dies durch, vergleiche
die Endergebnisse mit der Logiktabelle, stelle fest es
harkt an einer Stelle und fange von vorne an...
Dirk
Falk Brunner
> Hallo,
>
> hat den noch jemand praktische Tips oder Faustregeln
> für das Minimieren mit Hilfe der Schaltalgebra?
>
> Ich sitze jetzt (den ganzen Tag schon) vor solchen
> Ausdrücken (es sind dann noch 2 mehr):
>
> K=(Q3 Q2 -Q1 Q0)+(-Q3 -Q2 -Q1 Q0)+(-Q3 Q2 -Q1 -Q0)
>
> und
>
> J=(-Q3 Q2 Q1)+(Q2 Q1 Q0)+(-Q3 Q1 Q0)+(Q3 -Q2 Q1 -Q0)
Rot ist Blau und Plus ist Minus. Oder so ähnlich ;-))
Im Ernst. Bei der boolschen Schaltalgebra gibt eigentlich nur 3,4
Grundregeln.
- AND geht vor OR, äquivalent zu Punktrechnung geht vor Strichrechnung.
- Theorem von De Morgan.
A and B = (not A) or (not A) bzw.
A or B = (not A) and (not B)
- X and 0 = 0, X and 1 = X
- X or 0 = X, X and 1 = 1
- Klammern werden ebenso gehandhabt wie bei "richtigen" Gleichungen.
Damit kann man Boolsche Gleichungen genauso (einfach) zusammenfassen wie
"normale" Gleichungen.
Viel Erfolg.
MfG
Falk
Jan Kandziora
> Hallo,
>
> hat den noch jemand praktische Tips oder Faustregeln
> für das Minimieren mit Hilfe der Schaltalgebra?
>
Die Praktiker-Faustregel ist: Es geht primär nicht darum, Gatter zu
reduzieren, es geht darum, Bauteile zu sparen.
Wenn man tausende von Gattern braucht, nimmt man ein Gate-Array und kann
dann das Tool des Herstellers drüberlaufen lassen, um die Schaltung
möglichst gut auf dieses spezielle Gate-Array abzubilden.
Wenn man nur ein Dutzend Gatter braucht, ist meist die Beschaffbarkeit und
der Preis der Bausteine entscheidend.
Wenn das also keine Prüfungsaufgabe ist: Lass es.
--
Jan
Thomas Reinemann
> Eine Boolsche Minimierung in VHDL macht niemand (der VHDL kapiert hat).
> Denn dann schreibt man höchst selten in Gatterebene
>
> xyz <= a and b or c and d;
>
> sondern denkt auf Registerebene und schreibt Dinge wie
>
> if zähler=55 then
> ausgang <= '1';
> end if;
Völlig am Thema vorbei, was hat dein RTL-Beispiel mit Minimierung zu tun.
> Dann hat er VHDL nicht verstanden. Oder derjenige, der ihm VHDL
> beigebracht hat . . .*räusper* . .;-))
Genau darum geht es. Ihm hat man Logikminimierung beigebracht und leider
nicht VHDL.
> 1) Es geht um das unverzichtbare Grundverständnis. Ob man das mit nem
> reinen FlipFlop
Richtig, dazu gehöhrt "und", "oder" und das Speichern von Signalen in FF.
Ich habe nie geschrieben das dies sinnlos ist, sondern das man
Logikminimierung kaum noch braucht und es dementsprechend nicht mehr oder
deutlich weniger als vor zehn Jahren zu lehren ist. Auf diesem Stand
befinden sich aber noch die meisten Dozenten.
> Was willst du anstatt bezüglich Logikoptimierung vermittlen?
Den Studenten soll nicht stundenlang Logikminimierung beigebracht werden,
sondern die Spezifikation von Problemen in einer HDL. Das Grundverständnis
ist heute ein anderes.
Als erstes kommen heutige Studenten von der Software und kennen sich mit
Hardware nicht aus, dementsprechend ist Hardware einzuführen. Sehr
komprimiert könnte es so aussehen, auf VHDL bezogen:
-Schleifen werden mit dem process-Statement ausgedrückt.
-Ein Bit wird in einem Signal gespeichert, Zuweisungen geschehen an
Taktflanken.
-Ergebnisse von logischen Funktionen werden innerhalb eines Prozesses einem
Signal zugewiesen.
Dann kommen Sachen wie Vektoren, Variable usw. dran.
Genau genommen käme man sogar ohne D-FF aus, soweit würde ich aber nicht
gehen.
Bye Tom
Falk Brunner
> Falk Brunner wrote:
>
> > Eine Boolsche Minimierung in VHDL macht niemand (der VHDL kapiert hat).
> > Denn dann schreibt man höchst selten in Gatterebene
> >
> > xyz <= a and b or c and d;
> >
> > sondern denkt auf Registerebene und schreibt Dinge wie
> >
> > if zähler=55 then
> > ausgang <= '1';
> > end if;
>
> Völlig am Thema vorbei, was hat dein RTL-Beispiel mit Minimierung zu tun.
Nun, das war die Antwort auf deinen Einwurf.
> > Nein, genau wegen der Signatur.-). Unsere Probleme hier, spezifizieren
wir
> > in VHDL und implementieren in FPGAs, üblicherweise sage ich meinen
> > Studenten sie sollen nicht minimieren. Bei einem habe ich das mal
> > Dann hat er VHDL nicht verstanden. Oder derjenige, der ihm VHDL
> > beigebracht hat . . .*räusper* . .;-))
> Genau darum geht es. Ihm hat man Logikminimierung beigebracht und leider
> nicht VHDL.
Sag ich doch.
> > 1) Es geht um das unverzichtbare Grundverständnis. Ob man das mit nem
> > reinen FlipFlop
> Richtig, dazu gehöhrt "und", "oder" und das Speichern von Signalen in FF.
> Ich habe nie geschrieben das dies sinnlos ist, sondern das man
> Logikminimierung kaum noch braucht und es dementsprechend nicht mehr oder
> deutlich weniger als vor zehn Jahren zu lehren ist. Auf diesem Stand
> befinden sich aber noch die meisten Dozenten.
Schon möglich. Aber auch ich sagte nix von ewig und drei Tage KV-Diagramme
pauken. Aber wissen wie es geht sollte man schon.
> > Was willst du anstatt bezüglich Logikoptimierung vermittlen?
> Den Studenten soll nicht stundenlang Logikminimierung beigebracht werden,
> sondern die Spezifikation von Problemen in einer HDL. Das Grundverständnis
> ist heute ein anderes.
> Als erstes kommen heutige Studenten von der Software und kennen sich mit
Wenn überhaupt.
> Hardware nicht aus, dementsprechend ist Hardware einzuführen. Sehr
Hardware wird aber auch immer weniger, Software immer mehr. Klar, ganz ohne
Hardware läuft auch Software nicht, aber die Gewichte sind nun mal eindeutig
in Richtung Software verschoben. Und heutige Hardware ist ja auch schon fast
Software (HDL).
> komprimiert könnte es so aussehen, auf VHDL bezogen:
> -Schleifen werden mit dem process-Statement ausgedrückt.
> -Ein Bit wird in einem Signal gespeichert, Zuweisungen geschehen an
> Taktflanken.
> -Ergebnisse von logischen Funktionen werden innerhalb eines Prozesses
einem
> Signal zugewiesen.
Schon klar, aber dazu sollte man doch wenigstens die digitalen Grundlagen
kennen (State Machines, Decoder etc)
MfG
Falk
Dirk Bossenz
> Wer kennt's und kann helfen? Das ganze wird dann natürlich
> auf dem Digitaltrainer-Board aufgebaut, dementsprechend wenige
> Logikgatter sind vorhanden (8 AND/NAND mit 2 Input; 4 AND/NAND
> mit 4 Input; 4 OR/NOR mit 2 Input; 4 AND/NAND mit 4 Input;
> 8XOR mit 2 Input und 4 Inverter).
> Das heißt mit dem numerischen Verfahren kommt man nicht hin;
> zumindest habe ich es nicht geschafft mit ABEL (womit ich bisher
> immer sowas mache) mir Logik mit den nur vorhandenen Gattern
> zusammenzusetzen.
Gut ich glaube nun die Lösung gefunden zu haben.
Zumindest theoretisch mit der Logiktabelle durch
gespielt, geht es.
Wenn man das Problem stur mit den KV-Tabellen abarbeitet
und die so erhalten Terme nimmt - durch ausklammern und
ein wenig sich aufhebende Quotienten rausnimmt komme ich
schon weit - es reicht aber noch nicht.
Wenn wir nun aber noch den Fakt hinzunehmen das bei J=K=1
sich am Ausgang der Negierte Vorherzustand einstellt, kann
noch weiter minimiert werden.
Die Frage für mich ist, wie "sauber" ist diese Lösung?
Ich nehme an, das, wenn die Taktpulse entsprechend kurz
sind es zu "Fehlschaltungen" kommen kann, wenn bsp. am
J noch nicht 1 ist aber an K bereits anliegt...
Da ich den Takt "Handmade" in die Schaltung gebe, dürfte
es in diesem Fall aber keine Probleme geben.
Dirk
PS: Wer an der kompletten Lösung (Logiktabelle und minimierte
Gleichungen) interessiert ist, kann sich melden.
Falk Brunner
> Wenn man das Problem stur mit den KV-Tabellen abarbeitet
> und die so erhalten Terme nimmt - durch ausklammern und
> ein wenig sich aufhebende Quotienten rausnimmt komme ich
Quotienten??
> schon weit - es reicht aber noch nicht.
Tja, wahrscheinlich was vergessen.
> Wenn wir nun aber noch den Fakt hinzunehmen das bei J=K=1
> sich am Ausgang der Negierte Vorherzustand einstellt, kann
> noch weiter minimiert werden.
Schön.
> Die Frage für mich ist, wie "sauber" ist diese Lösung?
> Ich nehme an, das, wenn die Taktpulse entsprechend kurz
> sind es zu "Fehlschaltungen" kommen kann, wenn bsp. am
> J noch nicht 1 ist aber an K bereits anliegt...
;-))) Dann wird das FlipFlop bzw. die Gatter geschindigkeitsmässig
überfahren. Mit geringerer Taktfrequenz sollte es dann gehen. Wobei so eine
einfache Schaltung auch als TTL Grab sicher locker 10 MHz schaffen sollte.
> Da ich den Takt "Handmade" in die Schaltung gebe, dürfte
> es in diesem Fall aber keine Probleme geben.
Das ist ein verbreiteter (Anfänger) Irrtum. Das gilt nur, wenn man die Takte
per Hand vorgibt UND sicherstellt, dass sie SAUBER (nicht nur rein ;-) an
den FFs ankommen, dann gehts. Will sagen, der Taster zum Handtakten muss
entprellt sein. Also Schmitt-trigger mit RC Glied vorn dran. Ein einfacher
Taster tuts nicht!!!
MfG
Falk
Winfried Salomon
>>Was willst du anstatt bezüglich Logikoptimierung vermittlen?
>>
>>
>Den Studenten soll nicht stundenlang Logikminimierung beigebracht werden,
>sondern die Spezifikation von Problemen in einer HDL. Das Grundverständnis
>ist heute ein anderes.
>Als erstes kommen heutige Studenten von der Software und kennen sich mit
>Hardware nicht aus, dementsprechend ist Hardware einzuführen. Sehr
>komprimiert könnte es so aussehen, auf VHDL bezogen:
>-Schleifen werden mit dem process-Statement ausgedrückt.
>-Ein Bit wird in einem Signal gespeichert, Zuweisungen geschehen an
>Taktflanken.
>-Ergebnisse von logischen Funktionen werden innerhalb eines Prozesses einem
>Signal zugewiesen.
>
>Dann kommen Sachen wie Vektoren, Variable usw. dran.
>Genau genommen käme man sogar ohne D-FF aus, soweit würde ich aber nicht
>gehen.
>
>Bye Tom
>
>
ich bin etwas skeptisch, was den unkritischen Einsatz von solchen
Automatisierungstools wie VHDL betrifft, auch wenn das viele Vorteile
hat, jedoch nicht immer. Grade bin ich über 1 Problem gestolpert, das
mit VHDL nicht implementierbar scheint, mit der klassischen Methode über
KV-Minimierung aber durchaus zu 2 mir bekannten Lösungen führt, wenn
auch etwas mühsam und mit etwas Nachdenken verbunden.
Es handelt sich um einen symmetrischen Frequenzteiler /3, realisierbar
z.B. mit 3 D-FFs, Schaltungslösungen sind bekannt. Wenn Du das mit VHDL
in Hardware in 1 process implementieren kannst, sag mal Bescheid, ich
schaffe es nicht, obwohl die Formulierung ganz simpel ist. Viel Spaß :-)
Winfried
Georg Acher
>ich bin etwas skeptisch, was den unkritischen Einsatz von solchen
>Automatisierungstools wie VHDL betrifft, auch wenn das viele Vorteile
>hat, jedoch nicht immer. Grade bin ich über 1 Problem gestolpert, das
>mit VHDL nicht implementierbar scheint, mit der klassischen Methode über
>KV-Minimierung aber durchaus zu 2 mir bekannten Lösungen führt, wenn
>auch etwas mühsam und mit etwas Nachdenken verbunden.
Nachdem man in VHDL durchaus auch was strukturell beschreiben kann, muss alles
gehen, was sich als Schaltplan darstellen lässt.
>Es handelt sich um einen symmetrischen Frequenzteiler /3, realisierbar
>z.B. mit 3 D-FFs, Schaltungslösungen sind bekannt. Wenn Du das mit VHDL
>in Hardware in 1 process implementieren kannst, sag mal Bescheid, ich
>schaffe es nicht, obwohl die Formulierung ganz simpel ist. Viel Spaß :-)
Warum die Einschränkung auf einen Prozess?
--
Georg Acher, ac...@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Winfried Salomon
Hallo Georg,
Georg Acher wrote:
>Winfried Salomon <sal...@uni-wuppertal.de> writes:
>
>
>
>>ich bin etwas skeptisch, was den unkritischen Einsatz von solchen
>>Automatisierungstools wie VHDL betrifft, auch wenn das viele Vorteile
>>hat, jedoch nicht immer. Grade bin ich über 1 Problem gestolpert, das
>>mit VHDL nicht implementierbar scheint, mit der klassischen Methode über
>>KV-Minimierung aber durchaus zu 2 mir bekannten Lösungen führt, wenn
>>auch etwas mühsam und mit etwas Nachdenken verbunden.
>>
>>
>
>Nachdem man in VHDL durchaus auch was strukturell beschreiben kann, muss alles
>gehen, was sich als Schaltplan darstellen lässt.
>
>
>
Umgekehrt geht man ja vor, die Schaltung kennt man doch nicht. Natürlich
kannst Du jede Schaltung in VHDL umsetzen. Aber wenn Du z.B. einen
großen 16 Bit Counter hast, dann kannst Du die Schaltung nur noch mit
VHDL erzeugen, weil sie für Menschen zu groß wird. Und das geht eben
nicht immer.
>>Es handelt sich um einen symmetrischen Frequenzteiler /3, realisierbar
>>z.B. mit 3 D-FFs, Schaltungslösungen sind bekannt. Wenn Du das mit VHDL
>>in Hardware in 1 process implementieren kannst, sag mal Bescheid, ich
>>schaffe es nicht, obwohl die Formulierung ganz simpel ist. Viel Spaß :-)
>>
>>
>
>Warum die Einschränkung auf einen Prozess?
>
>
>
Weil es am einfachsten ist, obiges Problem ist so leicht zu
programmieren und zu simulieren. Natürlich kannst Du auch mehrere
Prozesse benutzen, aber wozu? Es wird dann jedenfalls komplizierter. Im
Moment bin ich dabei, 1 Lösung mit 2 Prozessen zu finden, aber das wird
dann nur ein Workaround sein und stellt mich nicht zufrieden.
Dieses Problem habe ich in comp.lang.vhdl diskutiert, will es aber nicht
unbedingt noch mehr ausbreiten. Das Ergebnis ist schon klar, mein
Implementationstool ist Schrott, weil Xilinx meint, solche Probleme gibt
es nicht. Das merkt man natürlich erst, wenn man auf so einen Fall
stößt, das ging bei mir aber sehr schnell.
Wenn Du Interesse hast, kann ich das VHDL-File posten, es sind nur
wenige Zeilen und ganz einfach aufgebaut, die Behavioral-Simulation
müßte auf jeden Fall funktionieren.
Winfried
Falk Brunner
"Winfried Salomon" <sal...@uni-wuppertal.de> schrieb im Newsbeitrag
news:35cgahF...@news.dfncis.de...
> >Warum die Einschränkung auf einen Prozess?
> >
> >
> >
> Weil es am einfachsten ist, obiges Problem ist so leicht zu
> programmieren und zu simulieren. Natürlich kannst Du auch mehrere
Oh mein Gott. !!!!
Wenn es jetzt schon zuviel verlangt ist, mal 3 Zeilen mehr hinzuschreiben,
und dadurch eine saubere Lösung eines einfachen Problems in sagen wir mal 5
Minuten zu erreichen, dann weiss ich auch nicht mehr weiter.
Aber dann lieber ewig und drei Tage philosophieren und diskutieren.
Ich versteh die Welt jeden Tag weniger . . . .
> Prozesse benutzen, aber wozu? Es wird dann jedenfalls komplizierter. Im
> Moment bin ich dabei, 1 Lösung mit 2 Prozessen zu finden, aber das wird
> dann nur ein Workaround sein und stellt mich nicht zufrieden.
>
> Dieses Problem habe ich in comp.lang.vhdl diskutiert, will es aber nicht
> unbedingt noch mehr ausbreiten. Das Ergebnis ist schon klar, mein
> Implementationstool ist Schrott, weil Xilinx meint, solche Probleme gibt
> es nicht. Das merkt man natürlich erst, wenn man auf so einen Fall
> stößt, das ging bei mir aber sehr schnell.
Kopfschüttelnd
Falk
> Wenn Du Interesse hast, kann ich das VHDL-File posten, es sind nur
> wenige Zeilen und ganz einfach aufgebaut, die Behavioral-Simulation
> müßte auf jeden Fall funktionieren.
????
100% Widerspruch zu oben gemachter Aussage.
Gotthilf.
Winfried Salomon
Falk Brunner wrote:
>>>Warum die Einschränkung auf einen Prozess?
>>>
>>>
>>>
>>>
>>>
>>Weil es am einfachsten ist, obiges Problem ist so leicht zu
>>programmieren und zu simulieren. Natürlich kannst Du auch mehrere
>>
>>
>
>Oh mein Gott. !!!!
>
>Wenn es jetzt schon zuviel verlangt ist, mal 3 Zeilen mehr hinzuschreiben,
>und dadurch eine saubere Lösung eines einfachen Problems in sagen wir mal 5
>Minuten zu erreichen, dann weiss ich auch nicht mehr weiter.
>Aber dann lieber ewig und drei Tage philosophieren und diskutieren.
>Ich versteh die Welt jeden Tag weniger . . . .
>
>
[......]
warum schreibst Du so provokant? Du hättest nur zu schreiben brauchen:
"Ja, poste mal." Locker bleiben :-).
Also geh ich doch mal detaillierter auf mein Problem ein, da Du ja
Interesse bekundet hast. Als Anfänger in VHDL bin ich über ein Problem
gestolpert, nämlich einen symmetrischen Frequenzteiler /3 in einem
Xilinx CPLD XC9572-15PC84 zu implementieren mit VHDL. Ich benutze ISE
6.103 mit ModelSim als Simulator. Das VHDL-File für die entity habe ich
als div3_vhdl.vhd als attachment angehängt. Es ist sehr klein und
erklärt sich selbst. Die Behavioral-Simulation funktioniert, die
Post-Fit-Simulation und die Hardware aber nicht. Verschiedene
Hilfegesuche auch bei Xilinx schlugen fehl. Mittlerweile nach Diskussion
in comp.lang.vhdl scheint klar, daß es an meinem Implementierungstool
XST liegen müßte. Dabei handelt es sich aber um eine gekaufte
Vollversion, das was in der Industrie so eingesetzt wird.
Der Kernpunkt des Problems ist: Man kann in 1 process nicht auf beide
Flanken eines Signals triggern, hier clock. Ein Workaround durch
Aufspalten in 2 getrennte Prozesse für jede Flanke, die miteinander
kommunizieren müssen, schlug bisher fehl, vielleicht auch mangels meiner
Kenntnisse.
Vom eingesetzten Chip hängt es übrigens nicht ab und getestete
Schaltungslösungen als Schaltpläne hab ich auch, es soll in VHDL gelöst
werden ohne Vorkenntnisse einer Schaltungslösung.
Ich weiß nicht ob Du Experte in dem Bereich bist, das war nicht zu
erkennen. Wenn ja, dann zeig mal was Du kannst.
Winfried
Georg Acher
<...>
>erklärt sich selbst. Die Behavioral-Simulation funktioniert, die
>Post-Fit-Simulation und die Hardware aber nicht. Verschiedene
>Hilfegesuche auch bei Xilinx schlugen fehl. Mittlerweile nach Diskussion
>in comp.lang.vhdl scheint klar, daß es an meinem Implementierungstool
>XST liegen müßte. Dabei handelt es sich aber um eine gekaufte
>Vollversion, das was in der Industrie so eingesetzt wird.
Das liegt nicht ursächlich an XST, sondern daran, dass es keine Flipflops gibt,
die auf beiden Flanken speichern. Und genau das beschreibst du mit einem process,
in dem kein "if clk'event and clk='1'" oder "wait until clk='1'" vorkommt. Bei
dir ist es effektiv halt ein Zähler, der mit beiden Flanken zählt. Und dass XST
nichts synthetisieren kann, für das es keine Hardwareentsprechung gibt, ist kein
Problem von XST, sondern eins des Benutzers...
Du solltest dir mal ein Buch über VHDL besorgen, dass explizit die Synthese
behandelt ;-)
Winfried Salomon
-----Ursprüngliche Nachricht-----
Von: "Georg Acher" <ac...@in.tum.de>
Newsgroups: de.sci.electronics
Gesendet: Montag, 24. Januar 2005 12:12
Betreff: Re: Schaltungsminimierung mit KV-Diagramm
> Das liegt nicht ursächlich an XST, sondern daran, dass es keine Flipflops
gibt,
> die auf beiden Flanken speichern. Und genau das beschreibst du mit einem
process,
> in dem kein "if clk'event and clk='1'" oder "wait until clk='1'" vorkommt.
Bei
> dir ist es effektiv halt ein Zähler, der mit beiden Flanken zählt. Und
dass XST
> nichts synthetisieren kann, für das es keine Hardwareentsprechung gibt,
ist kein
> Problem von XST, sondern eins des Benutzers...
>
das Argment habe ich bereits mehrfach gehört bzw. gelesen, die 1. Reaktion
eines Kollegen war genauso. Das finde ich zu einfach, die Schuld gleich auf
den Programmierer zu schieben. Außerdem gibt es einen einfachen
Lösungsansatz, nämlich einfach einen Inverter vor den Clock eines FF zu
setzen. So habe ich das gemacht und es klappt prima. Die Software, welche
auch immer, kommt nicht auf diese Lösung, warum ist mir egal.
Was macht also ein heutiger Jungingenieur, wenn er diese Aufgabe bekommt? Er
erschießt sich, weil sein Computer versagt und er selber keinen
Schaltungsentwurf mehr beherrscht ;-).
> Du solltest dir mal ein Buch über VHDL besorgen, dass explizit die
Synthese
> behandelt ;-)
Also ich hab hier grade in
Paul Molitor/ Jörg Ritter
VHDL Eine Einführung
Pearson Studium
geblättert. Die haben übrigens genau das gleiche Entwicklungssystem wie wir.
Da steht nichts. Dann habe ich noch ein Buch im PDF-Format
G. Lehmann, B. Wunder, M. Selz
Schaltungsdesign mit VHDL
auf das habe ich mich bisher gestützt. An sich ist das ganz gut, dort habe
ich schon versucht was zu finden, bisher ohne Erfolg. Diese Bücher haben den
Nachteil, daß meist völlig abgedrehte Beispiele gebracht werden, aber z.B.
kein universeller Moore-Automat, wie man ihn für viele State-Machines sicher
einsetzen könnte.
Kurz und gut, ich dachte mir schon, daß hier keiner eine Lösung finden
würde. Ich versuche einen Workaround mit 2 gekoppelten Prozessen, aber auch
das scheint zu scheitern. Xilinx haben sich wieder gemeldet, sie arbeiten
dran und haben wohl auch noch keine Lösung parat, sondern suchen nach einer
Erklärung, warum es nicht geht. Um zum Topic zurückzukommen, jetzt siehst Du
mal was es heißt, sich nur noch auf Computertools zu verlassen.
Winfried
Falk Brunner
news:ct3f63$799$03$1...@news.t-online.com...
> das Argment habe ich bereits mehrfach gehört bzw. gelesen, die 1. Reaktion
> eines Kollegen war genauso. Das finde ich zu einfach, die Schuld gleich
auf
> den Programmierer zu schieben. Außerdem gibt es einen einfachen
Ist aber öfter der Fall als man glaubt. Der Problem liegt vor dem Monitor
;-)
> Lösungsansatz, nämlich einfach einen Inverter vor den Clock eines FF zu
> setzen. So habe ich das gemacht und es klappt prima. Die Software, welche
> auch immer, kommt nicht auf diese Lösung, warum ist mir egal.
Weil DU und die Software eine Sprache sprechen müssen. VHDL kann nicht raten
was du willst. Du musst mit dem Compiler kommunizieren. Und da du ja ein
Anfäger in der Materie bist, wäre es keine schlechte Einstellung, mal die
Bälle etwas flacher zu halten und Fragen zu stellen, anstatt die bösen Tools
auszubuhen.
> Was macht also ein heutiger Jungingenieur, wenn er diese Aufgabe bekommt?
Er
> erschießt sich, weil sein Computer versagt und er selber keinen
> Schaltungsentwurf mehr beherrscht ;-).
Genau. Oder kauft für vieeele $$$ einen neuen VHDL COmpiler. Der kanns dann
zwar auch nicht, aber vielleicht bringt der Support was.
> auf das habe ich mich bisher gestützt. An sich ist das ganz gut, dort habe
> ich schon versucht was zu finden, bisher ohne Erfolg. Diese Bücher haben
den
> Nachteil, daß meist völlig abgedrehte Beispiele gebracht werden, aber z.B.
> kein universeller Moore-Automat, wie man ihn für viele State-Machines
sicher
> einsetzen könnte.
Tja, gute Informationen fallen halt nicht vom Himmel. Ist ja auch klar, in
der INFORMATIONsgesellschaft, in der Informationen bares Geld sind.
> Kurz und gut, ich dachte mir schon, daß hier keiner eine Lösung finden
Tststststs, diese Jugend von heute, keine Geduld und keinen Respekt vor dem
Alter ;-)
> würde. Ich versuche einen Workaround mit 2 gekoppelten Prozessen, aber
auch
> das scheint zu scheitern. Xilinx haben sich wieder gemeldet, sie arbeiten
Nur weil DU es nicht gebacken bekommst, heisst das nicht, dass VHDL versagt
hat . . .
> dran und haben wohl auch noch keine Lösung parat, sondern suchen nach
einer
> Erklärung, warum es nicht geht. Um zum Topic zurückzukommen, jetzt siehst
Du
Hmmm, komisch. Die FAEs die ich kenne, sind eigentlich SEHR fit. Und das ist
ja nun wirklich PillePalla. Versuchs mal in
comp.arch.fpga (da sind auch CPLDs erlaubt ;-))
> mal was es heißt, sich nur noch auf Computertools zu verlassen.
Meine Rede, aber hier liegt der Fall ja wohl eindeutig anders. Du und VHDL
reden aneinander vorbei.
Man muss die (Programmier)sprache seines Partner schon wirlich sprechen, das
geht bisweilen nicht so einfach hop hop von 0 auf 100% in 2 Stunden.
MfG
Falk
Georg Acher
>Naja, das grosse X hat auch FlipFlops, die auf beiden Flanken speichern
>(Coolrunner2). Sind aber Exoten.
Äben ;-) Und für alle anderen Fälle gibt es eine (D)PLL oder (übel, tut aber
auch) den guten alten Glitchgenerator. Das ist der, wo im Xilinx-Datenbuch noch
die Pistole daneben gedruckt war...
>> ist kein Problem von XST, sondern eins des Benutzers...
>
>Jaja, scheint irgendwas mit der Kernaussage diese Theads zu tun zu haben.
>KV-ist ja so out.
Ich bin immer noch der Meinung, dass KV (insbesondere in der Aufgabenstellung des
OP) witzlos (aka out) ist. Das ist öde Fleissarbeit, sonst nichts. Am schlimmsten
ist ja noch die Verteilung der 0en und 1en aus der Original-DNF ins Quadrat, ohne
dass man durcheinanderkommt.
Dass es mal in der Vorlesung dran kommt und man mit dem Namen was anfangen kann,
ok. Dass man mal eine DNF selber damit kleinkriegt, auch ok. Aber alles was
darüber hinausgeht, ist Zeitverschwendung.
>> Du solltest dir mal ein Buch über VHDL besorgen, dass explizit die
>> Synthese behandelt ;-)
>
>Back to basics. Oder wie es ein grosser deutscher Philosoph sagte.
>
>"Wer fliegen will, muss ersteinmal laufen lernen. Man kann nicht mit dem
>fliegen anfangen"
Man kann es aber auch übertreiben. Schuhkunde ist beim Fliegen auch recht sinnlos
Falk Brunner
> >Vollversion, das was in der Industrie so eingesetzt wird.
>
> Das liegt nicht ursächlich an XST, sondern daran, dass es keine Flipflops
gibt,
> die auf beiden Flanken speichern. Und genau das beschreibst du mit einem
process,
Naja, das grosse X hat auch FlipFlops, die auf beiden Flanken speichern
(Coolrunner2). Sind aber Exoten.
> in dem kein "if clk'event and clk='1'" oder "wait until clk='1'" vorkommt.
Bei
> dir ist es effektiv halt ein Zähler, der mit beiden Flanken zählt. Und
dass XST
> nichts synthetisieren kann, für das es keine Hardwareentsprechung gibt,
ist kein
> Problem von XST, sondern eins des Benutzers...
Jaja, scheint irgendwas mit der Kernaussage diese Theads zu tun zu haben.
KV-ist ja so out.
> Du solltest dir mal ein Buch über VHDL besorgen, dass explizit die
Synthese
> behandelt ;-)
Back to basics. Oder wie es ein grosser deutscher Philosoph sagte.
"Wer fliegen will, muss ersteinmal laufen lernen. Man kann nicht mit dem
fliegen anfangen"
MfG
Falk
Georg Acher
<xst vs. process>
>das Argment habe ich bereits mehrfach gehört bzw. gelesen, die 1. Reaktion
>eines Kollegen war genauso. Das finde ich zu einfach, die Schuld gleich auf
>den Programmierer zu schieben. Außerdem gibt es einen einfachen
>Lösungsansatz, nämlich einfach einen Inverter vor den Clock eines FF zu
>setzen. So habe ich das gemacht und es klappt prima. Die Software, welche
>auch immer, kommt nicht auf diese Lösung, warum ist mir egal.
Tolle Einstellung :-( Mein C-Compiler erlaubt mir zwar, dass ich ein
a=malloc(1024*1024*1024*1024) mache, aber das Programm stürzt ab. Wer ist jetzt
schuld?
Du musst verstehen, warum nicht jeder beliebige VHDL-Roman in Gatter umzusetzen
ist, zumindest nicht in *endlicher* Zeit. Das Gehirn kann viel mehr als jeder
Computer (Stichwort Turing...)
Und schon mal überprüft, ob deine Schaltung auch wirklich keine Glitches erzeugt?
Dekodierungen aus synchronen Flipflop-Ausgängen erzeugen sowas gern.
Du kannst ja auch mal versuchen, ob der Code mit dem schweineteuren (einige
10KEUR) Behavioral Compiler (bc) vom Synopsys geht. Ich zweifele...
>Was macht also ein heutiger Jungingenieur, wenn er diese Aufgabe bekommt? Er
>erschießt sich, weil sein Computer versagt und er selber keinen
>Schaltungsentwurf mehr mehr beherrscht ;-).
Aber KV-Diagramme helfen da auch nichts ;-)
>> Du solltest dir mal ein Buch über VHDL besorgen, dass explizit die
>Synthese
>> behandelt ;-)
>
>Also ich hab hier grade in
>
>Paul Molitor/ Jörg Ritter
>VHDL Eine Einführung
>Pearson Studium
Das finde ich nicht so berauschend. Die kleben viel zu sehr am Webpack.
>geblättert. Die haben übrigens genau das gleiche Entwicklungssystem wie wir.
>Da steht nichts. Dann habe ich noch ein Buch im PDF-Format
>
>G. Lehmann, B. Wunder, M. Selz
>Schaltungsdesign mit VHDL
>
>auf das habe ich mich bisher gestützt. An sich ist das ganz gut, dort habe
>ich schon versucht was zu finden, bisher ohne Erfolg. Diese Bücher haben den
>Nachteil, daß meist völlig abgedrehte Beispiele gebracht werden, aber z.B.
>kein universeller Moore-Automat, wie man ihn für viele State-Machines sicher
>einsetzen könnte.
Deutsche Bücher sind da nicht so der Hit. Es gibt zB. Chang "digital system
design with vhdl" und zig andere, die mir in der Bibliothek untergekommen sind.
In einem (Autor klang irgenwie indisch...) wurde sogar eine PCI-Statemachine
beschrieben. Allerdings sollte man sich nicht zu sehr an diese Schablonen dran
klammern, es gibt immer das 1001te Problem wo es so nicht oder nur umständlich
funktioniert. Kannst ja mal meine Diplomarbeit durchlesen, da gab's auch so ein
Problemchen...
>Kurz und gut, ich dachte mir schon, daß hier keiner eine Lösung finden
>würde. Ich versuche einen Workaround mit 2 gekoppelten Prozessen, aber auch
>das scheint zu scheitern. Xilinx haben sich wieder gemeldet, sie arbeiten
Hm, sooo schwierig ist das doch auch nicht (oder habe ich die Aufgabenstellung
falsch verstanden):
signal qx: unsigned(2 downto 0);
signal qy: std_logic;
process(clk,reset)
begin
if reset='1' then
qx<="001";
elsif rising_edge(clk) then
if qx="100" then
qx<="001";
else
qx<=qx(1 downto 0)&'0';
end if;
end if;
end process;
process(clk,reset)
begin
if reset='1' then
qy<='0';
elsif falling_edge(clk) then
qy<=qx(0);
end if;
end process;
out_3<=qx(0) or qy;
Hab's jetzt nicht simuliert/synthetisiert, aber es sollte schon gehen und das
auch ohne Glitches.
>dran und haben wohl auch noch keine Lösung parat, sondern suchen nach einer
>Erklärung, warum es nicht geht. Um zum Topic zurückzukommen, jetzt siehst Du
>mal was es heißt, sich nur noch auf Computertools zu verlassen.
Das Verständnis dafür lernt man aber auch nicht mit KV, ich hab's jedenfalls nie
gemacht. Das ist nämlich "langweilige" Optimierung, die keine Kreativität
braucht, deshalb läuft das ja mit dem Computer so gut... Eigentlich geht es nur,
wenn man was "programmiert" und sich dann das erzeugte anschaut oder wenn man
irgendwo hart "aufschlägt". Ein vergeigtes Design, wo man noch zig Drähte und
Chips nachfädeln muss, ist auch hilfreich ;-)
Falk Brunner
> >Oh mein Gott. !!!!
> >
> warum schreibst Du so provokant? Du hättest nur zu schreiben brauchen:
> "Ja, poste mal." Locker bleiben :-).
War generft, und diese Posting hat gernau den gereitzten Nerv getroffen.
Bin meist lockerer.
;-)
> Der Kernpunkt des Problems ist: Man kann in 1 process nicht auf beide
> Flanken eines Signals triggern, hier clock. Ein Workaround durch
Sehr richtig, ist aber auch gar nicht wirklich nötig. Hat der Georg ja schon
erklärt.
> Aufspalten in 2 getrennte Prozesse für jede Flanke, die miteinander
> kommunizieren müssen, schlug bisher fehl, vielleicht auch mangels meiner
> Kenntnisse.
Das schon eher. Its easy when you know how.
> Vom eingesetzten Chip hängt es übrigens nicht ab und getestete
> Schaltungslösungen als Schaltpläne hab ich auch, es soll in VHDL gelöst
> werden ohne Vorkenntnisse einer Schaltungslösung.
Piece of cake ;-))
> Ich weiß nicht ob Du Experte in dem Bereich bist, das war nicht zu
> erkennen. Wenn ja, dann zeig mal was Du kannst.
Naja, ob ich mich als Experte bezeichen will, hmm. Zumindest hab ich in
diesem Bereich (und wie der Zufall es will auch mit diesen Bausteinen und
Software) ein paar Jahre lang meine Brötchen verdient. Urteilen Sie selbst.
Naja, also schau mer mal.
Da ich ja, wie der geneigte LEser vielleicht schon mitbekommen hat, der
(wohl austerbenen) Spezies derjenigen angehöre, die Grundlagenkentnisse auch
im Clicki-Bunti-Zeitalter nicht für verzichtbar halten, ein ganz kurzer
Abriss zu Problematik.
Ein Zähler durch eine gerade Zahl (2,4,6, etc.) ist seher einfach, jeweils
nach der Hälfte muss der frequenzgeteilte Ausgang invertiert werden.
Ein Zähler durch eine ungerade Zahl ist auch einfach, wenn man nur an der
Frequenz interessiert ist, aber mit quasi beliebigen Tastverhältnissen leben
kann (was oft geht). Dazu muss nur ein programmierbarer Zähler geschaffen
werden, die Generierung der einen Flanke erfolgt beim Über/Unter lauf, die
andere an jedem beliebigen anderen Zählerstand.
Beispiel
process(clk)
begin
if clk='1' and clk'event then
-- ladbarer Rückwärtzähler
if cnt=0 then
cnt <= max_cnt;
clk_out <= '0'; -- Unterlauf,
Reset
else
cnt <= cnt-1;
if cnt=level then
clk_out <= '1';
end if;
end if;
Das alles läuft prima als absolut klassisch digitale Schaltung mit Reaktion
auf eine Taktflanke (fallend oder steigend).
Doch nun steigern wir das Nivau ein wenig.
Wenn wir nun wie in diesem Beispiel einen Takt durch 3 teilen wollen, und
dabei möglichst ein Tastverhältnis von 50% erreichen wollen, müssen wir uns
schon etwas anstrengen.
FlipFlops arbeiten immer nur mit einer Flanke (gilt auch für die
neumodischen DDR Rams, dort sind einfach zwei pro Datenleitung dran, DDR =
double Data Rate, hat nix mit Erichs altem Staat zu tun ;-)
Also, wir können mit Flipflops nur auf jeweils eine Flanke reagieren. Da
aber bei Teilung durch 3 die steigende Flanke des geteilten Taktes mit der
steigenden Flanke des Originaltaktes zusammenfällt, jdeoch die fallende
Flanke des geteilten Takte mit der fallenden Flanke des Originaltaktes,
müssen wir hier ein wenig "tricksen".
Der "Trick ist, dass ich zwei Zähler baue, welche durch 6 teilen, der eine
auf der fallenden, der andere auf der steigenden Flanke. Nun habe ich zwei
Bitmuster, die im Taktraster von halben Takten umschalten. Tja, das wars
schon fast. Über einen Decoder kann ich nun darauch meinen durch 3 geteilten
Ausgangstakt decodieren. Doch halt, nicht so schnell. Der eingeweihte wird
bei der Verbindung von "Takt" und "aus Decoder ableiten" hellhörig". Es muss
sichergestellt werden, dass der Decoderausgang glitchfei ist. Was das
bedeutet ist bleibt dem gneigten Leser als Übungsaufgabe vorbehalten. Aber
die Lösung gibt hier gratis. Der Eingangscode des Dekoders muss ein
Gray-Code sein. Siehe Beispiel.
Na, ist doch gar nciht so schwer, oder?
Kurzer Kommentar zu deinem VHDL Schnipsel. Das kann nicht laufen, du hast
die "Abfage" des Taktes vergessen. Klar, der Simulator schluckt das schon,
aber das ist keine Kunst. Es fehlt die sehr wichtige Zeile
if clk='1' and clk'event then
MfG
Falk
-- clock divide by 3
-- with duty cycle close to 50%
--
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity div_3 is
Port ( clk : in std_logic;
clk_div_3 : out std_logic);
end div_3;
architecture Behavioral of div_3 is
signal cnt_r : std_logic_vector(2 downto 0); -- counter, rising edge
signal cnt_f : std_logic_vector(2 downto 0); -- counter falling edge
begin
-- 6:1 divider, Gray code
process(clk)
begin
if clk='1' and clk'event then -- rising edge
case cnt_r is
when "000" => cnt_r <= "001";
when "001" => cnt_r <= "011";
when "011" => cnt_r <= "111";
when "111" => cnt_r <= "101";
when "101" => cnt_r <= "100";
when "100" => cnt_r <= "000";
when others => cnt_r <= "000";
end case;
end if;
end process;
-- not really a counter, just an additional register
process(clk)
begin
if clk='0' and clk'event then -- falling edge
cnt_f <= cnt_r;
end if;
end process;
-- decoder
-- IMPORTANT
-- since we generate a clock signal, it must be 100% glitch free
-- so the input code must be a gray code
process(cnt_r, cnt_f)
variable tmp: std_logic_vector(5 downto 0);
begin
tmp := cnt_f & cnt_r;
case tmp is
when "100000" => clk_div_3 <= '0';
when "000000" => clk_div_3 <= '0';
when "000001" => clk_div_3 <= '0';
when "001001" => clk_div_3 <= '1';
when "001011" => clk_div_3 <= '1';
when "011011" => clk_div_3 <= '1';
when "011111" => clk_div_3 <= '0';
when "111111" => clk_div_3 <= '0';
when "111101" => clk_div_3 <= '0';
when "101101" => clk_div_3 <= '1';
when "101100" => clk_div_3 <= '1';
when "100100" => clk_div_3 <= '1';
when others => clk_div_3 <= '0';
end case;
end process;
end Behavioral;
Winfried Salomon
"Georg Acher" <ac...@in.tum.de> schrieb im Newsbeitrag
news:ct3nhn$2pl$1...@wsc10.lrz-muenchen.de...
> "Winfried Salomon" <wsal...@t-online.de> writes:
>
> <xst vs. process>
> >das Argment habe ich bereits mehrfach gehört bzw. gelesen, die 1.
Reaktion
> >eines Kollegen war genauso. Das finde ich zu einfach, die Schuld gleich
auf
> >den Programmierer zu schieben. Außerdem gibt es einen einfachen
> >Lösungsansatz, nämlich einfach einen Inverter vor den Clock eines FF zu
> >setzen. So habe ich das gemacht und es klappt prima. Die Software, welche
> >auch immer, kommt nicht auf diese Lösung, warum ist mir egal.
>
> Tolle Einstellung :-( Mein C-Compiler erlaubt mir zwar, dass ich ein
> a=malloc(1024*1024*1024*1024) mache, aber das Programm stürzt ab. Wer ist
jetzt
> schuld?
>
wenn ich mich recht erinnere, muß man erstmal das Betriebssystem fragen, ob
der Speicher auch da ist, aber das sind ja klar umrissene Regeln. Aber da
VHDL eine Hardwarebeschreibungssprache ist, stelle ich mir vor, daß jede
fehlerfreie Beschreibung auch in Hardware umzusetzen ist, das ist offenbar
nicht der Fall. Oder sehe ich das falsch?
> Du musst verstehen, warum nicht jeder beliebige VHDL-Roman in Gatter
umzusetzen
> ist, zumindest nicht in *endlicher* Zeit. Das Gehirn kann viel mehr als
jeder
> Computer (Stichwort Turing...)
>
Das stelle ich mir auch sehr schwer vor, nur ist mein Beispiel so einfach
beschrieben, einfacher gehts fast nicht mehr.
> Und schon mal überprüft, ob deine Schaltung auch wirklich keine Glitches
erzeugt?
> Dekodierungen aus synchronen Flipflop-Ausgängen erzeugen sowas gern.
>
Für heute ist es mir etwas zu spät, um noch ASCII-Art zu zeichnen, kann ich
aber bei Interesse nachholen. Nein, Glitches können IMHO nicht auftreten,
hab ich simuliert und sicher beim Entwurf berücksichtigt, der aber schon
länger zurückliegt. Hab nochmal drüber nachgedacht, kann aber keine
Nachteile der Schaltung finden.
> Du kannst ja auch mal versuchen, ob der Code mit dem schweineteuren
(einige
> 10KEUR) Behavioral Compiler (bc) vom Synopsys geht. Ich zweifele...
>
Ich kenne die Industriepreise von Synopsis, das ist nicht drin, werde ich
wohl nicht nachprüfen können. Ich könnte mir aber schon
Qualitätsunterschiede vorstellen. Aber mir fällt grade ein, in der Xilinx
Foundation war was mit Synopsis Express drin. Damit habe ich die allerersten
VHDL-Versuche gemacht und die tollsten Effekte gehabt, nein ich weiß
nicht....
>
> Deutsche Bücher sind da nicht so der Hit. Es gibt zB. Chang "digital
system
> design with vhdl" und zig andere, die mir in der Bibliothek untergekommen
sind.
> In einem (Autor klang irgenwie indisch...) wurde sogar eine
PCI-Statemachine
> beschrieben. Allerdings sollte man sich nicht zu sehr an diese Schablonen
dran
> klammern, es gibt immer das 1001te Problem wo es so nicht oder nur
umständlich
> funktioniert. Kannst ja mal meine Diplomarbeit durchlesen, da gab's auch
so ein
> Problemchen...
>
Ne, laß mal, hab schon genug mit solchen Dingen zu tun. Bei uns wird
eigentlich mit dem System Generator gearbeitet, der erzeugt automatisch
VHDL-Code, aber was für welchen. Allerdings optimiert die ISE das wieder
relativ gut. Aber da sieht man noch mehr die Einschränkungen, nur streng
synchrone Designs sind möglich und konsequenterweise kommt man an FFs oder
gar den Takt auf der Ebene nicht mehr dran. Der Bezug zur Hardware ist dann
nicht mehr vorhanden und die Fehlersuche dementsprechend. Allerdings hat man
es dann auch mit Schaltungen zu tun, die ein Virtex-2 FPGA füllen können.
Diese Vorgehensweise ist dann der nächste Schritt und ich weiß nicht so
recht, was ich davon halten soll.
> >Kurz und gut, ich dachte mir schon, daß hier keiner eine Lösung finden
> >würde. Ich versuche einen Workaround mit 2 gekoppelten Prozessen, aber
auch
> >das scheint zu scheitern. Xilinx haben sich wieder gemeldet, sie arbeiten
>
> Hm, sooo schwierig ist das doch auch nicht (oder habe ich die
Aufgabenstellung
> falsch verstanden):
>
> signal qx: unsigned(2 downto 0);
> signal qy: std_logic;
>
> process(clk,reset)
> begin
> if reset='1' then
> qx<="001";
> elsif rising_edge(clk) then
> if qx="100" then <------- Fehlermeldung
> qx<="001";
> else
> qx<=qx(1 downto 0)&'0';
> end if;
> end if;
> end process;
>
> process(clk,reset)
> begin
> if reset='1' then
> qy<='0';
> elsif falling_edge(clk) then
> qy<=qx(0);
> end if;
> end process;
>
> out_3<=qx(0) or qy;
>
> Hab's jetzt nicht simuliert/synthetisiert, aber es sollte schon gehen und
das
> auch ohne Glitches.
>
Ich hab das mal getestet, scheint aber noch ein Syntaxfehler drin zu sein.
So richtig verstehe ich das Programm auch nicht, mir sind nicht alle
Operationen bekannt. Das mit dem Reset ist nicht so gut, die Schaltung
sollte von selbst anlaufen. Als oben mit Pfeil markierte Fehlermeldung
bekomme ich:
Compiling vhdl file K:/XilinxProjekte/div3_sy2_vhd/div3_vhdl5.vhd in Library
work.
ERROR:HDLParsers:3292 - K:/XilinxProjekte/div3_sy2_vhd/div3_vhdl5.vhd Line
30. = has two possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
> >dran und haben wohl auch noch keine Lösung parat, sondern suchen nach
einer
> >Erklärung, warum es nicht geht. Um zum Topic zurückzukommen, jetzt siehst
Du
> >mal was es heißt, sich nur noch auf Computertools zu verlassen.
>
> Das Verständnis dafür lernt man aber auch nicht mit KV, ich hab's
jedenfalls nie
> gemacht. Das ist nämlich "langweilige" Optimierung, die keine Kreativität
> braucht, deshalb läuft das ja mit dem Computer so gut... Eigentlich geht
es nur,
> wenn man was "programmiert" und sich dann das erzeugte anschaut oder wenn
man
> irgendwo hart "aufschlägt". Ein vergeigtes Design, wo man noch zig Drähte
und
> Chips nachfädeln muss, ist auch hilfreich ;-)
>
Sicher ist die reine KV-Optimierung nicht so sonderlich interessant, weil
ziemlich schematisch. Allerdings habe ich noch ein altes Valvo-Buch, in dem
so einige Tricks beschrieben werden, die aber auch ich nicht beherrsche.
Aber wenn Du ein Problem formulierst, dann häufig in Form einer
Wahrheitstafel, da kannst Du Deine Kreativität austoben. Daß ein Computer da
manchmal schwach ist, haben wir ja gesehen.
Winfried
Winfried Salomon
> > >Oh mein Gott. !!!!
> > >
> > warum schreibst Du so provokant? Du hättest nur zu schreiben brauchen:
> > "Ja, poste mal." Locker bleiben :-).
>
> War generft, und diese Posting hat gernau den gereitzten Nerv getroffen.
> Bin meist lockerer.
> ;-)
die 4 !-Zeichen sahen aber auf den ersten Blick schon erschreckend aus :-).
Die habe ich nicht vergessen, die wurde nicht akzeptiert. Was ich da alles
ausprobiert habe, weiß ich schon nicht mehr.
Der Code funktioniert, Gratulation! Du hast Dir wirklich Mühe gegeben, muß
ich sagen. Das mit tmp ist mir noch nicht ganz klar, muß mir das Programm
mal in Ruhe anschauen. Die erzeugte Schaltung sieht ziemlich groß aus, die
Timing-Analyse ist aber recht gut, besser als die Xilinx-Lösung. Es geht
also auch mit einer rein synchron getakteten Lösung, ohne den Clock zu
invertieren.
Was ich bisher erfolglos versucht hatte war, die Zählvariable in beiden
Prozessen hochzuzählen, bzw. hatte ich sie in ein entsprechendes Signal
kopiert, das in beiden Prozessen global existiert. Aber dann kam immer eine
Meldung wie "multiple sources" für dieses Signal, was ich als Kurzschluß
zweier Quellen interpretiere. Die Zusammenführung beider Signale ist mir
nicht gelungen.
Der Aufwand in VHDL für dieses Problem scheint mir sehr groß zu sein, mir
kommt er bald noch größer vor als die klassische "Papier"-Methode mit
anschließender KV-Minimierung. Wenn man sich die Einarbeitung in VHDL mal
vorstellt, so halte ich es für sinnvoll, überschaubare digitale Schaltungen
auch ohne Computerhilfe entwerfen zu können, zum Simulieren braucht man dann
sowieso einen.
mfg. Winfried
Rainer Buchty
>wenn ich mich recht erinnere, muß man erstmal das Betriebssystem fragen, ob
>der Speicher auch da ist, aber das sind ja klar umrissene Regeln. Aber da
>VHDL eine Hardwarebeschreibungssprache ist, stelle ich mir vor, daß jede
>fehlerfreie Beschreibung auch in Hardware umzusetzen ist, das ist offenbar
>nicht der Fall. Oder sehe ich das falsch?
Ja, das siehst Du falsch. Wieso glaubst Du, daß es bei einer
Hardwarebeschreibungssprache nicht auch klar umrissene Regeln gibt?
Bei malloc() stört es Dich ja offenbar nicht einmal, daß es eine vom
Betriebssystem bereitgestellte Funktion ist (andernfalls würdest Du den
Speicher direkt beschreiben, ohne ihn erst zu reservieren) und nicht etwa
ein integraler Bestandteil der Programmiersprache C. (Und auch in C kannst Du
grundsätzlich fehlerfreien Code beschreiben, der sich auf der Zielplattform so
eben gerade nicht implementieren läßt.)
Bei VHDL stört es Dich aber sehr wohl, daß Du nicht an der Hardware vorbei
programmieren kannst und erwartest, daß Compiler und Synthesizer schon etwas
aus Deiner Beschreibung backen, was irgendwie dann auf die Hardware paßt.
Warum?
>Das stelle ich mir auch sehr schwer vor, nur ist mein Beispiel so einfach
>beschrieben, einfacher gehts fast nicht mehr.
[ ] Du kennst den Unterschied zwischen simulierbar und synthetisierbar.
Wie Georg schon ausführlich schrieb: Wenn Deine Hardware kein bi-phase clocking
kann, kannst Du es zwar lange beschreiben, aber die Synthese wird schlicht an
den Hardwarevorgaben scheitern.
Eben aus diesem Grund war Dein Beispiel *zu* einfach.
Der Synthesizer wird nicht hingehen und sagen "oh, er betreibt bi-phase
clocking, aber ich habe nur single-phase zur Verfügung -- laß uns da mal den
Master-Takt und die Zählerstände verdoppeln" oder "ich sehe sein Problem und
breche es auf in zwei Prozesse, die in geeigneter Weise verkoppelt das tun,
was er will".
>Das mit dem Reset ist nicht so gut, die Schaltung sollte von selbst anlaufen.
OH NEIN!
Du *willst* einen Reset, der Deine Schaltung in einen definierten Anfangszustand
bringt. Nicht nur zur Simulation (denn X+1 ist immer noch X) sondern auch in der
realen Hardware.
Logik, die sich selbst an den Haaren aus dem Sumpf zieht, willst Du in (C)PLDs
und FPGAs nicht haben... (Womöglich auch noch unter Miteinbeziehung von
asynchronen Laufzeitspielereien, wie man sie in der seligen TTL-Zeit eben
gemacht hat.)
Erinnert mich spontan an einen Fall aus meiner FAE-Zeit. Kunde beschwert sich,
unsere PLDs seien schlecht, weil seit er die einsetzt, würde seine Schaltung
60% Initialausfälle zeigen. Vorher, mit dem (abgekündigten) Konkurrenz-PLD, sei
alles in Butter gewesen.
Da hatte der Gute also eine 3-Bit Statemachine mit 6 definierten Zuständen und
keinem Reset-Eingang, die unter idealen Bedingungen sich auch tatsächlich selbst
aus dem Sumpf zog. Die abgekündigten Konkurrenz-PLDs waren allerdings weit
langsamer und so glitchte seine Schaltung mit schnelleren Bausteinen dann schön
in einen der zwei undefinierten Zustände der Statemachine und verweilte dort...
>[...]Daß ein Computer da manchmal schwach ist, haben wir ja gesehen.
Nimm's mir nicht übel, aber Deine Argumentation in diesem Thread erinnert mich
etwas an meine Prä-C Ära... Da habe ich auch 1001 Argumente gefunden, wieso C
"schlecht" sei, weil ich mich da selbst um Speicherallokation kümmern muß, weil
ich nur noch * und & durch die Gegend schiebe, das sei doch keine Hochsprache
usw. usf.
Letztendlich war das Problem aber nur, daß es "anders" war als von mir erwartet
oder gedanklich gefordert und somit ein klassischer Fall von PEBCAK.
Rainer
Georg Acher
>wenn ich mich recht erinnere, muß man erstmal das Betriebssystem fragen, ob
>der Speicher auch da ist, aber das sind ja klar umrissene Regeln. Aber da
Ok, bringe einem C-Compiler bei, die Ackerman-Funktion in linearer Zeit zu
berechnen...
>VHDL eine Hardwarebeschreibungssprache ist, stelle ich mir vor, daß jede
>fehlerfreie Beschreibung auch in Hardware umzusetzen ist, das ist offenbar
>nicht der Fall. Oder sehe ich das falsch?
Von _allen_ simulierbaren (d.h. syntaktisch fehlerfreien) VHDL-Programmen sind
ziemlich genau 0% synthetisierbar! Jeder synthetisierbare Code kann durch
Einfügen _einer_ Zeile (wahrscheinlich reichen schon ein paar Zeichen) nicht mehr
synthetisierbar gemacht werden.
Beispiele:
if x='X' then
a<=a+1;
end if;
oder
rekursive Fibnocci-Zahlen mit function()
oder
while-Schleifen mit dynamischen Abbruchbedingungen
oder
wait mit Zeitangabe
oder
Zeiger (ja, VHDL hat auch Pointer...)
>> Du musst verstehen, warum nicht jeder beliebige VHDL-Roman in Gatter
>> umzusetzen
>> ist, zumindest nicht in *endlicher* Zeit. Das Gehirn kann viel mehr als
>> jeder Computer (Stichwort Turing...)
>>
>
>Das stelle ich mir auch sehr schwer vor, nur ist mein Beispiel so einfach
>beschrieben, einfacher gehts fast nicht mehr.
Das sieht nur so aus... Das ist ein "informatisches" Problem, sowas ist
prinzipiell nicht im allgemeinen Fall lösbar. Man kann zwar immer irgendwas
rumfrickeln, dass Spezialfälle erkannt werden. Die ganze HDL-Synthese ist ein
Spezialfall, der nur funktioniert, wenn man sich an gewisse
Konverntionen/Schablonen hält.
>> Und schon mal überprüft, ob deine Schaltung auch wirklich keine Glitches
>> erzeugt? Dekodierungen aus synchronen Flipflop-Ausgängen erzeugen sowas gern.
>>
>
>Für heute ist es mir etwas zu spät, um noch ASCII-Art zu zeichnen, kann ich
>aber bei Interesse nachholen. Nein, Glitches können IMHO nicht auftreten,
>hab ich simuliert und sicher beim Entwurf berücksichtigt, der aber schon
Auch in der Timingsimulation glitchfrei?
>länger zurückliegt. Hab nochmal drüber nachgedacht, kann aber keine
>Nachteile der Schaltung finden.
>
>> Du kannst ja auch mal versuchen, ob der Code mit dem schweineteuren
>(einige
>> 10KEUR) Behavioral Compiler (bc) vom Synopsys geht. Ich zweifele...
>>
>
>Ich kenne die Industriepreise von Synopsis, das ist nicht drin, werde ich
>wohl nicht nachprüfen können. Ich könnte mir aber schon
>Qualitätsunterschiede vorstellen. Aber mir fällt grade ein, in der Xilinx
>Foundation war was mit Synopsis Express drin. Damit habe ich die allerersten
>VHDL-Versuche gemacht und die tollsten Effekte gehabt, nein ich weiß
>nicht....
Ich hab den bc hier, da kann ich mal schauen. Bislang habe ich mit dem aber noch
nichts gemacht...
<...>
>Ne, laß mal, hab schon genug mit solchen Dingen zu tun. Bei uns wird
>eigentlich mit dem System Generator gearbeitet, der erzeugt automatisch
>VHDL-Code, aber was für welchen. Allerdings optimiert die ISE das wieder
>relativ gut. Aber da sieht man noch mehr die Einschränkungen, nur streng
>synchrone Designs sind möglich und konsequenterweise kommt man an FFs oder
In 99% sollte man auch nur synchrone Designs machen, alles andere macht gerne
Probleme. Meistens aber erst dann, wenn es schon fast zu spät ist... Dummerweise
denkt man am Anfang (ich auch...), dass Asynchron so schön schnell zu
implementieren ist.
>gar den Takt auf der Ebene nicht mehr dran. Der Bezug zur Hardware ist dann
>nicht mehr vorhanden und die Fehlersuche dementsprechend. Allerdings hat man
>es dann auch mit Schaltungen zu tun, die ein Virtex-2 FPGA füllen können.
>Diese Vorgehensweise ist dann der nächste Schritt und ich weiß nicht so
>recht, was ich davon halten soll.
Solange die Abläufe sich an Standard-Schablonen halten, geht das wohl recht gut.
>Ich hab das mal getestet, scheint aber noch ein Syntaxfehler drin zu sein.
Hm, ausser dass die signals natürlich direkt nach der architecture definiert
sein sollten, sieht es auch nach einem Tag noch richtig aus ;-)
>So richtig verstehe ich das Programm auch nicht, mir sind nicht alle
Der erste Prozess macht einen asymetrischen Teiler durch 3 mit einer
One-Hot-codierten Statemachine (001,010,100,001,...). Der zweite verzögert
Zustand 1 um einen halben Takt, macht also:
clk _-_-_-_-_-_-_-_-_-_-_
qx(0) _--____--____--____--
qx(1) ___--____--____--____
qx(2) _____--____--____--__
qy __--____--____--_____
out_3 _---___---___---___--
Glitcht auch nicht.
>Operationen bekannt. Das mit dem Reset ist nicht so gut, die Schaltung
>sollte von selbst anlaufen. Als oben mit Pfeil markierte Fehlermeldung
Das mit Reset sollte man IMMER machen! Das sagt dem Synthesizer nämlich, welchen
Zustand die FFs nach einem Powerup (nicht nur Reset) haben sollen. Den Resetpin
muss man nicht mal rausführen. Manche Synthesizer (z.B. Synopsys Design
Compiler) erzeugen machmal ohne expliziten Reset sogar richtigen Blödsinn...
>bekomme ich:
>
>Compiling vhdl file K:/XilinxProjekte/div3_sy2_vhd/div3_vhdl5.vhd in Library
>work.
>ERROR:HDLParsers:3292 - K:/XilinxProjekte/div3_sy2_vhd/div3_vhdl5.vhd Line
>30. = has two possible definitions in this scope. For example, parameter 2
>(string value) can be: SIGNED or UNSIGNED
Hm, da fehlt wahrscheinlich noch die Library-clause ganz am Anfang:
library IEEE;
use IEEE.numeric_std.all;
<...>
Falk Brunner
> die 4 !-Zeichen sahen aber auf den ersten Blick schon erschreckend aus
:-).
Das sollten sie auch. ;-)
> > if clk='1' and clk'event then
> >
>
> Die habe ich nicht vergessen, die wurde nicht akzeptiert. Was ich da alles
> ausprobiert habe, weiß ich schon nicht mehr.
Nun, wie bereits von dir selber und anderen festgestellt, in VHDL bist du
ein Absolutwer Anfänger.
Ist keine Schande, waren wir alle mal.
Nur muss man dann halt sich durchkämpfen.
> Der Code funktioniert, Gratulation! Du hast Dir wirklich Mühe gegeben, muß
> ich sagen. Das mit tmp ist mir noch nicht ganz klar, muß mir das Programm
> mal in Ruhe anschauen. Die erzeugte Schaltung sieht ziemlich groß aus, die
Nun ja, VHDl Basics sind nur duch noch bessere Kenntnis von VHDL Basics zu
ersetzen.
> Timing-Analyse ist aber recht gut, besser als die Xilinx-Lösung. Es geht
> also auch mit einer rein synchron getakteten Lösung, ohne den Clock zu
> invertieren.
Clock wird invertiert, in dem zweiten prozess der cnt_f steuert. Das ist
aber voll in Ordnung und immer noch sauberes synchrones Design.
> Was ich bisher erfolglos versucht hatte war, die Zählvariable in beiden
> Prozessen hochzuzählen, bzw. hatte ich sie in ein entsprechendes Signal
> kopiert, das in beiden Prozessen global existiert. Aber dann kam immer
eine
Geht nicht.
> Der Aufwand in VHDL für dieses Problem scheint mir sehr groß zu sein, mir
> kommt er bald noch größer vor als die klassische "Papier"-Methode mit
Der Eindruck täuscht.
MfG
Falk
Falk Brunner
> VHDL eine Hardwarebeschreibungssprache ist, stelle ich mir vor, daß jede
> fehlerfreie Beschreibung auch in Hardware umzusetzen ist, das ist offenbar
> nicht der Fall. Oder sehe ich das falsch?
Völlig falsch. VHDL ist zwar eine Beschreibungssprache für digitale Systeme,
synthetisierbar ist aber nur ein (kleiner) Teil der Konstrukte. Der Rest ist
nur für Simulation verwendbar.
> Ne, laß mal, hab schon genug mit solchen Dingen zu tun. Bei uns wird
> eigentlich mit dem System Generator gearbeitet, der erzeugt automatisch
> VHDL-Code, aber was für welchen. Allerdings optimiert die ISE das wieder
> relativ gut. Aber da sieht man noch mehr die Einschränkungen, nur streng
> synchrone Designs sind möglich und konsequenterweise kommt man an FFs oder
Was ist das Problem mit streng synchronen Designs?? Klar, die reale Welt
(tm) verlangt des öfteren die Koplung von Systemen, die asynchron zueinander
sind. Aber aus lieber langer Weile wird man sich sinnvollerweise nicht den
Teufel (in Gestalt asynchroner Bestien) an den Hals holen.
> gar den Takt auf der Ebene nicht mehr dran. Der Bezug zur Hardware ist
dann
> nicht mehr vorhanden und die Fehlersuche dementsprechend. Allerdings hat
man
Ist das gleiche Problem wie mit C-Compilern. Aber wenn diese einen gewissen
Entwicklungsstand erreicht haben, gibts da auch extrem selten GRund, den
Compiler anzuzweifeln (jaja, 100% sicher kann man nie sein)
> es dann auch mit Schaltungen zu tun, die ein Virtex-2 FPGA füllen können.
> Diese Vorgehensweise ist dann der nächste Schritt und ich weiß nicht so
> recht, was ich davon halten soll.
???
> Compiling vhdl file K:/XilinxProjekte/div3_sy2_vhd/div3_vhdl5.vhd in
Library
> work.
> ERROR:HDLParsers:3292 - K:/XilinxProjekte/div3_sy2_vhd/div3_vhdl5.vhd Line
> 30. = has two possible definitions in this scope. For example, parameter
2
> (string value) can be: SIGNED or UNSIGNED
use anweisung für librarys vergessen??
MfG
Falk
Falk Brunner
"Rainer Buchty" <buc...@atbode61.informatik.tu-muenchen.de> schrieb im
Newsbeitrag news:ct7r79$2uouk$1...@sunsystem5.informatik.tu-muenchen.de...
> >Das mit dem Reset ist nicht so gut, die Schaltung sollte von selbst
anlaufen.
>
> OH NEIN!
>
> Du *willst* einen Reset, der Deine Schaltung in einen definierten
Anfangszustand
> bringt. Nicht nur zur Simulation (denn X+1 ist immer noch X) sondern auch
in der
> realen Hardware.
Einspruch euer Ehren!!!
Ich behaupte genau das Gegenteil. Eben wenn die Hardware so ausgelegt ist,
dass sie keinen Reset braucht und sich selber wieder aus dem Sumpf ziehen
kann, ist sie wesentlich robuster. In meinem Dunstkreis (Telekommunikation)
ist gerade das eines der wichtigen Punkte. Niemand will nen Techniker nachts
um 3 in die Pampa schicken und auf nen Reset Knopf drücken lassen.
Softwerker machen sichs einfach mit nem Watchdaog. Hardwerker bauen robste
Logik. Mein VHDL hat sehr selten einen Reset.
> Logik, die sich selbst an den Haaren aus dem Sumpf zieht, willst Du in
(C)PLDs
> und FPGAs nicht haben... (Womöglich auch noch unter Miteinbeziehung von
> asynchronen Laufzeitspielereien, wie man sie in der seligen TTL-Zeit eben
> gemacht hat.)
Das ist eine andere Geschichte. Es gibt aber absolut saubere Methoden dazu
(indem man z.B. nichtverwendete Codes in State Machines auf den Reset-Code
springen lässt etc.)
.
> Da hatte der Gute also eine 3-Bit Statemachine mit 6 definierten Zuständen
und
> keinem Reset-Eingang, die unter idealen Bedingungen sich auch tatsächlich
selbst
> aus dem Sumpf zog. Die abgekündigten Konkurrenz-PLDs waren allerdings weit
> langsamer und so glitchte seine Schaltung mit schnelleren Bausteinen dann
schön
> in einen der zwei undefinierten Zustände der Statemachine und verweilte
dort...
Sag ich nicht? Tja, selber Schuld. Asynchroner Murks aus der TTL Zeit. Ein
Glück dass ich das nicht mehr erleben musste.
> Letztendlich war das Problem aber nur, daß es "anders" war als von mir
erwartet
> oder gedanklich gefordert und somit ein klassischer Fall von PEBCAK.
???
MfG
Falk
Winfried Salomon
"Georg Acher" <ac...@in.tum.de> schrieb im Newsbeitrag
news:ct81v3$6hb$1...@wsc10.lrz-muenchen.de...
> "Winfried Salomon" <wsal...@t-online.de> writes:
>
> >wenn ich mich recht erinnere, muß man erstmal das Betriebssystem fragen,
ob
> >der Speicher auch da ist, aber das sind ja klar umrissene Regeln. Aber da
>
> Ok, bringe einem C-Compiler bei, die Ackerman-Funktion in linearer Zeit zu
> berechnen...
>
kann ich nicht finden, was ist das für 'ne Funktion? Warum in linearer Zeit,
hat das was mit Echtzeit zu tun?
> >VHDL eine Hardwarebeschreibungssprache ist, stelle ich mir vor, daß jede
> >fehlerfreie Beschreibung auch in Hardware umzusetzen ist, das ist
offenbar
> >nicht der Fall. Oder sehe ich das falsch?
>
> Von _allen_ simulierbaren (d.h. syntaktisch fehlerfreien) VHDL-Programmen
sind
> ziemlich genau 0% synthetisierbar! Jeder synthetisierbare Code kann durch
> Einfügen _einer_ Zeile (wahrscheinlich reichen schon ein paar Zeichen)
nicht mehr
> synthetisierbar gemacht werden.
>
> Beispiele:
> if x='X' then
> a<=a+1;
> end if;
>
> oder
>
> rekursive Fibnocci-Zahlen mit function()
^
|
Fibonacci ;-)
das ist doch 'ne Reihenentwicklung, kann ich mir als Hardwareproblem jetzt
schwer vorstellen. Das mit der Rekursion erinnert mich an ein
Pascal-Lehrbuch, in dem sich selbst aufrufende procedures (bis der heap
platzt) beschrieben wurden. Sowas ist mir in mathematisch-technischen
Problemstellungen noch nie untergekommen, das geht auch alles einfacher.
>
> oder
>
> while-Schleifen mit dynamischen Abbruchbedingungen
>
> oder
>
> wait mit Zeitangabe
>
In VHDL stecken sicher noch einige Fallstricke, die ich noch nicht kenne, es
muß natürlich auch hardwaremäßig Sinn machen. Ich stelle mir dann eine
innere Logik im Programm vor, die die Funktion der Hardware widerspruchsfrei
und realisierbar beschreibt, es muß auch Realisierbarkeitsbedingungen geben.
Sich selbst aufrufende Logik kann ich mir im Moment überhaupt nicht
vorstellen, also geht das wahrscheinlich in die Hose. Bei Zeitverzögerungen
ist es etwas anders, die hab ich schon öfters gebraucht, es gibt da
Sonderfälle. IMHO bietet das Xilinx nicht an, obwohl es der Router
eigentlich in Grenzen können müßte.
> oder
>
> Zeiger (ja, VHDL hat auch Pointer...)
Hilfe! :-)
>
> >> Du musst verstehen, warum nicht jeder beliebige VHDL-Roman in Gatter
> >> umzusetzen
> >> ist, zumindest nicht in *endlicher* Zeit. Das Gehirn kann viel mehr als
> >> jeder Computer (Stichwort Turing...)
> >>
> >
> >Das stelle ich mir auch sehr schwer vor, nur ist mein Beispiel so einfach
> >beschrieben, einfacher gehts fast nicht mehr.
>
> Das sieht nur so aus... Das ist ein "informatisches" Problem, sowas ist
> prinzipiell nicht im allgemeinen Fall lösbar. Man kann zwar immer
irgendwas
> rumfrickeln, dass Spezialfälle erkannt werden. Die ganze HDL-Synthese ist
ein
> Spezialfall, der nur funktioniert, wenn man sich an gewisse
> Konverntionen/Schablonen hält.
Du meinst, die Synthese meines VHDL-Beispiels ist prinzipiell unlösbar? Mit
meinem Ansatz sehe ich da aber keine Probleme.
>
> >> Und schon mal überprüft, ob deine Schaltung auch wirklich keine
Glitches
> >> erzeugt? Dekodierungen aus synchronen Flipflop-Ausgängen erzeugen sowas
gern.
> >>
> >
> >Für heute ist es mir etwas zu spät, um noch ASCII-Art zu zeichnen, kann
ich
> >aber bei Interesse nachholen. Nein, Glitches können IMHO nicht auftreten,
> >hab ich simuliert und sicher beim Entwurf berücksichtigt, der aber schon
>
> Auch in der Timingsimulation glitchfrei?
>
> >länger zurückliegt. Hab nochmal drüber nachgedacht, kann aber keine
> >Nachteile der Schaltung finden.
> >
Jetzt versuche ich doch noch mal etwas zu malen. Die Schaltung hat weder in
der Timing-Simulation noch in der Hardware-Messung mit Scope Probleme
gemacht.
___ ___
------------|inv|------o-----------------|&
|------o------output
| |___| | --|___|
|
| | |
|
_______________________________ | |
|
| | | | |
|
| | | | |
|
| |
_____________________________________________|
| _____ | | _____ | | ______ |
___ ----| D Q|--- ---|D Q|-- -----|D Q|---
---|inv|-------| C | ------|C | ----|C |
| |___| |_____| | |____| | |______|
| | |
|____________________________|____________________|
|
input
Ich hoffe, ohne Proportionalschrift kann man das sehen, die mit Outlook
Express sind hier aufgeschmissen, am besten in ASCII-Editor kopieren.
> >> Du kannst ja auch mal versuchen, ob der Code mit dem schweineteuren
> >(einige
> >> 10KEUR) Behavioral Compiler (bc) vom Synopsys geht. Ich zweifele...
> >>
> >
> >Ich kenne die Industriepreise von Synopsis, das ist nicht drin, werde ich
> >wohl nicht nachprüfen können. Ich könnte mir aber schon
> >Qualitätsunterschiede vorstellen. Aber mir fällt grade ein, in der Xilinx
> >Foundation war was mit Synopsis Express drin. Damit habe ich die
allerersten
> >VHDL-Versuche gemacht und die tollsten Effekte gehabt, nein ich weiß
> >nicht....
>
> Ich hab den bc hier, da kann ich mal schauen. Bislang habe ich mit dem
aber noch
> nichts gemacht...
>
Ich glaube, ich mach auch nochmal 'nen Test mit Foundation FPGA Express,
aber erst morgen, es ist wieder so spät geworden, muß abbrechen.
> <...>
> >Ne, laß mal, hab schon genug mit solchen Dingen zu tun. Bei uns wird
> >eigentlich mit dem System Generator gearbeitet, der erzeugt automatisch
> >VHDL-Code, aber was für welchen. Allerdings optimiert die ISE das wieder
> >relativ gut. Aber da sieht man noch mehr die Einschränkungen, nur streng
> >synchrone Designs sind möglich und konsequenterweise kommt man an FFs
oder
>
> In 99% sollte man auch nur synchrone Designs machen, alles andere macht
gerne
> Probleme. Meistens aber erst dann, wenn es schon fast zu spät ist...
Dummerweise
> denkt man am Anfang (ich auch...), dass Asynchron so schön schnell zu
> implementieren ist.
>
Ich kenne das, der symmetrische Teiler /3 wird bei uns als abschreckendes
Beispiel im asynchronen Fall als Übung behandelt. Natürlich wollte ich dann
auch eine saubere synchrone Lösung haben :-).
Die wollte ich jetzt auch in VHDL haben, aber.....
> >gar den Takt auf der Ebene nicht mehr dran. Der Bezug zur Hardware ist
dann
> >nicht mehr vorhanden und die Fehlersuche dementsprechend. Allerdings hat
man
> >es dann auch mit Schaltungen zu tun, die ein Virtex-2 FPGA füllen können.
> >Diese Vorgehensweise ist dann der nächste Schritt und ich weiß nicht so
> >recht, was ich davon halten soll.
>
> Solange die Abläufe sich an Standard-Schablonen halten, geht das wohl
recht gut.
>
> >Ich hab das mal getestet, scheint aber noch ein Syntaxfehler drin zu
sein.
>
> Hm, ausser dass die signals natürlich direkt nach der architecture
definiert
> sein sollten, sieht es auch nach einem Tag noch richtig aus ;-)
>
Die Signaldeklarationen habe ich da auch reingesetzt.
> >So richtig verstehe ich das Programm auch nicht, mir sind nicht alle
>
> Der erste Prozess macht einen asymetrischen Teiler durch 3 mit einer
> One-Hot-codierten Statemachine (001,010,100,001,...). Der zweite verzögert
> Zustand 1 um einen halben Takt, macht also:
>
> clk _-_-_-_-_-_-_-_-_-_-_
> qx(0) _--____--____--____--
> qx(1) ___--____--____--____
> qx(2) _____--____--____--__
> qy __--____--____--_____
> out_3 _---___---___---___--
>
> Glitcht auch nicht.
>
Ok, sobald ich etwas Zeit habe werde ich mich da mal reindenken, da ich auch
den Fehler in meinem mißglückten Versuch verstehen möchte.
> >Operationen bekannt. Das mit dem Reset ist nicht so gut, die Schaltung
> >sollte von selbst anlaufen. Als oben mit Pfeil markierte Fehlermeldung
>
> Das mit Reset sollte man IMMER machen! Das sagt dem Synthesizer nämlich,
welchen
> Zustand die FFs nach einem Powerup (nicht nur Reset) haben sollen. Den
Resetpin
> muss man nicht mal rausführen. Manche Synthesizer (z.B. Synopsys Design
> Compiler) erzeugen machmal ohne expliziten Reset sogar richtigen
Blödsinn...
>
Du meinst 'nen Anschluß für Global Reset? Aber nicht rausführen ist doch
nicht so gut, dann hängt doch 'ne Leitung in der Luft? Bisher hab ich immer
Schematic Entry gemacht, da brauchte man bei Library-Elementen nicht
unbedingt reset. Nur wenn man ein FF aus Gattern selbst gemacht hatte, ging
die Simulation ohne Reset nicht.
> >bekomme ich:
> >
> >Compiling vhdl file K:/XilinxProjekte/div3_sy2_vhd/div3_vhdl5.vhd in
Library
> >work.
> >ERROR:HDLParsers:3292 - K:/XilinxProjekte/div3_sy2_vhd/div3_vhdl5.vhd
Line
> >30. = has two possible definitions in this scope. For example, parameter
2
> >(string value) can be: SIGNED or UNSIGNED
>
> Hm, da fehlt wahrscheinlich noch die Library-clause ganz am Anfang:
>
> library IEEE;
> use IEEE.numeric_std.all;
>
Habe ich eingefügt, ändert aber leider nichts.
mfg. Winfried
Rainer Buchty
>Ich behaupte genau das Gegenteil. Eben wenn die Hardware so ausgelegt ist,
>dass sie keinen Reset braucht und sich selber wieder aus dem Sumpf ziehen
>kann, ist sie wesentlich robuster.
Kommt auf den Anwendungsbereich an, würde ich sagen. Eine typische Glue-Logic
sollte schon mit dem Prozessor zusammen anfangen und nicht ein paar Zyklen
zum "sich Fangen" brauchen. Und wenn der FPGA/ASIC ein heutiges
Integrationsmonster mit integrierter CPU ist, möchte dieses sowieso ein Reset-
Signal haben.
Beim /3 ist es natürlich egal, wie die Flipflops hochkommen, das renkt sich nach
ein paar Takten ein. Aber eventuell muß man dann auch so lange das Reset-Signal
für die diesen Takt verarbeitenden Komponenten gesetzt lassen, damit diese nicht
aus dem Tritt kommen.
>In meinem Dunstkreis (Telekommunikation)
>ist gerade das eines der wichtigen Punkte. Niemand will nen Techniker nachts
>um 3 in die Pampa schicken und auf nen Reset Knopf drücken lassen.
>Softwerker machen sichs einfach mit nem Watchdaog. Hardwerker bauen robste
>Logik. Mein VHDL hat sehr selten einen Reset.
Nunja, es gibt ja auch Hardware-Watchdogs. Da braucht es dann auch keinen
Reset-Knopf und den Techniker, der nachts hinfährt zum Knöpfchendrücken.
So rein aus Neugier: Wenn ein Gerät aus Deinem Dunstkreis abschmiert, wie oft
liegt es tatsächlich an einem Hardwarefehler und wie oft hat sich einfach die
Software erhängt?
>> Letztendlich war das Problem aber nur, daß es "anders" war als von mir
>> erwartet oder gedanklich gefordert und somit ein klassischer Fall von PEBCAK.
"Problem exists between chair and keyboard"
Rainer
Winfried Salomon
"Rainer Buchty" <buc...@atbode61.informatik.tu-muenchen.de> schrieb im
Newsbeitrag news:ct7r79$2uouk$1...@sunsystem5.informatik.tu-muenchen.de...
> "Winfried Salomon" <wsal...@t-online.de> writes:
> >wenn ich mich recht erinnere, muß man erstmal das Betriebssystem fragen,
ob
> >der Speicher auch da ist, aber das sind ja klar umrissene Regeln. Aber da
> >VHDL eine Hardwarebeschreibungssprache ist, stelle ich mir vor, daß jede
> >fehlerfreie Beschreibung auch in Hardware umzusetzen ist, das ist
offenbar
> >nicht der Fall. Oder sehe ich das falsch?
>
> Ja, das siehst Du falsch. Wieso glaubst Du, daß es bei einer
> Hardwarebeschreibungssprache nicht auch klar umrissene Regeln gibt?
>
Kann garnicht sehen, daß ich das geschrieben habe, aber man könnte auf die
Idee kommen. Mein Beispiel ist ja syntaktisch richtig, läßt sich aber nicht
implementieren. Der Grund dafür ist eindeutig, daß die Software die
vorhandenen Lösungen nicht findet. Also hat Falk etwas hardwarenaher
programmiert und es geht. Das bedeutet in meinen Augen, daß der
Abstraktionsgrad der Software für diesen Fall nicht weit genug geht. Das
kann man vorher nicht wissen, denn nirgendwo steht, daß man nicht auf 2
Flanken in 1 process triggern darf, also sollte man es machen dürfen.
Demnach finde ich diese Regel schonmal nicht klar.
> Bei malloc() stört es Dich ja offenbar nicht einmal, daß es eine vom
> Betriebssystem bereitgestellte Funktion ist (andernfalls würdest Du den
> Speicher direkt beschreiben, ohne ihn erst zu reservieren) und nicht etwa
> ein integraler Bestandteil der Programmiersprache C. (Und auch in C kannst
Du
> grundsätzlich fehlerfreien Code beschreiben, der sich auf der
Zielplattform so
> eben gerade nicht implementieren läßt.)
>
Kenne mich mit C nicht gut aus, programmiere auch nur sporadisch. Ich weiß
aber, daß die Typendeklarationen von der Plattform abhängen trotz
ANSI-Standard. Oder z.B. speichern manche CPUs die Bytes spiegelverkehrt
zueinander ab wie Motorola und Intel, das kann Probleme machen. Mehr fällt
mir dazu jetzt nicht ein, aber läßt sich das mit VHDL vergleichen?
> Bei VHDL stört es Dich aber sehr wohl, daß Du nicht an der Hardware vorbei
> programmieren kannst und erwartest, daß Compiler und Synthesizer schon
etwas
> aus Deiner Beschreibung backen, was irgendwie dann auf die Hardware paßt.
>
> Warum?
>
Weil ich das so haben will :-).
> >Das stelle ich mir auch sehr schwer vor, nur ist mein Beispiel so einfach
> >beschrieben, einfacher gehts fast nicht mehr.
>
> [ ] Du kennst den Unterschied zwischen simulierbar und synthetisierbar.
>
> Wie Georg schon ausführlich schrieb: Wenn Deine Hardware kein bi-phase
clocking
> kann, kannst Du es zwar lange beschreiben, aber die Synthese wird schlicht
an
> den Hardwarevorgaben scheitern.
>
> Eben aus diesem Grund war Dein Beispiel *zu* einfach.
>
> Der Synthesizer wird nicht hingehen und sagen "oh, er betreibt bi-phase
> clocking, aber ich habe nur single-phase zur Verfügung -- laß uns da mal
den
> Master-Takt und die Zählerstände verdoppeln" oder "ich sehe sein Problem
und
> breche es auf in zwei Prozesse, die in geeigneter Weise verkoppelt das
tun,
> was er will".
>
So richtig klar ist mir der Unterschied zwischen simulierbar und
synthetisierbar nicht, obwohl ich schon gesehen habe, daß nicht alles in
Hardware Sinn macht, z.B. wird man ja wohl nicht auf die Idee kommen können,
in Hardware einen Text ausgeben zu wollen, ob das Compilieren erfolgreich
war. Aber was heißt denn "bi-phase"? In einer Parallelmail hab ich die
Schaltung mal gepostet, die ist "bi-phase" und funktioniert trotzdem. Man
braucht nur einen Clock zu invertieren und wenn man die Lösung vorgibt, läßt
sie sich auch implementieren. Wenn man aber nur ein Verhaltensmodell in VHDL
vorgibt wird klar, die Entwickler dieser Software haben einfach vergessen,
diese Optimierungsmöglichkeit mit einzubauen, weil sie sie wahrscheinlich
nicht kannten oder weil es zu aufwendig ist.
> >Das mit dem Reset ist nicht so gut, die Schaltung sollte von selbst
anlaufen.
>
> OH NEIN!
>
> Du *willst* einen Reset, der Deine Schaltung in einen definierten
Anfangszustand
> bringt. Nicht nur zur Simulation (denn X+1 ist immer noch X) sondern auch
in der
> realen Hardware.
>
> Logik, die sich selbst an den Haaren aus dem Sumpf zieht, willst Du in
(C)PLDs
> und FPGAs nicht haben... (Womöglich auch noch unter Miteinbeziehung von
> asynchronen Laufzeitspielereien, wie man sie in der seligen TTL-Zeit eben
> gemacht hat.)
>
Doch, die will ich haben, wieso meinst Du, ich wollte das nicht? Und mit
Laufzeiten braucht man hier auch nichts zu machen, das sind doch
Sonderfälle. Allerdings habe ich in meinem VHDL-Beispiel das Selbstanlaufen
weggelassen, damit es einfacher wird.
Wieso ist denn x+1=x?
Erinnert mich an einen hergeleiteten Beweis, daß 1=0 ist ;-).
> Erinnert mich spontan an einen Fall aus meiner FAE-Zeit. Kunde beschwert
sich,
> unsere PLDs seien schlecht, weil seit er die einsetzt, würde seine
Schaltung
> 60% Initialausfälle zeigen. Vorher, mit dem (abgekündigten)
Konkurrenz-PLD, sei
> alles in Butter gewesen.
>
> Da hatte der Gute also eine 3-Bit Statemachine mit 6 definierten Zuständen
und
> keinem Reset-Eingang, die unter idealen Bedingungen sich auch tatsächlich
selbst
> aus dem Sumpf zog. Die abgekündigten Konkurrenz-PLDs waren allerdings weit
> langsamer und so glitchte seine Schaltung mit schnelleren Bausteinen dann
schön
> in einen der zwei undefinierten Zustände der Statemachine und verweilte
dort...
>
Jaaa, da zeigt sich natürlich, wie gut jemand saubere Schaltungen entwerfen
kann, solche Dinge wie skew werden dann wichtig, denn auch synchrone Designs
reagieren da empfindlich. Undefinierte Zustände sollte man normalerweise
auch nicht zulassen, sonst kann sich die Statemachine aufhängen. IMHO gibt
es auch Strategien, um störsichere Statemachines zu entwerfen. Wenn man das
zum Beruf hat, sollte man das schon beherrschen.
> >[...]Daß ein Computer da manchmal schwach ist, haben wir ja gesehen.
>
> Nimm's mir nicht übel, aber Deine Argumentation in diesem Thread erinnert
mich
> etwas an meine Prä-C Ära... Da habe ich auch 1001 Argumente gefunden,
wieso C
> "schlecht" sei, weil ich mich da selbst um Speicherallokation kümmern muß,
weil
> ich nur noch * und & durch die Gegend schiebe, das sei doch keine
Hochsprache
> usw. usf.
>
> Letztendlich war das Problem aber nur, daß es "anders" war als von mir
erwartet
> oder gedanklich gefordert und somit ein klassischer Fall von PEBCAK.
>
Ich bin immer noch in der Prä-C-Ära :-), ist IMHO nur für Leute geeignet,
die sehr viel damit programmieren müssen. Vermutlich gilt für VHDL das
Gleiche.
mfg. Winfried
Falk Brunner
> So rein aus Neugier: Wenn ein Gerät aus Deinem Dunstkreis abschmiert, wie
oft
> liegt es tatsächlich an einem Hardwarefehler und wie oft hat sich einfach
die
> Software erhängt?
Keine Ahnung, meist wirds aber wohl Software sein (Wenn nicht mal wieder
State Machines undicht sind und alle Takte sauber sind)
MfG
Falk
Falk Brunner
> > Ja, das siehst Du falsch. Wieso glaubst Du, daß es bei einer
> > Hardwarebeschreibungssprache nicht auch klar umrissene Regeln gibt?
> >
>
> Kann garnicht sehen, daß ich das geschrieben habe, aber man könnte auf die
> Idee kommen. Mein Beispiel ist ja syntaktisch richtig, läßt sich aber
nicht
> implementieren. Der Grund dafür ist eindeutig, daß die Software die
> vorhandenen Lösungen nicht findet. Also hat Falk etwas hardwarenaher
Eieieieieiei.
Ich werde den Verdacht nicht los, dass du entwerder ein Troll oder Träumer
bist.
Akzepties einfach, DU hast von VHDL (noch) keine Ahnung.
DU muss dich VHDL anpassen, nicht anders herum.
DU hast einen Fehler gemacht, nicht der Compiler.
> programmiert und es geht. Das bedeutet in meinen Augen, daß der
> Abstraktionsgrad der Software für diesen Fall nicht weit genug geht. Das
> kann man vorher nicht wissen, denn nirgendwo steht, daß man nicht auf 2
> Flanken in 1 process triggern darf, also sollte man es machen dürfen.
Doch, wenn man die richtigen Bücher bzw. Informationsquellen hat. Lies mal
die Synthesis Guide von XST (der VHDL Compilers im Xilinx ISE) durch, dort
steht ziemlich genau was der Compiler wie interpretiert. Alles andere ist
akademisches Geschwätz.
>
> Kenne mich mit C nicht gut aus, programmiere auch nur sporadisch. Ich weiß
Merkt man. Das qualifiziert dich dann auch besonders gut, über die
(Un)fähigkeit von VHDL Compilern zu urteilen. Tstststst.
> Weil ich das so haben will :-).
Java Programmierer?? Ach ne, Programmier-Philosoph. ;-))
> So richtig klar ist mir der Unterschied zwischen simulierbar und
> synthetisierbar nicht, obwohl ich schon gesehen habe, daß nicht alles in
> Hardware Sinn macht, z.B. wird man ja wohl nicht auf die Idee kommen
können,
> in Hardware einen Text ausgeben zu wollen, ob das Compilieren erfolgreich
> war. Aber was heißt denn "bi-phase"? In einer Parallelmail hab ich die
Warum nicht? Macht jeder uC. Kann man ganz fix mit ner netten kleinen FSM
und nem UART (auch nur ne FSM) machen. Macht VHDL problemlos.
> Schaltung mal gepostet, die ist "bi-phase" und funktioniert trotzdem. Man
Ne, ist sie nicht. Mit "bi-phase" meinte der Poster, dass ein und das selbe
FlipFlop auf beide Flanken triggert. Du hast nur FlipFlops die entweder auf
die fallende oder steigende Flanke reagierten, aber nicht beides zugleich.
> braucht nur einen Clock zu invertieren und wenn man die Lösung vorgibt,
läßt
> sie sich auch implementieren. Wenn man aber nur ein Verhaltensmodell in
VHDL
> vorgibt wird klar, die Entwickler dieser Software haben einfach vergessen,
> diese Optimierungsmöglichkeit mit einzubauen, weil sie sie wahrscheinlich
> nicht kannten oder weil es zu aufwendig ist.
Jaja, erklär uns die Welt.
> Doch, die will ich haben, wieso meinst Du, ich wollte das nicht? Und mit
Weil man damit böse auf die Nase fällt. Vorzugsweise nicht im Labor, sondern
wenn 10000 Geräte nach Sibirien verkauft worden sind. Denn dort ist es kalt,
die ICs werden damit schneller und die bösen Glitches kommen aus ihren
Löchern gekrochen. Und du wirst dann vom Management nach Sibirien geschickt,
um 10000 CPLDs neu zu programmieren. Und wenn du dann dort nach 5 tägiger
Reise mit der Transib angekommen bist wirst du dich fragen, wieso auf
e´deinem Ticket one-way steht???
> Laufzeiten braucht man hier auch nichts zu machen, das sind doch
> Sonderfälle. Allerdings habe ich in meinem VHDL-Beispiel das
Selbstanlaufen
Jaja, eben die in Sibirien.
> weggelassen, damit es einfacher wird.
>
> Wieso ist denn x+1=x?
Weil etwas undefiniertes (x) plus 1 immer noch undefiniert ist.
> Jaaa, da zeigt sich natürlich, wie gut jemand saubere Schaltungen
entwerfen
> kann, solche Dinge wie skew werden dann wichtig, denn auch synchrone
Designs
> reagieren da empfindlich. Undefinierte Zustände sollte man normalerweise
> auch nicht zulassen, sonst kann sich die Statemachine aufhängen. IMHO gibt
> es auch Strategien, um störsichere Statemachines zu entwerfen. Wenn man
das
> zum Beruf hat, sollte man das schon beherrschen.
Gell, genauso wie VHDL??!!
> Ich bin immer noch in der Prä-C-Ära :-), ist IMHO nur für Leute geeignet,
> die sehr viel damit programmieren müssen. Vermutlich gilt für VHDL das
> Gleiche.
Schon möglich. Dann sollten die Schuster (die VHDL nicht besohlen) doch aber
bitte bei ihren Leisten bleiben, oder??.
Dieter Nuhr hat dafür einen wesentlich prägnanteren Satz geprägt, leider
verbietet mir meine Menschfreundlichkeit und (noch vorhandene) Gelassenheit
dessen Zitat ;-))
MfG
Falk
Georg Acher
>kann ich nicht finden, was ist das für 'ne Funktion? Warum in linearer Zeit,
>hat das was mit Echtzeit zu tun?
http://de.wikipedia.org/wiki/Ackermannfunktion
Das ist theoretische Informatik und das Problem, was überhaupt _wie_ mit einem
Computer gemacht werden kann. Die Funktion ist so ziemlich das schlimmste, was
man so berechnen kann. Obwohl das Ding ganz "einfach" ist, gibt es keinen
Compiler, der das automatisch optimieren könnte.
Weitere Stichworte in dem Bereich wären da Berechenbarkeit und NP-Vollständig.
Die VHDL-Synthese und erst recht auch auch die ganz normalen Logik-Optimierungen
fallen in den NP-vollständigen Bereich. Damit sind sie für nicht-triviale Fälle
nur vernünftig mit Heuristiken lösbar, d.h. das Optimum muss (kann...) nicht
immer gefunden werden.
>> rekursive Fibnocci-Zahlen mit function()
> ^
> |
> Fibonacci ;-)
>
>das ist doch 'ne Reihenentwicklung, kann ich mir als Hardwareproblem jetzt
>schwer vorstellen. Das mit der Rekursion erinnert mich an ein
>Pascal-Lehrbuch, in dem sich selbst aufrufende procedures (bis der heap
>platzt) beschrieben wurden. Sowas ist mir in mathematisch-technischen
>Problemstellungen noch nie untergekommen, das geht auch alles einfacher.
a) Ob technisch relevant oder nicht, die Funktion (in der rekursiven Version) ist
nicht in VHDL synthetisierbar, schon gar nicht als Aufruf in einem getakteten
Prozess. Simulieren kann man sie aber problemlos.
b) Es gibt doch auch in der Signalverarbeitung viele Probleme, die zunächst mal
rekursiv sind. Nur weil sowas dem gemeinen Techniker schon immer unsympatisch
war, wurde viel Hirn reingesteckt, um es iterativ zu bekommen. Automatisch geht
das aber (bis auf Spezialfälle) auch nicht.
<...>
>> wait mit Zeitangabe
>>
>
>In VHDL stecken sicher noch einige Fallstricke, die ich noch nicht kenne, es
>muß natürlich auch hardwaremäßig Sinn machen. Ich stelle mir dann eine
>innere Logik im Programm vor, die die Funktion der Hardware widerspruchsfrei
>und realisierbar beschreibt, es muß auch Realisierbarkeitsbedingungen geben.
>Sich selbst aufrufende Logik kann ich mir im Moment überhaupt nicht
>vorstellen, also geht das wahrscheinlich in die Hose. Bei Zeitverzögerungen
>ist es etwas anders, die hab ich schon öfters gebraucht, es gibt da
>Sonderfälle. IMHO bietet das Xilinx nicht an, obwohl es der Router
>eigentlich in Grenzen können müßte.
Das bietet kein Synthesizer an...
>> rumfrickeln, dass Spezialfälle erkannt werden. Die ganze HDL-Synthese ist
>> ein Spezialfall, der nur funktioniert, wenn man sich an gewisse
>> Konverntionen/Schablonen hält.
>
>Du meinst, die Synthese meines VHDL-Beispiels ist prinzipiell unlösbar? Mit
Für _ein_ spezielles Beispiel ist es immer lösbar, allgemein nicht (jedenfalls in
absehbarer Zeit).
>meinem Ansatz sehe ich da aber keine Probleme.
Dein Hirn nicht, aber das Hirn, dass einen Algorithmus entwerfen muss, der das
realisieren soll ;-)
>Jetzt versuche ich doch noch mal etwas zu malen. Die Schaltung hat weder in
>der Timing-Simulation noch in der Hardware-Messung mit Scope Probleme
>gemacht.
<...>
Ja, sieht glitchfrei aus. Aber _das_ aus deiner ursprünglichen VHDL-Beschreibung
rauszudestillieren schätze ich als unmöglich ein.
<...>
>Ich glaube, ich mach auch nochmal 'nen Test mit Foundation FPGA Express,
>aber erst morgen, es ist wieder so spät geworden, muß abbrechen.
Der kann sicher nicht. Dazu habe lange genug damit rumgemacht, der ist
"strunzdumm".
<...>
>Du meinst 'nen Anschluß für Global Reset? Aber nicht rausführen ist doch
>nicht so gut, dann hängt doch 'ne Leitung in der Luft? Bisher hab ich immer
Die wird im xst schon wegoptimiert, wenn es im Toplevel in der Luft hängt. Für
die Fälle, die nach dem Powerup aber was anderes als 0 brauchen, ist es die
einzige Möglichkeit.
>Schematic Entry gemacht, da brauchte man bei Library-Elementen nicht
>unbedingt reset. Nur wenn man ein FF aus Gattern selbst gemacht hatte, ging
>die Simulation ohne Reset nicht.
Auch für normale Simulation ist es gut, da Signale (und damit implizite FFs) nach
dem Start immer 'U' sind. Und 'U'+1 gibt 'X' und nicht '0'...
>Habe ich eingefügt, ändert aber leider nichts.
Hm, schluckt Synopsys hier problemlos. Versuch mal die Variante ohne unsigned
(brauchts eigentlich auch nicht, wenn man nicht rechnen will):
library IEEE;
use IEEE.std_logic_1164.all;
entity x is
port (clk,reset: in std_logic;
out_3: out std_logic
);
end x;
architecture bla of x is
signal qx: std_logic_vector(2 downto 0);
signal qy: std_logic;
begin
process(clk,reset)
begin
if reset='1' then
qx<="001";
elsif rising_edge(clk) then
if qx="100" then
qx<="001";
else
qx<=qx(1 downto 0)&'0';
end if;
end if;
end process;
process(clk,reset)
begin
if reset='1' then
qy<='0';
elsif falling_edge(clk) then
qy<=qx(0);
end if;
end process;
out_3<=qx(0) or qy;
end bla;
Rainer Buchty
>Mein Beispiel ist ja syntaktisch richtig, läßt sich aber nicht
>implementieren. Der Grund dafür ist eindeutig, daß die Software die
>vorhandenen Lösungen nicht findet.
Da wären wir wieder beim Unterschied "simulierbar" versus "synthetisierbar".
Der Synthesizer/Fitter kann nur das umsetzen, was Du ihm beschreibst. Da ist
er genauso dumm wie ein "normaler" Compiler. Nun hat aber die Zielhardware
bestimmte Eigenschaften nicht, die Deine Beschreibung fordert -- also streicht
er die Segel.
Wer den "semantischen Compiler" erfindet, der nicht nur stupide die Syntax
checkt und im Rahmen seiner Möglichkeiten eine Abbildung von einer
hochsprachlichen Beschreibung in eine niedrigere Abstraktionsebene vornimmt,
sondern auch noch in der Lage ist, zu erkennen, was da eigentlich mit gemeint
ist, der wird reich... Unglaublich reich :)
In Deinem Fall müßte der Compiler erkennen, daß hier ein Teiler durch 3
beschrieben wurde und eine adäquate Lösungsmöglichkeit ableiten, die auf die
Hardware paßt.
>Das kann man vorher nicht wissen, denn nirgendwo steht, daß man nicht auf 2
>Flanken in 1 process triggern darf, also sollte man es machen dürfen.
>Demnach finde ich diese Regel schonmal nicht klar.
Klassischer Anfängerfehler, da stolpert vermutlich jeder VHDL-Neuling drüber.
>Kenne mich mit C nicht gut aus, programmiere auch nur sporadisch. Ich weiß
>aber, daß die Typendeklarationen von der Plattform abhängen trotz
>ANSI-Standard. Oder z.B. speichern manche CPUs die Bytes spiegelverkehrt
>zueinander ab wie Motorola und Intel, das kann Probleme machen. Mehr fällt
>mir dazu jetzt nicht ein, aber läßt sich das mit VHDL vergleichen?
Ja. C selbst ist es nämlich erst mal egal, in welcher Byte- oder gar Bit-Order
der Prozessor Daten abspeichert. Oder wie groß denn nun "int" wirklich ist.
Genauso ist es mit VHDL. Die Sprache als solche läßt Dir die Wahl, alles zu
formulieren. Aber Du mußt es dann eben doch so formulieren, daß es zur Hardware
paßt.
>Weil ich das so haben will :-).
Das scheint mir das Grundproblem zu sein :)
>Aber was heißt denn "bi-phase"?
"dual-edge" :)
Auf beiden Taktflanken.
>Man braucht nur einen Clock zu invertieren und wenn man die Lösung vorgibt,
>läßt sie sich auch implementieren.
Ich weiß jetzt nicht, auf welche VHDL-Lösung Du das beziehst; aber wenn man Dein
Schaltbild nimmt, dann besteht die VHDL-Umsetzung eben aus zwei Prozessen:
Prozeß 1 triggert auf CLK (und bedient die rechten beiden D-FFs), Prozeß 2
triggert auf /CLK und bedient das linke D-FF.
>Wieso ist denn x+1=x?
X ist der undefinierte Zustand. Undefiniert +1 ist immer noch undefiniert.
>Ich bin immer noch in der Prä-C-Ära :-), ist IMHO nur für Leute geeignet,
>die sehr viel damit programmieren müssen. Vermutlich gilt für VHDL das
>Gleiche.
Von BASIC her kommend empfand ich C zunächst erst einmal als ein Rückschritt :)
Was VHDL anbelangt, löst man sich hier -- im Vergleich zu einfacheren
Logiksprachen wie ABEL, DSL oder PALASM extrem von der Hardware -- andererseits
darf man eben doch nicht zu losgelöst formulieren und möchte gerade für
effiziente Anpassungen die jeweilige Zielarchitektur im Auge behalten.
Rainer
Winfried Salomon
"Falk Brunner" <Falk.B...@gmx.de> schrieb im Newsbeitrag
news:35t2piF...@individual.net...
[....]
> Akzepties einfach, DU hast von VHDL (noch) keine Ahnung.
> DU muss dich VHDL anpassen, nicht anders herum.
> DU hast einen Fehler gemacht, nicht der Compiler.
>
> > programmiert und es geht. Das bedeutet in meinen Augen, daß der
> > Abstraktionsgrad der Software für diesen Fall nicht weit genug geht. Das
> > kann man vorher nicht wissen, denn nirgendwo steht, daß man nicht auf 2
> > Flanken in 1 process triggern darf, also sollte man es machen dürfen.
>
> Doch, wenn man die richtigen Bücher bzw. Informationsquellen hat. Lies mal
> die Synthesis Guide von XST (der VHDL Compilers im Xilinx ISE) durch, dort
> steht ziemlich genau was der Compiler wie interpretiert. Alles andere ist
> akademisches Geschwätz.
>
Mit der Dokumentation der ISE werde ich mich sicher noch beschäftigen
müssen, mal sehen. Der Grund warum ich in Newsgroups zu diesem Thema
geschrieben habe ist, daß Xilinx im Gegensatz zu sonst bisher keine
Hilfestellung geben konnte und das bei mir den Eindruck erweckt, auf ein
grundsätzliches Problem gestoßen zu sein. Bei Unklarheiten lasse ich
normalerweise auch nicht locker und scheue kontroverse Diskussionen nicht,
aber nun ist das Thema erschöpft. Ich werde mich mal mit den Workarounds
beschäftigen und sicher einiges draus lernen.
> > So richtig klar ist mir der Unterschied zwischen simulierbar und
> > synthetisierbar nicht, obwohl ich schon gesehen habe, daß nicht alles in
> > Hardware Sinn macht, z.B. wird man ja wohl nicht auf die Idee kommen
> können,
> > in Hardware einen Text ausgeben zu wollen, ob das Compilieren
erfolgreich
> > war. Aber was heißt denn "bi-phase"? In einer Parallelmail hab ich die
>
> Warum nicht? Macht jeder uC. Kann man ganz fix mit ner netten kleinen FSM
> und nem UART (auch nur ne FSM) machen. Macht VHDL problemlos.
>
War jetzt ein schlechtes Beispiel, es wird sicher bessere geben.
> > Schaltung mal gepostet, die ist "bi-phase" und funktioniert trotzdem.
Man
>
> Ne, ist sie nicht. Mit "bi-phase" meinte der Poster, dass ein und das
selbe
> FlipFlop auf beide Flanken triggert. Du hast nur FlipFlops die entweder
auf
> die fallende oder steigende Flanke reagierten, aber nicht beides zugleich.
>
Diesen FF-Typ kannte ich noch nicht, wieder ein neuer Gesichtspunkt, macht
offenbar auch Probleme.
[....]
> > Doch, die will ich haben, wieso meinst Du, ich wollte das nicht? Und mit
>
> Weil man damit böse auf die Nase fällt. Vorzugsweise nicht im Labor,
sondern
> wenn 10000 Geräte nach Sibirien verkauft worden sind. Denn dort ist es
kalt,
> die ICs werden damit schneller und die bösen Glitches kommen aus ihren
> Löchern gekrochen. Und du wirst dann vom Management nach Sibirien
geschickt,
> um 10000 CPLDs neu zu programmieren. Und wenn du dann dort nach 5 tägiger
> Reise mit der Transib angekommen bist wirst du dich fragen, wieso auf
> e´deinem Ticket one-way steht???
>
Was meinst Du jetzt? Ich wollte eine selbstanlaufende Schaltung haben, aber
keine Laufzeiten oder Glitches. Das mit den Timing-Constraints ist noch ein
anderes Thema, ein schwieriges, Stichwort sporadische Bitfehler in High
Speed Designs.
> >
> > Wieso ist denn x+1=x?
>
> Weil etwas undefiniertes (x) plus 1 immer noch undefiniert ist.
>
Das mit den 9 verschiedenen logischen Zuständen ist auch wieder so 'ne
gewöhnungsbedürftige Sache.
> > Jaaa, da zeigt sich natürlich, wie gut jemand saubere Schaltungen
> entwerfen
> > kann, solche Dinge wie skew werden dann wichtig, denn auch synchrone
> Designs
> > reagieren da empfindlich. Undefinierte Zustände sollte man normalerweise
> > auch nicht zulassen, sonst kann sich die Statemachine aufhängen. IMHO
gibt
> > es auch Strategien, um störsichere Statemachines zu entwerfen. Wenn man
> das
> > zum Beruf hat, sollte man das schon beherrschen.
>
> Gell, genauso wie VHDL??!!
>
Wenn es ein Anfänger war, ist ja noch Hoffnung.
> > Ich bin immer noch in der Prä-C-Ära :-), ist IMHO nur für Leute
geeignet,
> > die sehr viel damit programmieren müssen. Vermutlich gilt für VHDL das
> > Gleiche.
>
> Schon möglich. Dann sollten die Schuster (die VHDL nicht besohlen) doch
aber
> bitte bei ihren Leisten bleiben, oder??.
Man kommt nicht drum herum, aber gewöhnlich fehlt die Zeit, sich voll auf
eins dieser Themen zu konzentrieren, wird sicher vielen so gehen.
> Dieter Nuhr hat dafür einen wesentlich prägnanteren Satz geprägt, leider
> verbietet mir meine Menschfreundlichkeit und (noch vorhandene)
Gelassenheit
> dessen Zitat ;-))
?? Locker bleiben!
mfg. Winfried
Falk Brunner
> > Reise mit der Transib angekommen bist wirst du dich fragen, wieso auf
> > e´deinem Ticket one-way steht???
> >
>
> Was meinst Du jetzt? Ich wollte eine selbstanlaufende Schaltung haben,
aber
Du schiebst, dass du auch asynchrone Schaltungstricks haben willst. Jemand
anders meinte, dass du davon besser die Finger lassenn solltest, was bei dir
mal wieder auf taube Ohren stiess.
> Das mit den 9 verschiedenen logischen Zuständen ist auch wieder so 'ne
> gewöhnungsbedürftige Sache.
Tja, die Welt ist komplex.
> Man kommt nicht drum herum, aber gewöhnlich fehlt die Zeit, sich voll auf
> eins dieser Themen zu konzentrieren, wird sicher vielen so gehen.
Tja, dann also eine HopHop Lösung und Meckern, wenns nicht geht. Hmmm. . . .
> ?? Locker bleiben!
Nein, das war es nicht ;-)
MfG
Falk
Winfried Salomon
"Rainer Buchty" <buc...@atbode61.informatik.tu-muenchen.de> schrieb im
Newsbeitrag news:ctbsl2$310q1$1...@sunsystem5.informatik.tu-muenchen.de...
> "Winfried Salomon" <wsal...@t-online.de> writes:
> >Mein Beispiel ist ja syntaktisch richtig, läßt sich aber nicht
> >implementieren. Der Grund dafür ist eindeutig, daß die Software die
> >vorhandenen Lösungen nicht findet.
>
> Da wären wir wieder beim Unterschied "simulierbar" versus
"synthetisierbar".
>
> Der Synthesizer/Fitter kann nur das umsetzen, was Du ihm beschreibst. Da
ist
> er genauso dumm wie ein "normaler" Compiler. Nun hat aber die Zielhardware
> bestimmte Eigenschaften nicht, die Deine Beschreibung fordert -- also
streicht
> er die Segel.
>
> Wer den "semantischen Compiler" erfindet, der nicht nur stupide die Syntax
> checkt und im Rahmen seiner Möglichkeiten eine Abbildung von einer
> hochsprachlichen Beschreibung in eine niedrigere Abstraktionsebene
vornimmt,
> sondern auch noch in der Lage ist, zu erkennen, was da eigentlich mit
gemeint
> ist, der wird reich... Unglaublich reich :)
>
so hatte ich das auch bisher gedacht :-), aber man lernt ja nie aus. Ich
könnte mir vorstellen, daß wir es hier mit dem Problem zu tun haben, daß
Informatiker meinetwegen den Compiler bauen, aber nicht wissen wofür
eigentlich. Umgekehrt haben die Ingenieure dann keine Ahnung wie man 'nen
Compiler baut und so sieht das Resultat dann aus. Beides zusammen ist dann
für einen einzigen Menschen zuviel und ich frage mich überhaupt, wie die das
schaffen.
> In Deinem Fall müßte der Compiler erkennen, daß hier ein Teiler durch 3
> beschrieben wurde und eine adäquate Lösungsmöglichkeit ableiten, die auf
die
> Hardware paßt.
>
> >Das kann man vorher nicht wissen, denn nirgendwo steht, daß man nicht auf
2
> >Flanken in 1 process triggern darf, also sollte man es machen dürfen.
> >Demnach finde ich diese Regel schonmal nicht klar.
>
> Klassischer Anfängerfehler, da stolpert vermutlich jeder VHDL-Neuling
drüber.
Wird sicher so sein, ich habe mich nur gewundert, daß keiner (auch Experten
nicht) mit meinem Problem was anfangen konnten und erstmal ratlos dastanden.
Vielleicht ist es aber wirklich etwas ausgefallen. Grade hab ich eine
Antwort von Xilinx bekommen, die ich wohl als abschließend betrachten kann.
Ich hoffe, daß es mir keiner übelnimmt, wenn ich Teile zitiere:
"The main issue in your code is that you are detecting the level of the
clock which is causing problem in the timing simulation. You should be
detecting the edge of the clock. "
[....]
"If you want to see the timing simulation working correctly, you should code
in the same way as the hardware would work. "
Soweit Xilinx. Die erste Aussage betrifft das Fehlen einer Zeile wie
if(clock'event.....
und wie ich schon feststellte, lehnt der Compiler das hier aber ab, was auf
Unverträglichkeint mit VHDL hindeutet. Also ließ ich das ganz weg, weil das
Signal clock in der Sensitivty Liste schon ausreicht, um die Funktion
richtig zu simulieren.
Die zweite Aussage betrifft den strittigen Punkt, warum es nicht
synthetisierbar ist. Da habe ich die Erfahrung machen müssen, daß alle sich
auf die vorhandene Hardware beziehen wollen und ob es darauf umsetzbar ist.
So gesehen ist das bei meinem Beispiel nicht möglich, weil es keine
entsprechende Hardware gibt, die auf beide Flanken triggert. Da habe ich nun
alle gegen mich aufgebracht, weil ich mir unter VHDL etwas zuviel
vorgestellt habe ;-).
>
> >Kenne mich mit C nicht gut aus, programmiere auch nur sporadisch. Ich
weiß
> >aber, daß die Typendeklarationen von der Plattform abhängen trotz
> >ANSI-Standard. Oder z.B. speichern manche CPUs die Bytes spiegelverkehrt
> >zueinander ab wie Motorola und Intel, das kann Probleme machen. Mehr
fällt
> >mir dazu jetzt nicht ein, aber läßt sich das mit VHDL vergleichen?
>
> Ja. C selbst ist es nämlich erst mal egal, in welcher Byte- oder gar
Bit-Order
> der Prozessor Daten abspeichert. Oder wie groß denn nun "int" wirklich
ist.
>
> Genauso ist es mit VHDL. Die Sprache als solche läßt Dir die Wahl, alles
zu
> formulieren. Aber Du mußt es dann eben doch so formulieren, daß es zur
Hardware
> paßt.
>
> >Weil ich das so haben will :-).
>
> Das scheint mir das Grundproblem zu sein :)
>
Man kommt automatisch auf solche Gedanken und wundert sich hinterher, daß es
nicht so ist :-).
> >Aber was heißt denn "bi-phase"?
>
> "dual-edge" :)
>
> Auf beiden Taktflanken.
>
Ist mir neu, daß es solche Bauteile gibt, ist aber in dem CPLD nicht drin.
Kenne wohl zweiflankengesteuerte JK-FFs, die braucht man, um skew-Problemen
aus dem Weg zu gehen, sind aber in den CPLDs und FPGAs nicht drin, wohl zu
teuer oder zu groß. Die gab es früher als TTL-Bauteile (z.B. 74111), werden
aber schon lange nicht mehr produziert. Hat IMHO wohl keiner eingesetzt, was
ein bezeichnendes Licht auf die Anwender wirft.... .
> >Man braucht nur einen Clock zu invertieren und wenn man die Lösung
vorgibt,
> >läßt sie sich auch implementieren.
>
> Ich weiß jetzt nicht, auf welche VHDL-Lösung Du das beziehst; aber wenn
man Dein
> Schaltbild nimmt, dann besteht die VHDL-Umsetzung eben aus zwei Prozessen:
>
> Prozeß 1 triggert auf CLK (und bedient die rechten beiden D-FFs), Prozeß 2
> triggert auf /CLK und bedient das linke D-FF.
>
Ich meinte ganz einfach, die Schaltung als Schematic Entry wie sie ist zu
implementieren, IHMO wird die ja erstmal nach VHDL umgesetzt und trotzdem
geht es. Mit nur 1 process geht es aber nicht, man muß einen Ansatz mit 2
Prozessen schon selber finden.
> >Ich bin immer noch in der Prä-C-Ära :-), ist IMHO nur für Leute geeignet,
> >die sehr viel damit programmieren müssen. Vermutlich gilt für VHDL das
> >Gleiche.
>
> Von BASIC her kommend empfand ich C zunächst erst einmal als ein
Rückschritt :)
>
Ich habe einige Leute kennengelernt, die z.B. in Visual Basic programmieren
anstatt Visual C, vermutlich weil es einfacher ist. Aber ich bin dagegen,
man sollte sich schon auf 1 Sprache einigen. Mit Basic hab ich vor
Ewigkeiten auf meinem 1. "Computer" auch mal angefangen, aber das ist ja zu
nichts compatibel und nicht portabel. Auf DSPs oder Microcontrollern sollte
man besser C machen, Basic (hatten wir auch schon) finde ich da abwegig. Mit
Pascal konnte ich mich nicht anfreunden, ist zum Glück wieder aus der Mode
gekommen, also programmiere ich wie eh und je für mich in Fortran77, das
kriegt man mit GNU kostenlos und kann es auch mit C koppeln. Bin damit weit
schneller als mit C oder Pascal und ist auf allen Plattformen lauffähig. Bin
aber anscheinend weit und breit der einzige, der Fortran kann, hab dafür
aber endlos viel freie (oder auch nicht freie) Software zur Verfügung.
> Was VHDL anbelangt, löst man sich hier -- im Vergleich zu einfacheren
> Logiksprachen wie ABEL, DSL oder PALASM extrem von der Hardware --
andererseits
> darf man eben doch nicht zu losgelöst formulieren und möchte gerade für
> effiziente Anpassungen die jeweilige Zielarchitektur im Auge behalten.
>
Ich kannte noch Kollegen, die hatten die Bits einzeln in die Fuse Matrix
eingehämmert. Ich hoffe ja, daß man bei VHDL da Fortschritte gemacht hat
;-). Jedenfalls machen wir derzeit bei uns die Erfahrung, daß z.B.
automatische VHDL-Codegenerierung und anschließende Optimierung unter
Umständen zu extrem ineffektiven Lösungen führen kann, man muß also
aufpassen und Erfahrungen sammeln.
Winfried
Rainer Buchty
>Ich könnte mir vorstellen, daß wir es hier mit dem Problem zu tun haben, daß
>Informatiker meinetwegen den Compiler bauen, aber nicht wissen wofür
>eigentlich. Umgekehrt haben die Ingenieure dann keine Ahnung wie man 'nen
>Compiler baut und so sieht das Resultat dann aus.
Nö. Georg hat dazu ja schon einiges geschrieben...
"Intuition" und "Begreifen" sind Dinge, die dem Computer extrem fremd sind
und er deshalb -- so es nicht in eine mehr oder minder einfache Formel zu
pressen ist -- auf Heuristiken ausweicht. Greift gar nichts, streicht er
die Segel.
Du kannst z.B. in jeder Sprache Code produzieren, dem Du als Mensch ansiehst,
daß er sich in einer Endlosschleife erhängt. Compiler oder Simulator/Interpreter
werden's jedoch in aller Regel nicht bemerken (können).
>Wird sicher so sein, ich habe mich nur gewundert, daß keiner (auch Experten
>nicht) mit meinem Problem was anfangen konnten und erstmal ratlos dastanden.
Du hättest einfach nur fragen müssen "wie baut man in VHDL einen Teiler durch
3, da wären dann garantiert die zwei prinzipiellen Möglichkeiten gekommen
(Teiler durch 6 bei verdoppeltem Takt bzw. eine der Lösungen von Georg bzw.
Falk).
Stattdessen fingst Du eine Grundsatzdiskussion an, wo man dann nicht so recht
wußte, was denn nun eigentlich Dein Problem war.
>"The main issue in your code is that you are detecting the level of the
>clock which is causing problem in the timing simulation. You should be
>detecting the edge of the clock. "
>[....]
>"If you want to see the timing simulation working correctly, you should code
>in the same way as the hardware would work. "
Beide Antworten kennst Du ja auch von hier :)
>Die zweite Aussage betrifft den strittigen Punkt, warum es nicht
>synthetisierbar ist.
Der Punkt ist nicht strittig, der ist definitiv und wurde mehrfach erläutert.
>Ist mir neu, daß es solche Bauteile gibt, ist aber in dem CPLD nicht drin.
Ist auch relativ exotisch. In den Mach5 CPLDs gab's "dual edge" Clocking, was
auch extra als neues Sprachkonstrukt damals in DSL eingeführt wurde.
Daß die CoolRunner das auch können, habe ich hier im Thread erfahren; die hatte
ich mir allerdings auch noch nie angesehen.
>Ich meinte ganz einfach, die Schaltung als Schematic Entry wie sie ist zu
>implementieren
Das sollte gehen. Schematic Entry ist ja (zumindest auf diesem Level)
gleichzusetzen mit flachgeklopften Gleichungen.
>IHMO wird die ja erstmal nach VHDL umgesetzt und trotzdem geht es.
Ja, weil *die* Richtung immer einfach ist. Da wird dann auch entsprechend
flacher Coder erzeugt (wenn man überhaupt VHDL erzeugt und nicht gleich auf
die verwendete Zwischenrepräsentation geht).
Für VHDL würde da der Generator garantiert zwei Prozesse ausspucken, nämlich
für jede Clock-Domain eine.
>Ich habe einige Leute kennengelernt, die z.B. in Visual Basic programmieren
>anstatt Visual C, vermutlich weil es einfacher ist. Aber ich bin dagegen,
>man sollte sich schon auf 1 Sprache einigen.
Oh, Visual* war schon gewissermaßen nach meiner Zeit.
Bei mir fand die Infektion durch einen Sharp MZ80K statt, als "Zweitsprache"
folgte dann bald 6502-Assembler auf einem Rockwell AIM65.
Daß man sich auf eine Sprache einigen sollte, würde ich so nicht unterschreiben.
Man nimmt die Sprache, mit der die Aufgabe am besten zu lösen ist.
>Mit Basic hab ich vor Ewigkeiten auf meinem 1. "Computer" auch mal angefangen,
>aber das ist ja zu nichts compatibel und nicht portabel.
Och, spätestens wenn man systemspezifische Geschichten einbindet, hat sich das
auch mit der Portabilität von C und man muß ebenfalls wieder -- teils massiv --
Hand anlegen. Eine Windows-Anwendung ist auch zu nichts außer sich selbst
kompatibel und sträubt sich bisweilen sehr gegen eine Portierung auf andere
Plattformen.
Da ist ein BASIC-Programm teilweise noch richtig schnell mit einem automatischen
Übersetzer auf einen anderen BASIC-Dialekt gehoben.
>Mit Pascal konnte ich mich nicht anfreunden
VHDL ist ähnlich geschwätzig wie Pascal.
>Ich kannte noch Kollegen, die hatten die Bits einzeln in die Fuse Matrix
>eingehämmert.
Ja, damit wurden wir im Grundstudium, auch in Klausuren, ebenfalls noch
konfrontiert. Aus großer Gleichung via KV sowohl DNF wie KNF erzeugen und
dann das PAL von Hand stanzen.
Wobei die Erfahrung sicher nicht schlecht ist (genauso wie mal einen KV von
Hand durchgemacht zu haben), so daß man wengistens ansatzweise ein Gefühl
dafür bekommt, was da eigentlich unter der Haube passiert.
Ebenso würde ich Informatikstudenten ein Semester Assemblerprogrammierung
unter verschärften Bedingungen (z.B. nur 1k Hauptspeicher, der aber auch als
Bildschirmspeicher mitgenutzt wird, auf einer 3.5MHz CPU) verordnen, damit
sich das "die nächste Generation von Prozessoren und etwas mehr Hauptspeicher
werden's schon richten" gar nicht erst einschleift.
>Ich hoffe ja, daß man bei VHDL da Fortschritte gemacht hat ;-)
VHDL ist eine Sprache. Die macht diesbezüglich keine Fortschritte.
Was Fortschritte macht, sind Synthesizer und Fitter -- entsprechend anderen
Programmiersprachen, da evolviert der Compiler, die Sprache auch nur in
Ausnahmefällen.
Rainer
Winfried Salomon
"Georg Acher" <ac...@in.tum.de> schrieb im Newsbeitrag
news:ctbrog$46v$1...@wsc10.lrz-muenchen.de...
> "Winfried Salomon" <wsal...@t-online.de> writes:
>
> >kann ich nicht finden, was ist das für 'ne Funktion? Warum in linearer
Zeit,
> >hat das was mit Echtzeit zu tun?
>
> http://de.wikipedia.org/wiki/Ackermannfunktion
>
> Das ist theoretische Informatik und das Problem, was überhaupt _wie_ mit
einem
> Computer gemacht werden kann. Die Funktion ist so ziemlich das schlimmste,
was
> man so berechnen kann. Obwohl das Ding ganz "einfach" ist, gibt es keinen
> Compiler, der das automatisch optimieren könnte.
>
schwere Kost :-(, von der Informatik bin ich meilenweit entfernt.
> Weitere Stichworte in dem Bereich wären da Berechenbarkeit und
NP-Vollständig.
> Die VHDL-Synthese und erst recht auch auch die ganz normalen
Logik-Optimierungen
> fallen in den NP-vollständigen Bereich. Damit sind sie für nicht-triviale
Fälle
> nur vernünftig mit Heuristiken lösbar, d.h. das Optimum muss (kann...)
nicht
> immer gefunden werden.
>
Hätte nicht gedacht, daß mein einfaches Beispiel zu solchen Komplikationen
führt. Wenn man die Ausnahmen kennt, kann man vielleicht Musteransätze
einfügen.
[....]
> a) Ob technisch relevant oder nicht, die Funktion (in der rekursiven
Version) ist
> nicht in VHDL synthetisierbar, schon gar nicht als Aufruf in einem
getakteten
> Prozess. Simulieren kann man sie aber problemlos.
>
> b) Es gibt doch auch in der Signalverarbeitung viele Probleme, die
zunächst mal
> rekursiv sind. Nur weil sowas dem gemeinen Techniker schon immer
unsympatisch
> war, wurde viel Hirn reingesteckt, um es iterativ zu bekommen. Automatisch
geht
> das aber (bis auf Spezialfälle) auch nicht.
>
Mir fallen jetzt nur rekursive Filter ein, da gibt's wieder Gesichtspunkte,
die den Rahmen hier sprengen, aber die sind hier vermutlich nicht gemeint.
Wenn man aber eine rekursive Berechnung in VHDL durchführen möchte, scheint
das demnach technisch nicht realisierbar zu sein. Ich weiß nicht, was der
Core-Generator da alles enthält, man ist ja froh, daß fertige Lösungen
angeboten werden, die man selbst vielleicht kaum schaffen kann.
[....]
> >Du meinst, die Synthese meines VHDL-Beispiels ist prinzipiell unlösbar?
Mit
>
> Für _ein_ spezielles Beispiel ist es immer lösbar, allgemein nicht
(jedenfalls in
> absehbarer Zeit).
>
> >meinem Ansatz sehe ich da aber keine Probleme.
>
> Dein Hirn nicht, aber das Hirn, dass einen Algorithmus entwerfen muss, der
das
> realisieren soll ;-)
>
Bin ja froh, daß man den Menschen noch nicht ersetzen kann :-). Das war ja
der Grund meines Einwurfs, den ich anfangs gemacht hatte.
> >Jetzt versuche ich doch noch mal etwas zu malen. Die Schaltung hat weder
in
> >der Timing-Simulation noch in der Hardware-Messung mit Scope Probleme
> >gemacht.
> <...>
>
> Ja, sieht glitchfrei aus. Aber _das_ aus deiner ursprünglichen
VHDL-Beschreibung
> rauszudestillieren schätze ich als unmöglich ein.
>
Das Synthese-Tool müßte diesen Ansatz mit berücksichtigen. Aber es gibt noch
einen Ansatz von Xilinx selbst:
http://www.xilinx.com/xcell/xl33/xl33_30.pdf
Dort wird nicht der Clock invertiert, sondern statt dessen 1 RS-FF genommen,
geht auch. Vielleicht gibt es noch mehr Möglichkeiten, wobei mir meine
Lösung bisher am besten gefällt ;-).
> <...>
> >Ich glaube, ich mach auch nochmal 'nen Test mit Foundation FPGA Express,
> >aber erst morgen, es ist wieder so spät geworden, muß abbrechen.
>
> Der kann sicher nicht. Dazu habe lange genug damit rumgemacht, der ist
> "strunzdumm".
>
So ist es leider, nicht mal die functional Simulation geht da, bringt also
nichts.
[....]
> >Schematic Entry gemacht, da brauchte man bei Library-Elementen nicht
> >unbedingt reset. Nur wenn man ein FF aus Gattern selbst gemacht hatte,
ging
> >die Simulation ohne Reset nicht.
>
> Auch für normale Simulation ist es gut, da Signale (und damit implizite
FFs) nach
> dem Start immer 'U' sind. Und 'U'+1 gibt 'X' und nicht '0'...
>
Ist mir schon aufgefallen, führt immer mal wieder zur Verwirrung. Mit dem
ModelSim richtig umzugehen, will auch gelernt sein.
Ok, diesmal funktioniert es, vielen Dank für die Mühe! Diese VHDL-Lösung hat
laut RTL-Viewer sogar nur 4 D-FFs, wobei 1 clock doch tatsächlich invertiert
wird. So, dann werde ich mir jetzt mal die Musterlösungen ansehen und hoffe,
daß mir alles klar wird.
Winfried
Winfried Salomon
"Falk Brunner" <Falk.B...@gmx.de> schrieb im Newsbeitrag
news:35vdniF...@individual.net...
>
> "Winfried Salomon" <wsal...@t-online.de> schrieb im Newsbeitrag
> news:ctbvgd$t83$03$1...@news.t-online.com...
>
> > > Reise mit der Transib angekommen bist wirst du dich fragen, wieso auf
> > > e´deinem Ticket one-way steht???
> > >
> >
> > Was meinst Du jetzt? Ich wollte eine selbstanlaufende Schaltung haben,
> aber
>
> Du schiebst, dass du auch asynchrone Schaltungstricks haben willst. Jemand
> anders meinte, dass du davon besser die Finger lassenn solltest, was bei
dir
> mal wieder auf taube Ohren stiess.
>
Muß ein Mißverständnis sein, denn es entspricht nicht meiner Meinung, ich
meinte eine selbstanlaufende Schaltung. Der Mailbaum ist schon recht
unübersichtlich geworden.
[....]
> > Man kommt nicht drum herum, aber gewöhnlich fehlt die Zeit, sich voll
auf
> > eins dieser Themen zu konzentrieren, wird sicher vielen so gehen.
>
> Tja, dann also eine HopHop Lösung und Meckern, wenns nicht geht. Hmmm. . .
.
>
So eindeutig und einfach ist die Sache ja nicht, sogar die Hotline war
erstmal platt.
> > ?? Locker bleiben!
>
> Nein, das war es nicht ;-)
>
Hab ich nicht verstanden....
mfg Winfried
Winfried Salomon
"Rainer Buchty" <buc...@atbode61.informatik.tu-muenchen.de> schrieb im
Newsbeitrag news:ctenmr$31sg2$1...@sunsystem5.informatik.tu-muenchen.de...
> "Winfried Salomon" <wsal...@t-online.de> writes:
> >Ich könnte mir vorstellen, daß wir es hier mit dem Problem zu tun haben,
daß
> >Informatiker meinetwegen den Compiler bauen, aber nicht wissen wofür
> >eigentlich. Umgekehrt haben die Ingenieure dann keine Ahnung wie man 'nen
> >Compiler baut und so sieht das Resultat dann aus.
>
> Nö. Georg hat dazu ja schon einiges geschrieben...
>
Informatik ist nicht mein Gebiet, laß ich mal lieber.
> "Intuition" und "Begreifen" sind Dinge, die dem Computer extrem fremd sind
> und er deshalb -- so es nicht in eine mehr oder minder einfache Formel zu
> pressen ist -- auf Heuristiken ausweicht. Greift gar nichts, streicht er
> die Segel.
>
> Du kannst z.B. in jeder Sprache Code produzieren, dem Du als Mensch
ansiehst,
> daß er sich in einer Endlosschleife erhängt. Compiler oder
Simulator/Interpreter
> werden's jedoch in aller Regel nicht bemerken (können).
>
Ist schon klar, passiert einem auch schon mal. Nur scheint das ohne
Vorkenntnisse wohl nicht ganz vermeidbar zu sein. Letztens wollte ich einen
Up-Down Counter mit 2 unabhängigen Takten programmieren in 1 process, jedoch
wurde mir dann schnell klar, daß das nicht geht. Zum Glück ist mir ein
Workaround eingefallen.
> >Wird sicher so sein, ich habe mich nur gewundert, daß keiner (auch
Experten
> >nicht) mit meinem Problem was anfangen konnten und erstmal ratlos
dastanden.
>
> Du hättest einfach nur fragen müssen "wie baut man in VHDL einen Teiler
durch
> 3, da wären dann garantiert die zwei prinzipiellen Möglichkeiten gekommen
> (Teiler durch 6 bei verdoppeltem Takt bzw. eine der Lösungen von Georg
bzw.
> Falk).
>
Ich hatte das Problem woanders gesehen, nämlich auf 2 Flanken in 1 process
zu triggern. Dazu ist der Teiler nicht notwendig. Vielleicht hätte ich das
Problem mehr auf den Kern reduzieren sollen, z.B. einen Zähler zu bauen der
einfach nur Flanken zählt, steigende und fallende. Die Leute haben manchmal
verschiedene Perspektiven, so ist das im real life, passiert mir öfters.
> Stattdessen fingst Du eine Grundsatzdiskussion an, wo man dann nicht so
recht
> wußte, was denn nun eigentlich Dein Problem war.
>
Das war ursprünglich nicht meine Absicht, hat sich so ergeben. Wenn man in
Newsgroups schreibt, kann es manchmal ganz unerwartete Entwicklungen geben,
ist mir nicht neu. Eigentlich wollte ich nur vor dem unkritischen Einsatz
von VHDL warnen und sagen, daß man selbst die Fähigkeit behalten sollte,
Probleme ohne Computer lösen zu können. Mein Beispiel bestätigt auch eher
meine Meinung, auch wenn es etwas ausgefallen ist.
Sonst suchen die Leute bei solchen Problemen beim Hersteller nur noch nach
Applikation Notes (vermutlich ist es jetzt schon so) und wenn keine da sind,
ist es vorbei. Das beschränke ich nicht auf den Entwurf digitaler
Schaltungen.
> >"The main issue in your code is that you are detecting the level of the
> >clock which is causing problem in the timing simulation. You should be
> >detecting the edge of the clock. "
> >[....]
> >"If you want to see the timing simulation working correctly, you should
code
> >in the same way as the hardware would work. "
>
> Beide Antworten kennst Du ja auch von hier :)
Kamen etwas verspätet, nachdem schon alles vorbei war.
>
> >Die zweite Aussage betrifft den strittigen Punkt, warum es nicht
> >synthetisierbar ist.
>
> Der Punkt ist nicht strittig, der ist definitiv und wurde mehrfach
erläutert.
>
Also gut, strittig war :-), schließlich habe ich ja was dazugelernt.
> >Ist mir neu, daß es solche Bauteile gibt, ist aber in dem CPLD nicht
drin.
>
> Ist auch relativ exotisch. In den Mach5 CPLDs gab's "dual edge" Clocking,
was
> auch extra als neues Sprachkonstrukt damals in DSL eingeführt wurde.
>
> Daß die CoolRunner das auch können, habe ich hier im Thread erfahren; die
hatte
> ich mir allerdings auch noch nie angesehen.
>
Hab ich jetzt interessehalber mal ausprobiert, laut Datenblatt können die
tatsächlich auf beiden Flanken triggern. Bin bis zur Post Fit Simulation
gekommen, aber die sieht einfach furchtbar aus. Diesmal kommen tatsächlich
zuerst grüne Kurven mit logischen Pegeln, aber was für welche! Ich hab einen
Frequenzmultiplizierer * 3 erfunden, ohne PLL! :-) Spaß beiseite, es geht da
auch nicht, im RTL-Viewer sieht man auch gleich, daß es Unsinn ist, auch mit
Coolrunner II geht die Synthese nicht, sicher aus den bekannten Gründen.
> >Ich meinte ganz einfach, die Schaltung als Schematic Entry wie sie ist zu
> >implementieren
>
> Das sollte gehen. Schematic Entry ist ja (zumindest auf diesem Level)
> gleichzusetzen mit flachgeklopften Gleichungen.
>
> >IHMO wird die ja erstmal nach VHDL umgesetzt und trotzdem geht es.
>
> Ja, weil *die* Richtung immer einfach ist. Da wird dann auch entsprechend
> flacher Coder erzeugt (wenn man überhaupt VHDL erzeugt und nicht gleich
auf
> die verwendete Zwischenrepräsentation geht).
>
> Für VHDL würde da der Generator garantiert zwei Prozesse ausspucken,
nämlich
> für jede Clock-Domain eine.
>
Vielleicht sogar 3 für jedes D-FF? Im RTL-Viewer kommt als Voroptimierung
dieselbe Schaltung raus und wie man den erzeugten VHDL-Code anzeigen kann,
habe ich bei der ISE noch nicht herausgefunden.
> >Ich habe einige Leute kennengelernt, die z.B. in Visual Basic
programmieren
> >anstatt Visual C, vermutlich weil es einfacher ist. Aber ich bin dagegen,
> >man sollte sich schon auf 1 Sprache einigen.
>
> Oh, Visual* war schon gewissermaßen nach meiner Zeit.
>
Wieso, Du wirkst doch noch ganz munter :-).
> Bei mir fand die Infektion durch einen Sharp MZ80K statt, als
"Zweitsprache"
> folgte dann bald 6502-Assembler auf einem Rockwell AIM65.
>
> Daß man sich auf eine Sprache einigen sollte, würde ich so nicht
unterschreiben.
> Man nimmt die Sprache, mit der die Aufgabe am besten zu lösen ist.
>
Ok, das muß jeder selbst abwägen. Für handoptimierten Code nimmt man besser
Assembler, weil die Optimizer in C dann doch nicht so optimal sind, das
scheint mir mit dem VHDL-Problem verwandt zu sein. Bei uns ist mal was mit
DSPs in C gemacht wurden, wir hatten dann diese Vermutung.
> >Mit Basic hab ich vor Ewigkeiten auf meinem 1. "Computer" auch mal
angefangen,
> >aber das ist ja zu nichts compatibel und nicht portabel.
>
> Och, spätestens wenn man systemspezifische Geschichten einbindet, hat sich
das
> auch mit der Portabilität von C und man muß ebenfalls wieder -- teils
massiv --
> Hand anlegen. Eine Windows-Anwendung ist auch zu nichts außer sich selbst
> kompatibel und sträubt sich bisweilen sehr gegen eine Portierung auf
andere
> Plattformen.
>
Das ist natürlich klar, deshalb benutze ich auch derzeit gerne GNU-Compiler,
da gibt's sogar für Mikrocontroller was. Das sind aber einfache
Konsolenprogramme, was Windows-Anwendungen betrifft, mit dem Moloch möchte
ich mich nicht gern ohne Grund rumschlagen, da kann man IMHO nur
Insellösungen produzieren. Und was GNU-Fortran betrifft, ich kann sogar
Solaris-Programme unter Windows laufenlassen, mit kleinen Anpassungen
natürlich, oder meine alten Atari-Programme, da wirkt sich die Portabilität
sehr erfreulich aus.
> Da ist ein BASIC-Programm teilweise noch richtig schnell mit einem
automatischen
> Übersetzer auf einen anderen BASIC-Dialekt gehoben.
>
> >Mit Pascal konnte ich mich nicht anfreunden
>
> VHDL ist ähnlich geschwätzig wie Pascal.
>
Hab die Ähnlichkeit bemerkt.
> >Ich kannte noch Kollegen, die hatten die Bits einzeln in die Fuse Matrix
> >eingehämmert.
>
> Ja, damit wurden wir im Grundstudium, auch in Klausuren, ebenfalls noch
> konfrontiert. Aus großer Gleichung via KV sowohl DNF wie KNF erzeugen und
> dann das PAL von Hand stanzen.
>
> Wobei die Erfahrung sicher nicht schlecht ist (genauso wie mal einen KV
von
> Hand durchgemacht zu haben), so daß man wengistens ansatzweise ein Gefühl
> dafür bekommt, was da eigentlich unter der Haube passiert.
>
Wird auch heute noch gemacht, wobei ich das mit der KV-Minimierung noch für
wichtiger halte, denn die technische Umsetzung ändert sich mit der Zeit.
> Ebenso würde ich Informatikstudenten ein Semester Assemblerprogrammierung
> unter verschärften Bedingungen (z.B. nur 1k Hauptspeicher, der aber auch
als
> Bildschirmspeicher mitgenutzt wird, auf einer 3.5MHz CPU) verordnen, damit
> sich das "die nächste Generation von Prozessoren und etwas mehr
Hauptspeicher
> werden's schon richten" gar nicht erst einschleift.
>
Keine Ahnung, was in Informatik gemacht wird, wird aber als Fach heutzutage
auch in der Elektrotechnik behandelt. Ja, früher hat man wirklich jedes Bit
eingespart, die heutigen Werkzeuge scheinen das nicht unbedingt zu
unterstützen.
> >Ich hoffe ja, daß man bei VHDL da Fortschritte gemacht hat ;-)
>
> VHDL ist eine Sprache. Die macht diesbezüglich keine Fortschritte.
>
> Was Fortschritte macht, sind Synthesizer und Fitter -- entsprechend
anderen
> Programmiersprachen, da evolviert der Compiler, die Sprache auch nur in
> Ausnahmefällen.
>
Hoffen wir mal das Beste.
Winfried