Forum: FPGA, VHDL & Co. Nochmal Timings bei CPLD


von Christian H. (cavorca)


Lesenswert?

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

von Klaus Falser (Gast)


Lesenswert?

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

von Christian H. (cavorca)


Lesenswert?

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

von Klaus Falser (Gast)


Lesenswert?

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

von Christian H. (cavorca)


Lesenswert?

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 Klaus Falser (Gast)


Lesenswert?

> 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.


von Christian H. (cavorca)


Lesenswert?

> 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.

von Klaus Falser (Gast)


Lesenswert?

> 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
Noch kein Account? Hier anmelden.