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
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
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
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
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
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
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
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
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
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
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.
@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
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.
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
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.
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)
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.