mikrocontroller.net

Forum: FPGA, VHDL & Co. Abgeleitete clocks in der Simulation - wie Probleme vermeiden?


Autor: Matthias F. (flint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nachdem ich schon mehrfach Probleme mit den Clocks und insbesondere den 
abgeleiteten in der Simulation hatte, wollte ich mal mit jemand darüber 
reden ;) .


Konkret habe ich folgendes Problem: Ich bekomme einen Clock aus einem 
Core, der eine Schnittstelle des FPGA bedient. Diesen Clock, er sei mal 
Main Clock genannt, verwende ich einerseits in den State Machines, die 
mit diesem Core kommunizieren. Andererseits werden im eigentlichen 
Design in einer PLL aus dieser Clock noch andere abgeleitet, diese seien 
mal Derived Clocks genannt. Zwischen diesen beiden Teilen (einerseits 
die Anbindung an den Core, andererseits das eigentliche Design) findet 
die Kommunikation über interne SRAM Blöcke im FPGA statt.

Jetzt bekomme ich zwangsläufig das Problem, dass Teile die auf Derived 
Clocks laufen mit Teilen, die auf der Main Clock laufen, kommunizieren 
(was zu Problemen mit Delta Delays führen kann, bzw bei mir schon 
geführt hat).

Wie vermeidet ihr solche Probleme? Sowas kann einem ja schnell 
passieren, sobald man eine DCM oder eine PLL im Design hat, kann es 
schon zu seltsamen Effekten kommen.

Mir fallen momentan zwei mögliche Wege ein:

1. Eine Lösung, bei der man die Clockgenerierung über ein generic 
umschalten kann und damit für die Simulation nur Derived Clocks 
verwendet (die Lösung gefällt mir eigentlich nicht, da sie unter 
Umständen nicht mit jedem Design implementierbar ist).

2. Alle Derived Clocks werden verzögert generiert (zb indem der Eingang 
in die PLL verzögert wird), dann hat man keine Delta Delay Probleme mehr 
(diese Lösung gefällt mir besser aber ich bin mir noch nicht sicher, ob 
sie das Problem wirklich löst).


Ich weiß, das Thema und meine Probleme mögen lächerlich wirken, aber ich 
sehe das als große Fehlerquelle und hätte gerne mal eine Best Practice 
in der Hand, wie ich das Problem angehen soll.

LG
Matthias

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias F. (flint)

>Wie vermeidet ihr solche Probleme?

Taktung FPGA/CPLD

Natürlich ist das keine Patentlösung. Manchmal muss man eben auf PLLs 
zurückgreifen.

>Ich weiß, das Thema und meine Probleme mögen lächerlich wirken,

Keinesfalls! Das ist schon fast die hohe Schule des FPGA-Designs.

>sehe das als große Fehlerquelle und hätte gerne mal eine Best Practice
>in der Hand, wie ich das Problem angehen soll.

Man könnte sie generell als asynchron ansehen und behandeln. Allerdings 
werden dadurch bestimmte Steuerungsmechanismen langsamer, wegen der 
Synchronisierung/Abtastung. Oder man gaukelt der Simulation exakt 
phasengleiche Takte per Testbench vor. Wird aber problematisch, wenn der 
Core den Takt ausspukt. Sowas sollte wenn möglich vermieden werden. 
Vielleicht kann man das in den Core reinschmuggeln?

MFG
Falk

Autor: Matthias F. (flint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Anregungen. Mein Design versorgt noch andere 
angeschlossene Geräte mit Clocks, daher verwende ich eine PLL und werde 
wohl auch bei dieser bleiben (die PLL sollte ja ein schönes Signal 
erzeugen).


Phasengleiche Takte in der Simulation über die richtige Anzahl von 
Zuweisungen des Clock-Signals habe ich versucht, aber das ist 
unübersichtlich, schwer zu warten und ich fürchte, dass ich bei solchen 
Manövern erst recht Fehler einbringe.


Ob das mit der Clock im Core funktioniert muss ich mir mal anschauen.

LG
Matthias

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias F. (flint)

>Ob das mit der Clock im Core funktioniert muss ich mir mal anschauen.

Auch wenn der schon lange tot ist, tu dem Herrn Duden einen Gefallen und 
nenne es "der Takt", wenn möglich grammatikalisch korrekt dekliniert.

MFG
Falk

Autor: Mr.Mister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre es hier nicht "der Taktgeber" = die Clock?

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich Dein Problem richtig verstanden habe, dann geht es um die Delta 
Delays die durch das Mapping durch verschiedene Ebenen entsteht?! In 
dieses Problem bin ich ebenfalls schon beim Einsatz von IP-Cores 
gelaufen und es gibt da das "Standardrezept" das man die Datenleitungen, 
die betroffen sind, mit einem kleinen "after" verzögert. Das ist die 
einzige praktikabele Lösung die mir bekannt ist. Dadurch wird das Signal 
im Simulator zu einem neuen Zeitpunkt gescheduled.

Autor: Matthias F. (flint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk: Der Takt, des Taktes, dem Takt, den Takt, die Takte, der Takte, 
den Takten, die Takte. Besser so ;) ?

@Mathi: Genau das Problem habe ich. Das Rezept mit den after-Anweisungen 
kenne ich, aber das entspricht ja nicht der klassischen Schule der 
RTL-Simulation. Dennoch bleibt mir wohl nichts anderes übrig, ich komme 
hier nämlich nicht auf einen grünen Zweig.

Eine mögliche Idee war auch noch, dass das Design seine Takte noch 
einmal ausgibt und dann zb Testbench-Prozesse mit diesen Takten 
arbeiten. Aber selbst da kriege ich es nicht so ohne weiteres hin, dass 
die Takte überall im selben Delta Cycle ankommen (Port Mapping bringt zb 
anscheinend kein Delay, die Zuweisung des Signals an einen Port der 
Entity allerdings schon).

Das ganze wird mit der Zeit ziemlich vertakt, äh, vertrakt ;) .

LG
Matthias

Autor: Matthias F. (flint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na gut, nach einer Besprechung mit meinem Chef haben er und ich folgende 
Regeln festgestellt:

1. Takte sofern es geht nur über Port Mapping weitergeben, die kein 
Delta Delay hinzufügen.

2. Geht es nicht (zb weil eine PLL oder ein Teiler dazwischen sitzt) 
dann muss das Design die internen Takte wieder am Interface zur 
Verfügung stellen, wobei hier wieder darauf geachtet werden muss, dass 
diese Takte an interne Prozesse und an die Testbench nur mit Port 
Mapping weitergegeben werden.

3. Gibt es Punkte, an denen die Kommunikation zwischen einer Main Clock 
und einer Derived Clock zwangsläufig erforderlich ist, muss eine Art 
Einsampeln zwischen den beiden Prozessen gemacht werden. Das sollte nur 
die Testbench betreffen.


Ich habe zwar schon einen Wrapper um mein Design geschrieben, das die 
Signale in beide Richtungen verzögert, aber diese Regeln gefallen mir 
auch gut und sollten nach unserer Meinung funktionieren. Irgendwelche 
Einwände?

LG
Matthias

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.