www.mikrocontroller.net

Forum: FPGA, VHDL & Co. RLT-Simulation und Multicycle


Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
in einem Design taucht bei mir nun folgendes Problem auf: Ein Addierer 
schafft das Timing innerhalb eines Taktes nicht und ich habe deshalb 
daraus einen Multycycle Prozess gemacht. So weit so gut, das ist auch 
noch nicht die Schwierigkeit. Nun möchte ich das Design aber auf 
RTL-Ebene Simulieren. Dort spielt das Timing ja noch keine Rolle. Das 
Ergebnis des Addierers steht im Simulator ja bereit. Also sind die Daten 
immer beim nächsten Takt gültig. Wenn mein Design nun einen Fehler hat 
und das Additionsergebnis schon nach beim 1. Takt abholt anstatt die 
notwendigen Takte abzuwarten, dann führt das in der Simulation zu keinem 
Fehler. Was kann man denn da tun um dies in der Simulation zu 
berücksichtigen?

Wenn es eine reine Simulation wäre, dann könnte man für einen 
2-Takt-Multycycle folgenden Konstrukt wählen:
adder_result <= adder_out after 1.5 * CYCLE_TIME;
Das ganze soll aber ohne Änderungen im Synthetisierbar sein.

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einem Shiftregister für die Verzögerung entsprechend der 
Takte für die Addition? Wenn Du die Addition startest setzt Du den Pegel 
des SR auf 1, quasi als Enable/Start. Wenn die Addition fertig ist, 
kannst Du die 1 aus dem SR als Valid dafür nehmen. Damit solltest Du bei 
der Simulation sowie Synthese gut klar kommen.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo mac4ever
> Wie wäre es mit einem Shiftregister für die Verzögerung entsprechend der
> Takte für die Addition? ... .
Das ist schon klar. Habe ich auch so, bzw. so ähnlich umgesetzt. Bei mir 
ist es ein Zähler, der gestartet (geladen) wird und bis 0 runter zählt 
und am Ende ein Ready generiert. Die praktische, bzw. prinzipielle 
Umsetzung ist nicht das Problem: Was aber, wenn im Design der Zähler 
falsch beschrieben ist und einen Takt zu früh ein Ready zurück gibt? 
Dann führt das in der Simulation zu keinem Fehler.

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also auf einen Fehler wird dich der Simulator nicht hinweisen. Allein 
die Daten die Du an dieser Stelle abholst sind ungültig. Wenn die 
Addition über mehrere Takte verteilt abläuft sollte auch das Ergebnis in 
der Simulation zum gleichen Zeitpunkt wie nach der Synthese 
bereitstehen.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn die
> Addition über mehrere Takte verteilt abläuft sollte auch das Ergebnis in
> der Simulation zum gleichen Zeitpunkt wie nach der Synthese
> bereitstehen.

Das ist nicht ganz richtig. Die Addition selbst ist eine rein 
kombinatorische Logik. Daher läuft die Addition nicht über mehrere Takte 
verteilt (sozusagen nicht in Teilschritte). Dann wäre es auch kein 
Multicyle. Lediglich die Laufzeit der Gatter sind so langsam, dass das 
Additionsergebnis noch nicht nach der Zeit eines Taktes zur Verfügung 
steht. Ich muss mich deshalb selbst darum kümmern, dass ich das Ergebnis 
nicht zu zeitig übernehmen. Also eine Pause von 1 oder mehreren Takten 
einlege.

Autor: mac4ever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre es dann nicht sinnvoll die Addition entsprechend so aufzubauen, 
dass sie über mehrere Takte geht?
process(clk)
begin
 if rising_edge(clk) then
  x <= a+b; --Zwischenwert
  y <= c+d; --Zwischenwert
  z <= x+y; -- Endwert
 end if;
end process;

Und schon hast Du einen Takt Verzögerung ... in Simulation und Synthese.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wäre es dann nicht sinnvoll die Addition entsprechend so aufzubauen,
> dass sie über mehrere Takte geht?

Ja und Nein: Dies hat mehrere Nachteile.
1. wird das Design größer.
2. ist das mit dem Addierer nur ein Beispiel. Sozusagen als Platzhalter 
für beliebige kombinatorische Logik. Da geht das nicht immer.

Bei mir ist das z.B. ein generisches Modul von Altere aus der 
Megacore-Library. Da geht das schon mal nicht. Aber dazu gibt es ja das 
Mulicycle-Constraining um genau diese Probleme zu lösen.

Mein Design ist nun doch etwas komplizierter. Da sind unter Anderem 
State-Machins implementiert, die durch Signale mit höherer Priorität die 
Abläufe unterbrechen um schließlich irgendwann mal wieder dort hin 
zurück zu kehren. Aus den Statemachines wird unter anderem die 
Mulicycle-Kombinatorik gesteuert. Spätestens jetzt wird klar, dass man 
da mal was übersehen kann, oder etwas nicht bedacht hat. In der 
RTL-Simulation würde ich mir dann doch wünschen, dass solche Fehler 
auffliegen. Das erhöht dann die Design-Sicherheit und spart eine Menge 
Zeit der Fehlersuche zu späteren Zeitpunkten.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias G.:

In Deinem Fall wirst Du wohl um eine Timingsimulation nicht 
drumrumkommen.
Woher soll das RTL-Modell auch wissen, wie lange Deine Kombinatorik 
rechnet?!

Ich würde mal ein after xx ns am Ausgang deines kombinatorischen 
Blockes mal probieren. Das sollte die Synthese nicht aus dem Tritt 
bringen.

Duke

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

und wenn du dein ready dazu benutzt, dein Additionsergebnis zu 
validieren? Also etwa so: add_out <= add_result when ready='1' else 
x"00000000";
Damit ist dein Ergebnis nur im richtigen Cycle validiert.

Abgesehen davon halte ich so einen Design fuer grenzwertig. Das versteht 
in einem halben Jahr kein Mensch mehr. Wie faengst du denn den Fall ab, 
dass deine Adder-Inputs zum falschen Zeitpunkt flippen? Dann hast du 
auch erst wieder nach soundsovielen Zyklen ein gueltiges Ergebnis und 
damit deine FSM komplett auf's Kreuz gelegt (und der Simulator weiss 
davon auch wieder nichts...).

Also ich wuerde das sauber pipelinen. Damit koennte z.B. der Adder auch 
einfacher/kleiner werden (Resource-sharing in den Pipeline-Zyklen)

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo berndl:

> und wenn du dein ready dazu benutzt, dein Additionsergebnis zu
> validieren? Also etwa so: add_out <= add_result when ready='1' else
> x"00000000";
> Damit ist dein Ergebnis nur im richtigen Cycle validiert.

Aber das verlangt ja auch schon wieder, dass der richtige Zeitpunkt 
validiert ist. Das ist ja dann das gleiche Problem.

> Abgesehen davon halte ich so einen Design fuer grenzwertig. Das versteht
> in einem halben Jahr kein Mensch mehr.

Doku, Doku, Doku. Dann kann man wieder rein kommen. Ich verstehe mein 
Sachen schon selbst sehr viel früher nicht mehr. Dafür habe ich mir 
angewöhnt die Beweggründe für einen Lösungsansatz und die Umsetzung gut 
zu beschreiben.

> Wie faengst du denn den Fall ab,
> dass deine Adder-Inputs zum falschen Zeitpunkt flippen? Dann hast du
> auch erst wieder nach soundsovielen Zyklen ein gueltiges Ergebnis und
> damit deine FSM komplett auf's Kreuz gelegt (und der Simulator weiss
> davon auch wieder nichts...).

Die Eingänge einer Multicycle-Logik müssen auf jeden Fall gelatched 
sein. Solle ein "interrupt" mitten in eine Berechnung fallen, dann muss 
der Berechnungsschritt natürlich wieder von vorne beginnen. Das ganze 
ist dann weder vom Timing noch von Gesamtsystem grenzwertig.

> Also ich wuerde das sauber pipelinen. Damit koennte z.B. der Adder auch
> einfacher/kleiner werden (Resource-sharing in den Pipeline-Zyklen)

Das geht leider von den Systemanforderungen nicht.

Hallo Duke,

> Ich würde mal ein after xx ns am Ausgang deines kombinatorischen
> Blockes mal probieren. Das sollte die Synthese nicht aus dem Tritt
> bringen.

Ich werde es mal probieren. Es sollte mich aber wundern wenn das geht.
Man bräuchte halt so ne Art
#if defined
 für VHDL.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias G.:

Zur Not halt so:
data_o <= internal
--synthesis translate_off
after 10 ns
--synthesis translate_on
;

Ansonsten gib es sicher auch eine Tooldoku, wo drin steht, was der 
Synthesizer draus macht.

Duke

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
after Anweisungen werden meines Wissens einfach ignoriert, man kann also 
die Version aus dem ersten Post auch nehmen.

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja, ihr begebt euch hier aber in ziemliche Abhaengigkeit von 
irgendwelchen Tools. Also ich bleib' dabei: Ich wuerde das sauber 
designen, den 'langsamen' core irgendwie kapseln und dann mit 
handshake-signalen dafuer sorgen, dass ich Eingaenge festklemme und 
Ausgaenge nur lese wenn ich weiss dass ich dran bin.
Damit sollte man auch eine Testbench schreiben koennen, die unabhaengig 
von der verwendeten Technologie in der Simulation richtig funktioniert. 
Alles andere halte ich fuer sehr gefaehrlich.

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.