Ich bin dabei ein einfaches Lauflicht-Demo zu variieren. Dafür wollte ich eine der Tasten (T#1) nehmen, um die Richtung des Lauflichtes umzukehren. T#0 macht reset (muss man derzeit am Anfang auch noch machen, automatisches init fkt. auch noch nicht). Das Lauflicht verwendet dann LED 0..6 ('led') LED 7 ('bulp') will ich verwenden, um den Umschalt-Taster zu verifizieren, bevor er wirklich die Richtungsumkehr macht. Das Problem derzeit ist: Wenn ich T#1 drücke, dann wird die Richtung nur manchmal umgekehrt, aber nicht immer. Das liegt daran, dass ich keine "Flankensteuerung"(?) drin habe. Der Prozess, der T#1 behandelt, schaltet die Richtung permanent um. Je nachdem wann ich T#1 loslasse, erwische ich dann die Richtungsumkehr - oder auch nicht. Ich wollte mit dem T#1 ein asynchronen T-FlipFlop ansteuern und dann dessen Ausgang verwenden, um die Richtung des Lauflichtes umzudrehen. Vorher soll erst mal über T#1 nur die LED7 ('bulp') getoggelt werden. Klappt aber nicht - XST meckert, dass ich versuche mit "nicht-zulässigen" 1bit latches zu arbeiten(?)
Frank Bergemann schrieb: > > Ich wollte mit dem T#1 ein asynchronen T-FlipFlop ansteuern und dann > dessen Ausgang verwenden, um die Richtung des Lauflichtes umzudrehen. Genau der falsche Ansatz. Stichworte: Einsynchronisiereung asynchroner Signale, Flankenerkennung, eventuell Entprellung des Tasters (falls nicht schon in HW auf dem Evalboard) Hier gibt es viele Beispiele und Erklärung warum und wie so etwas gemacht wird: http://www.lothar-miller.de/s9y/
Dsnke für den link! - jetzt geht's schon mal besser. Ich muss allerdings noch aufräumen - ganz sauber ist das noch nicht.
ein bisschen aufgeräumt und mit Lauflicht speed-up/speed-down über die verbleibenden beiden Tasten des nexys-2. Fehlt noch die Initialisierung ohne Button #0 (Reset)...
Frank Bergemann schrieb: > ein bisschen aufgeräumt und mit Lauflicht speed-up/speed-down über die > verbleibenden beiden Tasten des nexys-2. > Fehlt noch die Initialisierung ohne Button #0 (Reset)... Lies mal auf Lothar Seite nach, was er über ein asynchrones Reset zu sagen hat. Behandle dein Reset genauso wie deine anderen Buttons.
Der Reset läuft jetzt nach dem gleich Muster. Da ist aber immer noch ein bißchen "Ballast" drin.
Frank Bergemann schrieb: > Der Reset läuft jetzt nach dem gleich Muster. > Da ist aber immer noch ein bißchen "Ballast" drin. Du verwendest unötigerweise 4 Processe. Den ersten zum einsyncen würde ich getrennt halltem aber die anderen 3 in einem zusammenfassen. Dann kann man auch count_next und led_next einsparen. Aber wir sind jetzt im Minenfeld der persöhnlichen Prereferenzen :-)
Frank Bergemann schrieb: > Da ist aber immer noch ein bißchen "Ballast" drin. Ich unterstelle auch mal, dass das mit dem Speed noch nicht so ganz lupenrein ist, oder habe ich etwas übersehen? Du schiebst zum Verändern der Geschwindigkeit ja nur das speed_reg hin hin und her. Also Multiplikation bzw. Division mit 2. Was passiert aber, wenn du jetzt öfter einen der beiden Taster drückst? z.B. 32 mal? :-)
Lattice User schrieb: > kann man auch count_next und led_next einsparen. Ich würde auch sagen, das sind Leichen der ursprünglichen Zwei-Prozess-Schreibweise, wo diesen Signalen kombinatorisch der nächste Wert zugewiesen wurde.
:
Bearbeitet durch Moderator
@Schlumpf: Dann sind die bits "weg" :-) Ich werde das mal durch srl und sll ersetzen und dafür die oberen und untere Grenze vernünftig setzen. Das Register kann dann verkleinert werden (trailing #0's für unbrauchbare Wartezeiten kann man weglassen). Ich brauch dann auch nur 1Bit zu setzen und nicht so ein kryptisches Bit-Muster das vom urspr. Initialwert #25000000 stammt. Und dann verringere ich bei der Gelegenheit gleich die Anzahl der Process'e. Als nächstes werde ich dann mal einen Counter für die Durchläufe (vorwärts/rückwärts incr/desr) einbauen und auf LED ausgeben. Wenn ich das dann separieren will - in getrennte Dateien: Kann ich z.B. verschiedene Process'e einer 'entity' in separate vhd files packen? Oder müssen in verschiedenen Dateien verschiedene 'entity's beschrieben werden? (Und falls letzteres: wie kann ich eine Kommunikation zwischen verschiedenen 'entity's beschreiben?)
:
Bearbeitet durch User
Frank Bergemann schrieb: > Ich werde das mal durch srl und sll ersetzen Tu dir das bitte nicht an ;-)
kurze Zwischenfrage: Ich hab' ein separates anderes mini-vhdl für die 7-Segment-Anzeige gemacht - funktioniert auch. Aber ich habe Probleme, die beiden Sachen zu mergen. Getrennte vhdl file in einem Projekt hat gar nicht funktioniert. Bei der "Synthese" wird nur ein file genommen(?). Ok, dann hab' ich in den sauren Apfel gebissen und es er einmal in eine Datei gepackt: #2 Entity's und #2 Architecture's. Aber da meckert "Implementation Design", das es einen der Teile nicht "übersetzen" kann, weil im ucf-file zu viel drin steht. Das ucf file enthält den superset - also auch sind Dinge, die (nur) der zweite Teil braucht. Die moniert "Implementation Design" für den ersten Teil (der ersten 'Entity' und 'Architecture). Wie rule'd man das denn? [Nachtrag] Ich hab' jetzt eine 'entity' definiert und zwei 'architecture' für diese 'entity'. "Implement Design" geht damit zwar durch, aber meldet bereits als Warnung:
1 | WARNING:Par:289 - The signal led<0>_OBUF has no driver. |
2 | PAR will not attempt to route this signal. |
Danach kommt bei "Generate Programming File" ein Fehler:
1 | ERROR:PhysDesignRules:368 - The signal <led<0>_OBUF> is incomplete. |
2 | The signal is not driven by any source pin in the design. |
:
Bearbeitet durch User
Anbei noch die Datei. Die LED Ansteuerung ist auch irgendwo "geräubert" und noch nicht aufgeräumt. Mir geht's erst mal nur darum, dass beide Architectures "ausgeführt" werden.
Frank Bergemann schrieb: > Ich hab' jetzt eine 'entity' definiert und zwei 'architecture' für diese > 'entity'. Du solltest dir unbedingt mal die Grundlagenabteilung deines VHDL-Buchs ansehen: es ist möglich, mehrere Architectures zu deklarieren, aber es wird nur die letzte in der Datei zur Simulation und Synthese herangenommen. Was du willst und brauchst nennt sich "Component": in eine Top-Level-Entity werden andere Entities als Komponenten eingebunden. Dort mache ich sowas mit einer DDFS-Einheit und einer PWM-Einheit: http://www.lothar-miller.de/s9y/archives/57-Sinusausgabe-mit-PWM.html
@lkmiller: In "VHDL - Eine Einführung (Molitor/Ritter)" hab' ich da leider nicht viel drüber gefunden. Aber dank Deines links konnte ich es wenigstens besser strukturieren. Leider bekomme ich immmer noch XST Warnungen
1 | WARNING:Xst:2211 - "D:/xilinx-workspace/nexys2/Lauflicht2/Lauflicht1.vhd" line 56: Instantiating black box module <led_impl>. |
2 | WARNING:Xst:2211 - "D:/xilinx-workspace/nexys2/Lauflicht2/Lauflicht1.vhd" line 65: Instantiating black box module <segment_impl>. |
Ich versteh' diese Warnung nicht. Ist es ein Problem, wenn die Components nichts miteinander austauschen, sondern nur gemeinsam clock beziehen? [Nachtrag] Ich versteh' auch nicht, wieso ich bei der Auslistung der Components in architecture Lauflicht_Impl noch mal deren Interface spezifizieren muss. Die Anbindung der Lauflicht_if ports an die ports der Components macht Sinn. Aber die I/F definition der Components kommt doch von den Components selbst(?)
:
Bearbeitet durch User
Frank Bergemann schrieb: > Ich versteh' auch nicht, wieso ich bei der Auslistung der Components in > architecture Lauflicht_Impl noch mal deren Interface spezifizieren muss. Naja, ist eben VHDL. Es ginge auch ohne "doppelte" Deklaration, aber dazu musst du noch mehr Hintergrundwissen haben...
Frank Bergemann schrieb: > Leider bekomme ich immmer noch XST Warnungen Zum Zeitpunkt, wo er die angemeckerten Module einbauen soll, sind sie noch gar nicht synthetisiert. Pack jedes der 3 Module in ein eigenes VHDL File und füge alle 3 zu deinem Projekt dazu.
Das hat geholfen - Danke! Ich hatte auch noch bei den 'components' fälschlicherweise die 'architecture' referenziert - anstelle der 'entity'.
Ich hab' jetzt zwei Demos als 'component's in einer 'architecture' zusammengebracht. Als nächstes will ich die 7Segment-Anzeige dazu verwenden, die Anzahl der Durchläufe des LED Lauflichts vorwärts und rückwärts zu zählen. Aber eine Sache irritiert mich: Seitdem ich beim LED Lauflicht (Led.vhd) das signal 'led_reg' initialisere, damit das LED Lauflicht nach dem laden des *.bit files direkt abläuft
1 | signal led_reg : unsigned (6 downto 0) := "0000001"; |
... leuchten die LEDs nur noch schwach - bis ich dann doch wieder den Button #0 (reset) drücke. Woran liegt das?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.