Hallo, kann man Modelsim/ActiveHDL so einstellen, das bei der Simulation die FPGA-Gatterlaufzeiten berücksichtigt werden? Ich habe in meinem Design sehr lange ein Problem nicht beheben konnte weil in der Realität (mit SignalTap rausgefunden) ein Signal später kamm als bei der Simulation. Ich würde es gerne ohne "a <= b after 1 ns;" machen da sonnst mein ganzes Design überarbeitet werden muss. MfG
>Ich würde es gerne ohne "a <= b after 1 ns;" machen
Was würdest du gerne so machen?
Die Synthese generiert an diversen Stellen unterschiedliche Simulations-Ersatz-Schaltungen des Designs, insbesondere bie Xilinx. Diese bestehen aus einer Schaltungsstrukturbeschreibung und einem Signal Delay file. Mit denen muss man ModelSim füttern und bekommt die worst case Abschätzungen für die simulierten Betriebsfälle. "worst Case" deshalb, weil die jeweils längsten Signallaufzeiten des konkreten Routings unter den schlechtesten Bedingungen verwendet werden.
Dimi S. schrieb: > kann man Modelsim/ActiveHDL so einstellen, das bei der Simulation > die FPGA-Gatterlaufzeiten berücksichtigt werden? Man kann, aber es ist nicht der richtige Weg. Außerdem sind die Gatterlaufzeiten nicht konstant, sondern hängen von der Temperatur ab und streuen von Baustein zu Baustein. > Ich habe in meinem Design sehr lange ein Problem nicht beheben > konnte weil in der Realität (mit SignalTap rausgefunden) ein > Signal später kamm als bei der Simulation. Du solltest lernen, Timing Constraints zu verwenden. Dann wird a) bei Fitting das Design so optimiert, das das Timing erreicht wird b) falls dies nicht möglich ist, eine Warnung oder ein Fehler ausgeben. > Ich würde es gerne ohne "a <= b after 1 ns;" machen da sonnst > mein ganzes Design überarbeitet werden muss. Das kann und sollte man in einem Design sowieso nicht verwenden. Kann es sein, dass Dein Design nicht komplett synchron ist?
Robert K. schrieb: > it denen muss man ModelSim füttern und bekommt die worst > case Abschätzungen für die simulierten Betriebsfälle. "worst Case" > deshalb, weil die jeweils längsten Signallaufzeiten des konkreten > Routings unter den schlechtesten Bedingungen verwendet werden. Das ist meiner Meinung nach der Irrtum und der Unsinn einer Timing Simulation. Der Simulator kann nur so gesetzt werden, dass ALLE Durchlaufzeiten auf Maximum, Typisch oder auf Minimum berechnet werden. Was aber, wenn der worst case dann auftritt, wenn ein Pfad minimale und der andere maximale Durchlaufzeiten hat?
Dimi S. schrieb: > Hallo, > > kann man Modelsim/ActiveHDL so einstellen, das bei der Simulation > die FPGA-Gatterlaufzeiten berücksichtigt werden? Ich denke das Modelsim die Gatterlaufzeiten mit berücksichtigt. Zwar sind die Werte nicht 100% identisch wie in der Realität aber kommen nahe dran. Das größere Problem liegt eher beim dem Synthese Programm (ISE z.B.). Das Programm hält sich nicht an die Regeln die Modelsim aufstellt. Es mscht seine eigene Regeln, wo die Signalpfade verlaufen. Dadurch kann z.B. der Clock-Tree immer anders aussehen. Es kommt immer darauf an wie du den Code schreibst. Und Somit kann sich die Laufzeit auch immer ändern. Grundsatz vertrau Modelsim nicht. Es ist nur eine Simulation und das noch von einer anderen Firma als ISE oder Quartus.
Marco ... schrieb: > Ich denke das Modelsim die Gatterlaufzeiten mit berücksichtigt Nee, erst mal nicht. Nur wenn man die per sdf File mitgibt. Aber das bringt alles wenig, wie schon oben steht. Das andere Problem ist, dass man halbwegs realistische Delays eh nur nach der P&R Simulation sieht, dann ist aber die interne Struktur komplett weg und man kann nur noch das angucken, was man auch auf der Platine mit dem LA sieht. Eine Laufzei-Simulation ist ziemlich unsinnig, realitätsfern und langwierig. Ein mittelgroßes Design rechnet dann schon mal Stunden in ModemSim. Timing Constraints richtig verstehen und setzen, das ganze Design synchron und dann die statische Timing-Analyse richtig lesen, damit erschlägt man 99,995% der Probleme. Der Rest besteht meist aus eigener Dummheit.
Christian R. schrieb: > damit > erschlägt man 99,995% der Probleme. Der Rest besteht meist aus eigener > Dummheit. Nur 0,005% Dummheit ? Wow, das möchte ich auch einmal erreichen :-)
Klaus Falser schrieb: > Nur 0,005% Dummheit ? In den anderen 99,995% stecken ja auch schon viele dumme Fehler drin, nur die findet man in der Regel schneller :)
Also Post-Place Timing Simulation macht ja Sinn, wenn ich einen ASIC baue. Ich kann dann mit sog. 'regression-runs' mich eben nochmal absichern, dass das physical design funktioniert hat. Aber fuer einen FPGA? Bullshit! Jede Leitung ist bzgl. Delay bekannt, was soll da bitte schoen noch rauskommen? Und wer das braucht, der hat einen asynchronen Design und weiss nicht warum der wie funktioniert! Also bei FPGA und ordentlichem Design: VERGESSEN!
Klaus Falser schrieb: > Außerdem sind die Gatterlaufzeiten nicht konstant, sondern hängen von > der Temperatur ab und streuen von Baustein zu Baustein. Diese Streuung ist aber in den Modellen mit drin. Bei den Constraints kann er nur den worst case benutzten und der ist bei komplexen Design weit weg von der Realistät. berndl schrieb: > Und wer das braucht, der hat einen asynchronen Design und weiss nicht > warum der wie funktioniert! Recht hast Du! (Nur) bei asynchronen Designs, bei denen man den Weg der globalen Synchronität im Baustein verlässt, wird das benötigt, um sich einen Eindrucj zu verschffen, wie man weiterbauen muss. Das geht dann in Richtung FPGA-Editor und Timing Optimierung. Das fruchtet vor allem dann, wenn man mit ein heterogenes Design hat, wo ein Teil Timing, der andere Flächenoptimiert laufen soll. Da kommen die Tools nicht mit klar und die XST schon am allerwenigsten.
>berndl schrieb: >> Und wer das braucht, der hat einen asynchronen Design und weiss nicht >> warum der wie funktioniert! >Recht hast Du! (Nur) bei asynchronen Designs, bei denen man den Weg der >globalen Synchronität im Baustein verlässt, wird das benötigt, um sich >einen Eindrucj zu verschffen, wie man weiterbauen muss. Nicht-synchrone designteile sind weiterverbreitete als man denkt oder geplant hat. oft wird einfach übershen das man asynchrone teile eingebaut hat. ... dort einen Taktübergang übersegen, da ein asynchroneer reset (weil das so im lehrbuch steht). oder vergessen das das signal das von der Domain mit dem doppelten Takt (phasenstar per DCM erzeugt) auch doppelt solang sein sollte das es sicher von der domain mit dem einfachen takt erzeugt wird... Oder Pfade sind unconstraint, weil man bei den Wildcards für die multicycle Pfade (fals_path) übers Ziel hinaus schoß. Oder ein FF das eigentlich im IN-Pad sitzen sollte ist in die Logic-Fabric gewandert, weil ein Muxer für den Build-IN-Testpattern-generator hinzugekommen ist. Post-Placeandroute simulation gehört einfach dazu wenn man eine hohe testabdeckung gewärhleisten muß. MfG
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.