Da ich demnächst bei Reichelt bestelle wollte ich mir auch gleich mal einen alternativen Ozillator fürmein FPGA Board holen, bin aber etwas unsicher ob man da einfach die "Standard" Kästchen nehmen kann? Im Userguide steht leider nur, das jeder 8-Pin Oszilator "vom Sockel aktzeptiert wird, welcher dort reinpaßt" und das man auf Pin 1 achten soll... Bevor ich jezt was kaputt spiele wollt ich mal nachfragen ob es auser "paßt in den Sockel" noch andere Anforderungen an die Taktquelle für den FPGA gibt?
Sieh mal an Pin 8 nach, welche Spannung du für den Oszillator brauchst - 3,3 oder 5 V.
> welche Spannung du für den Oszillator brauchst Alternativ: Sieh im Datenblatt vom FPGA nach, welche Eingangsspannung am CLK-Pin auftauchen darf. Du solltest eher mit einer niedrigen Frequenz ins FPGA fahren, höhere Frequenzen machst du auf dem FPGA mit DCM, DLL & Co. Ich halte die externe Taktfrequenz (wegen Störstrahlung) unter max. 50MHz. Die restlichen Anforderungen (Temperaturstabilität, Jitter, Rauschen) definiert deine Anwendung. BTW: > den FPGA heißt korrekt: das Feldprogrammierbare Gate-Array
Also auf dem Board ist ein Oszilator mit 50Mhz drauf (Spartan 3A Starter). Es ist nur so das ich aktuell ein Design habe was laut Synthese/Place&Route max 38Mhz verträgt :-\ Schaltplan ist estwas undurchsichtig scheint aber 5V zu sein, werd ich nochmal nachmessen. Hab auch überlegt die DCM zu nutzen um mir 25Mhz zu erzeugen aber die Vielzahl an Möglichkeiten hat mich etwas abgeschreckt da ich bisher mit DCMs noch nix gemacht habe. Und natürlich das FPGA :)
Also der Spartan hat nix mit 5V. Ich glaub der hat nicht mal 5V tolerante IOs. Nur 38MHz? Was ist das denn für ein komisches Design? Alles asynchron und das FPGA total voll? Das kann ja bald nicht normal sein. Hast du mal mit Timing Contraints gearbeitet? Gib ihm doch vor, dass es mit 50MHz laufen soll, dann versucht er es zu optimieren. Beim Spartan 3 sind aber bei ordentlichen synchronen Designs Frequenzen von weit über 100Mhz drin. Es darf halt nicht so viel Kombinatorik zwischen 2 Registern sein, mal ganz einfach gesprochen.
http://www.xilinx.com/products/devkits/HW-SPAR3A-SK-UNI-G.htm Also laut Userguide hat der 3.3V, 5V und eine Einstellbare Spannung für den ADC sowie 5V tollerante Eingänge. Das "Design" ist ne Nachbau CPU(32bit) aus dem Buch "Structured Computer Organisation", das Problem dort ist, das die Register/Speicher auf der steigenden Flanke geschrieben und auf der fallenden gelesen werden (dann gehts durch die ALU etc...) dadurch rduziert sich ja schonmal die Taktrate. Hatte aber sowieso noch nen (logischen) Fehler drinn, jezt hab chs wieder auf 50Mhz hochgebracht:
1 | Timing Summary: |
2 | --------------- |
3 | Speed Grade: -4 |
4 | Minimum period: 19.652ns (Maximum Frequency: 50.885MHz) |
5 | Minimum input arrival time before clock: No path found |
6 | Maximum output required time after clock: 5.531ns |
7 | Maximum combinational path delay: No path found |
Sicher könnte man da noch optimieren indem man nicht 50:50 duty-cycle nimmt aber das spar ich mir mal für dann auf wenns einigermaßen zuverlässig funktioniert :)
> das die Register/Speicher auf der steigenden Flanke geschrieben > und auf der fallenden gelesen werden Toller Murks :-/ Dann weiß ich schon mal, welches Buch ich nicht kaufen werde.
@Lothar Miller >> das die Register/Speicher auf der steigenden Flanke geschrieben >> und auf der fallenden gelesen werden >Toller Murks :-/ >Dann weiß ich schon mal, welches Buch ich nicht kaufen werde. Halt halt, nicht vorschnell Urteilen, ich denke das gilt nur für FPGAs, da macht es wohl keinen Sinn beide Taktflanken zu verwenden, aber bei ASICs kann man durch Ausnutzen beider Taktflanken Strom sparen. Macht aber das Design aufwändiger.
Jo, auch beim CoolRunner II kann man damit jede Menge Strom sparen. Allerdings ist da sicher noch irgendwo was im argen. Übrigens diese Meldung nach der Synthese ist nicht ernst zu nehmen. Wichtig ist, was nach Implement Design rauskommt. Mir zeigt der beim Spartan 3e auch 44,6MHz an, am Ende schafft er aber problemlos 100MHz nach dem Implement.
Das mit den Unterschiedlichen FLanken mache ich zur Zeit nur um erstmal ein lauffähiges Beispiel zu bekommen, letztendlich kann wahrscheinlich alles was auf der negativen Flanke geschieht einfach als Concurrent Anweisung abgehandelt werden... Die Beschreibung in dem Buch ist halt nicht auf FPGAs ausgelegt sondern eine Theoretische Beschreibung. Hab das vieleicht etwas mißverständlich ausgedrückt, also auf der steigenden Flanke werden die Werte in die Register übernommen (kurzer Puls), auf der fallende Flanke werden diese dann der Alu zur Verfügung gestellt also etwa so:
1 | _ _ |
2 | _| |__________| |_________ |
Das habe ich erstmal so übernommen (mein Takt hat halt nur 50:50), wengleich das sicher nicht nötig ist da in einem Prozess ja eh sich der Zustand eines Signals während der Ausführung nicht ändert, ich wollte aber wie gesagt jezt nicht an 10 Stellen debuggen sondern erstmal eine Lauffähige Version erstellen. Ich hatte auch im Design noch ein Register zuviel von daher hats eh nicht das gemacht was es sollte, es ist also möglich das ich noch den ein oder anderen "BUG" drinne habe :) @Christian R: Ich kann irgenwie immer beim Implement nicht finden wo die "reale" Taktrate angegeben wird, aber so lange er nicht meckert das die Timing Contraints nicht eingehalten werden hoff ich mal das das so in etwa hinkommt ;)
> Halt halt, nicht vorschnell Urteilen,... Ja, gut. Ich habe das auch schon gemacht für die Ankopplung eines SRAMs, aber gleich eine ganzes Design? > Ich kann irgenwie immer beim Implement nicht finden wo die "reale" > Taktrate angegeben wird Statische Timinganalyse heißt das Zauberwort. Es gibt Post Place Static Timing und Post Routing Static Timing Dort wird dir z.B. auch der kritische Pfad angegeben, der die Taktfrequenz beschränkt.
Hab jezt alles auf die Postive Flanke umgeschrieben, die große Verbesserung hat es jezt nicht gebracht. Post Place&Route sagt mir minimum period 19.993ns und der Kritische Pfad liegt irgnewo zwischen der UART Ausgabe und dem BlockRAM, also 50Mhz gerade noch so erreicht. Ich werd einfach mal noch etwas probieren ob ich noch was rausholen kann.
Hast du die 50MHz als Constrain vorgegeben? Wenn ja, dann hört der auf zu optimieren, sobald er die 50MHz erreicht hat, also bei knapp unter 20ns. Wenn du wissen willst, was das Design schafft, musst du mal 100MHz oder 150 oder so vorgeben, und schauen, wo er dann landet, wenn er sagt, dass er die Vorgabe nicht einhalten kann. Und dann gibts da ja eh noch massig Stellschrauben in den Optionen von Synthese, Place und Route. Da kann man im Ernstfall noch viel machen. Wenn das Design relativ schnell durchläuft und er die 50MHz schafft, ist aber noch Luft. Wenn´s knapp wird merkt man das an einem hohen Timing-Score (die Zahl in der Klammer bei "xx Unrouted (......)") wenn da in der Klammer eine hohe Zahl steht, hatte er massive Probleme beim Routen des Signals. Auch die Anzahl der Durchläufe sagt etwas über das Timing aus. Wenn´s eng wird, braucht der einige Routing-Durchläufe mehr, geht dann manchmal bis 20...25 oder sowas hoch und es dauert Stunden...
Vielleicht nicht mehr ganz zum Thema passend, aber Xilinx hat eine Application Note darüber, wie die Eingänge vom z.B. Spartan 3 mit 5V-Signale betrieben werden können. Xilinx schlägt hierzu tatsächlich Vorwiderstände vor, um den Stromfluss über die internen Schutzdioden auf ca. 1mA zu begrenzen. Grüße Gast
Ist bei meinem Board auch so geregelt für das 5V LCD Display.
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.