Hallo, ich versuche grade auf einem InOut Port, welcher ein STD_LOGIC_VECTOR mit 8bit ist, zu lesen und zu schreiben. Ich habe eine Statemachine, welche denPort erst verwendet, um Konfigurationsdaten nach Außen zu schreiben und dann Daten als Antwort einlesen soll. So wie ich das Verstanden habe, sind InOut Ports 3-State ports. Also, entweder, es wird ein Signal vom FPGA auf dem Port getrieben, ein Signal wird von Außen getrieben oder es ist einfach Hochohmig ('Z') ? Damit ich keine Latches bekomme habe ich in jedem CASE der Statemachine das Signal von neuem geschrieben. Außerdem wüsste ich noch gern, wie ich das Signal, dann zwischenspeichern kann, bis der nächste Zyklus ein neues Signal ausgibt. Wenn ich einen Buffer benutze, dann erzeugt das ein 8-Bit Latch. Alex
Tristate heißt dabei: 0, 1, Z D.h. wenn Du lesen willst, muss der Port hochohmig geschlatet werden, ansonsten gibt's einen Kurzschluss.
OK, bei einem 8-Port wäre das dann: ADC_PARALLEL_IN_OUT<="ZZZZZZZZ" Jetzt möchte ich das Ganze mit einer Testbench ausprobieren. Schreibe ich in die testbench ADC_PARALLEL_IN_OUT<="11110000" bekomme ich in der Simulation nur Us, also Undefined. wie kann ich nun ausprobieren, ob das Ganze funktionier.
1 | stim_proc2: process |
2 | begin
|
3 | wait until ADC_CSTART ='0'; |
4 | wait for 10 ns; |
5 | wait until ADC_CSTART ='1'; |
6 | ADC_INT_EOC<= '0'; |
7 | wait for 500ns; |
8 | ADC_INT_EOC<= '1'; |
9 | wait for 40 ns; |
10 | ADC_PARALLEL_IN_OUT <= "11110000"; |
11 | end process; |
So scheint es schonmal nicht zu gehen. Alex
Alex schrieb: > Us, also Undefined. Das stimmt nicht. 'U' bedeutet Uninitialized. Es wurde also noch kein Wert zugewiesen, oder es gibt einen Buskonflikt mit einem anderen 'U'. > So scheint es schonmal nicht zu gehen. Das Problem ist in dem Teil der Beschreibung, der nicht gepostet wurde...
Ok, dann nochmal die Beschreibung als Anhang. Falls euch noch andere Fehler auffallen, bitte auch melden ;) Alex
Habe deinen Code nur kurz überflogen, aber so wie ich es sehe, hast du in deiner Testbench keinen Wert für ADC_PARALLEL_IN_OUT zugewiesen. Daher ist er seitens der Testbench "UUUUUUUU". Und U ist "stärker" als "Z". Also erscheint in deiner Simulation "UUUUUUUUU" Hab es aber nur ganz kurz überflogen. Kann sein, dass ich da auch was anderes übersehen habe
Alex schrieb: > Falls euch noch andere Fehler auffallen, bitte auch melden ;) Soll die Beschreibung mal auf ein FPGA? Das wird nimals funktionieren. Stichwort: "versteckte kombinatorische Schleife". Dort im kombinatorischen Prozess ist ein Zähler:
1 | P5:process(ADC_PARALLEL_IN_OUT,current_s,ADC_INT_EOC,CLK) |
2 | begin
|
3 | case current_s is |
4 | when POWERUP=> |
5 | :
|
6 | :
|
7 | when SAMPLE=> |
8 | if counter_sample <12 then |
9 | counter_sample <= counter_sample +1; -- huiuiui |
Das kommt hier wieder mal von der Zwei-Prozess-Schreibweise. http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html Und zudem steht in der Sensitivliste der CLK, der wird aber nirgends verwendet, ist also unnötig und darf da nicht rein. Dafür fehlt der counter_sample, und deshalb sieht die Simulation sogar noch "brauchbar" aus, auch wenn der Zähler zu schnell zählt, nämlich bei jeder Taktflanke... :-O
also den counter_sample dann lieber in Prozess 2 hochzählen, wenn der current_s = "sample" oder wo soll ich das dann zählen?
Alex schrieb: > wo soll ich das dann zählen? Was ist in Hardware ein Zähler? Es ist ein Addierer und dahinter zum speichern des Wertes noch Flipflops. Diese Flipflops brauchen einen Takt. Für diese Zwei-Prozess-Schreibweise brauchst du also eigentlich (wie für den next_s ) einen next_counter_sample, der dann mit dem Takt dem counter_sample zugewiesen wird. Das ufert mit ein paar Zählern dann schnell mal aus... Du siehst warum ich die Ein-Prozess-Schreibweise bevorzuge?
:
Bearbeitet durch Moderator
Lothar Miller schrieb: > Das kommt hier wieder mal von der Zwei-Prozess-Schreibweise. Die 2-Prozess-Schreibweise ist aber nur dann gefährlich, wenn man sich nicht strikt an ein paar Regel hält. Falls man eine handvoll Regeln beachtet, ist die 2-Prozess-Schreibweise meines Erachtens eine hervorragende Methode. Nicht nur für FSM, sondern für jedes Design, das mindestens ein Register enthält. Ich benutze jedenfalls seit Jahren für ALLE meine Designs diese Methode und habe mir da ein paar coding-rules zurechtgelegt. Werden diese beachtet, ist das Entstehen von Latches, kombiatorischen Schleifen etc schon prinzipbedingt ausgeschlossen.
So das ganze jetzt nochmal überarbeitet. Jetzt bin ich wieder beim ursprünglichen Problem angekommen. Sobald das EOC bit Wieder gesetzt ist, soll von der Testbench der InOut Port getrieben werden. Leider Sehe ich in der Simulation weiterhin nur die Zs, also, dass der IO-Port hochohmig ist. Ist das nur eine Anzeigesache, oder muss ich innerhalb der FSM nochmal was ändern, damit ich dann die Werte einlesen kann? Alex
Du musst in der TB entsprechend dem Signal ADC_RD entscheiden ob du ADC_PARALLEL_IN_OUT auf 'Z' oder einen anderen Wert setzt. Das macht der ADC ja auch.
OK, jetzt funktioniert es, vielen Dank. Jetzt hab ich nur noch ein letztes Problem. Ich habe noch ein 8-Bit Latch, das durch den Buffer für die Daten vom ADC verursacht wird. Ich habe in jedem Case der FSM dem Buffer den Buffer Wert zugewiesen, ist ja eine Loop.
Alex schrieb: > Ich habe in jedem Case der FSM dem > Buffer den Buffer Wert zugewiesen, ist ja eine Loop. Ja, du hast in fast jedem Case den Buffer auf sich selbst zugewiesen. Ganz ohne Takt und das ist nun mal ein Latch. > ist ja eine Loop. Na ja, nicht wirklich. Du denkst zu sehr in Software. VHDL ist aber eine Hardware-Beschreibungssprache.
Alex schrieb: > Ich habe in jedem Case der FSM dem Buffer den Buffer Wert zugewiesen, > ist ja eine Loop. Schon, aber du weist dem Data_Buffer sich selbst zu. Das heißt er muss speichern. Und speichern können nur Latches und Flipflops. Ein Flipflop kann es nicht sein, denn Flipflops brauchen einen Takt...
Alex schrieb: > also den counter_sample dann lieber in Prozess 2 hochzählen, wenn der > current_s = "sample" oder wo soll ich das dann zählen? Im Datenpfad und nicht in der Zustandsmaschine (Stichwort FSMD). Der Synthesizer den ich hier nutze (Synplifie Pro mit eingeschaltetem FSM Compiler) hat auch seine Probleme damit, wenn man in der FSM noch zusätzliche Funktionen wie Zähler etc. mit einbauen will. Der hat mich dazu gezwungen, das zu trennen (So wie es mir eigentlich auch mal beigebracht wurde).
Bitte 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.