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
@ 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
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
@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
Wäre es hier nicht "der Taktgeber" = die Clock?
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.
@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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.