Hallo, Nachdem ich in diesem Forum viel gelernt habe über FSMs und wie man code schreibd, der wirklich zu dem synthetisiert wird was man haben will sieht mein Projekt jetzt besser aus. Allerdings herschen bei mir jetzt Erhebliche unklarheiten, was das Timing betrifft. Ich kenne jetzt eigentlich 2 Möglichkeiten um herauszufinden mit welchen Verzögerungen ich rechnen muss. Einerseits klicke ich im Fitter-Report auf Timing-Report. Da kann ich dann ablesen wie lange es dauert bis ein Signal am Ausgang anliegt z.b. nach fallender Taktflanke. Die andere Möglichkeit die ich kenne ist eine Post-Fit Simulation. Da kann ich es Grafisch ablesen. Mein Problem ist jetzt aber, dass diese Methoden recht unterschiedliche Ergebnisse liefern. Laut Timing-Report hat Signal A eine Verzögerung von 12,7 ns, Signal B hat 4,5ns. Steht bei Clock To Pad Timing. (Aber auch bei Pad to Pad. Ist das normal?) In der Post-Fit Simulation sind die Signale innerhalb der ablesegenauigkeit absolut synchron. Naja, jetzt weiß ich nicht welche Angabe richtig ist. Beide Signale sind Ausgänge von FFs bei dem einen ist noch ein Tristate-Buffer dazwischen. Eigentlich sollen die Signale synchron sein. Wie genau kann man sich eigentlich auf diese Angaben verlassen? Ich meine wenn 5 ns angegeben sind können es sicher auch im Aufbau 4,9ns sein. Aber wie groß ist die Ungenauigkeit da mal nur von der CPLD her? (Also unabhängig von Lastimpedanz am ausgang) Viele Grüße, Christian
Bei der Post-Fit Simulation mußt Du die SDF-Datei angeben, damit die Simulation wirklich das berechnete Timing verwendet. Vielleicht wurde das vergessen. Bezüglich der Genauigkeit wird von dem Hersteller meist ein Worst-Case angegeben, die wirklichen Signale sind schneller. Bei den internen Signalen kann der Hersteller diese auch relativ ganau bestimmen, weil die elektrischen Verhältnisse genau bekannt sind. Bei den Signalen die nach außen gehen, kann man prinzipiell keine so genauen Werte angeben, weil die Signale in Wirklichkeit nicht rechteckig sind. Versuch einmal, mit einem Oszilloskop den Unterschied zwischen 4.9 ns und 5.0 ns zu verifizieren, wenn du vielleicht Anstiegszeiten von 500 ps oder mehr siehst. Bei langsamen Signalen (< 100 MHz) wird man ausreichend Luft lassen, wenn Du theoretisch 10 ns brauchst, und die Tools Dir 9.9 ns geben bist Du schon zu eng. Bei schnellen Designs muß man mittels eigener Werkzeuge (Mentor HyperLynx) die Signale berechnen und damit das Layout und das Design hintrimmen. Klaus
Das Design soll mit 50MHz laufen. Es soll ein SRAM beschrieben werden, der einen 10ns writecycle hat. Wie viel wäre denn ausreichend luft? Ich wollte auf etwa 3ns hinarbeiten, aber im Moment habe ich Probleme das Ergebnis richtig zu lesen. Ich weiß nicht wie viel luft das jetzt wirklich ist. Die 4,9ns waren auch nur ein Beispiel. Ich habe ja keine Ahnung wie genau das ist. Mir geht es hier darum ob ich mich darauf verlassen kann, dass die verzögerung 5 ns ist und nicht vielleicht nur 2 ns. Ich meine wenn der writeenable puls dann zu kurz ist werden die Daten ja evtl nicht richtig geschrieben. Kannst du mir erklären wo ich diese Datei einbinden muss? Bei Properties konnte ich nichts finden. Bei Add Source wird dieser Dateityp nicht unterstützt, deshalb habe ich das bleiben lassen. Was mich jetzt aber ein wenig irritiert ist dass andere signale, und auch diese beiden Signale nicht zeitgleich mit der Taktflanke auftreten. Beide Signale (was ich oben A und B genannt habe) treten mit 4,5ns verzögerung auf. Ein anderes Signal, ist mit 7,5ns Verzögerung angegeben und man sieht auch in der pf-simu, dass es 7,5 ns Verzögerung hat. Was ist mit worst case eigentlich gemeint? worst case im sinne von "Chip ist so grade eben an fertigungstoleranzen vorbei gekommen" oder worst case im Sinne "bei den und den Zuständen dieses Designs im cpld"? Bisher habe ich es so verstanden als ob die erste Interpretation gemeint ist. Wenn es die 2. ist würde das einiges erklären. Christian
Welchen Simulator verwendest Du. Ich glaube der ISE Simulator macht das dann automatisch, beim Modelsim gibt es bei den Simulationsoptionen einen TAB, den genauen Menupunkt weiss ich leider jetzt nicht anuswendig. Worst Case heißt, daß alle gelieferten Chips garantiert besser sind als der angegebene Wert. Da können aufgrund der Fertigungstoleranzen Exemplare dabei sein, die gerade noch durchgehen, und andere die viel besser sind. Wenn Du ein genaues Input/Output Timing brauchst, solltest Du mit den OFFSET Constraints arbeiten. Du mußt aber beachet, daß diese sich auf den INTERNEN Takt beziehen. Die Zugriffszeit von 10 ns auszunützen, ist nicht ganz trivial, weil sich die 10 ns auf das WR-Signal, bwz. die Adress-Signale des SRAMs beziehen. Unterschiedlicher Verzögerungen können mehrere Ursachen haben. - Tristate Übergänge vom Hochohmig auf gültig sind z.B. langsamer als nicht tri-state Treiber von 0 aus 1. - Signal A ist ein direkter Ausgang aus einem FF Signal B hat zusätzliche Logik zwischen FF und Ausgang, z.B. von eine UND oder ODER verknüpfung. Klaus
Hallo Klaus,v Bisher verwende ich nur den in ISE integrierten. Der Andere war mir bisher zu Kompliziert bzw ich weiß noch nicht wie man ihn bediehnt. Das Datenblatt meines SRAMS habe ich verstanden als ob für einen Schreibvorgang einfach nur für 10ns WE low sein muss. Dabei müssen Adresse und Daten einen festen definierten Wert haben. Bevor und nachdem WE low ist müssen keine Daten anliegen, wie lange sie es trotzdem tun ist egal. (Lesen will ich nicht mit der Geschwindigkeit. Vermutlich ehr im Bereich von 125kHz.) Von daher dachte ich, dass ich nur drauf achten muss, dass der Schreibimpuls eine größere Verzögerung hat als die Adresse und die Daten. Ist diese Argumentation so richtig? Jetzt da du es sagst sehe ich auch, dass die Verzögerungen bei der Umschaltung Z<->1/0 die angegebenen 12,7ns sind. Ist das schon die Erklärung des Wiederspruchs? Im Simulator sehen die Signale auch alle aus, als ob sie die Timingvorgaben des RAMS erfüllen. Der Schreibimpuls das Ergebnis eines NAND-Gatters das den Ausgang eines FFs und den Globalen Takt als Eingang hat. Dem sind 2 Verzögerungen angegeben. Einmal 7,5ns (sieht man auch in der Simu) einmal 12,7ns (vermutlich bei umschaltung des FFs?). Was sind denn genau Offset Constraints? Gebe ich vor wie viel Verzögerung ein Signal mindestens zum Takt haben muss? Christian
> Von daher dachte ich, dass ich nur drauf achten muss, dass der > Schreibimpuls eine größere Verzögerung hat als die Adresse und die > Daten. Ist diese Argumentation so richtig? Prinzipiell ja, im Datenblatt wird auch angegeben sein, wieviel Zeit die Daten vor dem WE-Pulse gültig sein müssen. > Jetzt da du es sagst sehe ich auch, dass die Verzögerungen bei der > Umschaltung Z<->1/0 die angegebenen 12,7ns sind. Ist das schon die > Erklärung des Wiederspruchs? Denke schon. > Der Schreibimpuls das Ergebnis eines NAND-Gatters das den Ausgang eines > FFs und den Globalen Takt als Eingang hat. Dem sind 2 Verzögerungen > angegeben. Einmal 7,5ns (sieht man auch in der Simu) einmal 12,7ns > (vermutlich bei umschaltung des FFs?). Du mußt vielleicht aufpassen, daß es dabei nicht zu Glitches kommt > Was sind denn genau Offset Constraints? Gebe ich vor wie viel > Verzögerung ein Signal mindestens zum Takt haben muss? Es gibt OFFSET OUT constraints und OFFSET IN constraits. OFFSET OUT Constraints geben an, nach wievielen ns nach dem Clock ein Signal spätestens am Ausgang erscheinen soll. Damit würde dich das Tool z.B. warnen, wenn es nicht imstande ist dein WE-Signal, das nach dem Takt nocheinmal kombinatorisch verknüpft ist, schnell genug zu machen. OFFSET IN Constraints geben an, wieviel Zeit vor dem Takt Signal ein externes Signal am Pin gültig ist. Damit kann das Tool kontrollieren, ob die Setup-Zeit eingehalten wird.
> Prinzipiell ja, im Datenblatt wird auch angegeben sein, wieviel Zeit die > Daten vor dem WE-Pulse gültig sein müssen. Wie ich es verstanden habe 0ns > Denke schon. Gut. > Du mußt vielleicht aufpassen, daß es dabei nicht zu Glitches kommt In der Simulation sieht es aus, als ob das am Anfang und am Ende mal vorkommt. Das wäre aber nicht so schlimm. Es wäre nicht schlecht, wenn der Zähler erst nach 10 Takten oder so losläuft. Auch wegen der restlichen Elektronik. Vielleicht kann ich das extern machen, indem ich den Reset ein wenig später auslöse. Werde ich gleich mal ausprobieren. Eine automatische Lösung wäre auch schön, aber da habe ich noch keine Idee wie ich das realiesieren soll. >> Was sind denn genau Offset Constraints? Gebe ich vor wie viel >> Verzögerung ein Signal mindestens zum Takt haben muss? > Es gibt OFFSET OUT constraints und OFFSET IN constraits. > OFFSET OUT Constraints geben an, nach wievielen ns nach dem Clock ein > Signal spätestens am Ausgang erscheinen soll. Damit würde dich das Tool > z.B. warnen, wenn es nicht imstande ist dein WE-Signal, das nach dem > Takt nocheinmal kombinatorisch verknüpft ist, schnell genug zu machen. > OFFSET IN Constraints geben an, wieviel Zeit vor dem Takt Signal ein > externes Signal am Pin gültig ist. Damit kann das Tool kontrollieren, ob > die Setup-Zeit eingehalten wird. Gibt es auch ein Constraint für minimale Verzögerung? Also wie viele ms ein Signal mindestens braucht bis es am Ausgang ist? Ich meine, wenn 10ns angegeben sind, es aber schon nach 2 da ist helfen mir die anderen Constraints ja nicht so viel.
> Gibt es auch ein Constraint für minimale Verzögerung? Also wie viele ms > ein Signal mindestens braucht bis es am Ausgang ist? Nicht daß ich wüßte. Es werden immmer nur Maximal-Zeiten angegeben. Ein Grund dafür ist auch, daß sich die Hersteller die Möglichkeit offen lassen, jederzeit durch verbesserte Produktionsprozesse die Bausteine schneller zu machen. Außerdem hängen die Verzögerungszeiten von Tempertur und Versorgungsspannung ab. Weil man aber doch machmal definierte Verzögerungen braucht, haben moderne FPGAs programmierbare Verzögerungen in den Ausgangs- und Eingangsbuffern, welche so konstruiert sind, daß sie von Spannung und Temperatur relativ unabhängig sind.
Bitte 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.