Hallo,
ich habe folgenden Prozess:
counter: for x in 0 to bandwidth generate
process(clk)
begin
if rising_edge(clk) then
if cnt_trigger(x) = '1' then
if decoded(x) = '1' then
high_counters(x) <= high_counters(x) +1;
else
low_counters(x) <= low_counters(x) +1;
end if;
else
if low_reset(x) = '1' then
low_counters(x) <= (others => '0');
end if;
if high_reset(x) = '1' then
high_counters(x) <= (others => '0');
end if;
end if;
end if;
end process;
end generate;
cnt_trigger ist ein Triggersignal für die Zähler high_counters und
low_counters.
Decoded beinhaltet die Information, welche Zähler inkrementiert werden
sollen. D.h. wenn decoded(x) 0 ist wird low_counters(x) inkrementiert.
Wenn decoded(x) 1 ist, wird high_counters(x) inkrementiert.
Nun soll es auch möglich sein, diese Zähler zu resetten.
Dazu habe ich separate Resetleitungen für jeden Zähler(nämlich
low_reset und high_reset).
Wie im Code ersichtlich ist soll derjenige Zähler resettet werden,
dessen Resetleitung high ist.
In der Simulation passiert absolut gar nichts, wenn eine Resetleitung
auf high geht(es wird nur in diesem einen Prozess auf das Signal
geschrieben)
Woran könnte das liegen?
Danke!
Daniel
Gast
#389781
Steht cnt_trigger auf '1' während du reset durchführst? Dann würde er den else-Zweig, indem du den Rest ausführen willst, gar nicht abarbeiten.
Gast
#389782
würde zuerst die Abfrage nach Reset machen: am besten, du beschreibst die beiden Zähler getrennt: if rising_edge(clk) then if low_reset(x) = '1' then... elsif cnt_trigger(x) = '1' and decoded = '1' then... end if; if high_reset(x) = '1' then... elsif cnt_trigger(x) = '1' and decoded = '0' then... end if; end if; in der Form hat der Reset auf jeden Fall "Vorrang"
Ich habe beide Varianten probiert: Zuerst Reset-Abfrage und dann der Rest und auch andersrum. Beides mal das Gleiche. Das Signal nimmt den zugewiesenen Wert nicht an, sondern bleibt auf dem vordefinierten Wert 0.
Gast
#389784
Ja aber ud setzt doch im Reset das Signal auch auf 0. Ich versteh dann das Problem glaub nicht ganz
In meinem letzten Beitrag habe ich mich verschrieben... Es sollte heißen: ...sondern bleibt auf dem aktuellen Wert. Das Signal wird einfach nicht auf 0 gesetzt, obwohl die anderen Signale in der Simulation so sind, wie sie sein sollen. Es treten keine Undefinierten Zustände auf... Ich habe keine Ahnung was daran falsch sein könnte. Daniel
Gast
#389786
grins... mach doch mal das Reset-Signal in deine Sensitivity-Liste!
Das Reset-Signal braucht nicht in die sensitivity list, da mit diesem VHDL ein synchroner Reset beschrieben wird. Aber man brauchst natürlich eine Taktflanke, damit das Reset Signal erkannt wird. Wenn ein asynchroner Reset gewünscht wird, dann müßte man folgendermasen beschreiben :
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Dabei könnte es passieren, daß das (x) in der sensitivity liste nicht akzeptiert wird. Für "high_counters" ist ein getrenntes generate nötig. Grüße Klaus
> Für "high_counters" ist ein getrenntes generate nötig.
Ein getrennter Prozess genügt auch.
Und die Zeile "if (if low_reset(x) = '1' braucht ein "if"
weniger.
Klaus
Gast
#389789
Na das ist klar! Aber ich geh davonaus, dass der Reset absichtlich synchron ist. Daher wollte ich auch nix anderes vorschlagen. Ich selber hatte jedenfalls schon mal das Problem, dass ein Vergleichssignal in einer synchronen IF-Abfrage nicht in der sensitivity-List stand und Modelsim dannn diese Abrage komplett ignoriert hat.
Ja, der reset ist absichtlich synchron, ein Takt liegt an. >>Für "high_counters" ist ein getrenntes generate nötig. >>Ein getrennter Prozess genügt auch. Warum sowas? Wenn ich einen weiteren Prozes habe gibts ne Multisource. Daniel
Gast
#389791
Hast das mit der sensitivity List probiert?
Nein noch nicht. Ich probiere es unverzüglich...
>>Für "high_counters" ist ein getrenntes generate nötig. >>Ein getrennter Prozess genügt auch. > Warum sowas? > Wenn ich einen weiteren Prozes habe gibts ne Multisource. Das braucht es nur für meine Variante mit dem asynchronen Reset. Multisource gibt es, wenn Du aus 2 verschieden Prozessen das gleiche Signal setzt. Wenn Du 2 getrennte Prozesse jeweils für low_counters und für high_counters hast, dann gibts kein multisource. Klaus
Ich habe nun auch die 2-Prozess Version versucht(mit Signalen in Sensivity List). Wieder das Gleiche.
Gast
#389795
Und du bist sicher, dass zum Simulationszeitpunt, wenn der Reset kommt, das Triggersignal auf 0 ist?
ja, ganz sicher
Gast
#389797
Hallo Daniel, vielleicht könntest Du mal einen Screenshot von der Simulation posten!? Das würde sicherlcih die Fehlersuche erleichtern. Ines
Gast
#389798
Also ich hab deinen Code von dem allerersten Post gerade mal simuliert und es funktioniert! Ich denk mal, dass du in deiner Simulation einen Fehler hast. (siehe Anhang)
OK, ich werde sobald ich Zeit dazu habe mal nen Screenshot machen. Die Test-bench lasse ich direkt von ISE generieren und simuliere mit Modelsim. Viel falsch kann daran nicht sein. Daniel
Gast
#389800
ja und was ist mit deinen Testcases? Ich mein, die musst du dir doch selber überlegen.... und genau da ist vielleicht ein Fehler drin!
Da kann nicht viel falsch sein. Das passt alles. Überzeuge Dich selbst davon(Bild im Anhang). Die nicht relevanten Signale habe ich rausgenommen, damit es übersichtlich bleibt. Daniel
Angehängte Dateien:
-
Simulation.JPG
(150 KB)
Gast
#389802
Wie sieht die Definition der Reset-Signale und Counter-Signale aus? Ein Fehler könnte noch sein, dass zB. der Reset mit msb downto lsb und die Counter mit lsb to msb definiert wurden. Sonst müsste der Code oben funzen, da is erstmal kein Fehler drin. T.M. ============================= http://editthis.info/freefpga =============================
Alle Signale sind std_logic_vector mit MSB downto LSB. Keine Ahnung, warum ModelSim das in dem Fall andersrum darstellt... Ich weiß echt nicht mehr weiter. Ich glaube ich teste das mal direkt in der Hardware. Wenn es nuu an der Simulation liegt, dann ist der ganze Aufwand nach dem Fehler zu suchen umsonst. Daniel
Gast
#389804
hmm, dann fällt mir jetzt auch nix mehr dazu ein.. sorry!
Gast
#389805
Ich sehe momentan auch nichts :-| Vielleicht wenn den mal dne kompletten Code schicken würdest ... Ines
Der ganze Code würde wohl auch nichts nützen, denn das Generieren der reset-Signale funzt. Nur der Reset nicht. Ich muss mal mit meinem "Arbeitgeber" sprechen ob er nichts dagegen hat, wenn ich den Code poste. Daniel
Gast
#389807
warum verändern sich eigentlich deine Counter bei 1008800 ns, obwohl gar kein cnt_trigger anliegt?
Ich habe die Signale mit "force" in Modelsim geändert. Sonst wäre es mit allen anderen Signalen zu unübersichtlich geworden. Den Code werde ich demnächst posten. Daniel
Gast
#389809
Aaaaalso fassen wir zusammen: Der Zählerausgang verändert sich, ohne dass die entsprechenden Eingangssignale anliegen. Du schreibst, dass du den mit "force" änderst. Allerdings wird der Zähler ja getrieben (von deiner Logik) udn wenn du da mit force dagegenhältst, dann gibt es keine "sinnvollen" Zählerstände, sondern "xxx". Du hast aber gültige Zählerstände. Das iist nur dann möglich, wenn du das Zählersignal gar nicht treibst. Simulierst du überhaupt dein Design oder was ganz was anderes? Sorry, dass ich so frage, aber ich hab langsam den Eindruck, dass dein Problem wo ganz anders liegt
Wie Du willst: Ich mache Dir einen Screenshot vom ganzen Design und den kompletten Quellcode gibts auch dazu. Ich wollte nur nicht den ganzen Käse, der unnötig ist in der Simulation haben, damit jeder den Überblick behält. >>Allerdings wird der Zähler ja getrieben (von deiner Logik) udn wenn du >>da mit force dagegenhältst, dann gibt es keine "sinnvollen" >>Zählerstände, sondern "xxx". Ist mir noch gar nie passiert. >>Simulierst du überhaupt dein Design oder was ganz was anderes? Es ist tatsächlich das richtige Design. Bis später.. Daniel
Hallo, Asche auf mein Haupt. Ich Schlafmütze hatte die ganze Zeit mit force simuliert, anstatt die Zähler regulär zählen zu lassen(ging zu lang). Force lässt sich dann leider nicht mit der treibenden Logik überschreiben. Dafür gibts ja no force, welches ich vergessen hatte anzuklicken. Jetzt funktioniert alles. Trotzdem vielen Dank, dass Ihr mir geholfen habt. Daniel
Gast
#389812
Was soll ich dazu noch sagen??????? Na ja, ich verstreu mal nen ganzen Laster Asche auf deinem Haupt und das nächste mal einfach die beiträge richtig lesen! "Allerdings wird der Zähler ja getrieben (von deiner Logik) udn wenn du da mit force dagegenhältst, dann gibt es keine "sinnvollen" Zählerstände, sondern "xxx"" Na ja, sei´s drum.. hauptsache es tut jetzt
Das Problem war ja, dass es keine "XXX" gegeben hat. Ich habe schon
richtig gelesen...
>>Na ja, ich verstreu mal nen ganzen Laster Asche auf deinem Haupt
Die Lieferadresse lasse ich Dir per e-mail zukommen. ;))))
Daniel
Gast
#389814
Hi, was bedeutet Force & No Force ? Gruß, Dirk
Gast
#389815
Jaja, ob sorum oder sorum... das ist doch völlig wurscht! Kannst ja mal zwei IC´s mit den Ausgängen zusammenschalten und dann sagen, welcher Schuld ist, dass es nicht tut. Isdt einfach so, dass du immer mit Problemen rechnen musst, wenn du an zwei Stellen auf ein Signal treibst, ob mit force , aus dem Design an sich oder aus dem Tester. Das mit den x-en passiert, wenn du ein signal bereits aus VHDL treibst (z.B. mit '0' und dann das signal mit force 1 überschreibst, dann weiss der simulator nimmer, was er machen soll und zeigt x an). wenn das signal natürlich vorher auf "unassigned" steht, weil dein system gar nich läuft (z.B. kein resetwert, vondem der zähler loslaufen kann, dann kann dieses natürlich schon mit force überschrieben werden. Dumm nur, wenn dann das Design was machen soll. Und das ist bei dir passiert. Nun, aber wenn´s jetzt funzt, dann ist ja alles prima... hab schon an meinem Verstand gezweifelt ;-) @Dirk mit force kann man ein Signal in Modelsim auf einen pegel "zwingen" "force trigger 1" setzt das signal "trigger" auf '1' und das ganz ohne testbench. Allerdings gefährlich, weil es dann eben, wie oben passieren kann, dass ein Signal, das von einem Prozess getrieben wird, einen komischen Zustand einnimmt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.