Schaltungsminimierung mit KV-Diagramm

"Rainer Buchty" schrieb im Newsbeitrag news:ctaj7m$30h89$ snipped-for-privacy@sunsystem5.informatik.tu-muenchen.de...

oft

die

Keine Ahnung, meist wirds aber wohl Software sein (Wenn nicht mal wieder State Machines undicht sind und alle Takte sauber sind)

MfG Falk

Reply to
Falk Brunner
Loading thread data ...

Hallo Rainer,

"Ra> >wenn ich mich recht erinnere, muß man erstmal das Betriebssystem fragen,

ob

offenbar

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.

Du

Zielplattform so

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?

etwas

Weil ich das so haben will :-).

clocking

an

den

und

tun,

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.

anlaufen.

Anfangszustand

in der

(C)PLDs

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

sich,

Schaltung

Konkurrenz-PLD, sei

und

selbst

schön

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.

mich

wieso C

weil

Hochsprache

erwartet

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

Reply to
Winfried Salomon

"Winfried Salomon" schrieb im Newsbeitrag news:ctbfbl$l8g$04$ snipped-for-privacy@news.t-online.com...

nicht

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.

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.

Merkt man. Das qualifiziert dich dann auch besonders gut, über die (Un)fähigkeit von VHDL Compilern zu urteilen. Tstststst.

Java Programmierer?? Ach ne, Programmier-Philosoph. ;-))

können,

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.

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.

läßt

VHDL

Jaja, erklär uns die Welt.

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

Selbstanlaufen

Jaja, eben die in Sibirien.

Weil etwas undefiniertes (x) plus 1 immer noch undefiniert ist.

entwerfen

Designs

das

Gell, genauso wie VHDL??!!

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

Reply to
Falk Brunner

formatting link

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.

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.

Das bietet kein Synthesizer an...

Für _ein_ spezielles Beispiel ist es immer lösbar, allgemein nicht (jedenfalls in absehbarer Zeit).

Dein Hirn nicht, aber das Hirn, dass einen Algorithmus entwerfen muss, der das realisieren soll ;-)

Ja, sieht glitchfrei aus. Aber _das_ aus deiner ursprünglichen VHDL-Beschreibung rauszudestillieren schätze ich als unmöglich ein.

Der kann sicher nicht. Dazu habe lange genug damit rumgemacht, der ist "strunzdumm".

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.

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

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

Reply to
Georg Acher

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.

Klassischer Anfängerfehler, da stolpert vermutlich jeder VHDL-Neuling drüber.

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.

Das scheint mir das Grundproblem zu sein :)

"dual-edge" :)

Auf beiden Taktflanken.

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.

X ist der undefinierte Zustand. Undefiniert +1 ist immer noch undefiniert.

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

Reply to
Rainer Buchty

Hallo Falk,

"Falk Brunner" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

[....]

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.

erfolgreich

War jetzt ein schlechtes Beispiel, es wird sicher bessere geben.

Man

selbe

auf

Diesen FF-Typ kannte ich noch nicht, wieder ein neuer Gesichtspunkt, macht offenbar auch Probleme.

[....]

sondern

kalt,

geschickt,

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.

Das mit den 9 verschiedenen logischen Zuständen ist auch wieder so 'ne gewöhnungsbedürftige Sache.

gibt

Wenn es ein Anfänger war, ist ja noch Hoffnung.

geeignet,

aber

Man kommt nicht drum herum, aber gewöhnlich fehlt die Zeit, sich voll auf eins dieser Themen zu konzentrieren, wird sicher vielen so gehen.

Gelassenheit

?? Locker bleiben!

mfg. Winfried

Reply to
Winfried Salomon

"Winfried Salomon" schrieb im Newsbeitrag news:ctbvgd$t83$03$ snipped-for-privacy@news.t-online.com...

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.

Tja, die Welt ist komplex.

Tja, dann also eine HopHop Lösung und Meckern, wenns nicht geht. Hmmm. . . .

Nein, das war es nicht ;-)

MfG Falk

Reply to
Falk Brunner

Hallo Rainer,

"Ra> >Mein Beispiel ist ja syntaktisch richtig, läßt sich aber nicht

"synthetisierbar".

ist

streicht

vornimmt,

gemeint

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.

die

2

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

weiß

fällt

Bit-Order

ist.

zu

Hardware

Man kommt automatisch auf solche Gedanken und wundert sich hinterher, daß es nicht so ist :-).

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

vorgibt,

man Dein

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.

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.

andererseits

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

Reply to
Winfried Salomon

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

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.

Beide Antworten kennst Du ja auch von hier :)

Der Punkt ist nicht strittig, der ist definitiv und wurde mehrfach erläutert.

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.

Das sollte gehen. Schematic Entry ist ja (zumindest auf diesem Level) gleichzusetzen mit flachgeklopften Gleichungen.

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.

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.

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.

VHDL ist ähnlich geschwätzig wie Pascal.

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.

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

Reply to
Rainer Buchty

Hallo Georg,

"Georg Acher" schrieb im Newsbeitrag news:ctbrog$46v$ snipped-for-privacy@wsc10.lrz-muenchen.de...

Zeit,

einem

was

schwere Kost :-(, von der Informatik bin ich meilenweit entfernt.

NP-Vollständig.

Logik-Optimierungen

Fälle

nicht

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.

[....]

Version) ist

getakteten

zunächst mal

unsympatisch

geht

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.

[....]

Mit

(jedenfalls in

das

Bin ja froh, daß man den Menschen noch nicht ersetzen kann :-). Das war ja der Grund meines Einwurfs, den ich anfangs gemacht hatte.

in

VHDL-Beschreibung

Das Synthese-Tool müßte diesen Ansatz mit berücksichtigen. Aber es gibt noch einen Ansatz von Xilinx selbst:

formatting link
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 ;-).

So ist es leider, nicht mal die functional Simulation geht da, bringt also nichts.

[....]

ging

FFs) nach

Ist mir schon aufgefallen, führt immer mal wieder zur Verwirrung. Mit dem ModelSim richtig umzugehen, will auch gelernt sein.

unsigned

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

Reply to
Winfried Salomon

Hallo Falk,

"Falk Brunner" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

dir

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.

[....]

auf

.

So eindeutig und einfach ist die Sache ja nicht, sogar die Hotline war erstmal platt.

Hab ich nicht verstanden....

mfg Winfried

Reply to
Winfried Salomon

Hallo Rainer,

"Ra> >Ich könnte mir vorstellen, daß wir es hier mit dem Problem zu tun haben,

daß

Informatik ist nicht mein Gebiet, laß ich mal lieber.

ansiehst,

Simulator/Interpreter

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.

Experten

dastanden.

durch

bzw.

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.

recht

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.

code

Kamen etwas verspätet, nachdem schon alles vorbei war.

erläutert.

Also gut, strittig war :-), schließlich habe ich ja was dazugelernt.

drin.

was

hatte

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.

auf

nämlich

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.

programmieren

Wieso, Du wirkst doch noch ganz munter :-).

"Zweitsprache"

unterschreiben.

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.

angefangen,

das

massiv --

andere

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.

automatischen

Hab die Ähnlichkeit bemerkt.

von

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.

als

Hauptspeicher

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.

anderen

Hoffen wir mal das Beste.

Winfried

Reply to
Winfried Salomon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.