Signal lässt sich nicht beschreiben(VHDL)

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

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.

[schlumpf (Gast)]

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"

[Daniel R. (daniel_r)]

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.

[schlumpf (Gast)]

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

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

grins... mach doch mal das Reset-Signal in deine Sensitivity-Liste!

[Klaus F. (kfalser)]

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

[Klaus F. (kfalser)]

> 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

[schlumpf (Gast)]

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.

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

Hast das mit der sensitivity List probiert?

[Daniel R. (daniel_r)]

Nein noch nicht. Ich probiere es unverzüglich...

[Klaus F. (kfalser)]

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

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

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

[Daniel R. (daniel_r)]

ja, ganz sicher

[Ines (Gast)]

Hallo Daniel,

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

Ines

[schlumpf (Gast)]

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)

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

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

[Daniel R. (daniel_r)]

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

[T.M. (Gast)]

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

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

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

[Ines (Gast)]

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

Ines

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

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

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

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

[Daniel R. (daniel_r)]

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

[Daniel R. (daniel_r)]

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

[schlumpf (Gast)]

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

[Daniel R. (daniel_r)]

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

[Dirk (Gast)]

Hi,

was bedeutet Force & No Force ?

Gruß,
Dirk

[schlumpf (Gast)]

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.