mikrocontroller.net

Forum: FPGA, VHDL & Co. Seltsame (Neben-)Effekte in der Simulation


Autor: Anfänger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe mich endlich mit Modelsim arrangiert und jetzt ein kleines Projekt 
(siehe Anhang) simuliert.

Das Spartan 3E Dev-Board hat ja einen LTC1407 drauf und dafür habe ich 
einmal ein Modul für den Spartan und zum anderen ein Modul für den 
Simulator, in dem auch der ADC simuliert wird.

Die Testbench liest die gewünschten ADC-Werte aus einer Datei und gibt 
die entsprechend weiter. Im "Groben" funktioniert es, aber im Detail 
klemmt es. Jetzt weiß ich aber nicht wo - höchstwahrscheinlich fehlt mir 
wieder etwas Verständnis ...

Es gibt ja jetzt einige "gleichzeitige" Prozesse und ich bin mir nicht 
sicher, welche davon ich zu synchronisieren habe und welche - per 
Definition - unsynchronisiert sein sollen.
Um den Zeitversatz auf der Platine (übertrieben) ins Spiel zu bringen, 
arbeitet der gefakte ADC mit der fallenden Taktflanke, das FPGA-Modul 
mit der steigenden.

Wenn also mal jemand von denen, die sich auskennen, drüber schauen und 
mir etwas Nachhilfe geben könnte, würde mir das sehr freuen :)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Um den Zeitversatz auf der Platine (übertrieben) ins Spiel zu bringen,
> arbeitet der gefakte ADC mit der fallenden Taktflanke, das FPGA-Modul
> mit der steigenden.
Das macht man aber anders   :-o    Dafür gibt es after
Mit einer funktionalen Simulation findest du sowieso keine 
(relevanten) Timing-Verletzungen. Machs besser straight-forward (mit dem 
selben Takt), damit du Funktionsfehler findest.

Was willst du jetzt eigentlich testen?
Das Modul LTC1407 eigentlich nicht.
Denn dort stehen Sachen drin, die die Synthese ins Grübeln bringen...
(Am Rande: Der Name des Moduls ist ungünstig, LTC1407 ist ein Bauteil 
von LT. Das macht was anderes, als das was in dem vhdl-File steht...)

BTW:
      if (cs = '0') then
      :
      elsif rising_edge(clk50) then
      :
Das ist bedenklich, falls der cs (in der Realität) asynchron zum clk50 
kommen kann...

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen Lothar,

Vielen Dank für Deine Hilfe!

> Das macht man aber anders   :-o    Dafür gibt es after

Danke für den Tip - habe doch gleich interessante Beispiele gefunden!
Was ein guter Suchbegriff nicht ausmachen kann :)

> Machs besser straight-forward (mit dem
> selben Takt), damit du Funktionsfehler findest.

Hm, die seltsamen Effekte hatten mich dazu gebracht, es mit einem 
Zeitversatz zu probieren - mir scheint, dass noch was anderes zuschlägt.

> Was willst du jetzt eigentlich testen?
> Das Modul LTC1407 eigentlich nicht.

Hm, schon - aber da ich das fake-Modul für den ADC ja selbst geschnitzt 
habe, wie auch die Testbench, bin ich mir nicht sicher, wo ich den 
Fehler suchen kann, bzw. wie ich ihm auf die Spur komme.

Sinn der Sache ist doch, dass die Ausgabe, die die Werte für den 
Speicher kontrolliert, genau die gleichen Werte in der gleichen 
Reihenfolge ausspuckt, wie die Testdaten, die ich der Testbench zur 
Verfügung stelle.

Der Punkt ist, dass die Übertragung bei jedem 2. Messwert funktioniert, 
dazwischen wird 0 in den Speicher geschrieben. Jetzt weiß ich aber von 
niemand, der die 0 produziert - habe die Testdaten extra mit != 0 
initialisiert.

> Denn dort stehen Sachen drin, die die Synthese ins Grübeln bringen...

Ich weiß. Die Meldung habe ich nur eingebaut, um zu sehen, was abgeht.

> Das ist bedenklich, falls der cs (in der Realität) asynchron zum clk50
> kommen kann...

Genau aus dem Grunde habe ich es so geschrieben. Ich habe zuerst Deine 
Variante vom Beitrag "Re: Der vhdl-Schnipsel-Anfängerfragen Thread" 
simuliert, dann aber gesehen, dass der Reset nicht in meinem Sinne 
funzt.
Kann durchaus sein, dass ich beim Umschreiben noch was verbockt habe.

Autor: Anfänger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe es etwas umgestellt, um dem Fehler auf die Spur zu kommen, 
dabei ist es leider noch schlimmer geworden :(

die gesamte Ausgabe der Simulation:
# start reading test data from file ...
# -- xFE xAB -- 254 171 -- 11111110  10101011
# got row #0 of test data as ch-A: 254, ch-B: 171, FRC: 1
#                  -- 218  35 -- 11011010  00100011
# got row #1 of test data as ch-A: 218, ch-B: 35, FRC: 1
#                  --  18 239 -- 00010010  11101111
# got row #2 of test data as ch-A: 18, ch-B: 239, FRC: 1
#                  -- 105  63 -- 01101001  00111111
# got row #3 of test data as ch-A: 105, ch-B: 63, FRC: 1
#                    --  65  23 -- 01000001  00010111
# got row #4 of test data as ch-A: 41, ch-B: 17, FRC: 1
# DONE reading test data!
# activated test data of row #0
# test data on lines - A:UUUUUUUUUUUUUUUU, B:UUUUUUUUUUUUUUUU
# testdata to transmit: 000UUUUUUUUUUUU0000UUUUUUUUUUUU000
# activated test data of row #1
# test data should be - A:0000000011011010, B:0000000000100011
# test data on lines - A:UUUUUUUUUUUUUUUU, B:UUUUUUUUUUUUUUUU
#             7654321-7654321-7654321-76543210
# current sr: UU000UUUUUUUUUUUU0000UUUUUUUUUUU
# ** Warning: NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
#    Time: 930 ns  Iteration: 2  Instance: /testbench
# ** Warning: NUMERIC_STD.TO_INTEGER: metavalue detected, returning 0
#    Time: 930 ns  Iteration: 2  Instance: /testbench
#      >>> wrote channel-A with: 0, channel-B with: 0, to address: 0

Es geht um diese Passage, genauer um die Signale "iChA" und "iChB":
      iChA <= std_logic_vector(to_unsigned(myTestData(row).chn_A, 16));
      iChB <= std_logic_vector(to_unsigned(myTestData(row).chn_B, 16));
      if (myTestData(row).FRC = 1) then
         ADC_frc <= '1';
      else
         ADC_frc <= '0';
      end if;
      write(scratch, STRING'("activated test data of row #")); write(scratch, row);
      writeline(output, scratch);

      write(scratch, STRING'("test data should be - A:")); write(scratch, std_logic_vector(to_unsigned(myTestData(row).chn_A, 16)));
      write(scratch, STRING'(", B:")); write(scratch, std_logic_vector(to_unsigned(myTestData(row).chn_B, 16)));
      writeline(output, scratch);
      write(scratch, STRING'("test data on lines - A:")); write(scratch, iChA);
      write(scratch, STRING'(", B:")); write(scratch, iChB);
      writeline(output, scratch);

... welche folgende Ausgabe erzeugt:
# activated test data of row #1
# test data should be - A:0000000011011010, B:0000000000100011
# test data on lines - A:UUUUUUUUUUUUUUUU, B:UUUUUUUUUUUUUUUU

Die gesamte Testbench ist im Anhang.

Wo liegt mein (Denk-)Fehler?

Autor: Anfänger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab's jetzt zwar selber hinbekommen, aber was mich frustriert: ich weiß 
nicht, warum es jetzt tut.

Gut, beim FPGA-modul hatte ich einen Takt zuwenig gezählt, sodass der 
ADC garkeine Chance hatte, das neue Startsignal mit zu bekommen.
... auch habe ich bei der Testbench 2 Prozesse wieder zusammengefasst.

Schätze mein Verstädnis krankt noch daran, wann ein Signal den ihm 
zugewiesenen Wert erhält.
Also z.B. ich mache das "gleiche" in 3 verschiedenen Prozessen (in 
unterschiedlichen Simulationen, nur zum Verständnis):
1.) ein Prozess mit einer Signalabhängigkeit linear kodiert mit 
Flankenabfrage auf das angegebene Signal:
PROCESS (...) BEGIN
   if rising_edge(...) then
       ...
   end if;
END PROCESS;

2.) ein Prozess ohne Signalabhängigkeit
PROCESS BEGIN
   WAIT UNTIL rising_edge(...);
   ...
END PROCESS;
3.) ein Prozess ohne Signalabhängigkeit, der aber eine (Endlos-)Schleife 
hat, sodass der Prozess nie beendet und neu gestartet wird. In der 
Schleife wird auf unterschiedliche Ereignisse gewartet.

In jedem dieser Prozesse weise ich einem Signal einen neuen Wert zu.
Wovon hängt es jetzt ab, wann der neue Signalpegel aktiv ist? - Egal ob 
für andere Prozesse oder denselben Prozess? Gibt es hier Unterschiede 
zwischen Simulation und Synthese?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese beiden Beschreibungen verhalten sich exakt identisch. Eine 
Sensitivliste ist quasi eine andere Schreibweise für ein wait until.

Das wait until hat den Vorteil, dass es keine unvollständige 
Sensitivliste geben kann. Siehe z.B. 
http://www.lothar-miller.de/s9y/archives/16-Takt-i...

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lothar,

selbst wenn die ersten beiden identisch zu sein scheinen - bleibt für 
mich noch immer die Frage offen, wann denn eine Signalzuweisung aktiv 
wird und wovon es abhängt.

Noch interessanter ist doch diese Variante, bei der der Prozess niemals 
verlassen wird:
   PROCESS BEGIN
      ...
      LOOP
         mySignal <= '1';
 
         WAIT UNTIL rising_edge(clock);
         ...
      END LOOP;
      WAIT;
   END PROCESS;

In manchen Beschreibungen steht zu lesen, dass ein Signal erst nach 
Beendigung des Prozesses den zugewiesenen Wert erhält (und wird als 
Gegensatz zu den Variablen hervorgehoben). Das scheint so aber nicht 
ganz zu stimmen ...

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> In manchen Beschreibungen steht zu lesen, dass ein Signal erst nach
> Beendigung des Prozesses den zugewiesenen Wert erhält
Nicht am Ende des Prozesses, also nicht bei der Zeile END PROCESS, 
sondern nachdem alle Prozesse an einen Wait-Statement (implizit oder 
explizit) angekommen sind.
Dann werden alle Signale aktualisiert und der nächste Event 
abgearbeitet.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anfänger schrieb:
> Noch interessanter ist doch diese Variante, bei der der Prozess niemals
> verlassen wird:
>
>    PROCESS BEGIN
>       ...
>       LOOP
> 
>          WAIT UNTIL rising_edge(clock);
>          ...
>       END LOOP;
>       WAIT;
>    END PROCESS;
> 
Schon mal probiert, das zu synthetisieren?

Fehler:
Bad condition in wait statement, or only one clock per process.
Ursache: das zweite WAIT;

Wird das auskommentiert, kommt der Folgefehler:
Wait statement is not supported in this configuration.
Da liegt daran. dass ein WAIT in LOOPs (derzeit noch) nicht 
synthetisiert werden kann.

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Klaus,

das war genau die Erklärung, die ich gesucht habe!
Sie ist plausibel und jetzt leuchtet mir auch ein, warum meine Testbench 
mit mehreren Prozessen nicht geklappt hat (Synchronisierung der 
WAIT-statements hat nicht geklappt).

Gibt es die Möglichkeit, Prozesse zu priorisieren, d.h. irgendwie 
festzulegen, in welcher Reihenfolge die Prozesse wieder anlaufen?

Wie sieht das eigentlich mit den Auswirkungen des IO auf das 
Zeitverhalten der Simulation aus?
Das Einlesen der Datei in den Speicher ist in der Zeitachse nicht zu 
sehen, aber wenn ich pro Testzyklus einen Dateizugriff mache, kommt die 
Zeitsteuerung durcheinander (subjektiver laienhafter Eindruck - muss 
nicht stimmen).

@Lothar
Mir ging es nicht darum, zu synthetisieren, sondern zu verstehen.
Das Beispiel ist aus meiner (funktionierenden) Testbench - da besteht 
nichtmal der Wunsch, das zu synthetisieren. Im Augenblick ist mir die 
Synthese völlig egal, da die Verständnislücken noch zu groß sind.
Deshalb "entwickle" ich gerade mit Modelsim und dem Wavediagram. Wenn 
ich dann mit dem Zeitverhalten meiner Module zufrieden bin, dann widme 
ich mich wieder der Synthese.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gibt es die Möglichkeit, Prozesse zu priorisieren, d.h. irgendwie
> festzulegen, in welcher Reihenfolge die Prozesse wieder anlaufen?
Du kannst in einem Prozess ein Signal setzen, und im anderen abfragen, 
wie der Zustand des Signals ist:
:
signal weiter : std_logic := '0';
:
process begin
   :
   tuwas...
   wait for 3 us;
   machwas...
   wait until irgendwas;
   :
   wait for 300 ns;
   weiter <= '1';
end process;

process begin
   wait until rising_edge(weiter);
   :
   :
end process;
Aber sowas wird schnell unübersichtlich. Besser wäre da eine zentrale 
State-Machine, die die Verwaltung der einzelnen Prozesse übernimmt.

> Wie sieht das eigentlich mit den Auswirkungen des IO auf das
> Zeitverhalten der Simulation aus?
Während der Dateizugriffe bleibt die simulierte Zeit einfach stehen. Die 
Zugriffe finden quasi mit delta-T=0 statt.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Deshalb "entwickle" ich gerade mit Modelsim und dem Wavediagram. Wenn
> ich dann mit dem Zeitverhalten meiner Module zufrieden bin, dann widme
> ich mich wieder der Synthese.

Nur als Empfehlung, aber ich denke nicht, dass dies ein günstige Ansatz 
ist.
Du mußt lernen zu unterscheiden :
- Was darf ich in einem Modul verwenden, das synthetisiert werden soll 
und wie beschreibe mein gewünschtes Verhalten. Dazu gehören Register, 
FFs, FSM usw.
Diese Muster kann man auch anwenden, wenn man nicht alle Feinheiten von 
VHDL verstanden hat.
- Was kann ich in einer Testbench verwenden.
Das sind Delays, File I/O, waits an beliebigen Stellen in Prozessen usw.

Du verwendest File I/O und ähnliches, aber die Grundlagen scheinen noch 
nicht ganz zu sitzen.

Autor: Anfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Gibt es die Möglichkeit, Prozesse zu priorisieren, d.h. irgendwie
>> festzulegen, in welcher Reihenfolge die Prozesse wieder anlaufen?
> Du kannst in einem Prozess ein Signal setzen, und im anderen abfragen,
> wie der Zustand des Signals ist:

Ok, das habe ich ja schon gemacht. Danke.

> Du mußt lernen zu unterscheiden :
> - Was darf ich in einem Modul verwenden, das synthetisiert werden soll
> und wie beschreibe mein gewünschtes Verhalten. Dazu gehören Register,
> FFs, FSM usw.
> Diese Muster kann man auch anwenden, wenn man nicht alle Feinheiten von
> VHDL verstanden hat.
> - Was kann ich in einer Testbench verwenden.
> Das sind Delays, File I/O, waits an beliebigen Stellen in Prozessen usw.

Hm, ich denke, das habe ich verstanden.
Die delays, die ich in den Modulen eingesetzt habe, die mal 
synthetisiert werden sollen, sind nur für die Simulation drin.
Irgendwie musste ich meinem "Fehler" ja auf die Spur kommen.
Genauso wie die Konsolen-Ausgaben - die sind nur für die Simulation.

... by the way: gibt es sowas wie ein #ifdef für VHDL?

> Du verwendest File I/O und ähnliches, aber die Grundlagen scheinen noch
> nicht ganz zu sitzen.

File I/O verwende ich aus Faulheit ;) Einmal habe ich die Werte seriell 
kodiert - nur um dann festzustellen, dass die Fehlerquelle und 
Fehlerwahrscheinlichkeit viel zu hoch ist, um einem Testergebnis zu 
vertrauen.

Also habe ich ne Testbench geschrieben, die die Werte aus einer Datei 
liest. Das tut jetzt zuverlässig. Und da ich auch an dieser Stelle sehr 
bequem bin, musste das File I/O auch gleich die Zahlentypen 
konvertieren, sodass ich Werte als Int-, Hex-, Oktal- und Binärwert 
angeben kann.

Die Grundlagen sitzen deshalb noch nicht, weil dies meine erste 
Testbench ist. In den meisten Tutorials wird der BNF-Graph der Sprache 
abgedruckt, ohne auf Sinn und Zweck einzugehen, geschweige denn 
sinnvolle Beispiele zu geben.

Vieles habe ich mir von Lothar, opencores und freemodel abgeschaut. 
Jetzt aber die Theorie und Praxis zusammen zu bringen - da krankt es 
noch etwas.
Deshalb kann es schon vorkommen, dass ich hier scheinbar abstruse Fragen 
stelle.

Dank Eurer Hilfe wird aus den Puzzleteilen langsam ein Bild :)

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.informatik.uni-kiel.de/en/schimmler/tea...

Da gibt es zwei "Bücher" als PDF vieleicht hilft dir das und kostet nix 
;)

Bie VHDL Kompakt ist zu der Syntax form auf jedenfall auch noch immer 
ein Beipiel wie man es anwendet dabei.

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.