www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Signal lässt sich nicht beschreiben(VHDL)


Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja aber ud setzt doch im Reset das Signal auch auf 0.
Ich versteh dann das Problem glaub nicht ganz

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
grins... mach doch mal das Reset-Signal in deine Sensitivity-Liste!

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :
process(clk,low_reset(x))
begin
if (if low_reset(x) = '1' then
    low_counters(x)  <= (others => '0');
elsif rising_edge(clk) then
  if cnt_trigger(x) = '1' then
    if decoded(x) = '1' then
      low_counters(x) <= low_counters(x) +1;
    end if;
  end if;
end if;
end process

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

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast das mit der sensitivity List probiert?

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein noch nicht. Ich probiere es unverzüglich...

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun auch die 2-Prozess Version versucht(mit Signalen in
Sensivity List). Wieder das Gleiche.

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und du bist sicher, dass zum Simulationszeitpunt, wenn der Reset kommt,
das Triggersignal auf 0 ist?

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, ganz sicher

Autor: Ines (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

vielleicht könntest Du mal einen Screenshot von der Simulation posten!?
Das würde sicherlcih die Fehlersuche erleichtern.

Ines

Autor: schlumpf (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja und was ist mit deinen Testcases? Ich mein, die musst du dir doch
selber überlegen.... und genau da ist vielleicht ein Fehler drin!

Autor: Daniel R. (daniel_r)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
=============================

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm, dann fällt mir jetzt auch nix mehr dazu ein.. sorry!

Autor: Ines (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe momentan auch nichts :-| Vielleicht wenn den mal dne kompletten
Code schicken würdest ...

Ines

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
warum verändern sich eigentlich deine Counter bei 1008800 ns, obwohl gar
kein cnt_trigger anliegt?

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 gibt’s ja „no force“, welches ich vergessen hatte
anzuklicken.
Jetzt funktioniert alles.

Trotzdem vielen Dank, dass Ihr mir geholfen habt.


Daniel

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel R. (daniel_r)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

was bedeutet Force & No Force ?

Gruß,
Dirk

Autor: schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.