Forum: FPGA, VHDL & Co. Wie aussagekräftig ist die Timinganalyse


von Hagen (Gast)


Angehängte Dateien:

Lesenswert?

Hi Leute,

ich habe wiedermal Zeit gefunden um an meinem VGA Controller für den
AVR zu basteln. Kurz umrissen geht es darum:

ATMega128 wird per XMEM Interface an einen Altera MAX7128S CPLD
angeschlossen. Der CPLD soll mit 50Mhz getaktet werden. Am CPLD hängt
ein >= 64Kb SRAM mit < 20ns Zugriffszeit. Der CPLD übernimmt dabei
mehrere Aufgaben:
1.) VGA Text-Controller für Standard VGA 80x25 bis 80x30 mit 16
Hintergrund- und 16 Vordergrundfarben pro ASCII Zeichen. Die ASCII
zeichen sind über eine Zeichentabelle mit 8x16 Pixeln definiert.
Pixelclock ist 25 Mhz.
2.) Address Latch für die untersten 8 Bits des Addressbusses
3.) Address Dekoder für 6 externe Geräte um diese Memory Mapped
anzusteuern
4.) Memory Controller damit AVR und VGA Karte simultanen Zugriff auf
den externen SRAM haben. Die VGA Karte benötigt ja ihren Bildschirm
speicher.

Nun zu meinen zwei Fragen:

1.) wenn in der Timing Simulation für Clock eine maximale Taktfrequenz
von 53.19MHz ausgerechnet wird, inwieweit ist das schon zu kritisch für
die 50Mhz die ich real benutzen möchte. Ich weis das dies eng ist, aber
kann man sich auf die Timinganalyse verlassen ?
Falls nein brauch ich erst garnicht das Ding real aufbauen.

2.) das VHDL benutzt ALE,WR und Clock als Clocksignale, sind also
synchron. Alledings sind die Clocks ALE,WR nicht synchron zur Clock.
Denoch müssen in alle drei Clocks untereinander auf gleiche Signale
zugegriffen werden.

Geht das besser ? und wie dann bitte ?

Die Simulation macht aber exakt das was sie machen soll.

Gruß Hagen

von Sven Johannes (Gast)


Lesenswert?

Moin...

Zumindestens benutzt kein Prozess mehrere Trigger in der sensitivity
List, asynchron ist das Design trotzdem. Ich habe das jetzt nicht ganz
überblickt, aber änderst du Signale in einem Prozess und fragst diese
in einem Anderen wieder ab? Kommt nicht so gut, da drohen metastabile
Zustände. Kannst du zeitlich Beziehungen zwischen den Takten
formulieren? Wenn ja müssen die in die Constraints aufgenommen werden.

Vielleicht solltest du noch versuchen diese Reihe geschachtelter if
Anweisungen zu verkürzen. ISt für die Software wohl nicht ideal.

Die Timinganalyse ist ansonten sehr gut, wenn du Modelsim das Zeitmodel
mitbekommt, beim Aufruf aus dem ISE passiert das automatisch.

--
 Sven Johannes

von Hagen (Gast)


Angehängte Dateien:

Lesenswert?

Danke für deine Mühen mal in den Source rein zu schauen, scheint ja kein
Anderer dazu bereit zu sein (trotz der Downloads, schade eigentlich)

>> Zumindestens benutzt kein Prozess mehrere Trigger in der
>> sensitivity List,

Naja soviel habe ich als "Anfänger" nun schon begriffen ;)

>>asynchron ist das Design trotzdem.

Ja ist es.

>> Ich habe das jetzt nicht ganz überblickt, aber änderst du Signale
>> in  einem Prozess und fragst diese in einem Anderen wieder ab?

Ja, muß ich leider, und ich wüsste auch nicht wie man gemeinsamme
Signale/Latches etc. in zwei getrennten Clockdomains untereinander
synchronmisieren kann (zumindestens nicht für einen 128FF CPLD, auf
FPGAs hat man ja ausreichend Resourcen).

>> Kommt nicht so gut, da drohen metastabile Zustände. Kannst du
>> zeitlich  Beziehungen zwischen den Takten formulieren?

Ja kann ich. Clock ist 50 MHz, davon intern halbiert 25 MHz der
Pixeltakt der aber nur die VGA Zähler beeinflusst.
Extern der AVR mit maximal 16 MHz, d.h. AVR_ALE/AVR_WR/AVR_WR kommen
mit 1/3 16MHz = 5.2 MHz aber mit 33% Dutycycle.
Der SRAM wird nun per FSM mit 50Mhz angesteuert, heist 20ns pro SRAM
Zugriff sind es exakt.

Das heist ->

VGA Part hat 40ns Zyklus.
Clock +SRAM hat 20ns Zyklus.
AVR hat 63 ns Zyklus.

Aus Sicht des AVR's ist also der SRAM Zugriff 3 mal schneller, und
somit sichergestellt das der Clock-Hauptprozess nun wirklich nichts
verschlafen kann.

Da ich im Clock Prozess die Signal AVR_ALE und AVR_WR über jeweils zwei
getaktete FF's sample kann es aber sein das bei einem Read des AVR der
CPLD maximal 45ns später als die fallende Flanke vom AVR_RD die
korrekten Daten liefern kann. Allerdings bezieht sich dies auv einen
16MHz AVR ohne WaitStates. Sollte das nicht reichen würde man einfach 1
oder 2 Waitstates einfügen und so mit 63/127/189 ns Read/Write Zyklus
arbeiten.

Nun kommt noch hinzu das alle gemeinsam genutzten Signal in den 3
Clocks sich NICHT metastabil ändern können, glaube ich zumindestens.
Zb. wird das Latch befüllt durch AVR_ALE so ist es sichergestellt das
es im Clock-Hauptprocess NICHT benutzt wird, da einfach die FSM noch
nicht den entsprechenden State erreicht haben kann.
Die Low-Aktiven Phasen von AVR_ALE/AVR_WR sind mindesten 3 mal länger
als die der Clock, heist mindestens 2 vollständige Clockzyklen sind
AVR_ALE/AVR_WR aktiv.
Der SRAM Zugriff des VGA Controllers wird aber weniger priorisiert als
der des AVR's, was nicht störend ist weil der VGA Controller inerhalb
von 16 Clockzyklen nur 3 Clockzyklen benötig um seine Daten zu holen.

Greift also der AVR + VGA mit maximaler Geschwindigkeit auf den SRAM so
wird der SRAM nur ca. 1/3'tel der Laufzeit real angesprochen.
Man, es ist echt schwierig sowas in Worte zu fassen, deshalb anbei mal
ein Timing Diagram.

Du siehst 2 Lesezugriffe des AVR's + 1 Schreibzugriff des AVR's.
Im markierten Bereich von 360ns = 18 Clockzyklen = 9 Pixeltakte = 9
Pixel eines ASCII Zeichens, sieht man das maximal 6 Clockzyklen auf den
SRAM zugegriffen werden kann. Also nur maximal 33% der Zeit zur
Darstellung eines Pixels wird auf den SRAM zugegriffen. Die FSM des
Memorycontrollers stellt dabei sicher das der AVR immer höher
priorisiert wird. Die sich überlappenden Speicherzugriffe des VGA
Controllers werden durch die FSM entsprechend verzögert. Die FSM des
Memoryzufgriffes hat also durchschnittlich 18-3 = 15 Clockzyklen Zeit
um die nächsten 3 Datenbytes für den VGA Controller aus dem SRAM zu
lesen. Der Memorycontroller nimmt dabei das AVR_ALE Signal als Event um
spekulativ den Lesezyklus für den AVR zu starten. Also auch wenn der AVR
garnicht den SRAM lesen möchte, aber über AVR_ALE den Addressbus
anspricht liest die FSM denoch das entsprechende Datenbyte aus dem
SRAM. Das mache ich damit bei einem realen Lesezugriff's des AVR's
schon frühzeitiger die Daten zur Verfügung stehen. Bei einem
Schreibzugriff des AVR's wird nach diesem Zugriff ein
Dummy-Wait-Zyklus eingelegt damit SRAM_Data ausreichend Zeit hat auf
High-Z zu gehen und so Buskonflikte zu vermeiden.
Wie gesagt dasDiagram zeigt Clock = 50Mz, Pixeldarstellung von zwei
ACSII Zeichen mit 25Mhz, Speicherzugriffe mit 20ns, AVR liest Addresse
0x3FFFF das Datenbyte 0xFF, danach 3 Lesezugriffe der VGA, dann AVR
Addresse 0x02099 = 0xEE, dann nächtes Pixel + AVR Schreib/Lese Zugriff
mit eingefügtem Wait-Zyklus nach dem schreiben des SRAM's.


Denoch, die Frage ist ob man das Design überhaupt komplett synchron
bekommen kann OHNE die Antwortzeiten des CPLD's auf den AVR noch
stärker zu verlängern. Immerhin, eine wichtige Grundbedingung habe ich
nicht erwähnt: ich habe hier mehrere MAX7812S-10ns rumliegen und diesen
MUSS ich verbauen. D.h. das Target steht von Anfang an fest und somit
haben ich nur 128 Makrozellen Spielraum. Obiger Code benötigt 125
Makrozellen.


>> Vielleicht solltest du noch versuchen diese Reihe geschachtelter if
>> Anweisungen zu verkürzen. ISt für die Software wohl nicht ideal.

Habe ich alles schon probiert, auch die Variablen im Prozess hatte ich
schon als Signale deklariert. Aber egal was ich anstellte das jetzige
Design ist das kompakteste. Nehme ich ausschließlich den VGA Part, ohne
SRAM,AVR etc. und alles in Signalen, vollsynchron, so komme ich trotzdem
nur auf 55 MHz Laufzeit. Die jetzigen 53.19MHz sind also für die
erzielte Markozellen Einsparungen durch die lokalen Variablen
garnichtmalso schlecht.

Mir wird wohl nichts anderes übrigbleiben und das Design in real zu
testen.

Gruß Hagen

von Hagen (Gast)


Lesenswert?

Das einzigste Synchronisatins-Problem das ich in einem älteren Design
hatte war das der Clock-Hauptprocess Read/Write Events des AVR's
verschluckte. Die FSM also nicht auf Lese/Schreib Anforderungen des
AVR's reagierte. Dies habe ich aber gelösst über die 2 FF's
CurAVR_ALE/LastAVR_ALE die AVR_ALE im Hauptprocess sampeln.

Im Diagram sieht man auch sehr schön das das interne Latch das AVR_AL
und die SRAM_Addr bei ZUgriffen des AVR's befüllt zwar asynchron und
Clockübergreifend ist, aber durch die FSM denoch niemals parallel zu
metastabilen Zuständen führen kann. Dies sieht man bei der zweiten
Markierung bei +360ns. Bei AVR_ALE'Low wird Latch gefüllt mit 0x88.
Zusammen mit BankSelect + AVR_AH ergibt sich so die SRAM_Addr =
0x3_8888. Beim Lesezgriff der FSM um die Daten für den AVR zu holen ist
AVR_ALE aber schon wieder längst Low und Latch kann nicht mehr geändert
werden. Da die FSM aber erst den Leseprozess startet wenn AVR_ALE
zweimal mit 20ns gesampelt wurde ist sichergestellt das Latch entweder
durch AVR_ALE'High->Low gefüllt wird oder aber unverändert nur lesen
im Clockprocess=FSM benutzt wird.

Das Design ist also asynchron, aber auf Grund der äußeren Bedingungen
meine ich das das kein Problem darstellen sollte. Ich weiß es aber eben
nichtund deshalb meine Frage ob 53.19MHz als Timinganalyse eine sicherer
Aussage darstellen das man das Design mit 50Mhz takten kann.

Im Diagram sieht man leider nicht was passiert falls zb AVR_ALE/AVR_WR
exakt zum Zeitpunkt einer fallenden/steigenden Clockflanke eintreffen.
Ich habe das alles schon simuliert und auch da verhielt sich alles
sauber.

Gruß Hagen

von Hagen (Gast)


Lesenswert?

Achso vielleicht noch zur Ergänzung. Ich habe das Design auch schon auf
einem 15ns CPLD simuliert. Die Timing Analyse sagte aus das Clock
maximal 45 MHz sein darf. Ich habe aber mit 50Mhz simuliert und denoch
funktionierte alles so wie es sein sollte !

Gruß Hagen

von Hagen (Gast)


Angehängte Dateien:

Lesenswert?

Für diejenigen die mir eventuell noch einige Fragen beantworten wollen
hier das komplette QuartusII 4.1 Projekt. Das VHDL wurde geändert um
256Kb SRAM in Pages ansprechen zu können.

Gruß Hagen

von high_speed (Gast)


Lesenswert?

Hallo Hagen

> mal in den Source rein zu schauen, scheint ja kein
> Anderer dazu bereit zu sein (trotz der Downloads, schade eigentlich)

Wir Menschen sind eben immer noch Jäger und Sammler.
Wenn es etwas um sonst gibt.

Bei mir benötigt deine „VGA-Karte“ 128 Macrocells von 128.
Liegt wahrscheinlich an der Lizenz.

Von dem Timing sieht es nach meiner Meinung nicht ganz so schlecht
aus.
Bei der Timinganalyse werden doch die schlechtesten Signale
aufgelistet.
Man sieht zum mindestens noch nichts rotes.

Bei den Einstellungen hast du nur für ein einziges Signal die Frequenz
festgelegt. (Clock)
In deinem Design tauchen aber unterschiedliche Taktanforderungen auf.

Bei mir waren schon teilweise einige Signale rot bei der Timinganalyse,
aber auf der Zielhartwehr lief es unter normalen Bedingungen (20°C,
....) ohne Fehler.
Bei dem Design hatte ich auch schon in die Trickkiste gegriffen.
(Vierfachabtastung eines seriellen Datenstroms mit 2 Clock-Signalen
[0°, 90°] aus einer PLL.)

Die Timinganalysewerte habe ich dann durch gezieltes setzen von
Timinganforderungen verbessern können.
Woher soll der „Fitter“ wissen, wie schnell externe Signale sind?

MfG
Holger

von Hagen (Gast)


Lesenswert?

Danke Holger,

zusammengefasst bist du also der Meinung das ich es wagen könnte für
dieses Design mich an die Arbeit zu machen und ein Board zu routen.

>Bei mir benötigt deine ?VGA-Karte? 128 Macrocells von 128.
>Liegt wahrscheinlich an der Lizenz.

Nee, das ist Version 2 :) das erste VHDL in diesem Thread kann nur 64Kb
SRAM ansprechen, dafür aber 6 externe Geräte.
Das habe ich auf 4 reduziert zugunsten eines 256Kb SRAMs + Memory Bank
Controller im CPLD.

Die Clocks und Constraints hatte ich alle schon deklariert gehabt.
Allerdings, so wie jetzt ohne jegliche Restriktion hat der Fitter eben
mehr Möglichkeiten der Optimierung. Deshalb habe ichs für diese
Simulation wieder rausgenommen. Es gibt aber im Grunde keinerlei
Unterschiede, egal mit oder ohne Clock Constraints, es wird exakt die
gleiche Simulation.

Die Clocks AVR_ALE/AVR_WR haben eh in der Timing Analyse mit 100Mhz den
maximalen Takt erzielt. Also braucht man diese doch nicht mit 16Mhz in
den Constraints vorgeben, oder ?

Gruß Hagen

von Sven Johannes (Gast)


Lesenswert?

Moin...

Bei den Constraints  geht es besonders darum das die Software die
Taktdomänen gegeneinader prüft. Also die Takte gegeneinander, die
Geschwindigkeit eines einzelnen Taktes ist eher uninteressant.

Leider kann ich mich nicht weiter in den Code einarbeiten, morgen um 4
gehts auf die Bahn.... seid fünf Jahren mal wieder so etwas wie
Urlaub!!

--
 Sven Johannes

von Dirk (Gast)


Lesenswert?

Hi,

ich habe mir mal dein VHDL File gesaugt. Beim synthsieren kriege ich
aber leider immer eine Fehlermeldung.

Er meckert in der Zeile 238 rum (Pixel is not 9).

Haettest du einen kleinen Tipp. Ich bin nebenbei beim VHDL + FPGA
lernen und bis jetzt haben deine Programme mir mehr geholfen als andere
Programme.

Ich finde deinen Code irgendwie verstaendlicher als andere Sachen die
ich so finde.

Gruß,

Dirk

von FPGA-User (der andere) (Gast)


Lesenswert?

Hallo Hagen,

hab mal kürz über vga.vhd geschaut, mir ist folgendes aufgefallen:

Du fragst den Wert von 4 Variablen ab, bevor Du den Variablen
einen Wert zuweist. Damit verhalten sie sich wie Signale, also
es werden Register produziert.

    variable NextColor...
    variable NextPixel...
    variable NextPixel9...
    variable InsertPixel9...

Ich nehme an, das ist so beabsichtigt, oder ?
Also Dir ist klar, dass sich das Verhalten ändert, wenn man
den Teil

case State is...

unmittelbar an den Anfang des Prozesses stellt.
Dann wird aus den Registern wieder reine Kombinatorik, da
den Variablen zuerst ein Wert zugewiesen wird und dann die
Abfrage erfolgt.

War mir nur aufgefallen, weil ich Variablen in VHDL generell
nur für Kombinatorik verwende, also immer zuerst die Zuweisung
der Variable mache und dann den Wert abfrage.

von Hagen (Gast)


Lesenswert?

@FPGA-User:

das mit den Variablen und dem State ist mir bewusst. Anfangs MUSSTE ich
so vorgehen weil die VGA Datenreichenfolge im Speicher eine andere war.
Wie bei Standard VGA üblich hatte ich die Bytes Farbe+ASCII im SRAM
gespeichert, was beim Lesen des SRAM's dazu führte das ich
Farbe+ASCII+Zeichentabelle-ASCII-Pixel gelesen habe. Nun, nach dem
Lesen des ASCII Wertes benötigte ich desse Wert im Prozess sofort um
die korrekte Addresse erzeugen zu können um dessen Pixeldaten aus der
Zeichentabelle lesen zu können. Wäre NextPixel also ein ordinäres
Signal dann müsste ich den Zugriff darauf um daraus die Addresse zum
Zugriff auf die Zeichentabelle zu erzeugen, um 1 Clock Takt
verschieben.

Da im neuen Design aber die Datenbytes andersherum gespeichert werden,
sprich ASCII+Farbe, ergibt sich nun ein andere Speicherzugriff ->
ASCII,Farbe,Pixel. Somit ist sichergestellt das NextPixel := ASCII und
NextPixel := ASCII immer ein Clock Takt für NextColor dazwischen
liegt.

Im neuen VHDL könnte man also sehr wohl alles wieder auf Signal
umstellen OHNE Probleme damit zu bekommen. ABER! es zeigte sich das die
Variablen ca. 1-2 FF's im Design einsparen, und bei nur 128FF's die
zur Verfügung stehen sind diese FF's sehr wohl relevant.
Der max. Takt des Design beträgt mit Signalen 55.5MHz und mit Variablen
53.19MHz, also nur 2MHz langsammer, dafür aber 2 FF's weniger
Resourcen.

Wie gegsagt Grundbedingung ist das Verbauen eines MAX7182S-10ns, ich
weiß keine so gute Herangehensweise, aber als Hobbyist verbaut man das
was man kostenlos bekommen kann.

@Dirk:

Im neuen VHDL, oben komplett als ZIP gepostet steht an Zeile 238 bei
mir ein "else".
Ich habe aber eigentlich alles soweit komplett getestet. Falls du die
ältere Version gemeint hast so ist es wichtig die korrekten
Einstellungen im QuartusII für die Synthese + Fitting zu benutzen. Lade
am besten das ZIP runter und schaue dir dort die Einstellunge genauer
an.

Ansonsten danke für dein Kompliment, ja auch wenn ich selber Anfänger
in VHDL bin, so ist mir exakt das Gleiche wir dir an anderen VHDL
Sourcen aufgefallen. Die meisten Coder in VHDL sind noch schlechter als
C/C++ Coder, deren Source konnte auch ich nicht verstehen weil sie viel
zu unübersichtlich schreiben.
Ich programmiere halt schon über 20 Jahre auf Computern professionell,
von daher kommt eventuell meine Disziplin relativ sauberen Source zu
schreiben. Nur, nützt dies leider nichts wenn die Logik NICHT korrekt
ist.
Beachte also das ich bei diesem Projekt logisch nicht alles richtig
programmieren konnte, weil ich ständig Kompromisse machen musste.
Vollsynchron ist das Design also nicht, aber auf Grund der äußeren
Bedingungen sollte es nie zu metastabilen Zuständen kommen. Das
Problemist einfach das man kompliziertere äußere Abhängigkeiten in der
Simulation/Fitting leider nicht vorgeben kann. Zb. AVR_WR,AVR_RD sind
immer HIGH solange AVR_ALE HIGH ist. Oder nur AVR_WR oder AVR_RD kann
LOW sein aber niemals beide gemeinsam. Oder wärend der Fallenden Flanke
vom AVR_ALE in der das Register Latch gefüllt wird kann NIEMALS im Clock
Prozesse dieses Latch Register für einen sinnvollen Zugriff auf den SRAM
benutzt. Latch wird zwar permanent verwendet in diesem Prozess aber eben
sinnvoller Weise immer nur dann wenn AVR_ALE nicht den Latch befüllt.
Es gibt also viele logische Zusammenhänge der angelegten Signale die
man dem Fitter/Simulator so nicht mitteilen kann. bzw. ich weis nicht
wie man es ansonsten deklarieren könnte so das Quartus damit was
anfangen kann.

Gruß Hagen

von FPGA-User (Gast)


Lesenswert?

Hallo Hagen,

dass die Variablen FFs sparen würde ich verstehen, wenn Sie
Kombinatorik erzeugen aber nicht wenn aufgrund der Beschreibung
wieder FFs generiert werden.
Wie auch immer - Hauptsache die Simulation funktioniert und
die 128 Macrozellen reichen. Die Herangehensweise kann ich
schon nachvollziehen, hatte mir auch mal zum Ziel gesetzt,
einen 7-stelligen Frequenzzähler (multiplex, inkl. BCD-zu
7-Segment-Decoder und Zeitbasisteiler) in einem XC9572
zu realisieren und siehe da - mit einigen Tricks gings.

Bei den Timing-Constraints kann man eigentlich alles vorgeben,
was nötig ist, um es dem Fitter so einfach wie möglich zu
machen. Wichtig ist, dass man langsamen Pfaden auch ein
Constraint verpasst, dann muss sich der Fitter dort nicht
soviel Mühe geben und kann woanders evt. ein besseres Timing
erreichen.

Übrigens, wenn die Timing-Analyse 50.0 MHz sagt, dann hätte ich
keine Angst, das Deisgn auch mit 50 MHz zu betreiben.
Die Timing-Analyse wird für min. Betr-Spannung und max. Temp
gemacht, also darauf ist normalerweise Verlass.
Die Taktfrequenz gilt aber nur für die Design-Teile die auch
mit einem Takt laufen.
Du hast hoffentlich auch Constraints für reine Kombinatorik
gesetzt, falls es diese gibt.

von Hagen (Gast)


Lesenswert?

Endlich mal eine klare Aussage, danke FPGA-User (der andere???) oder
(der NICHT-andere ???)

Das mit dem Setzen der Constraints ist so eine Sache. In QuartusII gibt
es diese Möglichkeit an mehreren Stellen was schonmal verwirrend sein
kann. Desweiteren kann man beim Setzen dieser Constraints eben nicht
erkennen ob diese nun Einfluß auf die Synthese, den Fitter, die
Simulation, dem Design-Assistent oder nur rein Informativ und somit
garkeinen Einfluß haben.

Aber für mein Design am wichtigsten wären Constraints der Art:

"AVR_ALE = High->Low dann kann AVR_WR oder AVR_RD erst frühestens nach
32.5ns auf Low fallen". Oder:
"Signal Latch ist zur Addressbildung nur relevant wenn es in SRAM_Addr
eingerechnet wird und SRAM_OE oder SRAM_WR auf Low fallen, ansonsten
darf Latch asynchron durch AVR_ALE'Event geschrieben werden".

Wo definiert man sowas ? Denn das wäre nötig um 100% vollständige
Constrains basteln zu können.

Ich verstehe schon das der reine VHDL nichts, auch wirklich nichts, mit
dem eigentlichen Fitting zu tuen hat, bzw. das die korrekte Einstellung
und Deklaration von Constraints die eigentlich mühsehlige Aufgabe
darstellt wenn man es richtig machen möchte. Leider ist aber gerade
dieser Punkt nicht Standardisiert oder so unübersichtlich in den Tools
gelösst das man viel länger benötigt diese zu tunen als den VHDL zu
schreiben.

Alleine schon das Pinning in Quartus II war kompliziert, ist nämlich
schon aufwendig wenn man nirgendswo bei Altera ein PDF mit den
Bennamten Pinning aller P/TQPF's >= 100 Pins findet. Das muss man dann
per Hand in den Ausdruck auf Papier eintragen. Kostet alles unnötigen
Streß und Zeit.

Gruß Hagen

von FPGA-User (Quarkus) (Gast)


Lesenswert?

Quarkus ist mir als Ableitung von Quartus eingefallen ...

das Setzen von Timing-Constraints im Quartus II
ist eine absolute KATASTROPHE, das muss mal so gesagt
werden.
Hier hat man krampfhaft versucht, alle möglichen Einstellungen
über die Oberfläche machen zu können, und mit der Zeit hat
sich das ganze so aufgebläht, dass jeder Anfänger den
Überblick verliert. Es gibt sage und schreibe 23 verschiedene
Timing-Constraints und allein schon in der IDE 4 (!) Möglichkeiten,
Timing-Contraints zu definieren (Assignments) :
-> Timing Settings
-> Settings
-> Timing Wizard
-> Assignment Editor
Abgesehen davon gibt es mindestens noch die 3 Möglichkeiten, das
*.qsf-File per Hand zu ändern und TCL-Kommandos in der IDE
einzugeben oder ein TCL-Script auszuführen.
Jede der nun schon 7 Varianten bietet unterschiedliche Möglichkeiten!

Dazu kommt noch der Menü-Punkt "Time Groups" in Assignments.

Ich kann da keine Empfehlung abgeben, probiers doch erstmal
über die Oberfläche mit Assignments -> Assignment Editor -> Timing
und definiere dort z.B. ein TPD_REQUIREMENT für die Laufzeit
AVR_ALE nach AVR_WR von 32 ns.
Die Signale in FROM und TO kann man sich mit dem "Node Finder"
anzeigen lassen, oder Du gibst sie per Hand ein, das geht schneller.

Am Ende müsste das Constraint im *.qsf-File landen, dort würde
ich die Zeile für weitere solcher Constraints einfach kopieren.

Schau mal in der Hilfe unter Inhalt -> Running Timing Analysis
-> Making Individual Timing Assignments,
dort findet sich unter "Assignment Name" schliesslich die
Liste aller mögl. Timing Constraints.

Das geniale ist, dass man im Assignment Editor ohne weiteres
Constraints setzen kann, die völlig unsinnig sind bzw. die
schon rein von der Zuordnung FROM - TO - CONSTRAINT nicht
gehen und damit später ignoriert werden !

Das einzige Dokument, dass ich bei ALTERA zum Thema empfehlen
kann ist "Quartus II Timing Analysis" :
http://www.altera.com/literature/hb/qts/qts_qii53004.pdf

da steht aber auch nicht alles drin...

Also viel mehr fällt mir nicht ein, probier einfach mal was aus.

von Hagen (Gast)


Lesenswert?

Time Groups habe ich schon drinnen.
Clocks habe ich schon drinnen.
Einzigste was fehlt sind:
- Pin Assignment, da ich dies erstmal später machen will
- TPD Requierements, das ist das was ich als nächstes definieren werde,
da ich damit noch nichts anfangen konnte.

Ansonsten Danke für deine Hilfe, hat mich in doppelter Hinsicht
weitergebracht. Erstens was neues gelernt und zweites in meiner Meinung
über Quartus in diesem Punkt bestätigt.

Gruß Hagen (ein dummes Kalb)

von Hagen (Gast)


Angehängte Dateien:

Lesenswert?

eine sehr wichtige Frage habe ich noch.

Also beim Lesen vom SRAM_Data Bus innerhalb des Clock Prozesses dauert
die SRAM_OE Phase exakt 20ns, logisch bei 20ns Clock Takt. Aber der
SRAM_Data Bus wird nach 10ns wenn SRAM_OE auf Low geht gesampelt. Das
bedeutet für mich das ich unbedingt einen SRAM nehmen muß der maximal
10ns Zugriffszeit hat, da ansonsten der Clock Prozess die falschen
Werte am Bus sampelt. Die komplette Zugriffszeit im Clock Process ist
aber 20ns lang.

Wie und Wo kann ich nun in den Constraint festlegen das SRAM_Data zb.
erst nach zb. 15ns oder 18ns gesampelt wird ?

Im obigen Screenshot beginnt der Leseprocess bei 450ns, gesampelt wird
bei +10ns der Wert 0xEE, ich möchte aber das erst später gesampelt wird
so das eben der Wert 0xFF an AVR_Data~Result statt 0xEE erscheint.

Gruß Hagen

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.